What is an OCI Image

• Image spec: manifest + config + layers (tar.gz each)
• Distribution spec: HTTP API for push/pull with registry
• Runtime spec: how runtime starts the container (runc, crun implementations)
• Multi-arch: manifest list for x86_64 + arm64 + s390x
• Artifacts: not only images — Helm charts, SBOMs, policies — all in OCI format

# Inspect OCI manifest
docker manifest inspect nginx:latest
# Or with skopeo:
skopeo inspect --raw docker://nginx:latest

# Multi-arch build
docker buildx build --platform linux/amd64,linux/arm64 -t myimage:v1 .

# Push Helm chart as OCI
helm push mychart-1.0.0.tgz oci://ghcr.io/me/charts

• Helm
• K8s Operator

The OCI image format is a standardized method of packaging applications and their dependencies into a single, portable unit. An OCI image consists of multiple layers, each represented as a tarball, along with a JSON manifest that describes the image's structure and configuration.

Each layer in an OCI image is a file system change, which means that the final image is built incrementally. The layers are stacked and can be reused across different images, optimizing storage and download times. The config.json file within the image specifies runtime parameters, such as environment variables, entry points, and working directories.

Here's a breakdown of the key components of an OCI image:

• Layers: Each layer is a compressed tarball containing filesystem changes.
• Manifest: A JSON file that lists the layers, their digests, and the configuration data.
• Config: A JSON file that provides the runtime configuration for the container.
• Digest: A unique identifier (SHA256) for each layer and the image as a whole, ensuring integrity and versioning.

By adhering to the OCI specifications, developers can ensure compatibility across various container runtimes and registries, promoting a more unified and interoperable ecosystem.

Creating and distributing OCI images is a straightforward process that can be accomplished using various tools like buildah and podman. Below are practical examples of how to build, tag, and push OCI images to a registry.

1. **Building an OCI Image**: You can use buildah to create an OCI-compliant image from a Dockerfile:

buildah bud -t myapp:latest .

This command builds an image named myapp:latest based on the Dockerfile in the current directory.

2. **Pushing to an OCI Registry**: To push the built image to an OCI-compatible registry, use the following commands:

buildah push myapp:latest oci:myapp-oci:latest

This command pushes the image to the local OCI store. To push it to a remote registry, you would first need to tag it appropriately:

buildah tag myapp:latest myregistry.com/myapp:latest
buildah push myregistry.com/myapp:latest

3. **Using Podman**: If you prefer using podman, you can build and push images similarly:

podman build -t myapp:latest .
podman push myapp:latest myregistry.com/myapp:latest

By following these commands, developers can efficiently build and distribute OCI images, ensuring they meet the required standards for compatibility across various platforms.

While both OCI images and Docker images serve the same primary purpose—packaging applications and their dependencies—there are important distinctions between the two formats that developers should be aware of.

1. **Standardization**: OCI images are standardized under the Open Container Initiative, which provides a set of specifications for container image formats and runtimes. Docker images, while widely used, are not strictly compliant with these standards. This means that OCI images are designed to be compatible across different container runtimes, such as containerd and CRI-O.

2. **Image Composition**: Both OCI and Docker images consist of multiple layers and a manifest file. However, the specifications for these components differ slightly. For instance, the OCI image manifest includes an annotations field, which allows for additional metadata, while Docker images may not support this feature.

3. **Runtime Compatibility**: OCI images are compatible with any container runtime that adheres to the OCI specifications. Docker images can be run using Docker's runtime but may require conversion to OCI format for use with other runtimes. This can lead to a lack of portability for Docker images in multi-runtime environments.

4. **Distribution**: OCI images can be distributed through any OCI-compliant registry, such as Docker Hub, Google Container Registry, or GitHub Container Registry. Docker images are typically pushed to Docker Hub by default, which may not be suitable for all use cases.

In summary, while Docker images have been a cornerstone in the container ecosystem, OCI images provide a standardized and interoperable solution that enhances portability and compatibility across diverse environments.