We all know how docker has taken the world of containers but it’s not perfect either. Docker has its own flaws and problems.
Docker architecture is Flawed - The first problem when people talk about docker is about its architecture. It is fundamentally flawed. What exactly does this mean?
in Linux, Init is a abbreviation for initialization. This is a daemon process which starts as soon as the machine starts or boot up. This process runs until the machine is shutdown. This is the first process that starts and also is responsible for starting other process and thus becoming the parent for all other process that starts. This will typically be assigned “pid=1”. The problem with this intialization process is that it starts processes in a serial order. It starts one tasks only after the last task startup was successful and it is loaded into the memory. This can result in longer startup.
There are many works done in enhancing the init process and they came up with the systemd. Though the systemd was not designed for speed but to start things faster ,cleaner and nicer.
Now the docker problem, When ever systemd start a service it creates a series of cgroups. When the same service spawns any child process , they stay in that same cgroup thus blocking them with the restrictions provided by that cgroup. This way systemd will always know what child process are created ,how much resources they are using etc. If that parent service dies all clean up can be done easliy regardless of the parent as systemd know all details about that parent and children.
Docker breaks all this by making a RPC call to the docker daemon when a “docker run” command is triggered. When this call is made, docker spawns a child process that becomes the PID 1 of the container. As soon as the docker client makes the RPC call , systemd will lose track of whats going on as the container is spawned in a different cgroup. this cgroup is different from the docker client cgroup which is being handled by the systemd. Hence systemd cannot manage the docker containers since they are trigged by a docker daemon and running in a different cgroup.
Hence docker is called as flawed. So what is Rkt and how is that different?
rkt is a container system developed by CoreOS as a light weight and secure alternative to docker. it is build based on the Open Container standard known as “App Container” or “appc” specification. The image build on this specification are protable across many container systems that follow the same standard.
How is Rkt different than this?
No Daemon - Rkt from CoreOs handles the setting up of the resources for the containers and then delegates everything to the systemd-nspawn to do the rest.
No Daemon - Rkt from CoreOs handles the setting up of the resources for the containers and then delegates everything to the systemd-nspawn to do the rest.
Protable image format - Since Rkt uses the “appc” specification it is portable to other container technologies that uses the same “appc” specification.
Light weight - Similar to Docker or runC, rkt also minimizes the number of process, resource utilization. It is easier to put all Application depdencies into a small image and ship that every where
Secure by Design - In Docker, if a user break out of a container using a kernel exploit, the attacker can control the whole machine where the container is started. An Additional security is required to handle this situation in docker. Rkt run containers as un priviliged users so that even some thing breaks out , they cannt affect other container or take control the underlying machine.
Rkt uses cryptographic signature checks on downloaded images so that only trustered containers are allowed to start and run.
More to Come,Happy learning :-)
