Answers: <p>Gitlab CI supports running all of your builds inside Docker containers so you have a clean build environment every time. I'd recommend starting with the basic <a href="https://docs.gitlab.com/runner/executors/docker.html" rel="nofollow noreferrer">Docker executor</a> but there is also an opportunity to <a href="https://docs.gitlab.com/runner/install/autoscaling.html" rel="nofollow noreferrer">autoscale your runners</a> using <a href="https://docs.docker.com/machine/" rel="nofollow noreferrer">Docker Machine</a> or to <a href="https://docs.gitlab.com/runner/executors/kubernetes.html" rel="nofollow noreferrer">execute the runners on a Kubernetes pod</a>.</p>
  
  <p>If you need to use Docker as part of your build (such as building, tagging and pushing images) then you can either use <a href="https://docs.gitlab.com/ce/ci/docker/using_docker_build.html#use-docker-in-docker-executor" rel="nofollow noreferrer">Docker in Docker</a> or, preferably, <a href="https://docs.gitlab.com/ce/ci/docker/using_docker_build.html#use-docker-socket-binding" rel="nofollow noreferrer">bind mount the Docker socket</a> of the host into your runner allowing it to run Docker containers as a sibling rather than child process. Note that the <a href="https://jpetazzo.github.io/" rel="nofollow noreferrer">original author of DIND</a> <a href="https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/" rel="nofollow noreferrer">recommends</a> using bind mounting instead of DIND, especially for CI.</p>
  
  <p>To bind mount the Docker socket register your runner with the following command:</p>
  
  <pre><code>sudo gitlab-runner register -n \
    --url https://gitlab.com/ \
    --registration-token REGISTRATION_TOKEN \
    --executor docker \
    --description "My Docker Runner" \
    --docker-image "docker:latest" \
    --docker-volumes /var/run/docker.sock:/var/run/docker.sock
  </code></pre>
  
  <p>And then in your <code>.gitlab-ci.yml</code> file you can define your job as so:</p>
  
  <pre><code>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
  </code></pre>
  
  <p>Using just the basic <code>docker</code> image rather than the <code>docker:dind</code> image</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-09-12T08:57:41.220Z
Answers: 2017-09-12T08:57:41.220Z
Answers: ydaetskcoR
Answers: <p>I prefer <a href="https://docs.gitlab.com/ce/ci/docker/using_docker_build.html" rel="nofollow noreferrer">DIND</a> as every run start with a clean sheet. Otherwise the docker image will be built on the gitlab host itself.</p>
  
  <ul>
  <li>installation of gitlab runner</li>
  <li>registration of runner</li>
  </ul>
  
  <blockquote>
  <pre><code>sudo gitlab-ci-multi-runner register -n \
    --url https://gitlab.com/ \
    --registration-token REGISTRATION_TOKEN \
    --executor docker \
    --description "My Docker Runner" \
    --docker-image "docker:latest" \
    --docker-privileged
  </code></pre>
  </blockquote>
  
  <ul>
  <li>commit and push .gitlab-ci.yml</li>
  </ul>
  
  <blockquote>
  <pre><code>image: docker:latest
  
  # When using dind, it's wise to use the overlayfs driver for
  # improved performance.
  variables:
    DOCKER_DRIVER: overlay2
  
  services:
  - docker:dind
  
  before_script:
  - docker info
  
  build:
    stage: build
    script:
    - docker build -t my-docker-image .
    - docker run my-docker-image /script/to/run/tests
  </code></pre>
  </blockquote>
  
Answers: CC BY-SA 3.0
Answers: 2017-09-11T19:42:32.010Z
Answers: 2017-09-11T19:42:32.010Z
Answers: 030
Body: <p>With Bamboo, a best practice for infrastructure management of agents seems to be using Docker: any time you need a new version of compiler or test tool, the path to deploy a modified version of an agent is very fast.</p>
  
  <p>How could this work with GitLab?</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-09-11T14:04:23.717Z
Comments: This topic seems well documented on gitlab website: https://docs.gitlab.com/ce/ci/docker/using_docker_images.html
Comments: Michael Pereira
Tags: <docker><continuous-integration><gitlab>
Title: Mastering CI infrastructure changes with GitLab
UserDisplayName: Ta Mu
ThreadText: # Mastering CI infrastructure changes with GitLab
  
  (Asked by: username_0 on 2017-09-11)
  
  With Bamboo, a best practice for infrastructure management of agents seems to be using Docker: any time you need a new version of compiler or test tool, the path to deploy a modified version of an agent is very fast.
  
  How could this work with GitLab?
  
  **Tags:** docker, continuous-integration, gitlab
  
  > **Comments:**
  > **username_1**: This topic seems well documented on gitlab website: https://docs.gitlab.com/ce/ci/docker/using_docker_images.html  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2017-09-12. Score: 3
  
  Gitlab CI supports running all of your builds inside Docker containers so you have a clean build environment every time. I'd recommend starting with the basic [Docker executor](https://docs.gitlab.com/runner/executors/docker.html) but there is also an opportunity to [autoscale your runners](https://docs.gitlab.com/runner/install/autoscaling.html) using [Docker Machine](https://docs.docker.com/machine/) or to [execute the runners on a Kubernetes pod](https://docs.gitlab.com/runner/executors/kubernetes.html).
  
  If you need to use Docker as part of your build (such as building, tagging and pushing images) then you can either use [Docker in Docker](https://docs.gitlab.com/ce/ci/docker/using_docker_build.html#use-docker-in-docker-executor) or, preferably, [bind mount the Docker socket](https://docs.gitlab.com/ce/ci/docker/using_docker_build.html#use-docker-socket-binding) of the host into your runner allowing it to run Docker containers as a sibling rather than child process. Note that the [original author of DIND](https://jpetazzo.github.io/) [recommends](https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/) using bind mounting instead of DIND, especially for CI.
  
  To bind mount the Docker socket register your runner with the following command:
  
  ```
  sudo gitlab-runner register -n \
    --url https://gitlab.com/ \
    --registration-token REGISTRATION_TOKEN \
    --executor docker \
    --description "My Docker Runner" \
    --docker-image "docker:latest" \
    --docker-volumes /var/run/docker.sock:/var/run/docker.sock
  
  ```
  
  And then in your `.gitlab-ci.yml` file you can define your job as so:
  
  ```
  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
  
  ```
  
  Using just the basic `docker` image rather than the `docker:dind` image
  
  
  ---
  
  ### Answer by username_3 on 2017-09-11. Score: 1
  
  I prefer [DIND](https://docs.gitlab.com/ce/ci/docker/using_docker_build.html) as every run start with a clean sheet. Otherwise the docker image will be built on the gitlab host itself.
  
  * installation of gitlab runner
  * registration of runner
  
  > ```
  > sudo gitlab-ci-multi-runner register -n \
  >   --url https://gitlab.com/ \
  >   --registration-token REGISTRATION_TOKEN \
  >   --executor docker \
  >   --description "My Docker Runner" \
  >   --docker-image "docker:latest" \
  >   --docker-privileged
  >
  > ```
  
  * commit and push .gitlab-ci.yml
  
  > ```
  > image: docker:latest
  >
  > # When using dind, it's wise to use the overlayfs driver for
  > # improved performance.
  > variables:
  >   DOCKER_DRIVER: overlay2
  >
  > services:
  > - docker:dind
  >
  > before_script:
  > - docker info
  >
  > build:
  >   stage: build
  >   script:
  >   - docker build -t my-docker-image .
  >   - docker run my-docker-image /script/to/run/tests
  >
  > ```
  
  
  ---
  
  