Mentions légales du service

Skip to content
Snippets Groups Projects
Commit 0414fa40 authored by ARRIVAULT Denis's avatar ARRIVAULT Denis :strawberry:
Browse files

Update README

parent 6f92b548
No related branches found
No related tags found
No related merge requests found
Pipeline #942719 passed
# docker-in-docker
# docker-in-docker with a shared runner
Examples of docker in docker usage. Each branch corresponds to a specific case.
## Using a shared runner : see shared-runner branch
Example of docker in docker usage with a shared runner.
To run this kind of project you first have to check that:
......@@ -15,122 +13,3 @@ The *.gitlab-ci.yml* file contains two jobs/stages that will be executed sequent
The first one does load the docker:20.10.16 image that has a valid docker daemon. This daemon is used to build the docker image with the given Dockerfile. This image is then stored in the [*Packages and registries - Container Registry*](https://gitlab.inria.fr/gitlabci_gallery/docker/docker-in-docker/container_registry).
The second one does load the docker image build and registered during the first stage and run a simple command in this container.
**[- WARNING: The incoming authentification token workflow for runners (gitlab V17+) will probably lead to make the following self-hosted examples inaccurate. -]**
## Using a self hosted runner
To run this kind of project you first have to check that:
1. The *CI/CD* option is switched on in [*Settings - General - Visibility, project features, permissions*](https://gitlab.inria.fr/gitlabci_gallery/docker/docker-in-docker/edit).
2. The *Container registry* option is switched on in [*Settings - General - Visibility, project features, permissions*](https://gitlab.inria.fr/gitlabci_gallery/docker/docker-in-docker/edit).
Then you have to configure your runner with gitlab-runner as root. In this example, we did:
```bash
root@ci:/# gitlab-runner register
Runtime platform arch=amd64 os=linux pid=631455 revision=7f093137 version=15.2.0
Running in system-mode.
Enter the GitLab instance URL (for example, https://gitlab.com/):
https://gitlab.inria.fr/
Enter the registration token:
xxxx
<<<<<<< HEAD
=======
Enter a description for the runner:
[ci]: docker 20.10.16
Enter tags for the runner (comma-separated):
docker 20.10.16
Enter optional maintenance note for the runner:
Registering runner... succeeded runner=xxxx
Enter an executor: custom, docker, shell, ssh, kubernetes, docker-ssh, parallels, virtualbox, docker+machine, docker-ssh+machine:
docker
Enter the default Docker image (for example, ruby:2.7):
docker:20.10.16
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
Configuration (with the authentication token) was saved in "/etc/gitlab-runner/config.toml"
```
The registration token can be found in [*Settings - CI/CD - Runners - Specific runners*](https://gitlab.inria.fr/gitlabci_gallery/docker/docker-in-docker/-/settings/ci_cd#js-runners-settings)
At this stage the runner does not have any docker daemon started. To do that we have two options, either we use the one of the VM that run the runner, or we start a daemon in the runner.
### Using the daemon of the VM : see self-hosted-runner-VM-daemon branch
To do so we have to modify the runner configuration file to mount the VM daemon socket in the runner. Open the
*/etc/gitlab-runner/config.toml* file and add `"/var/run/docker.sock:/var/run/docker.sock"` in the volumes option of
your runner:
```toml
[[runners]]
name = "docker 20.10.16, VM daemon"
url = "https://gitlab.inria.fr/"
token = "xxxx"
executor = "docker"
[runners.custom_build_dir]
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
[runners.cache.azure]
[runners.docker]
tls_verify = false
image = "docker:20.10.16"
privileged = false
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/var/run/docker.sock:/var/run/docker.sock","/cache"]
shm_size = 0
```
Restart the gitlab-runner service (`systemctl restart gitlab-runner`).
The *.gitlab-ci.yml* file contains two jobs/stages that will be executed sequentially. Both are executed in the runner
identified by its tag 'docker 20.10.16'.
The first stage loads the docker:20.10.16 image that has been specified as the default docker image (that is why we
do specify the image name in the stage description). The VM daemon is used to build the docker image with the given
Dockerfile. This image is then stored in the [*Packages and registries - Container Registry*](https://gitlab.inria.fr/gitlabci_gallery/docker/docker-in-docker/container_registry).
The second stage does load the docker image build and registered during the first stage and run a simple command in this
container.
### Starting a daemon in the runner : see self-hosted-runner-runner-daemon branch
To start a docker daemon in your docker container you should set privileged mode in your */etc/gitlab-runner/config.toml*
because docker will need it:
```toml
[[runners]]
name = "docker 20.10.16, runner daemon"
url = "https://gitlab.inria.fr/"
token = "xxxx"
executor = "docker"
[runners.custom_build_dir]
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
[runners.cache.azure]
[runners.docker]
tls_verify = false
image = "docker:20.10.16"
privileged = true
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/cache"]
shm_size = 0
```
Restart the gitlab-runner service (`systemctl restart gitlab-runner`).
In the *.gitlab-ci.yml* , you have also to:
* Specify where the docker socket is. It is done with the *DOCKER_HOST* variable.
* Specify that docker should not start over tls. It is done with the *DOCKER_TLS_CERTDIR* variable.
* Start a docker daemon in the first stage that is building the image. It is done by the *services* keyword.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment