当 运行 带有 FF_NETWORK_PER_BUILD 标志的 Gitlab CI 作业时 --network=host 是否仍然连接到主机网络？
Does --network=host still connect to the host network when running a Gitlab CI job with the FF_NETWORK_PER_BUILD flag?
我正在尝试 运行 在 Gitlab CI 作业中使用 docker 中的 docker 进行测试。我的理解是，启用 FF_NETWORK_PER_BUILD 标志将自动创建一个用户定义的桥接网络，作业 运行ner 和该作业中所有创建的 dockers 将连接到......但是看着 Gitlab 文档我有点困惑...
本页：https://docs.gitlab.com/ee/ci/services/
给出了将 docker:dind 服务与 FF_NETWORK_PER_BUILD: "true"
结合使用的示例
但是当使用 docker run 时，它们仍然包含 --network=host 标志。
这里是给定的例子：
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"
我正在努力确保我在这份工作中的所有 docker 都在他们自己的独立网络上，
那么在这种情况下使用 --network=host 标志是否会将新的 docker 连接到实际作业 运行 所在的主机服务器？或者刚刚创建的每个工作网络？在什么情况下您希望创建一个 per-job 网络并仍然将一个新的 docker 连接到主机网络？
如有任何建议，我们将不胜感激！
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?
这可能令人困惑，因为 --network=host 中的“主机”并不像底层运行器主机/'baremetal' 系统中那样表示 主机。要了解这里发生了什么，我们必须首先了解 docker:dind 服务的工作原理。
当您使用服务 docker:dind 从构建作业中为 docker 命令提供支持时，您是 运行 容器'on' docker:dind服务；它是 docker 守护进程。
当您向 docker run 提供 --host 选项时，它指的是 daemon I.E. 的主机网络。 docker:dind 容器，而不是底层系统主机。
当您指定 FF_NETWORK_PER_BUILD 时，即为构建作业指定 docker 网络及其封装所有作业容器的服务容器。
因此，相关活动按顺序发生如下：
- GitLab runner 为构建创建一个新的 docker 网络
- 运行器创建
docker:dind 和 tutum/wordpress:latest 服务，连接到步骤 (1) 中创建的网络
- 您的作业容器启动，也连接到步骤 (1) 中的 docker 网络
- 您的作业联系
docker:dind 容器并要求它启动一个新的 curl 容器，连接到 docker:dind 容器的主机网络 -- 在步骤 (1) 中创建的相同网络，允许它到达服务容器。
如果没有 --network=host 标志，创建的容器将位于不同的桥接网络上，并且无法访问从步骤 (1) 创建的网络。
我正在尝试 运行 在 Gitlab CI 作业中使用 docker 中的 docker 进行测试。我的理解是，启用 FF_NETWORK_PER_BUILD 标志将自动创建一个用户定义的桥接网络，作业 运行ner 和该作业中所有创建的 dockers 将连接到......但是看着 Gitlab 文档我有点困惑...
本页：https://docs.gitlab.com/ee/ci/services/
给出了将 docker:dind 服务与 FF_NETWORK_PER_BUILD: "true"
但是当使用 docker run 时，它们仍然包含 --network=host 标志。
这里是给定的例子：
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"
我正在努力确保我在这份工作中的所有 docker 都在他们自己的独立网络上，
那么在这种情况下使用 --network=host 标志是否会将新的 docker 连接到实际作业 运行 所在的主机服务器？或者刚刚创建的每个工作网络？在什么情况下您希望创建一个 per-job 网络并仍然将一个新的 docker 连接到主机网络？
如有任何建议，我们将不胜感激！
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?
这可能令人困惑，因为 --network=host 中的“主机”并不像底层运行器主机/'baremetal' 系统中那样表示 主机。要了解这里发生了什么，我们必须首先了解 docker:dind 服务的工作原理。
当您使用服务 docker:dind 从构建作业中为 docker 命令提供支持时，您是 运行 容器'on' docker:dind服务；它是 docker 守护进程。
当您向 docker run 提供 --host 选项时，它指的是 daemon I.E. 的主机网络。 docker:dind 容器，而不是底层系统主机。
当您指定 FF_NETWORK_PER_BUILD 时，即为构建作业指定 docker 网络及其封装所有作业容器的服务容器。
因此，相关活动按顺序发生如下：
- GitLab runner 为构建创建一个新的 docker 网络
- 运行器创建
docker:dind和tutum/wordpress:latest服务，连接到步骤 (1) 中创建的网络 - 您的作业容器启动，也连接到步骤 (1) 中的 docker 网络
- 您的作业联系
docker:dind容器并要求它启动一个新的curl容器，连接到docker:dind容器的主机网络 -- 在步骤 (1) 中创建的相同网络，允许它到达服务容器。
如果没有 --network=host 标志，创建的容器将位于不同的桥接网络上，并且无法访问从步骤 (1) 创建的网络。