Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
Jib is another tool by Google, specifically for building Java images. It includes Maven and Gradle plugins, which can make it easy for you to build images without messing with Dockerfiles.
Kaniko is meant to be run as an image, using gcr.io/kaniko-project/executor, which makes sense for Kubernetes, but isn't very convenient for local builds and kind of defeats the purpose as you would need to use Docker to run Kaniko image to build your images. That being said, if you are looking for tool for building images in your Kubernetes cluster (e.g. in CI/CD pipeline), then Kaniko might be a good option, considering that it's daemonless and (maybe) more secure.
Last but not least is Bazel, which is anoooother tool by Google. This one is not just for building container images, but rather a complete build system. If you just want to build an image, then diving into Bazel might be a bit of an overkill, but definitely a good learning experience, so if you're up for it, then rules_docker section is a good starting point for you.
One alternative to runc is similarly (and confusingly) named crun. This is tool developed by Red Hat and fully written in C (runc is written in Go). This makes it much faster and more memory efficient than runc. Considering that it's also OCI compliant runtime, you should be able switch to it easily enough, if you want to check for yourself. Even though it's not very popular right now, it will be in tech preview as an alternative OCI runtime as of the RHEL 8.3 release and considering that it's Red Hat product we might eventually see as default for Podman or CRI-O.
The only tool which I will mention here that can do these tasks is Skopeo. It's made by Red Hat and it's an accompanying tool for Buildah, Podman and CRI-O. Apart from the basic skopeo inspect which we all know from Docker, Skopeo is also able to copy images using skopeo copy which allows you to mirror images between remote registries without first pulling them to local registry. This feature can also act as pull/push if you use local registry.
The third contender here is buildkit, which could be also called the next-generation docker build. It's part of Moby project (as is Docker) and can be enabled with Docker as an experimental feature using DOCKER_BUILDKIT=1 docker build .... Well, but what exactly will this bring to you? It introduces bunch of improvements and cool features including parallel build steps, skipping unused stages, better incremental builds and rootless builds. On the other hand however, it still requires daemon to run (buildkitd). So, if you don't want to get rid of Docker, but want some new features and nice improvements, then using buildkit might be the way to go.
If you are scared of switching to different set of tools, because you would have to learn to work with different CLI, different API or in general different concepts, then that won't be a problem. Choosing any of the tools shown in this article can be completely seamless as they all (including Docker) adhere to same specification under OCI, which is short for Open Container Initiative. This initiative contains specifications for container runtime, container distribution and container images, which covers all the features needed for working with containers.
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, so pretty much everything expect for LXD (which uses LXC). There's not much else I can add. It's default for (almost) everything, so even if you ditch Docker after reading this article, you will most likely still use runc.
Source-To-Image (S2I) is a toolkit for building images directly from source code without Dockerfile. This tool works well for simple, expected scenarios and workflows but quickly becomes annoying and clumsy if you need little too much customization or if your project doesn't have the expected layout. You might consider using S2I if you are not very confident with Docker yet or if you build your images on OpenShift cluster, as builds with S2I are a built-in feature.
As a little bonus, I want to also mention Dive, which is a tool for inspecting, exploring and analyzing images. It's little more user friendly, provides more readable output and can dig (or dive, I guess) a bit deeper into your image and analyze and measure its efficiency. It's also suitable for use in CI pipelines, where it can measure whether your image is "efficient enough" or in other words - whether it wastes too much space or not.