using_docker_build.md 11.4 KB
Newer Older
1 2
# Using Docker Build

3
GitLab CI allows you to use Docker Engine to build and test docker-based projects.
4 5 6

**This also allows to you to use `docker-compose` and other docker-enabled tools.**

7
One of the new trends in Continuous Integration/Deployment is to:
8

9 10
1. create an application image,
1. run tests against the created image,
11 12
1. push image to a remote registry, and
1. deploy to a server from the pushed image.
13

14
It's also useful when your application already has the `Dockerfile` that can be used to create and test an image:
15 16 17 18 19 20 21
```bash
$ docker build -t my-image dockerfiles/
$ docker run my-docker-image /script/to/run/tests
$ docker tag my-image my-registry:5000/my-image
$ docker push my-registry:5000/my-image
```

22
This requires special configuration of GitLab Runner to enable `docker` support during builds.
23

24 25 26 27 28
## Runner Configuration

There are three methods to enable the use of `docker build` and `docker run` during builds; each with their own tradeoffs.

### Use shell executor
29 30

The simplest approach is to install GitLab Runner in `shell` execution mode.
Mark Pundsack's avatar
Mark Pundsack committed
31
GitLab Runner then executes build scripts as the `gitlab-runner` user.
32 33 34 35 36 37

1. Install [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/#installation).

1. During GitLab Runner installation select `shell` as method of executing build scripts or use command:

    ```bash
Mark Pundsack's avatar
Mark Pundsack committed
38
    $ sudo gitlab-ci-multi-runner register -n \
39
      --url https://gitlab.com/ci \
Mark Pundsack's avatar
Mark Pundsack committed
40
      --registration-token REGISTRATION_TOKEN \
41
      --executor shell \
42 43 44
      --description "My Runner"
    ```

45
2. Install Docker Engine on server.
46

47
    For more information how to install Docker Engine on different systems checkout the [Supported installations](https://docs.docker.com/engine/installation/).
48 49

3. Add `gitlab-runner` user to `docker` group:
50

51 52 53 54 55
    ```bash
    $ sudo usermod -aG docker gitlab-runner
    ```

4. Verify that `gitlab-runner` has access to Docker:
56

57 58 59
    ```bash
    $ sudo -u gitlab-runner -H docker info
    ```
60

61 62 63 64
    You can now verify that everything works by adding `docker info` to `.gitlab-ci.yml`:
    ```yaml
    before_script:
      - docker info
65

66 67 68 69 70 71 72 73
    build_image:
      script:
        - docker build -t my-docker-image .
        - docker run my-docker-image /script/to/run/tests
    ```

5. You can now use `docker` command and install `docker-compose` if needed.

74
> **Note:**
Mark Pundsack's avatar
Mark Pundsack committed
75 76
* By adding `gitlab-runner` to the `docker` group you are effectively granting `gitlab-runner` full root permissions.
For more information please read [On Docker security: `docker` group considered harmful](https://www.andreas-jung.com/contents/on-docker-security-docker-group-considered-harmful).
77

78
### Use docker-in-docker executor
79

80 81
The second approach is to use the special docker-in-docker (dind)
[Docker image](https://hub.docker.com/_/docker/) with all tools installed
82 83 84
(`docker` and `docker-compose`) and run the build script in context of that
image in privileged mode.

Mark Pundsack's avatar
Mark Pundsack committed
85
In order to do that, follow the steps:
86 87 88

1. Install [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/#installation).

89 90
1. Register GitLab Runner from the command line to use `docker` and `privileged`
   mode:
91 92

    ```bash
93
    sudo gitlab-ci-multi-runner register -n \
94
      --url https://gitlab.com/ci \
95
      --registration-token REGISTRATION_TOKEN \
96 97
      --executor docker \
      --description "My Docker Runner" \
98
      --docker-image "docker:latest" \
99 100
      --docker-privileged
    ```
101

102 103 104 105 106
    The above command will register a new Runner to use the special
    `docker:latest` 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] mode, you always have to use `privileged = true`
    in your Docker containers.
107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124

    The above command will create a `config.toml` entry similar to this:

    ```
    [[runners]]
      url = "https://gitlab.com/ci"
      token = TOKEN
      executor = "docker"
      [runners.docker]
        tls_verify = false
        image = "docker:latest"
        privileged = true
        disable_cache = false
        volumes = ["/cache"]
      [runners.cache]
        Insecure = false
    ```

Mark Pundsack's avatar
Mark Pundsack committed
125
1. You can now use `docker` in the build script (note the inclusion of the `docker:dind` service):
126

127
    ```yaml
128 129 130 131 132
    image: docker:latest

    services:
    - docker:dind

133
    before_script:
134
    - docker info
135 136 137

    build:
      stage: build
138
      script:
139 140
      - docker build -t my-docker-image .
      - docker run my-docker-image /script/to/run/tests
141 142
    ```

Mark Pundsack's avatar
Mark Pundsack committed
143
Docker-in-Docker works well, and is the recommended configuration, but it is not without its own challenges:
Mark Pundsack's avatar
Mark Pundsack committed
144
* By enabling `--docker-privileged`, you are effectively disabling all of
145 146 147
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].
Mark Pundsack's avatar
Mark Pundsack committed
148
* Using docker-in-docker, each build is in a clean environment without the past
149
history. Concurrent builds work fine because every build gets 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.
Mark Pundsack's avatar
Mark Pundsack committed
150
* By default, `docker:dind` uses `--storage-driver vfs` which is the slowest form
151
offered.
152 153

An example project using this approach can be found here: https://gitlab.com/gitlab-examples/docker.
154

155
### Use Docker socket binding
156 157 158

The third approach is to bind-mount `/var/run/docker.sock` into the container so that docker is available in the context of that image.

Mark Pundsack's avatar
Mark Pundsack committed
159
In order to do that, follow the steps:
160 161 162

1. Install [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/#installation).

Mark Pundsack's avatar
Mark Pundsack committed
163
1. Register GitLab Runner from the command line to use `docker` and share `/var/run/docker.sock`:
164 165

    ```bash
166
    sudo gitlab-ci-multi-runner register -n \
167
      --url https://gitlab.com/ci \
168
      --registration-token REGISTRATION_TOKEN \
169 170 171 172 173 174 175 176
      --executor docker \
      --description "My Docker Runner" \
      --docker-image "docker:latest" \
      --docker-volumes /var/run/docker.sock:/var/run/docker.sock
    ```

    The above command will register a new Runner to use the special
    `docker:latest` image which is provided by Docker. **Notice that it's using
177
    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.
178 179 180 181 182 183

    The above command will create a `config.toml` entry similar to this:

    ```
    [[runners]]
      url = "https://gitlab.com/ci"
184
      token = REGISTRATION_TOKEN
185 186 187 188 189 190
      executor = "docker"
      [runners.docker]
        tls_verify = false
        image = "docker:latest"
        privileged = false
        disable_cache = false
191
        volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]
192 193 194 195
      [runners.cache]
        Insecure = false
    ```

196
1. You can now use `docker` in the build script (note that you don't need to include the `docker:dind` service as when using the Docker in Docker executor):
197 198 199 200 201 202 203 204 205 206 207 208 209 210

    ```yaml
    image: docker:latest

    before_script:
    - docker info

    build:
      stage: build
      script:
      - docker build -t my-docker-image .
      - docker run my-docker-image /script/to/run/tests
    ```

211
While the above method avoids using Docker in privileged mode, you should be aware of the following implications:
Mark Pundsack's avatar
Mark Pundsack committed
212
* By sharing the docker daemon, you are effectively disabling all
213 214 215 216
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.
Mark Pundsack's avatar
Mark Pundsack committed
217
* Concurrent builds may not work; if your tests
218
create containers with specific names, they may conflict with each other.
Mark Pundsack's avatar
Mark Pundsack committed
219 220 221 222 223
* 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`

224 225
## Using the GitLab Container Registry

226 227
> **Note:**
This feature requires GitLab 8.8 and GitLab Runner 1.2.
228

229 230 231 232 233
Once you've built a Docker image, you can push it up to the built-in [GitLab Container Registry](../../container_registry/README.md). For example, if you're using
docker-in-docker on your runners, this is how your `.gitlab-ci.yml` could look:


```yaml
234
 build:
Mark Pundsack's avatar
Mark Pundsack committed
235
   image: docker:latest
236 237
   services:
   - docker:dind
238 239 240 241 242 243 244
   stage: build
   script:
     - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.example.com
     - docker build -t registry.example.com/group/project:latest .
     - docker push registry.example.com/group/project:latest
```

245 246 247 248 249 250
You have to use the credentials of the special `gitlab-ci-token` user with its
password stored in `$CI_BUILD_TOKEN` in order to push to the Registry connected
to your project. This allows you to automate building and deployment of your
Docker images.

Here's a more elaborate example that splits up the tasks into 4 pipeline stages,
251 252 253 254 255 256
including two tests that run in parallel. The build is stored in the container
registry and used by subsequent stages, downloading the image
when needed. Changes to `master` also get tagged as `latest` and deployed using
an application-specific deploy script:

```yaml
Mark Pundsack's avatar
Mark Pundsack committed
257
image: docker:latest
258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308
services:
- docker:dind

stages:
- build
- test
- release
- deploy

variables:
  CONTAINER_TEST_IMAGE: registry.example.com/my-group/my-project:$CI_BUILD_REF_NAME
  CONTAINER_RELEASE_IMAGE: registry.example.com/my-group/my-project:latest

before_script:
  - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.example.com

build:
  stage: build
  script:
    - docker build --pull -t $CONTAINER_TEST_IMAGE .
    - docker push $CONTAINER_TEST_IMAGE

test1:
  stage: test
  script:
    - docker pull $CONTAINER_TEST_IMAGE
    - docker run $CONTAINER_TEST_IMAGE /script/to/run/tests

test2:
  stage: test
  script:
    - docker pull $CONTAINER_TEST_IMAGE
    - docker run $CONTAINER_TEST_IMAGE /script/to/run/another/test

release-image:
  stage: release
  script:
    - docker pull $CONTAINER_TEST_IMAGE
    - docker tag $CONTAINER_TEST_IMAGE $CONTAINER_RELEASE_IMAGE
    - docker push $CONTAINER_RELEASE_IMAGE
  only:
    - master

deploy:
  stage: deploy
  script:
    - ./deploy.sh
  only:
    - master
```

309 310 311 312 313
Some things you should be aware of when using the Container Registry:
* You must log in to the container registry before running commands. Putting this in `before_script` will run it before each build job.
* Using `docker build --pull` makes sure that Docker fetches any changes to base images before building just in case your cache is stale. It takes slightly longer, but means you don’t get stuck without security patches to base images.
* Doing an explicit `docker pull` before each `docker run` makes sure to fetch the latest image that was just built. This is especially important if you are using multiple runners that cache images locally. Using the git SHA in your image tag makes this less necessary since each build will be unique and you shouldn't ever have a stale image, but it's still possible if you re-build a given commit after a dependency has changed.
* You don't want to build directly to `latest` in case there are multiple builds happening simultaneously.
Mark Pundsack's avatar
Mark Pundsack committed
314

315
[docker-in-docker]: https://blog.docker.com/2013/09/docker-can-now-run-within-docker/
316
[docker-cap]: https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities