debian-mirror-gitlab/doc/ci/docker/using_kaniko.md

149 lines
6.2 KiB
Markdown
Raw Normal View History

2019-09-04 21:01:54 +05:30
---
2020-06-23 00:09:42 +05:30
stage: Verify
2021-09-04 01:27:46 +05:30
group: Pipeline Execution
2021-02-22 17:27:13 +05:30
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-09-04 21:01:54 +05:30
type: howto
---
2021-04-17 20:07:23 +05:30
# Use kaniko to build Docker images
2018-11-18 11:00:15 +05:30
2020-06-23 00:09:42 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/45512) in GitLab 11.2. Requires GitLab Runner 11.2 and above.
2018-11-18 11:00:15 +05:30
[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
2020-06-23 00:09:42 +05:30
[Docker-in-Docker
2021-03-08 18:12:59 +05:30
build](using_docker_build.md#use-the-docker-executor-with-the-docker-image-docker-in-docker) method:
2018-11-18 11:00:15 +05:30
2020-06-23 00:09:42 +05:30
- Docker-in-Docker requires [privileged mode](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)
2021-01-03 14:25:43 +05:30
to function, which is a significant security concern.
2020-06-23 00:09:42 +05:30
- Docker-in-Docker generally incurs a performance penalty and can be quite slow.
2018-11-18 11:00:15 +05:30
## Requirements
2021-01-03 14:25:43 +05:30
To use kaniko with GitLab, [a runner](https://docs.gitlab.com/runner/) with one
of the following executors is required:
2019-09-04 21:01:54 +05:30
- [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-11-18 11:00:15 +05:30
## 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-02-22 17:27:13 +05:30
- The entrypoint needs to be [overridden](using_docker_images.md#overriding-the-entrypoint-of-an-image),
otherwise the build script doesn't run.
2018-11-18 11:00:15 +05:30
- A Docker `config.json` file needs to be created with the authentication
information for the desired container registry.
2019-09-04 21:01:54 +05:30
In the following example, kaniko is used to:
1. Build a Docker image.
2019-12-04 20:38:33 +05:30
1. Then push it to [GitLab Container Registry](../../user/packages/container_registry/index.md).
2018-11-18 11:00:15 +05:30
2021-02-22 17:27:13 +05:30
The job runs only when a tag is pushed. A `config.json` file is created under
2018-12-13 13:39:08 +05:30
`/kaniko/.docker` with the needed GitLab Container Registry credentials taken from the
2021-03-11 19:13:27 +05:30
[predefined CI/CD variables](../variables/README.md#predefined-cicd-variables)
2019-09-04 21:01:54 +05:30
GitLab CI/CD provides.
In the last step, kaniko uses the `Dockerfile` under the
2018-11-18 11:00:15 +05:30
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:
name: gcr.io/kaniko-project/executor:debug
entrypoint: [""]
script:
2020-10-24 23:57:45 +05:30
- mkdir -p /kaniko/.docker
2018-12-13 13:39:08 +05:30
- echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
2018-11-18 11:00:15 +05:30
- /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG
2021-02-22 17:27:13 +05:30
rules:
- if: $CI_COMMIT_TAG
2018-11-18 11:00:15 +05:30
```
2019-02-15 15:39:39 +05:30
2021-03-08 18:12:59 +05:30
### 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:
- Adding the proxy to `/kaniko/.docker/config.json`
2021-03-11 19:13:27 +05:30
- Passing the `http_proxy` environment variables as build arguments so the Dockerfile
2021-03-08 18:12:59 +05:30
instructions can use the proxy when building the image.
The previous example can be extended as follows:
```yaml
build:
stage: build
image:
name: gcr.io/kaniko-project/executor:debug
entrypoint: [""]
script:
- mkdir -p /kaniko/.docker
- |-
KANIKOPROXYBUILDARGS=""
KANIKOCFG="{ \"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}"
if [ "x${http_proxy}" != "x" -o "x${https_proxy}" != "x" ]; then
KANIKOCFG="${KANIKOCFG}, \"proxies\": { \"default\": { \"httpProxy\": \"${http_proxy}\", \"httpsProxy\": \"${https_proxy}\", \"noProxy\": \"${no_proxy}\"}}"
KANIKOPROXYBUILDARGS="--build-arg http_proxy=${http_proxy} --build-arg https_proxy=${https_proxy} --build-arg no_proxy=${no_proxy}"
fi
KANIKOCFG="${KANIKOCFG} }"
echo "${KANIKOCFG}" > /kaniko/.docker/config.json
- /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile $KANIKOPROXYBUILDARGS --destination $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG
2021-09-04 01:27:46 +05:30
rules:
- if: $CI_COMMIT_TAG
2021-03-08 18:12:59 +05:30
```
2019-02-15 15:39:39 +05:30
## 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-03-13 15:44:24 +05:30
```shell
2019-02-15 15:39:39 +05:30
$ /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-11-24 15:15:51 +05:30
before_script:
- mkdir -p /kaniko/.docker
- echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
- |
echo "-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----" >> /kaniko/ssl/certs/additional-ca-cert-bundle.crt
2019-02-15 15:39:39 +05:30
```
2019-09-04 21:01:54 +05:30
2020-05-24 23:13:21 +05:30
## 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-09-04 01:27:46 +05:30
- [GitLab.com shared runners](../runners/README.md)
2020-11-24 15:15:51 +05:30
- [The Kubernetes runner executor](https://docs.gitlab.com/runner/executors/kubernetes.html)
2020-05-24 23:13:21 +05:30
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.
2021-02-22 17:27:13 +05:30
## Troubleshooting
2019-09-04 21:01:54 +05:30
2021-02-22 17:27:13 +05:30
### 403 error: "error checking push permissions"
2019-09-04 21:01:54 +05:30
2021-02-22 17:27:13 +05:30
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.