diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-07-20 15:26:25 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-07-20 15:26:25 +0300 |
commit | a09983ae35713f5a2bbb100981116d31ce99826e (patch) | |
tree | 2ee2af7bd104d57086db360a7e6d8c9d5d43667a /doc/ci/docker | |
parent | 18c5ab32b738c0b6ecb4d0df3994000482f34bd8 (diff) |
Add latest changes from gitlab-org/gitlab@13-2-stable-ee
Diffstat (limited to 'doc/ci/docker')
-rw-r--r-- | doc/ci/docker/using_docker_build.md | 44 | ||||
-rw-r--r-- | doc/ci/docker/using_docker_images.md | 89 | ||||
-rw-r--r-- | doc/ci/docker/using_kaniko.md | 2 |
3 files changed, 69 insertions, 66 deletions
diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index 65b9c03186b..4bed6d9e323 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -123,7 +123,7 @@ not without its own challenges: - By default, Docker 17.09 and higher uses `--storage-driver overlay2` which is the recommended storage driver. See [Using the overlayfs driver](#use-the-overlayfs-driver) for details. -- Since the `docker:19.03.11-dind` container and the Runner container don't share their +- Since the `docker:19.03.12-dind` container and the Runner container don't share their root filesystem, the job's working directory can be used as a mount point for child containers. For example, if you have files you want to share with a child container, you may create a subdirectory under `/builds/$CI_PROJECT_PATH` @@ -142,14 +142,14 @@ not without its own challenges: An example project using this approach can be found here: <https://gitlab.com/gitlab-examples/docker>. In the examples below, we are using Docker images tags to specify a -specific version, such as `docker:19.03.11`. If tags like `docker:stable` +specific version, such as `docker:19.03.12`. If tags like `docker:stable` are used, you have no control over what version is going to be used and this can lead to unpredictable behavior, especially when new versions are released. #### TLS enabled -NOTE: **Note** +NOTE: **Note:** Requires GitLab Runner 11.11 or later, but is not supported if GitLab Runner is installed using the [Helm chart](https://docs.gitlab.com/runner/install/kubernetes.html). See the @@ -158,7 +158,7 @@ issue](https://gitlab.com/gitlab-org/charts/gitlab-runner/-/issues/83) for details. The Docker daemon supports connection over TLS and it's done by default -for Docker 19.03.11 or higher. This is the **suggested** way to use the +for Docker 19.03.12 or higher. This is the **suggested** way to use the Docker-in-Docker service and [GitLab.com Shared Runners](../../user/gitlab_com/index.md#shared-runners) support this. @@ -174,13 +174,13 @@ support this. --registration-token REGISTRATION_TOKEN \ --executor docker \ --description "My Docker Runner" \ - --docker-image "docker:19.03.11" \ + --docker-image "docker:19.03.12" \ --docker-privileged \ --docker-volumes "/certs/client" ``` The above command will register a new Runner to use the special - `docker:19.03.11` image, which is provided by Docker. **Notice that it's + `docker:19.03.12` image, which is provided by Docker. **Notice that it's using the `privileged` mode to start the build and service containers.** If you want to use [Docker-in-Docker](https://www.docker.com/blog/docker-can-now-run-within-docker/) mode, you always have to use `privileged = true` in your Docker containers. @@ -199,7 +199,7 @@ support this. executor = "docker" [runners.docker] tls_verify = false - image = "docker:19.03.11" + image = "docker:19.03.12" privileged = true disable_cache = false volumes = ["/certs/client", "/cache"] @@ -209,10 +209,10 @@ support this. ``` 1. You can now use `docker` in the build script (note the inclusion of the - `docker:19.03.11-dind` service): + `docker:19.03.12-dind` service): ```yaml - image: docker:19.03.11 + image: docker:19.03.12 variables: # When using dind service, we need to instruct docker, to talk with @@ -237,7 +237,7 @@ support this. DOCKER_TLS_CERTDIR: "/certs" services: - - docker:19.03.11-dind + - docker:19.03.12-dind before_script: - docker info @@ -264,7 +264,7 @@ Assuming that the Runner `config.toml` is similar to: executor = "docker" [runners.docker] tls_verify = false - image = "docker:19.03.11" + image = "docker:19.03.12" privileged = true disable_cache = false volumes = ["/cache"] @@ -274,10 +274,10 @@ Assuming that the Runner `config.toml` is similar to: ``` You can now use `docker` in the build script (note the inclusion of the -`docker:19.03.11-dind` service): +`docker:19.03.12-dind` service): ```yaml -image: docker:19.03.11 +image: docker:19.03.12 variables: # When using dind service we need to instruct docker, to talk with the @@ -298,7 +298,7 @@ variables: DOCKER_TLS_CERTDIR: "" services: - - docker:19.03.11-dind + - docker:19.03.12-dind before_script: - docker info @@ -318,7 +318,7 @@ container so that Docker is available in the context of that image. NOTE: **Note:** If you bind the Docker socket [when using GitLab Runner 11.11 or newer](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1261), -you can no longer use `docker:19.03.11-dind` as a service because volume bindings +you can no longer use `docker:19.03.12-dind` as a service because volume bindings are done to the services as well, making these incompatible. In order to do that, follow the steps: @@ -333,12 +333,12 @@ In order to do that, follow the steps: --registration-token REGISTRATION_TOKEN \ --executor docker \ --description "My Docker Runner" \ - --docker-image "docker:19.03.11" \ + --docker-image "docker:19.03.12" \ --docker-volumes /var/run/docker.sock:/var/run/docker.sock ``` The above command will register a new Runner to use the special - `docker:19.03.11` image which is provided by Docker. **Notice that it's using + `docker:19.03.12` image which is provided by Docker. **Notice that it's using the Docker daemon of the Runner itself, and any containers spawned by Docker commands will be siblings of the Runner rather than children of the Runner.** This may have complications and limitations that are unsuitable for your workflow. @@ -352,7 +352,7 @@ In order to do that, follow the steps: executor = "docker" [runners.docker] tls_verify = false - image = "docker:19.03.11" + image = "docker:19.03.12" privileged = false disable_cache = false volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"] @@ -361,11 +361,11 @@ In order to do that, follow the steps: ``` 1. You can now use `docker` in the build script (note that you don't need to - include the `docker:19.03.11-dind` service as when using the Docker in Docker + include the `docker:19.03.12-dind` service as when using the Docker in Docker executor): ```yaml - image: docker:19.03.11 + image: docker:19.03.12 before_script: - docker info @@ -419,10 +419,10 @@ any image that's used with the `--cache-from` argument must first be pulled Here's a `.gitlab-ci.yml` file showing how Docker caching can be used: ```yaml -image: docker:19.03.11 +image: docker:19.03.12 services: - - docker:19.03.11-dind + - docker:19.03.12-dind variables: # Use TLS https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#tls-enabled diff --git a/doc/ci/docker/using_docker_images.md b/doc/ci/docker/using_docker_images.md index 2448bb536ab..735cf35584f 100644 --- a/doc/ci/docker/using_docker_images.md +++ b/doc/ci/docker/using_docker_images.md @@ -149,14 +149,14 @@ the job will fail: ```yaml job: services: - - php:7 - - node:latest - - golang:1.10 + - php:7 + - node:latest + - golang:1.10 image: alpine:3.7 script: - - php -v - - node -v - - go version + - php -v + - node -v + - go version ``` If you need to have `php`, `node` and `go` available for your script, you should @@ -176,7 +176,7 @@ You can then use for example the [tutum/wordpress](https://hub.docker.com/r/tutu ```yaml services: -- tutum/wordpress:latest + - tutum/wordpress:latest ``` If you don't [specify a service alias](#available-settings-for-services), @@ -219,7 +219,7 @@ default: test: script: - - bundle exec rake spec + - bundle exec rake spec ``` The image name must be in one of the following formats: @@ -238,16 +238,16 @@ default: test:2.6: image: ruby:2.6 services: - - postgres:11.7 + - postgres:11.7 script: - - bundle exec rake spec + - bundle exec rake spec test:2.7: image: ruby:2.7 services: - - postgres:12.2 + - postgres:12.2 script: - - bundle exec rake spec + - bundle exec rake spec ``` Or you can pass some [extended configuration options](#extended-docker-configuration-options) @@ -260,17 +260,17 @@ default: entrypoint: ["/bin/bash"] services: - - name: my-postgres:11.7 - alias: db-postgres - entrypoint: ["/usr/local/bin/db-postgres"] - command: ["start"] + - name: my-postgres:11.7 + alias: db-postgres + entrypoint: ["/usr/local/bin/db-postgres"] + command: ["start"] before_script: - - bundle install + - bundle install test: script: - - bundle exec rake spec + - bundle exec rake spec ``` ## Passing environment variables to services @@ -292,21 +292,21 @@ variables: POSTGRES_INITDB_ARGS: "--encoding=UTF8 --data-checksums" services: -- name: postgres:11.7 - alias: db - entrypoint: ["docker-entrypoint.sh"] - command: ["postgres"] + - name: postgres:11.7 + alias: db + entrypoint: ["docker-entrypoint.sh"] + command: ["postgres"] image: name: ruby:2.6 entrypoint: ["/bin/bash"] before_script: -- bundle install + - bundle install test: script: - - bundle exec rake spec + - bundle exec rake spec ``` ## Extended Docker configuration options @@ -330,8 +330,8 @@ For example, the following two definitions are equal: image: "registry.example.com/my/image:latest" services: - - postgresql:9.4 - - redis:latest + - postgresql:9.4 + - redis:latest ``` 1. Using a map as an option to `image` and `services`. The use of `image:name` is @@ -342,8 +342,8 @@ For example, the following two definitions are equal: name: "registry.example.com/my/image:latest" services: - - name: postgresql:9.4 - - name: redis:latest + - name: postgresql:9.4 + - name: redis:latest ``` ### Available settings for `image` @@ -378,8 +378,8 @@ would not work properly: ```yaml services: -- mysql:latest -- mysql:latest + - mysql:latest + - mysql:latest ``` The Runner would start two containers using the `mysql:latest` image, but both @@ -392,10 +392,10 @@ look like: ```yaml services: -- name: mysql:latest - alias: mysql-1 -- name: mysql:latest - alias: mysql-2 + - name: mysql:latest + alias: mysql-1 + - name: mysql:latest + alias: mysql-2 ``` The Runner will still start two containers using the `mysql:latest` image, @@ -427,7 +427,7 @@ CMD ["/usr/bin/super-sql", "run"] # .gitlab-ci.yml services: -- my-super-sql:latest + - my-super-sql:latest ``` After the new extended Docker configuration options, you can now simply @@ -437,8 +437,8 @@ set a `command` in `.gitlab-ci.yml`, like: # .gitlab-ci.yml services: -- name: super/sql:latest - command: ["/usr/bin/super-sql", "run"] + - name: super/sql:latest + command: ["/usr/bin/super-sql", "run"] ``` As you can see, the syntax of `command` is similar to [Dockerfile's `CMD`](https://docs.docker.com/engine/reference/builder/#cmd). @@ -545,9 +545,8 @@ runtime. support for using private registries, which required manual configuration of credentials on runner's host. We recommend to upgrade your Runner to at least version **1.8** if you want to use private registries. -- Not available for [Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes.html), - follow <https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2673> for - details. +- Available for [Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes.html) + in GitLab Runner 13.1 and later. ### Using statically-defined credentials @@ -601,6 +600,7 @@ There are two ways to determine the value of `DOCKER_AUTH_CONFIG`: Open a terminal and execute the following command: ```shell + # Note the use of "-n" - it prevents encoding a newline in the password. echo -n "my_username:my_password" | base64 # Example output to copy @@ -681,11 +681,13 @@ To add `DOCKER_AUTH_CONFIG` to a Runner: 1. Restart the Runner service. -NOTE: **Note:** The double quotes included in the `DOCKER_AUTH_CONFIG` +NOTE: **Note:** +The double quotes included in the `DOCKER_AUTH_CONFIG` data must be escaped with backslashes. This prevents them from being interpreted as TOML. -NOTE: **Note:** The `environment` option is a list. So your Runner may +NOTE: **Note:** +The `environment` option is a list. So your Runner may have existing entries and you should add this to the list, not replace it. @@ -715,7 +717,8 @@ To configure credentials store, follow these steps: `${GITLAB_RUNNER_HOME}/.docker/config.json`. GitLab Runner will read this configuration file and will use the needed helper for this specific repository. -NOTE: **Note:** `credsStore` is used to access ALL the registries. +NOTE: **Note:** +`credsStore` is used to access ALL the registries. If you will want to use both images from private registry and public images from DockerHub, pulling from DockerHub will fail, because Docker daemon will try to use the same credentials for **ALL** the registries. diff --git a/doc/ci/docker/using_kaniko.md b/doc/ci/docker/using_kaniko.md index d53430400ec..1580080ac6e 100644 --- a/doc/ci/docker/using_kaniko.md +++ b/doc/ci/docker/using_kaniko.md @@ -90,7 +90,7 @@ store: - | echo "-----BEGIN CERTIFICATE----- ... - -----END CERTIFICATE-----" >> /kaniko/ssl/certs/ca-certificates.crt + -----END CERTIFICATE-----" >> /kaniko/ssl/certs/additional-ca-cert-bundle.crt ``` ## Video walkthrough of a working example |