We often use Docker when we talk about containers, similar to we use ‘Coke’ when we talk about carbonated soft drink. We all know that Coke is not the only brand that sells carbonated soft drink. Same to Docker, it is not the only one that does containers.
Why not Docker
Docker has been around for quite a while and it is a good tool. It is one of the very first thing I always tell junior developers to study when they start their first job from school.
Recenly, I feel annoying installing Docker on my different machines that I need to switch back and forth. Due to its big installation file so it is heavy weight. I normally use Docker to just build images and deploy workloads on my Kubernetes clusters and use it for nothing else.
I knew about podman and skopeo that may do the job I need but never have a chance to try them out until I stumble upon this blog from Martin Heinz.
You Don’t Have to Use Docker Anymore
Docker is not the only containerization tool out there and there might just be better alternatives…
It is pretty long one but good to read through. But if you don’t have time, here is my summary:
- Docker is a monolithic tool that tries to do everything. But the functionality can be divided into several components:
- Container Engines is a tool providing UI for working with images and containers (excluding running containers)
- The most prominent competitor to Docker is Podman, developed by Red Hat.
- Podman doesn’t need daemon to run and also doesn’t need root privileges which has been long-standing concern with Docker.
- Podman can also run pods which make it easier to later migrate the workloads to Kubernetes.
- Podman provides the exact same CLI commands as Docker as they are implemented using the same standard defined by the Open Container Initiatives (OCI).
- There are other Container Engines but can be considered as dead-end e.g. LXD, CRI-O, rkt (rocket)
- Buildah is another tool developed by Red Hat and it comes along with Podman and is called when you run
- Buildah is daemonless and rootless and produces OCI compliant images so it’s guaranteed that your images will run the same way as the ones built with Docker.
- Buildah is also able to build images from
- Buildah are user specific, so you will be able to list only images you built yourself.
buildahCLI is superset of commands included in
podman build. Learn more about the differences between Podman and Buildah from this article.
- Another tools for building images are Google’s Kaniko, Docker’s buildkit, OpenShift’s Source-To-Image (S2I), Jib, and Bazel.
- Container Runtime is responsible for running containers and is one part of the whole container lifecycle/stack, which you will most likely not going to mess with.
- runc is the most popular container runtime created based on OCI container runtime specification. It’s used by Docker (through containerd), Podman, and CRI-O (default for OpenShift cluster).
- Alternative to runc is crun which is a tool developed by Red Hat and fully written in C (runc is written in Go). Considering that it’s Red Hat product, we might eventually see as default for Podman or CRI-O.
- Last one to mention is containerd which is a CNCF graduating project and acts as an API facade for various container runtimes. It’s used by Docker Engine, Google Kubernetes Engine (GKE), IBM Kubernetes Service (IKS).
Image Inspection and Distribution
- Skopeo is made by Red Hat and it’s an accompanying tool for Buildah, Podman.
- Skopeo is also able to copy images using
skopeo copywhich allows you to mirror images between remote registries without first pulling them to local registry.
- Dive is another tool for inspecting, exploring, and analyzing images. It’s little more user friendly and provides more readable output.
Install podman, buildah, and skopeo
Now, it’s time for hands-on. Let’s install these three tools from Red Hat. Please note that here I tried on Ubuntu 18.04 so the steps may be different on other distros.
In order to map container ports to host ports, you also need slirp4netns. It must be found within PATH variable so check it with command
which slirp4netns. If not found, install using the script below.
Add it to PATH variable, if you haven’t done so.
Run a new httpd container and forward port 8080 to host.
If you get the error
ERRO unable to write pod event: "write unixgram @00018->/run/systemd/journal/socket: sendmsg: no such file or directory", you seem to run podman in WSL2. Then you need to use the flag
--events-backend=file to suppress this error.
Note: Podman will search in default registries if you don’t specify full image name. The default registries are defined in
/etc/containers/registries.conf. You can use command
podman infoto see the list of registries.
Check container status.
Try accessing the application at http://localhost:8080.
Clone repository https://github.com/pacroy/flask-app and use buildah to build the image from the Dockerfile.
List local images.
Run the container
Try accessing the application at http://localhost:5000.
You can inspect properties or configuration of an image on a remote repository using skopeo.
Note: If you don’t have jq installed, you can download it from https://stedolan.github.io/jq/ and add it to PATH variable.
You can also inspect a local image.
Next, we will push the built image to Docker.io. Create a new repository on Docker Hub first if you haven’t done so. Login and push the image, just like you use Docker.
Then, we will copy the image from Docker.io to Quay.io. Create a new repository on quay.io first and then copy the image from docker.io.
Note: You may want to use access tokens (aka. robot account in quay.io) instead of password.
Now, I hope you see that we can use podman, buildah, and skopeo for working with containers and images like we use Docker. There are also some useful features that does not even exist in Docker CLI that you may love.
Next time, when you feel overwhelm with Docker installation then now you know an alternative option.