Docker != Containers
Chronicles of Containers - Part 2
Hey there!
There has been a slight delay in production of these Newsletters, and this has been due to a fact that I got quite enrolled in a lot of conferences in the past period, which left almost no time for BitesizedEngineering. Bummer! Good news is - I’m done (for a while) with public speaking and will fully focus on this Newsletter :)
So, let’s discuss the Docker and the fact that people often confuse Docker & Containers. First the infographic and then the text description:
Many of us use "Docker" and "Containers" interchangeably, as if Docker is THE ONLY Containerization technique. Hint: it is not. It was (and still is) just the most popular one. But there are others (e.g. rkt, podman, etc.).
If you are enthusiastic enough, you could start a container without Docker (or any other engine). Totally doable. But it's pain in the butt. If you want to experiment - go and look up dockerd, hcshim, runc, etc. Those are all the low-level tools that Docker builds on top of to make a way smoother experience. It's same as with Git really - you - on a very basic level, Git is really just a key-value storage. And you could do all of the Git-low-level stuff without high-level commands (like commit for example). But unless you are trying to build a more efficient and user-friendly version - you wouldn't do it; because, why would you, right?
Whole thing is, as Ivan Velichko (guy behind iximiuz dot com) says - Docker is a behemoth. It's a huge pack of tons of interconnected things that both make for a really nice experience (end-user really needs just to define a Dockerfile and execute "docker run" without much thinking of everything else). On the other hand, it hides so much that happens in the background that people rightfully assume that 'containers are simple to do'. They aren't; or at least - they weren't. But then OCI happened.
One thing that is not obvious at a first sight is that, back in the day, there was no standard on how you build containers. There were tools that you could use, but there was no standard. And that's precisely why Open Container Initiative (OCI) was established back in 2015. We'll discuss this way more in future articles, but what you need to know is that OCI defines three specifications - Runtime Spec which standardizes the way we start & run containers, Image Spec which defines how you build (or bundle) Images and Distribution Spec which specifies how you can distribute your Images and make it easy for others to use.
Great thing about any standard is that, once you have it, many others can attach and build up on it, while at the same time ensuring that it's compliant with all other tools (and OS') that follow the same. But this will be a topic of our next #BitesizedEngineering article.
Stay tuned!
Other articles in the Container series:
Containers vs VMs (Part 1 of the series) - intro to ever-lasting debate of whether container is a lightweight VM.
Container is not a VM - and what that really means? (Part 3 of the series) - a glimpse into some of the main differences between the two.
Containers are like The Truman Show (Part 4 of the series) - some words on the fact how Containers see themselves (and what really happens on the outside).