Enhance your Docker image build pipeline with Kaniko

Nico Meisenzahl
Sep 24, 2018 · 2 min read

Kaniko is a new project build by Google which allows you to build Docker images without any privileges or DinD (Docker in Docker). This is helpful when your build pipeline is based on containers or even running on Kubernetes.

DinD (Docker in Docker)

This is probably the most common solution to build Docker images within a Docker container. Technically, you will run a container based on the library/docker image which contains the Docker CLI. The CLI will then talk to the hosts Docker daemon to run the Docker build process. A requirement to talk to the hosts Docker daemon is to mount the Docker daemon within the container and also to run the container in the privileged mode. Both, privileged mode as well as mounting the Docker daemon may lead to security issues which are therefore not allowed in every environment.

Kaniko

Kaniko other than DinD does not depend on the Docker daemon and therefore allows you to build Docker images within the container userspace. Without any external dependencies or privileges. You will find the Kaniko documentation here.

How to use Kaniko

In this example, I will use Kaniko in a Gitlab build pipeline. The whole pipeline is documented here. Kaniko is based on the gcr.io/kaniko-project/executor image. It’s recommended to run the Kaniko binary only in the official image.

To build an image you will need to provide different arguments:

  • --context will define the context root of your project
  • --dockerfile the location of your Dockerfile
  • --destination will be used to define the target Registry, the image name as well as tag

Depending on your target Registry you might need to define authentication details. Those can be defined in a file called /root/.docker/config.json:

As already mentioned above, Kaniko is perfect to enhance your Docker image build pipeline. Below you will find an example of how to use Kaniko within your image build stage in your Gitlab build pipeline:

You will need to use the debug image because all others do not include a shell which you will need to be able to run it in your Gitlab pipeline.

In this example I’m using Gitlab pipeline variable to define most of the configuration settings:

  • $CI_REGISTRY contains the name of the projects image Registry
  • $CI_JOB_TOKEN contains a one-time token which to authenticate against the project image Registry
  • $CI_PROJECT_DIR contains the path of your project
  • $CI_REGISTRY_IMAGE contains the image name
  • $CI_BUILD_REF will be used as image tag

I hope this post has given you a brief overview of how to use Kaniko to build your images.

01001101

Stories related to DevOps topics by Nico Meisenzahl. 01001101? First char of my surname.

Nico Meisenzahl

Written by

Senior Consultant @panagenda, @soccnx & @DockerRosenheim team member. Blogger, speaker & IBM Champion. Loves DevOps, K8s. His desk is a ping pong table.

01001101

01001101

Stories related to DevOps topics by Nico Meisenzahl. 01001101? First char of my surname.