@@ -67,7 +67,8 @@ GitLab Runner then executes build scripts as the `gitlab-runner` user.
5. You can now use `docker` command and install `docker-compose` if needed.
By adding `gitlab-runner` to `docker` group you are effectively granting `gitlab-runner` full root permissions.
Notes:
* By adding `gitlab-runner` to `docker` group you are effectively granting `gitlab-runner` full root permissions.
For more information please checkout [On Docker security: `docker` group considered harmful](https://www.andreas-jung.com/contents/on-docker-security-docker-group-considered-harmful).
## 2. Use docker-in-docker executor
...
...
@@ -138,15 +139,16 @@ In order to do that, follow the steps:
- docker run my-docker-image /script/to/run/tests
```
By enabling `--docker-privileged` you are effectively disabling all
Notes:
* By enabling `--docker-privileged` you are effectively disabling all
the security mechanisms of containers and exposing your host to privilege
escalation which can lead to container breakout. For more information, check out the official Docker documentation on
[Runtime privilege and Linux capabilities][docker-cap].
Using docker-in-docker, each build is in a clean environment without the past
*Using docker-in-docker, each build is in a clean environment without the past
history. Concurrent builds work fine because every build get it's own instance of docker engine so they won't conflict with each other. But this also means builds can be slower because there's no caching of layers.
By default`docker:dind` uses ``--storage-driver vfs` which is the slowest form
* By default,`docker:dind` uses ``--storage-driver vfs` which is the slowest form
offered.
An example project using this approach can be found here: https://gitlab.com/gitlab-examples/docker.
...
...
@@ -207,15 +209,21 @@ In order to do that, follow the steps:
- docker run my-docker-image /script/to/run/tests
```
By sharing the docker daemon, you are effectively disabling all
Notes:
* By sharing the docker daemon, you are effectively disabling all
the security mechanisms of containers and exposing your host to privilege
escalation which can lead to container breakout. For example, if a project
ran `docker rm -f $(docker ps -a -q)` it would remove the GitLab Runner
containers.
Also, concurrent builds may not work; if your tests
* Concurrent builds may not work; if your tests
create containers with specific names, they may conflict with each other.
* Sharing files and directories from the source repo into containers may not
work as expected since volume mounting is done in the context of the host
machine, not the build container.
e.g. `docker run --rm -t -i -v $(pwd)/src:/home/app/src test-image:latest run_app_tests`
## Using the GitLab Container Registry
Once you've built a Docker image, you can push it up to the built-in [GitLab Container Registry](../../container_registry/README.md).
