I am trying to run a test using docker in docker within a Gitlab CI job. My understanding is that enabling the FF_NETWORK_PER_BUILD flag will automatically create a user-defined bridge network that the job runner and all of the created dockers within that job will connect to... but looking at the Gitlab documentation I am slightly confused...

This page: https://docs.gitlab.com/ee/ci/services/

Gives an example of using the docker:dind service with FF_NETWORK_PER_BUILD: "true"

But then when using docker run they still include the --network=host flag.

Here is the given example:

  stage: build
  image: docker:19.03.1
  services:
    - docker:dind                    # necessary for docker run
    - tutum/wordpress:latest
  variables:
    FF_NETWORK_PER_BUILD: "true"     # activate container-to-container networking
  script: |
    docker run --rm --name curl \
      --volume  "$(pwd)":"$(pwd)"    \
      --workdir "$(pwd)"             \
      --network=host                 \
      curlimages/curl:7.74.0 curl "http://tutum-wordpress"

I am trying to ensure that all of my dockers within this job are on their own separate network, so does using the --network=host flag in this instance connect the new docker to the host server that the actual job runner is on? Or the per-job network that was just created? In what case would you want to create a per-job network and still connect a new docker to the host network?

Would appreciate any advice!

CodePudding user response：

does using the --network=host flag in this instance connect the new docker to the host server that the actual job runner is on? Or the per-job network that was just created?

This is probably confusing because the "host" in --network=host does not mean host as in the underlying runner host / 'baremetal' system. To understand what is happening here, we must first understand how the docker:dind service works.

When you use the service docker:dind to power docker commands from your build job, you are running containers 'on' the docker:dind service; it is the docker daemon.

When you provide the --host option to docker run it refers to the host network of the daemon I.E. the docker:dind container, not the underlying system host.

When you specify FF_NETWORK_PER_BUILD that was specifying the docker network for the build job and its service containers that encapsulates all of your job's containers.

So, in order, the relevant activities happen as follows:

1. The GitLab runner creates a new docker network for the build
2. The runner creates the docker:dind and tutum/wordpress:latest services, connected to the network created in step (1)
3. Your job container starts, also connected to the docker network in step (1)
4. Your job contacts the docker:dind container and asks it to start a new curl container, connected to the host network of the docker:dind container -- the same network created in step (1), allowing it to reach the service containers.

Without the --network=host flag, the created container would be on a different bridge network and be unable to reach the network created from step (1).