Uffizzi provides a multi-tenant Kubernetes-native foundation for platform teams. Every engineer gets self-service, sandboxed virtual clusters. It runs on our infrastructure or yours.
Spin up your cluster in under a minute on the Free Starter Tier at uffizzi.com
🗓️ What's new this week
🔴 Live show: Multipass Guide for Docker and Kubernetes (Ep 235)
On this week's livestream, Nirmal and I are joined by Multipass engineer Chris Townsend. We'll cover how to use Multipass as a local virtual machine manager for Ubuntu, Docker, Kubernetes, and more!
👉 Ensure you’re ready for OCI's future
This is Part 3 of my multipart series (Part 1, Part 2) on the upcoming OCI Distribution and Image specification updates.
Two weeks ago, in Part 1, I wrote about the growing need for a universal deployment artifact solution and how the OCI is updating its specifications for container image registries to accommodate these new “artifact” data types.
So, what should we registry users do to prepare for the coming changes in OCI specs? In short, nothing. All your tools should work today and will just get better with 1.1. 😅
Remember that OCI is just a specification. You fine readers don’t use OCI directly; you use a registry or CLI that adheres to the OCI Distribution specification. For years, that has held steady at a ~1.0 release. OCI has a great, short post summarizing technical changes in OCI Image 1.1 and Distribution 1.1 specifications. Over the years of the OCI working toward this update, there have been many meetings, working groups, and PRs. Most tools implementing OCI specs have been following those plans and working to add planned changes in preparation for a General Availability release of the specs. This means within days or weeks of that release, we should start hearing about tools and services that are 1.1 compliant.
Since 1.1 is a minor release, and the significant changes are all done with backward compatibility in mind, I would not expect any existing tools to break if you’re using a 1.0 tool with a 1.1 registry or vice versa.
How can I use OCI artifacts today?
Remember the “two types” of artifacts I described in last week's newsletter?
The first type, which is “image-related artifacts” (SBOMs, providence, scans, and signatures), have an inconsistent implementation with OCI registries today and will likely need an update after OCI Distribution 1.1 is released (GA) before they will work well across all registries with proper registry-aware references (Referrers API and the artifactType metadata). I plan to do a breakdown of these tools in a future newsletter (Cosign, Notation, BuildKit, Trivy, Syft, Grype, etc.), but the idea here is we won’t need an additional tool like the ORAS CLI to upload these artifacts in a "1.1 spec-friendly way".
Once 1.1 lands, I hope these tools that already support container images will get updated to package their output into an OCI Distribution 1.1 artifact and co-locate them with the image they came from for easy finding.
But the 2nd type, the “unrelated artifacts” that don’t need special registry metadata to link two artifacts together… are the ones we can use freely today! Yes, the APIs will change with how they talk to registries and store data, but that shouldn’t affect much for us users of the tools that store and use artifacts. Various registries have added UI support for specific artifact types, including Docker Hub identifying a few types by name and Harbor identifying types by their brand logo.
Here is a partial list of those "2nd type" tools
In my experience, most hosted registries allow these types, but not always. YMMV.
🐳 For the pure Docker fans out there, you can…
- Run Wasm Modules on an existing
wasi/wasmruntime without needing a full container image. - (Coming soon as “publish”) Store Docker Compose YAML as its own OCI artifact. Ideally, we’ll be able to run a project from a
compose upwithout needing to clone a repo. - Push and pull Docker Volumes with the Docker Desktop extension or my simple shell script.
⎈ For the Kubernetes clusters and workloads, you can…
- Store Helm Charts in an OCI registry directly from the helm CLI.
- Deploy Gatekeeper, Kyverno, and Kubewarden policies to Kubernetes via OCI registries.
- Use the Kubernetes Security Profiles Operator (SPO) to deploy seccomp, SELinux, and AppArmor profiles to your clusters through SPO’s built-in support for OCI artifacts.
- For GitOps (maybe we call it ArtifactOps in this case), you can use Flux to pull your desired state from registries rather than git. Read and watch through the progress the Flux team has made so far in implementing OCI artifact support. They even have a cheatsheet.
- For Tekton, you can use OCI artifacts for Bundles and Chains.
- Control Falco rules with falcoctl on Linux and Kubernetes by distributing them through OCI artifacts.
🌍 And then there’s everything else…
- I’ve mentioned Homebrew as an early adopter of OCI artifacts for all your tools, serving through GitHub Container Registry at a rate of over 500 terabytes monthly. Here’s a breakdown of how their packages look in the manifest metadata.
- Store Dev Container Features (
devcontainer.json) as OCI artifacts. - Use IBMs package manager to package and deploy software to z/OS.
- Maybe someday, rpm's via OCI artifact.
- Check out the list of tools using ORAS. Here's an incomplete list of tools conforming to the Distribution spec.
I hope you enjoyed this 3-part series on the OCI updates!
👀 In case you missed last week's newsletter
Did you miss last week's newsletter? Read it here. I continued my blog about OCI registries and focused on how artifacts are changing the OCI registry. I covered:
👉 The beginning of the OCI artifact sprawl
👉 First use case: Image-manifest-adjacent artifacts
👉 Second use case: General artifact support