2019-06-07 04:00:41 -04:00
---
2020-05-29 14:08:26 -04:00
stage: Verify
2021-05-26 11:10:57 -04:00
group: Pipeline Execution
2020-11-26 01:09:20 -05:00
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2019-06-07 04:00:41 -04:00
type: howto
---
2021-06-21 20:07:53 -04:00
# Use kaniko to build Docker images **(FREE)**
2018-08-16 10:32:15 -04:00
2020-05-20 23:08:00 -04:00
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/45512) in GitLab 11.2. Requires GitLab Runner 11.2 and above.
2018-08-16 10:32:15 -04:00
[kaniko ](https://github.com/GoogleContainerTools/kaniko ) is a tool to build
container images from a Dockerfile, inside a container or Kubernetes cluster.
kaniko solves two problems with using the
2022-01-11 19:16:35 -05:00
[Docker-in-Docker build ](using_docker_build.md#use-docker-in-docker )
2021-10-18 08:13:41 -04:00
method:
2018-08-16 10:32:15 -04:00
2020-05-27 05:08:30 -04:00
- Docker-in-Docker requires [privileged mode ](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities )
2020-10-08 02:08:35 -04:00
to function, which is a significant security concern.
2020-05-27 05:08:30 -04:00
- Docker-in-Docker generally incurs a performance penalty and can be quite slow.
2018-08-16 10:32:15 -04:00
## Requirements
2020-10-08 02:08:35 -04:00
To use kaniko with GitLab, [a runner ](https://docs.gitlab.com/runner/ ) with one
of the following executors is required:
2019-06-07 04:00:41 -04:00
- [Kubernetes ](https://docs.gitlab.com/runner/executors/kubernetes.html ).
- [Docker ](https://docs.gitlab.com/runner/executors/docker.html ).
- [Docker Machine ](https://docs.gitlab.com/runner/executors/docker_machine.html ).
2018-08-16 10:32:15 -04:00
## Building a Docker image with kaniko
When building an image with kaniko and GitLab CI/CD, you should be aware of a
few important details:
- The kaniko debug image is recommended (`gcr.io/kaniko-project/executor:debug`)
because it has a shell, and a shell is required for an image to be used with
GitLab CI/CD.
2021-10-22 05:09:20 -04:00
- The entrypoint needs to be [overridden ](using_docker_images.md#override-the-entrypoint-of-an-image ),
2020-11-18 10:09:08 -05:00
otherwise the build script doesn't run.
2018-08-16 10:32:15 -04:00
2019-06-07 04:00:41 -04:00
In the following example, kaniko is used to:
1. Build a Docker image.
2019-09-17 08:06:48 -04:00
1. Then push it to [GitLab Container Registry ](../../user/packages/container_registry/index.md ).
2018-08-16 10:32:15 -04:00
2020-11-18 10:09:08 -05:00
The job runs only when a tag is pushed. A `config.json` file is created under
2018-10-03 05:15:12 -04:00
`/kaniko/.docker` with the needed GitLab Container Registry credentials taken from the
2021-06-28 11:08:03 -04:00
[predefined CI/CD variables ](../variables/index.md#predefined-cicd-variables )
2022-08-26 08:11:48 -04:00
GitLab CI/CD provides. These are automatically read by the Kaniko tool.
2019-06-07 04:00:41 -04:00
In the last step, kaniko uses the `Dockerfile` under the
2018-08-16 10:32:15 -04:00
root directory of the project, builds the Docker image and pushes it to the
project's Container Registry while tagging it with the Git tag:
```yaml
build:
stage: build
image:
2022-08-26 08:11:48 -04:00
name: gcr.io/kaniko-project/executor:v1.9.0-debug
2018-08-16 10:32:15 -04:00
entrypoint: [""]
script:
2022-08-26 08:11:48 -04:00
- /kaniko/executor
2021-10-21 20:13:18 -04:00
--context "${CI_PROJECT_DIR}"
--dockerfile "${CI_PROJECT_DIR}/Dockerfile"
--destination "${CI_REGISTRY_IMAGE}:${CI_COMMIT_TAG}"
2020-12-10 04:09:32 -05:00
rules:
- if: $CI_COMMIT_TAG
2018-08-16 10:32:15 -04:00
```
2018-12-17 10:26:53 -05:00
2022-03-22 17:07:19 -04:00
If you authenticate against the [Dependency Proxy ](../../user/packages/dependency_proxy/index.md#authenticate-within-cicd ),
you must add the corresponding CI/CD variables for authentication to the `config.json` file:
```yaml
- echo "{\"auths\":{\"$CI_REGISTRY\":{\"auth\":\"$(printf "%s:%s" "${CI_REGISTRY_USER}" "${CI_REGISTRY_PASSWORD}" | base64 | tr -d '\n')\"},\"$CI_DEPENDENCY_PROXY_SERVER\":{\"auth\":\"$(printf "%s:%s" ${CI_DEPENDENCY_PROXY_USER} "${CI_DEPENDENCY_PROXY_PASSWORD}" | base64 | tr -d '\n')\"}}}" > /kaniko/.docker/config.json
```
2021-01-08 19:10:30 -05:00
### Building an image with kaniko behind a proxy
If you use a custom GitLab Runner behind an http(s) proxy, kaniko needs to be set
up accordingly. This means:
2021-01-22 19:08:46 -05:00
- Passing the `http_proxy` environment variables as build arguments so the Dockerfile
2021-01-08 19:10:30 -05:00
instructions can use the proxy when building the image.
The previous example can be extended as follows:
```yaml
build:
stage: build
2022-08-26 08:11:48 -04:00
variables:
http_proxy: < your-proxy >
https_proxy: < your-proxy >
no_proxy: < your-no-proxy >
2021-01-08 19:10:30 -05:00
image:
2022-08-26 08:11:48 -04:00
name: gcr.io/kaniko-project/executor:v1.9.0-debug
2021-01-08 19:10:30 -05:00
entrypoint: [""]
script:
2022-08-26 08:11:48 -04:00
- /kaniko/executor
2021-10-21 20:13:18 -04:00
--context "${CI_PROJECT_DIR}"
2022-08-26 08:11:48 -04:00
--build-arg http_proxy=$http_proxy
--build-arg https_proxy=$https_proxy
--build-arg no_proxy=$no_proxy
2021-10-21 20:13:18 -04:00
--dockerfile "${CI_PROJECT_DIR}/Dockerfile"
--destination "${CI_REGISTRY_IMAGE}:${CI_COMMIT_TAG}"
2021-06-15 11:10:04 -04:00
rules:
- if: $CI_COMMIT_TAG
2021-01-08 19:10:30 -05:00
```
2022-08-04 11:11:28 -04:00
## Build a multi-arch image
You can build [multi-arch images ](https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/ )
inside a container by using [`manifest-tool` ](https://github.com/estesp/manifest-tool ).
For a detailed guide on how to build a multi-arch image, read [Building a multi-arch container image in unprivileged containers ](https://ingenuity.siemens.com/2022/07/building-a-multi-arch-container-image-in-unprivileged-containers/ ).
2018-12-17 10:26:53 -05:00
## Using a registry with a custom certificate
When trying to push to a Docker registry that uses a certificate that is signed
by a custom CA, you might get the following error:
2020-01-30 10:09:15 -05:00
```shell
2018-12-17 10:26:53 -05:00
$ /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --no-push
INFO[0000] Downloading base image registry.gitlab.example.com/group/docker-image
error building image: getting stage builder for stage 0: Get https://registry.gitlab.example.com/v2/: x509: certificate signed by unknown authority
```
This can be solved by adding your CA's certificate to the kaniko certificate
store:
```yaml
2020-09-08 14:08:48 -04:00
before_script:
- |
echo "-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----" >> /kaniko/ssl/certs/additional-ca-cert-bundle.crt
2018-12-17 10:26:53 -05:00
```
2019-06-07 04:00:41 -04:00
2020-04-22 23:09:51 -04:00
## Video walkthrough of a working example
The [Least Privilege Container Builds with Kaniko on GitLab ](https://www.youtube.com/watch?v=d96ybcELpFs )
video is a walkthrough of the [Kaniko Docker Build ](https://gitlab.com/guided-explorations/containers/kaniko-docker-build )
Guided Exploration project pipeline. It was tested on:
2021-06-28 08:38:12 -04:00
- [GitLab.com shared runners ](../runners/index.md )
2020-08-20 23:10:16 -04:00
- [The Kubernetes runner executor ](https://docs.gitlab.com/runner/executors/kubernetes.html )
2020-04-22 23:09:51 -04:00
The example can be copied to your own group or instance for testing. More details
on what other GitLab CI patterns are demonstrated are available at the project page.
2020-12-11 01:10:17 -05:00
## Troubleshooting
2019-06-07 04:00:41 -04:00
2020-12-11 01:10:17 -05:00
### 403 error: "error checking push permissions"
2019-06-07 04:00:41 -04:00
2020-12-11 01:10:17 -05:00
If you receive this error, it might be due to an outside proxy. Setting the `http_proxy`
and `https_proxy` [environment variables ](../../administration/packages/container_registry.md#running-the-docker-daemon-with-a-proxy )
can fix the problem.