GitLab CI/CD can be used with Docker to build, test, and push container images.

Tier: Free, Premium, Ultimate. Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated.

To run Docker commands in CI/CD jobs, you must configure GitLab Runner to support `docker` commands. The approach you choose depends on your infrastructure, executor type, and security requirements. Some approaches require `privileged` mode on the runner. If you cannot enable `privileged` mode, use a Docker alternative.

## Approaches

- **Shell executor**: Shell executor, no privileged mode, Linux.

- **Docker-in-Docker**: Docker or Kubernetes executor, privileged mode, Linux.

- **Docker socket binding**: Docker or Kubernetes executor, no privileged mode, Linux.

- **Docker pipe binding**: Docker or Kubernetes executor, no privileged mode, Windows.

## Use Docker-in-Docker

Docker-in-Docker (`dind`) means your registered runner uses the Docker executor or the Kubernetes executor, and the executor uses a container image of Docker to run your CI/CD jobs. Each job gets its own isolated Docker daemon, so concurrent jobs do not conflict. This is the recommended approach when your runner supports `privileged` mode.

## Use the shell executor

To include Docker commands in your CI/CD jobs, you can configure your runner to use the `shell` executor. In this configuration, the `gitlab-runner` user runs the Docker commands, but needs permission to do so. You can now use `docker` commands (and install Docker Compose if needed).

When you add `gitlab-runner` to the `docker` group, you effectively grant `gitlab-runner` full root permissions.

## Use Docker socket binding

To use Docker commands in your CI/CD jobs, you can bind-mount `/var/run/docker.sock` into the build container. Docker is then available in the context of the image.

When you use Docker socket binding, you avoid running Docker in privileged mode. However, the implications of this method are:

- When you share the Docker daemon, you effectively disable the container’s security mechanisms and expose your host to privilege escalation. This can cause container breakout.

- Concurrent jobs might not work. If your tests create containers with specific names, they might conflict with each other.

- Any containers created by Docker commands are siblings of the runner, rather than children of the runner. This might cause complications for your workflow.

- Sharing files and directories from the source repository into containers might not work as expected. Volume mounting is done in the context of the host machine, not the build container.