🎉 CNDO #30: One Registry To Rule Them All?

A Platform for Platform Teams | Uffizzi

Platform teams need control. Dev teams need autonomy. Uffizzi provides a multi-tenant, Kubernetes-native foundation that accomplishes both.

Customer logo - TilledUffizzi

🗓️ What's new this week

🔴 Live show: Everything AWS Lambda Containers with Ken Collins (Ep 233)

On this week's livestream, Nirmal and I talk to our guest Ken Collins about all things Lambda and digging into the details of running containers in serverless. Ken is a AWS Serverless Hero and a Principal Engineer at Custom Ink.

👨‍💻 OCI Registries for Everything?

Docker didn’t just invent the modern container; they also created the artifact store for container images they called registry. Quickly, the registry code was open-sourced as "distribution" in 2014 and eventually standardized as the OCI Distribution Specification in 2018, alongside the OCI image and runtime specifications.

GitHub - distribution/distribution: The toolkit to pack, ship, store, and deliver container content

The toolkit to pack, ship, store, and deliver container content - GitHub - distribution/distribution: The toolkit to pack, ship, store, and deliver container content

GitHubdistribution

We all know this as various casual terms like "Docker Registry", "OCI Registry", or just an "Image Registry." They tend to be "set and forget" file storage systems that are the bridge between source code, CI, and your servers that run containers.

You may not have thought much about the registry you’re using, but that's about to change (if it hasn't already for you).

OCI-compatible registries (in all their forms) are everywhere, and many organizations use multiple registries in the cloud, on-prem, and in their CI. No big deal; OCI registries are just a new type of artifact store for a new kind of artifact. Many of us already have one or more artifact stores in our organization. But now we have a N+1 problem where we're expected to run an artifact store for every package format we want to support.

Doh! We just broke a rule of mine: "Don't install a new solution similar to the old solution without a plan to phase out the old." - Says Me

Many of us have more of these "file and metadata" storage systems floating around. The core problem is that we were building and using artifact-specific storage systems. Sure, a few proprietary solutions run many different unrelated storage APIs on a single tool for all the various package and artifact types, but that's not ideal for us or the industry, and that's also not the "CNCF way." We need a single artifact storage standard flexible enough to be used by most of the tools we have today with artifact needs.

The OCI Distribution standard and our OCI registry products are likely a reasonable solution for more than just container images. Many tools are also starting to use OCI registries to store their non-image artifacts.

Helm was the tip of the iceberg

Likely, your first use of an OCI registry for something other than a container image was in storing Helm charts in an OCI registry repo. There was the old proprietary way that Helm had in v1 and v2 of sticking Helm charts in a web server, then starting in Helm v3.5 we were given a new storage option of using a registry via Helms's new OCI artifact support.

Many other tools also support this idea, including security tools storing SBOMs, image-signing, Kubernetes security profiles, OPA policies, and even non-container-related artifacts like WASM modules and Homebrew packages.

In Next week's newsletter, I discussed what's happening with OCI Registry 1.1 in 2023.

🗓 Next big thing️

I'm creating my two talks for DockerCon in a month!

🐦 Tweet of the week

Quite a thread on rightsizing your K8s clusters through estimation tools from Daniele at learnk8s.

👀 In case you missed last week's newsletter

Did you miss last week's newsletter? We celebrated passing 300,000 students in our Docker Mastery course on Udemy. I tell the story of how it all started. Read it here.