diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2021-02-18 13:34:06 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2021-02-18 13:34:06 +0300 |
commit | 859a6fb938bb9ee2a317c46dfa4fcc1af49608f0 (patch) | |
tree | d7f2700abe6b4ffcb2dcfc80631b2d87d0609239 /doc/ci/docker | |
parent | 446d496a6d000c73a304be52587cd9bbc7493136 (diff) |
Add latest changes from gitlab-org/gitlab@13-9-stable-eev13.9.0-rc42
Diffstat (limited to 'doc/ci/docker')
-rw-r--r-- | doc/ci/docker/README.md | 18 | ||||
-rw-r--r-- | doc/ci/docker/index.md | 18 | ||||
-rw-r--r-- | doc/ci/docker/using_docker_build.md | 6 | ||||
-rw-r--r-- | doc/ci/docker/using_docker_images.md | 20 | ||||
-rw-r--r-- | doc/ci/docker/using_kaniko.md | 4 |
5 files changed, 37 insertions, 29 deletions
diff --git a/doc/ci/docker/README.md b/doc/ci/docker/README.md index 2b97f317fc1..c94d6e3ea80 100644 --- a/doc/ci/docker/README.md +++ b/doc/ci/docker/README.md @@ -1,18 +1,8 @@ --- -stage: Verify -group: Continuous Integration -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 -comments: false -type: index +redirect_to: 'index.md' --- -# Docker integration +This document was moved to [another location](index.md). -GitLab CI/CD can be combined with [Docker](https://www.docker.com) to enable -integration between the two. - -The following documentation is available for using GitLab CI/CD with Docker: - -- [Using Docker images](using_docker_images.md). -- [Building Docker images with GitLab CI/CD](using_docker_build.md). -- [Building images with kaniko and GitLab CI/CD](using_kaniko.md). +<!-- This redirect file can be deleted after 2021-05-01. --> +<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page --> diff --git a/doc/ci/docker/index.md b/doc/ci/docker/index.md new file mode 100644 index 00000000000..18a9d63b694 --- /dev/null +++ b/doc/ci/docker/index.md @@ -0,0 +1,18 @@ +--- +stage: Verify +group: Continuous Integration +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 +comments: false +type: index +--- + +# Docker integration + +GitLab CI/CD can be combined with [Docker](https://www.docker.com) to enable +integration between the two. + +The following documentation is available for using GitLab CI/CD with Docker: + +- [Building Docker images with GitLab CI/CD](using_docker_build.md). +- [Using Docker images](using_docker_images.md). +- [Building images with kaniko and GitLab CI/CD](using_kaniko.md). diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index af88a006156..46ced9b4d6d 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -126,7 +126,7 @@ not without its own challenges: instance of Docker engine so they don't conflict with each other. But this also means that jobs can be slower because there's no caching of layers. - 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) + the recommended storage driver. See [Using the OverlayFS driver](#use-the-overlayfs-driver) for details. - Since the `docker:19.03.12-dind` container and the runner container don't share their root file system, the job's working directory can be used as a mount point for @@ -801,7 +801,7 @@ NOTE: The shared runners on GitLab.com use the `overlay2` driver by default. By default, when using `docker:dind`, Docker uses the `vfs` storage driver which -copies the filesystem on every run. This is a disk-intensive operation +copies the file system on every run. This is a disk-intensive operation which can be avoided if a different driver is used, for example `overlay2`. ### Requirements @@ -830,7 +830,7 @@ which can be avoided if a different driver is used, for example `overlay2`. ### Use the OverlayFS driver per project You can enable the driver for each project individually by using the `DOCKER_DRIVER` -environment [variable](../yaml/README.md#variables) in `.gitlab-ci.yml`: +[CI/CD variable](../yaml/README.md#variables) in `.gitlab-ci.yml`: ```yaml variables: diff --git a/doc/ci/docker/using_docker_images.md b/doc/ci/docker/using_docker_images.md index 630e106b72c..67450d442a9 100644 --- a/doc/ci/docker/using_docker_images.md +++ b/doc/ci/docker/using_docker_images.md @@ -91,7 +91,7 @@ Services inherit the same DNS servers, search domains, and additional hosts as the CI container itself. You can see some widely used services examples in the relevant documentation of -[CI services examples](../services/README.md). +[CI services examples](../services/index.md). ### How services are linked to the job @@ -272,11 +272,11 @@ test: - bundle exec rake spec ``` -## Passing environment variables to services +## Passing CI/CD variables to services -You can also pass custom environment [variables](../variables/README.md) +You can also pass custom CI/CD [variables](../variables/README.md) to fine tune your Docker `images` and `services` directly in the `.gitlab-ci.yml` file. -For more information, read [custom environment variables](../variables/README.md#gitlab-ciyml-defined-variables) +For more information, read about [`.gitlab-ci.yml` defined variables](../variables/README.md#gitlab-ciyml-defined-variables). ```yaml # The following variables are automatically passed down to the Postgres container @@ -528,7 +528,7 @@ To access private container registries, the GitLab Runner process can use: To define which should be used, the GitLab Runner process reads the configuration in the following order: - `DOCKER_AUTH_CONFIG` variable provided as either: - - A [variable](../variables/README.md#gitlab-cicd-environment-variables) in `.gitlab-ci.yml`. + - A [CI/CD variable](../variables/README.md) in `.gitlab-ci.yml`. - A project's variables stored on the projects **Settings > CI/CD** page. - `DOCKER_AUTH_CONFIG` variable provided as environment variable in `config.toml` of the runner. - `config.json` file placed in `$HOME/.docker` directory of the user running GitLab Runner process. @@ -627,7 +627,7 @@ Use one of the following methods to determine the value of `DOCKER_AUTH_CONFIG`: To configure a single job with access for `registry.example.com:5000`, follow these steps: -1. Create a [variable](../variables/README.md#gitlab-cicd-environment-variables) `DOCKER_AUTH_CONFIG` with the content of the +1. Create a [CI/CD variable](../variables/README.md) `DOCKER_AUTH_CONFIG` with the content of the Docker configuration file as the value: ```json @@ -702,7 +702,7 @@ To configure credentials store, follow these steps: 1. Make GitLab Runner use it. There are two ways to accomplish this. Either: - Create a - [variable](../variables/README.md#gitlab-cicd-environment-variables) + [CI/CD variable](../variables/README.md) `DOCKER_AUTH_CONFIG` with the content of the Docker configuration file as the value: @@ -734,7 +734,7 @@ To configure access for `aws_account_id.dkr.ecr.region.amazonaws.com`, follow th Make sure that GitLab Runner can access the credentials. 1. Make GitLab Runner use it. There are two ways to accomplish this. Either: - - Create a [variable](../variables/README.md#gitlab-cicd-environment-variables) + - Create a [CI/CD variable](../variables/README.md) `DOCKER_AUTH_CONFIG` with the content of the Docker configuration file as the value: @@ -781,13 +781,13 @@ registries to the `"credHelpers"` hash as described above. Many services accept environment variables, which you can use to change database names or set account names, depending on the environment. -GitLab Runner 0.5.0 and up passes all YAML-defined variables to the created +GitLab Runner 0.5.0 and up passes all YAML-defined CI/CD variables to the created service containers. For all possible configuration variables, check the documentation of each image provided in their corresponding Docker hub page. -All variables are passed to all services containers. It's not +All CI/CD variables are passed to all services containers. It's not designed to distinguish which variable should go where. ### PostgreSQL service example diff --git a/doc/ci/docker/using_kaniko.md b/doc/ci/docker/using_kaniko.md index 7eb2a8286c7..2122cf2bf16 100644 --- a/doc/ci/docker/using_kaniko.md +++ b/doc/ci/docker/using_kaniko.md @@ -49,7 +49,7 @@ In the following example, kaniko is used to: The job runs only when a tag is pushed. A `config.json` file is created under `/kaniko/.docker` with the needed GitLab Container Registry credentials taken from the -[environment variables](../variables/README.md#predefined-environment-variables) +[predefined CI/CD variables](../variables/README.md#predefined-cicd-variables) GitLab CI/CD provides. In the last step, kaniko uses the `Dockerfile` under the @@ -76,7 +76,7 @@ If you use a custom GitLab Runner behind an http(s) proxy, kaniko needs to be se up accordingly. This means: - Adding the proxy to `/kaniko/.docker/config.json` -- Passing the `http_proxy` environment variables as build args so the Dockerfile +- Passing the `http_proxy` environment variables as build arguments so the Dockerfile instructions can use the proxy when building the image. The previous example can be extended as follows: |