Docker, Kaniko, Buildah
Different ways to build container images
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: