You Don’t Have to Use Docker Anymore
By Martin Heinz, DevOps Engineer at IBM
In the traditional occasions of containers (actually extra like four years in the past) Docker was the one participant within the container recreation. That’s not the case anymore although and Docker is just not the one, however reasonably simply one other container engine on the panorama. Docker permits us to construct, run, pull, push or examine container photos, however for every of those duties there are different different instruments, which could simply do higher job at it than Docker. So, let’s discover the panorama and (simply perhaps) uninstall and neglect about Docker altogether…
Why Not Use Docker, Though?
If you’ve been a docker person for very long time, I feel it’s going to take some persuading for you to even contemplate to change to completely different tooling. So, right here goes:
First of all, Docker is a monolithic device. It’s a device that tries to do every part, which usually is just not the perfect strategy. Most of the time it’s higher to select a specialised device that does only one factor, however does it very well.
If you might be frightened of switching to completely different set of instruments, since you would have to study to work with completely different CLI, completely different API or normally completely different ideas, then that gained’t be an issue. Choosing any of the instruments proven on this article might be fully seamless as all of them (together with Docker) adhere to identical specification beneath OCI, which is brief for Open Container Initiative. This initiative incorporates specs for container runtime, container distribution and container photos, which covers all of the options wanted for working with containers.
Thanks to the OCI you’ll be able to select a set of instruments that finest fit your wants and on the identical time you’ll be able to nonetheless get pleasure from utilizing the identical APIs and identical CLI instructions as with Docker.
So, for those who’re open to making an attempt out new instruments, then let’s examine the benefits, disadvantages and options of Docker and it’s opponents to see whether or not it truly is smart to even contemplate ditching Docker for some new shiny device.
When evaluating Docker with another device we’d like to break it down by its elements and very first thing we must always speak about are container engines. Container engine is a device that gives person interface for working with photos and containers so that you simply don’t have to mess with issues like
SECCOMP guidelines or SELinux insurance policies. Its job can be to pull photos from distant repositories and broaden them to your disk. It additionally seemingly runs the containers, however in actuality its job is to create container manifest and listing with picture layers. It then passes them to container runtime like
crun (which we are going to speak about little later).
There are many container engines obtainable, however essentially the most outstanding competitor to Docker is Podman, developed by Red Hat. Unlike Docker, Podman doesn’t want daemon to run and likewise doesn’t want root privileges which has been long-standing concern with Docker. Based on the title, Podman cannot solely run containers, but in addition pods. In case you aren’t aware of idea of pods, then pod is the smallest compute unit for Kubernetes. It consists of a number of containers — the primary one and so-called sidecars — that carry out supporting duties. This makes it simpler for Podman customers to later migrate their workloads to Kubernetes. So, as a easy demonstration, that is how you’d run 2 containers in a single pod:
Finally, Podman gives the very same CLI instructions as Docker so you’ll be able to simply do
alias docker=podman and faux that nothing modified.
There are different container engines apart from Docker and Podman, however I might contemplate all of them a dead-end tech or not an appropriate possibility for native improvement and utilization. But to have an entire image, let’s not less than point out what’s on the market:
- LXD — LXD is container supervisor (daemon) for LXC (Linux Containers). This device gives capability to run system containers that present container atmosphere that’s extra comparable to VMs. It sits in very slender area and doesn’t have many customers, so except you might have very particular use case, you then’re most likely higher off utilizing Docker or Podman.
- CRI-O — When you google what’s cri-o, you would possibly discover it described as container engine. It actually is container runtime, although. Apart from the truth that it isn’t truly an engine, it additionally is just not appropriate for “normal” use. And by that I imply that it was particularly constructed to be used as Kubernetes runtime (CRI) and never for an end-user utilization.
- rkt — rkt (“rocket”) is container engine developed by CoreOS. This challenge is talked about right here actually only for completeness, as a result of the challenge ended and its improvement was halted — and subsequently it shouldn’t be used.
With container engines there was actually just one different to Docker. When it comes to constructing photos although, we’ve got many extra choices to select from.
First, let me introduce Buildah. Buildah is one other device developed by Red Hat and it performs very properly with Podman. If you already put in Podman, you may need even observed the
podman construct subcommand, which is de facto simply Buildah in disguise, as its binary is included in Podman.
As for its options, it follows identical route as Podman — it’s daemonless and rootless and produces OCI compliant photos, so it’s assured that your photos will run the identical manner as those constructed with Docker. It’s additionally ready to construct photos from
Dockerfile or (extra suitably named)
Containerfile which is identical factor with completely different title. Apart from that, Buildah additionally gives finer management over picture layers, permitting you to commit many adjustments into single layer. One sudden however (in my view) good distinction from Docker is that photos constructed by Buildah are person particular, so it is possible for you to to checklist solely photos you constructed your self.
Now, contemplating that Buildah is already included in Podman CLI, you could be asking why even use the separate
buildah CLI? Well, the
buildah CLI is superset of instructions included in
podman construct, so that you won’t want to ever contact the
buildah CLI, however through the use of it you may additionally uncover some further helpful options (For specifics about variations between
podman construct and
buildah see following article).
With that stated, let’s see just a little demonstration:
From the above script you’ll be able to see you can construct photos merely utilizing
buildah bud, the place
bud stands for construct utilizing Dockerfile, however you can too use extra scripted strategy utilizing Buildahs
copy, that are equal instructions to the instructions in Dockerfile (
Next up is Google’s Kaniko. Kaniko additionally builds container photos from Dockerfile and equally to Buildah, it additionally doesn’t want a daemon. The main distinction from Buildah is that Kaniko is extra targeted on constructing photos in Kubernetes.
Kaniko is supposed to be run as a picture, utilizing
gcr.io/kaniko-project/executor, which is smart for Kubernetes, however is not very handy for native builds and type of defeats the aim as you would want to use Docker to run Kaniko picture to construct your photos. That being stated, if you’re on the lookout for device for constructing photos in your Kubernetes cluster (e.g. in CI/CD pipeline), then Kaniko could be a superb possibility, contemplating that it is daemonless and (perhaps) safer.
From my private expertise although — I used each Kaniko and Buildah to construct photos in Kubernetes/OpenShift clusters and I feel each will do the job simply nice, however with Kaniko I’ve seen some random construct crashes and fails when pushing photos to registry.
The third contender right here is buildkit, which could possibly be additionally known as the next-generation
docker construct. It’s a part of Moby challenge (as is Docker) and might be enabled with Docker as an experimental function utilizing
DOCKER_BUILDKIT=1 docker construct .... Well, however what precisely will this carry to you? It introduces bunch of enhancements and funky options together with parallel construct steps, skipping unused levels, higher incremental builds and rootless builds. On the opposite hand nonetheless, it nonetheless requires daemon to run (
buildkitd). So, if you don’t need to eliminate Docker, however need some new options and good enhancements, then utilizing buildkit could be the way in which to go.
As within the earlier part, right here we even have a couple of “honorable mentions” which fill some very particular use instances and wouldn’t be one in all my high decisions:
- Source-To-Image (S2I) is a toolkit for constructing photos straight from supply code with out Dockerfile. This device works effectively for easy, anticipated eventualities and workflows however shortly turns into annoying and clumsy for those who want little an excessive amount of customization or in case your challenge doesn’t have the anticipated structure. You would possibly think about using S2I if you’re not very assured with Docker but or for those who construct your photos on OpenShift cluster, as builds with S2I are a built-in function.
- Jib is one other device by Google, particularly for constructing Java photos. It contains Maven and Gradle plugins, which might make it straightforward for you to construct photos with out messing with Dockerfiles.
- Last however not least is Bazel, which is anoooother device by Google. This one isn’t just for constructing container photos, however reasonably an entire construct system. If you simply need to construct a picture, then diving into Bazel could be a little bit of an overkill, however positively a superb studying expertise, so for those who’re up for it, then rules_docker part is an effective place to begin for you.
Last huge piece of a puzzle is container runtime which is answerable for, effectively, operating containers. Container runtime is one a part of the entire container lifecycle/stack, which you’ll probably not going to mess with, except you might have some very particular requirement for velocity, safety, and many others. So, for those who’re uninterested in me already, then you may want skip this one part. If however, you simply need to know what are the choices, then right here goes:
runc is the preferred container runtime created primarily based on OCI container runtime specification. It’s utilized by Docker (by containerd), Podman and CRI-O, so just about every part anticipate for LXD (which makes use of LXC). There’s not a lot else I can add. It’s default for (virtually) every part, so even for those who ditch Docker after studying this text, you’ll probably nonetheless use runc.
One different to runc is equally (and confusingly) named crun. This is device developed by Red Hat and totally written in C (runc is written in Go). This makes it a lot quicker and extra reminiscence environment friendly than runc. Considering that it’s additionally OCI compliant runtime, you have to be ready change to it simply sufficient, if you would like to examine for your self. Even although it’s not highly regarded proper now, it will likely be in tech preview instead OCI runtime as of the RHEL 8.three launch and contemplating that it’s Red Hat product we would finally see as default for Podman or CRI-O.
Speaking of CRI-O. Earlier I stated that CRI-O isn’t actually a container engine, however reasonably container runtime. That’s as a result of CRI-O doesn’t embrace options like pushing photos, which is what you’d anticipate from container engine. CRI-O as a runtime makes use of runc internally to run containers. This runtime is just not the one you need to attempt utilizing in your machine, because it’s constructed to be used as runtime on Kubernetes nodes and you may see it described as “all the runtime Kubernetes needs and nothing more”. So, except you might be establishing Kubernetes cluster (or OpenShift cluster — CRI-O is default there already), you then most likely mustn’t contact this one.
Last one for this part is containerd, which is a CNCF graduating challenge. It’s a daemon that acts as an API facade for varied container runtimes and OS. In the background it depends on runc and it’s the default runtime for Docker engine. It’s additionally utilized by Google Kubernetes Engine (GKE) and IBM Kubernetes Service (IKS). It’s an implementation of Kubernetes Container Runtime Interface (identical as CRI-O), subsequently it’s a superb candidate for runtime of your Kubernetes cluster.
Image Inspection and Distribution
Last a part of container stack is picture inspection and distribution. This successfully replaces
docker examine and likewise (optionally) provides capability to copy/mirror photos between distant registries.
The solely device which I’ll point out right here that may do these duties is Skopeo. It’s made by Red Hat and it’s an accompanying device for Buildah, Podman and CRI-O. Apart from the fundamental
skopeo examine which everyone knows from Docker, Skopeo can be ready to copy photos utilizing
skopeo copy which permits you to mirror photos between distant registries with out first pulling them to native registry. This function can even act as pull/push for those who use native registry.
As just a little bonus, I need to additionally point out Dive, which is a device for inspecting, exploring and analyzing photos. It’s little extra person pleasant, gives extra readable output and might dig (or dive, I assume) a bit deeper into your picture and analyze and measure its effectivity. It’s additionally appropriate to be used in CI pipelines, the place it might measure whether or not your picture is “efficient enough” or in different phrases — whether or not it wastes an excessive amount of area or not.
This article wasn’t meant to persuade you to fully ditch Docker, reasonably its objective was to present you the entire panorama and all of the choices for constructing, operating, managing and distributing containers and their photos. Each of those instruments together with Docker, has its execs and cons and it’s essential to consider what set of instruments fits your workflow and use case the perfect and I hope this text will provide help to with that.
Bio: Martin Heinz is a DevOps Engineer at IBM. A software program developer, Martin is obsessed with laptop safety, privateness and cryptography, targeted on cloud and serverless computing, and is all the time prepared to tackle a brand new problem.
Original. Reposted with permission.