Storage Azure

MicroCeph 19.2.3 on Ubuntu 24.04 on Azure User Guide

Last updated: 2026-08-10 | Product: MicroCeph 19.2.3 on Ubuntu 24.04 on Azure

Overview

MicroCeph is Canonical's distribution of Ceph built for single-node and edge deployments. It packages the full Ceph storage engine — object, block and file storage on a self-healing, strongly-consistent cluster — as a single snap that stands up a complete cluster on one machine. This image ships MicroCeph 19.2.3 (Ceph "Squid") and turns a single Azure VM into a working, S3-compatible object store within minutes of launch.

At first boot the appliance bootstraps its own single-node cluster, provisions loop-file-backed OSDs so it runs standalone with no extra block devices, and enables the RADOS Gateway (RGW) as a TLS S3 endpoint. It reaches Ceph HEALTH_OK out of the box. Point any S3 client, SDK or backup tool at it and start creating buckets and objects.

Security by design

The only two surfaces this appliance exposes are SSH and the S3 endpoint (TLS 443). There is no web console, no management port, and no cleartext object port.

The cluster is bootstrapped per-VM, never at build time. microceph cluster bootstrap binds the Ceph monitor to the VM's own address and generates the cluster's auth keyrings. Doing that during the build would bake a shared cluster key and the build VM's IP into every image. Instead, the shipped image carries only the installed snap; each VM bootstraps its own cluster and mints its own secrets on first boot.
No baked S3 keypair. On first boot every instance generates a fresh S3 access key and secret key, creates the RGW admin user, and writes them — together with the cluster FSID and the S3 endpoint URL resolved to this VM's own public IP — to a root-only file. No two machines share a secret and there is no default to guess.
TLS only. The S3 endpoint is served over HTTPS on port 443 using a per-VM self-signed certificate generated at first boot. When a certificate is supplied MicroCeph binds RGW on 443 only — there is no cleartext listener.
Administration is over your own key-based SSH. There is no product login to harden.

What is included:

MicroCeph 19.2.3 (Ceph "Squid") from the squid/stable snap track, pinned/held so an unattended refresh can never move your storage cluster to a new Ceph major
A single-node cluster (mon, mgr, 3 OSDs) bootstrapped fresh per-VM, reaching HEALTH_OK
The RADOS Gateway S3 object endpoint on TLS 443, with per-VM keys and a per-VM certificate
microceph-firstboot.service — bootstraps the cluster, provisions OSDs, enables RGW and mints per-VM credentials
Ubuntu 24.04 LTS base, fully patched, unattended security upgrades enabled
Licences shipped at /usr/share/doc/cloudimg/ (MicroCeph AGPL-3.0; Ceph LGPL-2.1)
24/7 cloudimg support, 24h response SLA

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet/subnet. Standard_B2s (2 vCPU, 4 GB RAM) is the recommended and proven size — bootstrap, three loop OSDs, the S3 gateway and a full round-trip all run comfortably within it. For larger object capacity, grow the OSD size/count or attach a dedicated Azure data disk (see Scaling capacity).

Step 1: Deploy the Virtual Machine

Option A: Azure Portal

Search the Marketplace for MicroCeph Single-Node Object Storage on Ubuntu 24.04, choose your VM size and provide your SSH public key. Attach a network security group that allows:

TCP 22 (admin SSH) from your management network only.
TCP 443 (the S3 endpoint) from the clients that will use the object store.

Option B: Azure CLI

RG="microceph-prod"; LOCATION="eastus"; VM_NAME="microceph-01"
GALLERY_IMAGE_ID="/subscriptions/<sub-id>/resourceGroups/azure-cloudimg/providers/Microsoft.Compute/galleries/cloudimgGallery/images/microceph/versions/<version>"
SSH_KEY="$(cat ~/.ssh/id_rsa.pub)"
az group create --name "$RG" --location "$LOCATION"
az network vnet create -g "$RG" --name microceph-vnet --address-prefix 10.80.0.0/16 --subnet-name microceph-subnet --subnet-prefix 10.80.1.0/24
az network nsg create -g "$RG" --name microceph-nsg
az network nsg rule create -g "$RG" --nsg-name microceph-nsg --name allow-admin-ssh --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp
az network nsg rule create -g "$RG" --nsg-name microceph-nsg --name allow-s3 --priority 110 \
  --source-address-prefixes "<your-client-cidrs>" --destination-port-ranges 443 --access Allow --protocol Tcp
az vm create -g "$RG" --name "$VM_NAME" --image "$GALLERY_IMAGE_ID" --size Standard_B2s \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name microceph-vnet --subnet microceph-subnet --nsg microceph-nsg --public-ip-sku Standard

Step 2: Connect via SSH

ssh azureuser@<public-ip>

First boot bootstraps the cluster and mints your keys; it typically completes within two to three minutes of the VM starting. You can watch it with journalctl -u microceph-firstboot.service -f.

Step 3: Confirm the cluster is healthy

sudo microceph.ceph -s
sudo microceph.ceph health

microceph.ceph -s shows the cluster identity, health: HEALTH_OK, one mon and mgr, three OSDs up and in, and the RGW daemon active. The screenshot below shows the installed version and a healthy single node.

Terminal showing microceph reporting Ceph version 19.2.3 squid stable, and microceph.ceph -s reporting health HEALTH_OK with one monitor and manager, three OSDs up and in, the RGW daemon active, and all placement groups active and clean on the single node

Step 4: The S3 gateway

The RADOS Gateway serves the S3 API over TLS on port 443. Confirm it is listening and healthy:

sudo systemctl is-active snap.microceph.rgw.service
sudo ss -ltnp | grep radosgw
curl -sk https://127.0.0.1/ -o /dev/null -w 'RGW HTTPS status: %{http_code}\n'

The gateway listens on :443 only; there is no cleartext port. The certificate is a per-VM self-signed certificate whose subject alternative names include this VM's public and private IPs — trust it in your client's CA store, or pass the client's --no-verify-ssl / equivalent for development.

Terminal showing the RGW service reported active, radosgw listening on TCP port 443, an HTTPS request to the gateway returning status 200, and the per-VM self-signed certificate subject and subject alternative names covering the VM's public and private IP addresses

Step 5: Retrieve your per-VM S3 credentials

Every instance writes its own S3 credentials to a root-only file at first boot:

sudo cat /root/microceph-credentials.txt

It contains S3_ENDPOINT_URL (this VM's public IP, over HTTPS), S3_ACCESS_KEY, S3_SECRET_KEY, the RGW user (cloudimg) and the cluster CEPH_FSID. These are unique to this VM — nothing is baked into the image.

Terminal showing the per-VM MicroCeph credentials file with the S3 endpoint URL pointing at the VM's own public IP over HTTPS, the S3 access key, the secret key redacted, the RGW user cloudimg and the cluster FSID, followed by microceph.ceph df reporting the cluster raw and per-pool capacity

Step 6: Your first S3 round-trip

A shipped helper proves the object store works end to end — it reads the per-VM keys, creates a bucket, writes an object, reads it back and verifies the bytes:

sudo /usr/local/sbin/microceph-s3-roundtrip.py

It prints S3_ROUNDTRIP_OK. This is the same proof run at build time and again by the cloudimg smoke gate on a fresh VM, so what you receive is verified working, not merely "the port is open".

Terminal showing a full S3 round-trip against the MicroCeph gateway using the per-VM keys: making a demo bucket, uploading an object, listing the bucket, and downloading the object back with its contents intact

Step 7: Use it from your own machine

The endpoint speaks the S3 API, so any S3 client works. With the AWS CLI, using the keys from /root/microceph-credentials.txt and the VM's public IP (self-signed cert, so --no-verify-ssl for development):

$ export AWS_ACCESS_KEY_ID=<s3-access-key>
$ export AWS_SECRET_ACCESS_KEY=<s3-secret-key>
$ aws --endpoint-url https://<public-ip> --no-verify-ssl s3 mb s3://my-bucket
$ aws --endpoint-url https://<public-ip> --no-verify-ssl s3 cp ./report.pdf s3://my-bucket/
$ aws --endpoint-url https://<public-ip> --no-verify-ssl s3 ls s3://my-bucket

For production, add the per-VM certificate (/etc/cloudimg/tls/rgw.crt) to your client's trust store instead of disabling verification, or place the endpoint behind your own DNS name and certificate.

Scaling capacity

The default cluster uses three 4 GiB loop-file OSDs on the OS disk — ample for development and testing. To grow capacity:

Add more loop OSDs: sudo microceph disk add loop,10G,3 adds three 10 GiB OSDs (ensure the OS disk has room, or attach a larger OS disk).
Use a real Azure data disk (recommended for production): attach an empty data disk to the VM, then add it as an OSD with sudo microceph disk add /dev/disk/azure/scsi1/lun0 so Ceph stores data on dedicated block storage rather than loop files.

Check capacity any time with sudo microceph.ceph df.

Managing the service

sudo microceph.ceph -s                 # cluster status and health
sudo microceph status                  # microceph node/service view
sudo systemctl restart snap.microceph.rgw.service   # restart the S3 gateway
sudo microceph.radosgw-admin user info --uid=cloudimg   # inspect the RGW user

To create additional, scoped S3 users: sudo microceph.radosgw-admin user create --uid=<name> --display-name=<name> returns a fresh access/secret keypair for that user.

Server Components

MicroCeph 19.2.3 — Ceph "Squid" packaged as a single snap (squid/stable, held)
Ceph mon + mgr — the single monitor and manager for the cluster
3 OSDs — loop-file-backed object storage daemons providing a 3-replica cluster on one host
RADOS Gateway (radosgw) — the S3-compatible object endpoint on TLS 443
microceph-firstboot.service — per-VM bootstrap, OSD provisioning, RGW enable and key minting

Filesystem Layout

/root/microceph-credentials.txt — per-VM S3 keys, endpoint URL, RGW user, FSID (0600 root:root)
/etc/cloudimg/tls/rgw.crt, rgw.key — per-VM RGW TLS certificate and key
/var/snap/microceph/common/ — MicroCeph state, OSD loop files and data
/usr/local/sbin/microceph-firstboot.sh — the first-boot bootstrap script
/usr/local/sbin/microceph-s3-roundtrip.py — the S3 round-trip proof
/usr/share/doc/cloudimg/MICROCEPH-COPYING.txt — the AGPL-3.0 licence text

Persistence, first boot and updates

The cluster, its data and the per-VM credentials persist across reboots on the OS disk. First boot runs once (guarded by /var/lib/cloudimg/microceph-firstboot.done) and never re-bootstraps a live cluster. OS security updates are applied automatically by unattended-upgrades; the MicroCeph snap is held so it will not move Ceph majors unattended — upgrade Ceph deliberately with sudo snap refresh microceph --channel=<track> after reviewing the MicroCeph release notes.

Troubleshooting

First boot still running: journalctl -u microceph-firstboot.service -f — bootstrap plus OSD provisioning takes a couple of minutes on first boot.
HEALTH_WARN briefly after boot: placement groups settle for a short time after the OSDs come up; it converges to HEALTH_OK within a minute.
S3 client TLS errors: the certificate is self-signed — trust /etc/cloudimg/tls/rgw.crt or use your client's insecure/no-verify flag for development.
Cannot reach the endpoint remotely: confirm the NSG allows TCP 443 from your client and that you are using https:// and the VM's public IP.

Security Recommendations

Scope the NSG so TCP 22 is reachable only from your management network and TCP 443 only from your S3 clients.
Replace the self-signed certificate with one issued for your own DNS name for production use, and add clients' trust accordingly.
Rotate the RGW keys periodically with sudo microceph.radosgw-admin key create/rm and create per-application users rather than sharing the cloudimg admin keypair.
Keep the OS current (unattended-upgrades is enabled) and review MicroCeph releases before refreshing the snap.

Support

cloudimg provides 24/7 support with a 24-hour response SLA for this image. This is a repackaged open source software product with additional charges for cloudimg support services. MicroCeph is distributed under the GNU Affero General Public License v3.0 and Ceph under the GNU Lesser General Public License v2.1; both are trademarks of their respective owners. Use of the names does not imply affiliation or endorsement.