Skip to content

G
gitlab-ce
Commit 9b0972cd authored by Joao Cunha's avatar Joao Cunha
Browse files
Options

Updates all usage of docker 19.03.11 to 19.03.12 

Also updates documentation
parent 3e2e2a8b
Hide whitespace changes
Inline Side-by-side
Showing with 44 additions and 44 deletions
doc/ci/docker/using_docker_build.md
View file @ 9b0972cd
......@@ -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,7 +142,7 @@ 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.
......@@ -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
......
doc/user/application_security/container_scanning/index.md
View file @ 9b0972cd
......@@ -58,10 +58,10 @@ To enable Container Scanning in your pipeline, you need the following:
```yaml
build:
image: docker:19.03.11
image: docker:19.03.12
stage: build
services:
- docker:19.03.11-dind
- docker:19.03.12-dind
variables:
IMAGE_TAG: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA
script:
......@@ -114,7 +114,7 @@ build:
image: docker:stable
stage: build
services:
- docker:19.03.11-dind
- docker:19.03.12-dind
variables:
IMAGE: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA
script:
......@@ -283,7 +283,7 @@ stages:
build_latest_vulnerabilities:
stage: build
services:
- docker:19.03.11-dind
- docker:19.03.12-dind
script:
- docker pull arminc/clair-db:latest
- docker tag arminc/clair-db:latest $CI_REGISTRY/namespace/clair-vulnerabilities-db
......
doc/user/packages/container_registry/index.md
View file @ 9b0972cd
......@@ -248,10 +248,10 @@ should look similar to this:
```yaml
build:
image: docker:19.03.11
image: docker:19.03.12
stage: build
services:
- docker:19.03.11-dind
- docker:19.03.12-dind
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t $CI_REGISTRY/group/project/image:latest .
......@@ -262,10 +262,10 @@ You can also make use of [other variables](../../../ci/variables/README.md) to a
```yaml
build:
image: docker:19.03.11
image: docker:19.03.12
stage: build
services:
- docker:19.03.11-dind
- docker:19.03.12-dind
variables:
IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
script:
......@@ -288,9 +288,9 @@ when needed. Changes to `master` also get tagged as `latest` and deployed using
an application-specific deploy script:
```yaml
image: docker:19.03.11
image: docker:19.03.12
services:
- docker:19.03.11-dind
- docker:19.03.12-dind
stages:
- build
......@@ -363,9 +363,9 @@ Below is an example of what your `.gitlab-ci.yml` should look like:
```yaml
build:
image: $CI_REGISTRY/group/project/docker:19.03.11
image: $CI_REGISTRY/group/project/docker:19.03.12
services:
- name: $CI_REGISTRY/group/project/docker:19.03.11-dind
- name: $CI_REGISTRY/group/project/docker:19.03.12-dind
alias: docker
stage: build
script:
......@@ -373,7 +373,7 @@ Below is an example of what your `.gitlab-ci.yml` should look like:
- docker run my-docker-image /script/to/run/tests
```
If you forget to set the service alias, the `docker:19.03.11` image won't find the
If you forget to set the service alias, the `docker:19.03.12` image won't find the
`dind` service, and an error like the following will be thrown:
```plaintext
......@@ -443,10 +443,10 @@ stages:
- clean
build_image:
image: docker:19.03.11
image: docker:19.03.12
stage: build
services:
- docker:19.03.11-dind
- docker:19.03.12-dind
variables:
IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
script:
......@@ -459,10 +459,10 @@ build_image:
- master
delete_image:
image: docker:19.03.11
image: docker:19.03.12
stage: clean
services:
- docker:19.03.11-dind
- docker:19.03.12-dind
variables:
IMAGE_TAG: $CI_PROJECT_PATH:$CI_COMMIT_REF_SLUG
REG_SHA256: ade837fc5224acd8c34732bf54a94f579b47851cc6a7fd5899a98386b782e228
......
lib/gitlab/ci/templates/Jobs/Browser-Performance-Testing.gitlab-ci.yml
View file @ 9b0972cd
performance:
stage: performance
image: docker:19.03.11
image: docker:19.03.12
allow_failure: true
variables:
DOCKER_TLS_CERTDIR: ""
SITESPEED_IMAGE: "sitespeedio/sitespeed.io:11.2.0"
services:
- docker:19.03.11-dind
- docker:19.03.12-dind
script:
- |
if ! docker info &>/dev/null; then
......
lib/gitlab/ci/templates/Jobs/Build.gitlab-ci.yml
View file @ 9b0972cd
build:
stage: build
image: "registry.gitlab.com/gitlab-org/cluster-integration/auto-build-image:v0.3.0"
image: "registry.gitlab.com/gitlab-org/cluster-integration/auto-build-image:v0.3.1"
variables:
DOCKER_TLS_CERTDIR: ""
services:
- docker:19.03.11-dind
- docker:19.03.12-dind
script:
- |
if [[ -z "$CI_COMMIT_TAG" ]]; then
......
lib/gitlab/ci/templates/Jobs/Code-Quality.gitlab-ci.yml
View file @ 9b0972cd
code_quality:
stage: test
image: docker:19.03.11
image: docker:19.03.12
allow_failure: true
services:
- docker:19.03.11-dind
- docker:19.03.12-dind
variables:
DOCKER_DRIVER: overlay2
DOCKER_TLS_CERTDIR: ""
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7