Docker, Kaniko, Buildah

Different ways to build container images

Luc Juggery
ITNEXT
Published in
6 min readMay 3, 2021

--

Photo by Debby Hudson on Unsplash

In 2015 Docker and some other leaders in container technologies created the OCI (Open Container Initiative) to define :

  • the Image Specification: how a container image must be structured
  • the Runtime Specification: how a container must be run from an Image Specification

The commanddocker image build is probably the best known to create a container image. However on top of Docker there are other tools that know how to build an image (how to structure its filesystem and provide the associated metadata) so that it conforms to the image specification.

In this article we will illustrate the usage of 3 of those tools in the context of a GitLab CI pipeline:

As often, we will illustrate this in the context of the VotingApp, a sample microservices application I regularly use to illustrate various kinds of technologies.

ℹ️ If you do not know the VotingApp, please check this short article presenting the application, its architecture and the different versions.

Additional pieces of context:

  • each microservice of the VotingApp has its own GitLab CI pipeline defined in a .gitlab-ci.yaml file (one in each repository)
  • the pipelines of vote-ui, vote, result-ui use Docker to build an image, result uses Kaniko andworker uses Buildah so those 3 technologies are illustrated in the VotingApp
  • when source code is pushed into a repository, the CI is triggered and the commands specified in .gitlab-ci.yaml are executed. This builds an image for the current microservice and pushes that one into the GitLab registry

Let’s now see an example that uses Docker to build an image from the GitLab CI pipeline.

The vote microservices (and a couple of others) uses Docker to build an image and push it to the GitLab registry. Below is the part of .gitlab-ci.yaml defining this step:

--

--

Docker & Kubernetes trainer (CKA / CKAD), 中文学生, Learning&Sharing