How are Container Images Distributed?
Chronicles of Containers - Part 14
Howdy! 👋
We’re nearing the end of the ride of Container series. As such, given that Image distribution is one of the last steps you’d do, we are going to talk about it now :) Do keep in mind that from next week I’ll go back to C++ & Memory Management topic, so if that’s of interest - consider subscribing :)
Anyway, you know the drill already - bitesized graphic first and then more detailed explanation below.
(click on image to expand)
I usually like to say that Images have their own GitHub. Place where they are uploaded, mingled with other Images and eventually consumed by interested parties.
Those places are called Registries and, just like with your regular code, they can be either Public (e.g. Docker Hub) or private (e.g. Azure’s ACR offering stands for Azure Container Registry). There are also some nice on-prem solutions like Harbor.
Anyway, let’s see all this registry stuff in action. I’m going to pull an image of a Sample ASP.NET container and discuss what we can see here. Here’s the command:
ctr.exe images pull mcr.microsoft.com/dotnet/samples:aspnetappand the output:
What just happened? Well, we pulled an Image of ASP.NET app and we can actually run it and open it from a Web Browser. But that’s not really what I’m aiming at here. If you recall what we discussed in Deep-dive into exported Container Image content, I said that, among other things, everything inside the image is in Content-addressible storage (CAS). That means - all config files and all Image Layers are named after hashing their bytes. So what you see above is that we pulled bunch of Image Layers.
Let’s actually confirm that we do see them inside the image. First I’ll export the image content:
ctr.exe images export aspnet.tar mcr.microsoft.com/dotnet/samples:aspnetapp
tar -xvf aspnet.tar -C .\aspnetimageAnd the output does match what we see above (although in a bit different order, but you should be able to see every blob in there):
So what does this tell us? It tells us that pretty much all that Container Registry does is that it stores blobs of content, named after their hashes (i.e. Digests). Again, if you missed the article on Image Layers, I highly recommend you check it out afterwards, as it will give a sense to all of this.
What’s also cool about what we see above is that Registries actually CACHE the content! What that means is that if you create 10 containers out of ASP.NET base image, most of the layers (i.e. base image, .NET framework, etc.) will be stored JUST ONCE in the Registry! It’s cached based on it’s content! So you don’t really have to worry about storing tons of images - most of the stuff will be stored just once.
Lastly, let’s just take a sneap peak into this ASP.NET image, using the Dive tool:
dive.exe mcr.microsoft.com/dotnet/samples:aspnetapp
We can see that our image has 11 layers, and that total size of image is 400MBs. Not great, but not terrible either, considering that you pretty much have a Windows OS and .NET framework inside!
And that’d be about it for today’s session. If you want to learn morea about Image Distribution, OCI Distribution Specification has you covered!
Next time I’m likely going to go back to C++ & Memory Management, but do know that I’m planning on publishing one Mega-Article that combines all bitesized images that I created on Containers!
In the meantime, if you enjoyed this article, do consider sharing it and subscribing if you haven’t already :) Thanks for reading!
Other interesting articles in the Container series: