▸Azure·Compute Gallery image definitions and versions
Azure Compute Gallery image definitions and versionshigh
Organized in galleries with image definitions and versioned images (Microsoft.Compute/galleries/images/versions), more structured than flat Glance images.
Supports global replication to regions with replicas (up to 100), ZRS storage, unlike OpenStack's store-only model.
Sharing via RBAC, community galleries, or direct share; requires gallery setup vs simple OpenStack image sharing.
New features like Trusted Launch only in Gallery, legacy managed images deprecated.
DigitalOcean classifies images into specific types (snapshots, backups, applications/1-Click, distributions, custom) rather than OpenStack Glance’s more generalized image model with visibility/properties/metadata.
Custom images are imported by providing a URL to a supported disk format (raw, qcow2, vhdx, vdi, vmdk) and have a documented max decompressed size (100 GB), which differs from typical OpenStack flows where images are uploaded directly to Glance and size limits are operator-defined.
DigitalOcean image operations are through /v2/images in their API, not Glance (and images also include DigitalOcean-specific fields like kind values base/snapshot/backup/custom/admin).
DigitalOcean's "applications" images (1-Click Apps/Marketplace style) are a first-class image type, whereas OpenStack commonly treats such preconfigured stacks as separate concerns (OpenTofu modules, Heat templates, app catalogs) rather than an image 'type'.
Images give each new instance the same starting point: operating system, tooling, and baseline configuration. The Images service (OpenStack Glance) lets you discover, register, and retrieve virtual machine images, upload and share image files, and supply the template Compute uses when it boots an instance.
Glance works with cloud-init and other platform services so metadata, distribution, and first-boot configuration stay consistent across projects and regions.
An image is a file that captures a disk state: typically an operating system plus optional applications and settings. You use it as a reusable template: each launch gets a fresh copy derived from that template, so teams avoid hand-building machines one by one.
The same image produces the same baseline on each instance, which simplifies patching strategies, compliance, and troubleshooting.
Image lifecycle: build a base image, launch instances, snapshot a known-good state, and promote it as the next baseline
The service supports storage of virtual machine images (including QCOW2), discovery and search, registration of new images, retrieval when Compute creates instances, sharing across projects, protections for image data, and integration with the rest of the cloud stack.
In practice you register images with metadata (name, format, size, and related fields) so they can be managed and found. Images can be distributed to multiple locations so instances can be placed closer to users or workloads. You create, list, update, and delete images through the Console, CLI, or API.
When you create an instance, you point Compute at an image; Compute pulls it from the Images service and boots from it. Snapshots of running instances are stored as images, so you can clone a point-in-time state or recover from backup.
Image signing and verification help you trust that an image has not been tampered with between upload and deploy.
Images work best with Linux distributions that ship cloud-init. Cloud-init runs on first boot to apply network settings, users, packages, and SSH keys from metadata. That is how key pairs and user data reach the guest without baking secrets into the disk image.
Reusability means one golden image can launch many instances with identical baselines. Portability means images can move between compatible OpenStack-style environments when you collaborate or migrate. Customization lets you build images that already contain your stack, so instances start closer to bootable.
Snapshots capture running state for backup, migration, or cloning. They trade storage for speed when you need a known-good copy of an instance.
An image is the template; an instance is a running VM created from that template. Each boot copies the image content into the instance disk (behavior may vary by image format and storage type), then cloud-init and your configuration finish the story. When you snapshot an instance, you produce a new image that encodes disk state at that moment: useful for golden images, migration, or rollback after risky upgrades.
That loop (build image, launch many instances, snapshot the best, promote the snapshot to the next baseline) is how teams standardize environments without manual cloning.
Prefer vendor-provided or well-maintained community images when you want predictable updates and security posture. Refresh custom images with patches on a schedule so new launches do not inherit old vulnerabilities. Trim unused packages and files to reduce size, storage cost, and boot time. Harden images (disable unused services, sensible defaults, monitoring agents) so launched instances inherit those choices.
Document what each custom image contains (packages, users, agents) so operators know which image to pick when requirements change.