Create Kubernetes clusters with Kind, rootless Docker and rootless Podman

Kind is a tool which can be used for running local multi node Kubernetes clusters. Kind was primarily designed for testing Kubernetes itself and associated extensions, but may be used for local development or CI. With the Kind, you can spin up a multi node Kubernetes cluster in couple of minutes, perform your work and then wind it down. And nobody need to worry about the Bill! Starting with kind 0.11.0, Rootless Docker and Rootless Podman can be used as the node provider of kind. Its not running kubernetes in rootless mode as some component of kubernetes stack cannot run rootless yet, however it is certainly a step in that direction.

Read More »

Spinning up and Managing Pods with multiple containers with Podman

docker-compose is a popular choice to spin up applications needing multiple containers and run them. It allows to define the configuration in a simple yaml format and with few commands, you can create/manage all your application containers at once. Podman does not have a counterpart to the docker-compose command. There is a project in the works called podman-compose, which is supposed to do the same basic thing as docker-compose.

However Podman uses a concept called pods. Pods are a way of grouping containers together inside their own namespace, network, and security context. You can start and stop the whole pod at once to manage your application.

Read More »

Unsharing is Caring – User Namespace, Rootless containers and Security

Those who have been working with containers, have long been worried about security aspects associated with underlying containers. One of the vulnerability associated with containers is with running containers as root user. Containers have often required to do some privileged tasks such as mount filesystems, associated with packet route tables on the host networks etc which have historically needed privileged access on the underlying host machine. So this has allowed malicious actors to try to exploit vulnerabilities in containers host.

With rootless containers, we are slowly shifting to overcome this scenario. Rootless containers refers to the ability for an unprivileged user to create, run and otherwise manage containers. This term also includes the variety of tooling around containers that can also be run as an unprivileged user.

Read More »

Going Down the Rabbit Hole of Docker Engine… – dockerd

So you might ask – what does dockerd do? As its turns out, it does quite a lot of thing actually!! Things like networking, logging, docker-swarm, service discovery, DNS implementation, authentication, image management, storage management etc. It also exposes API to listen to requests from docker cli, you know the tool that decides how we interact with docker engine, in our daily lives. Someday these functionalities might be spun off to their own smaller counterparts, but for now these are all the things that dockerd does on a daily basis. Not only this, there are two different versions of docker engine – docker community edition (or docker CE) and docker enterprise edition (or docker EE).

Read More »

Going Down the Rabbit Hole of Docker Engine… – shim

So far we have discussed about runc, containerd in detail and their relative counterparts. We now need to take a look at the component called shim. The shim is integral to the implementation of daemonless containers and separating the low-level container runtimes such as crun or runc from high-level container runtimes such as containerd. As we discussed earlier that containerd uses runc to create new containers. In fact, it forks a new instance of runc for every container it creates. However, once each container is created, the parent runc process exits. This means we can run hundreds of containers without having to run hundreds of runc instances.

Read More »

Going Down the Rabbit Hole of Docker Engine… – containerd

As we discussed in previous posts, that Docker team re-factored, extracted and donated containerd as container runtime to the CNCF in Mar’2017. As of docker engine 1.11, docker engine switch to containerd as default runtime as well and it has been there since. containerd implements downloading images, managing them, and running containers from images. When it needs to run a container it unpacks the image into an OCI runtime bundle and shells out to runc to run it. Also, containerd is platform agnostic, so you can run it on pretty much any OS.

Read More »

Going down the Rabbit Hole of Docker Engine… – runc

As we have mentioned previously, runc was donated to OCI and have been managed separately since then. runc is located at GitHub at https://github.com/opencontainers/runc. It is the de-facto standard low-level container runtime. It is written in Golang based CLI tool for spawning, running and managing containers according to the OCI specification. And its very fast at that. To create a container, runc needs two things – a specification file named config.json and a root filesystem as per OCI specifications, both of these present inside a directory/bundle:

Read More »

Going Down the Rabbit Hole of Docker Engine…

Docker Engine from Docker, Inc has been at forefront of technology, when it comes to containers. It was so synonymous with containers, that docker and containers used to mean the same thing for a long time. It used to be so till the time Kubernetes and OCI came and confusion has taken over since. However, Docker Engine contains so many UX enhancements, that it feels like magic till today and still a recommended option for anyone starting to get their hands dirty in container technology. What we call Docker Engine or simply docker, is composed of many small components tied together like a car engine. Note that Docker Engine is further a small component in set of tools included in the Docker Desktop, which in itself is a separate world.

Read More »