In our Dockerless course we’ve discussed that there are many different bits and pieces that make up a container: cgroups, user namespaces, process namespaces, various security mechanisms like SELinux and Linux Capabilities and so on. To avoid people manually binding all of these things together, some smart folks came up with the concept of a container runtime.
Container runtime is basically a tool that starts and runs your containers. You tell the container runtime to run a new container, and it will prepare everything for you - it will create the namespaces, cgroups and other isolation mechanisms and it will start the process with all of the isolation layers around it.
Because the container process is fully isolated from the host where it runs, it needs the complete filesystem with all the binaries, libraries, config files and what not to be able to run successfully. Providing this filesystem is not exactly the job of the container runtime - you need a different set of tools for that.
As you can imagine, there could be many different ways to implement the container runtime, and even more ways to prepare a filesystem for the container. One company could build one tool to solve this problem, some other company could come up with another tool, while the open source community could implement a third one from scratch.
The outcome of this could be that multiple conflicting implementations of how to work with containers would co-exist, each of them incompatible with one another.
This would be similar to the situation we have with virtualisation. If you look around, you won't find many widely adopted open standards for virtualisation - every virtualisation technology is different and there is no open standard that would be identical for each of them.
On the other hand, look at the modern web technologies. Regardless of which browser and operating system you are using, each of them speaks the language of HTML, CSS and JavaScript, each of them works with exactly the same, standard HTTP requests, websockets and many many other components of the modern and open web.
In order to avoid virtualization case with containers, the Open Containers Initiative was created back in 2015 by Docker, CoreOS and other leaders in the container industry. The purpose of OCI is creating and maintaining a set of open standards around container formats and runtimes.
There are 3 main specifications that OCI provides:
- runtime-spec, which specifies how to create a container out of a container bundle
- image-spec, which defines everything related to container images
- distribution-spec, which defines an API protocol for the distribution of content - this covers, first and foremost, container registry and operations to pull and push images
These 3 specifications together ensure that regardless of which container tool you use, as long as they comply with the standard, they will work nicely together. For example, you can use one tool to build images and a completely different tool to run containers from these images.
You can also use one container runtime in production, as part of your Kubernetes cluster and another one on your laptop - again, it doesn't matter which one you use, as long as both of them follow the OCI standards.
Open Container Standard is what allows us to embrace the Dockerless world. It would be very hard to try any other container tools, if every image and every system would be Docker-specific, but luckily, they are not - thanks to the standards, we can jump between Docker and other tools without sacrificing anything.
In our Dockerless course, we also examine the image and runtime spec. The relationship between them is somehow curious. We start with the image spec and move down to the runtime spec, even though, as you will learn, you don't even need a container image to run the container.
Here' the same article in video form for your convenience:
.
Top comments (0)