Docker 1.9:向运行中的nginx容器添加-链接目标

Question

问题：

我部署在码头1.9上

我首先运行一个nginx容器：

docker run \
  --name=nginx \
  --link=php1:php1 \
  --link=php2:php2 \
  --restart=always \
  -p 80:80 -p 443:443 \
  -v /var/docker/nginx/conf.d:/etc/nginx/conf.d \
  -d nginx:latest

请注意，我链接了两个exist php容器：php1和php2。

现在，我启动了一个新的容器php3。

我可以在主机上用一个bash脚本添加一个nginx到php3的链接吗？

我为什么要这么做？

因为我有许多不同的php应用程序要部署，而且每个实例我都将创建一个新的php:fpm容器来运行代码。

他们共享相同的nginx服务。

我想为php应用程序制作一个动态部署bash脚本，以进行单键部署。

但是我被阻止了，因为nginx不知道新创建的php主机名。

Answer 1

动态添加链接是第3155期的一部分。

预libnetwork (1.9，主要是1.10)，您可以使用jwilder/nginx代理来生成正确的nginx.conf，并在每次需要链接新容器时重新启动nginx服务。

但是，随着libnetwork (及其0.6 2月初发布)的出现，docker 1.10推出了新的码头网络特征。

这意味着您将能够将您的容器附加到(用户定义的网络)上，使它们通过名称在彼此之间自动可见！

$ docker run -itd --name=container2 busybox
498eaaaf328e1018042c04b2de04036fc04719a6e39a097a4f4866043a2c2152

然后创建一个独立的、需要测试的桥网络。

$ docker network create -d bridge --subnet 172.25.0.0/16 isolated_nw
06a62f1c73c4e3107c0f555b7a5f163309827bfbbf999840166065a8f35455a8

$ docker run -itd --name=container2 busybox
498eaaaf328e1018042c04b2de04036fc04719a6e39a097a4f4866043a2c2152
$ docker network connect isolated_nw container2

$ docker run --net=isolated_nw --ip=172.25.3.3 -itd --name=container3 busybox

所选IP地址是容器网络配置的一部分，将在容器重新加载期间保留。 这个特性只能在用户定义的网络上使用，因为它们保证它们的子网配置不会在守护进程重新加载时发生变化。 在用户定义的isolated_nw上，Docker服务器为网络中的其他容器启用名称解析。在container2内部，可以按名称ping container3

它的意思是，与码头1.10，容器连接到一个用户定义的网络可以看到对方的名字。

但还有更多：在用户定义的网络中连接容器

$ docker run --net=isolated_nw -itd --name=container4 --link container5:c5 busybox
01b5df970834b77a9eadbaff39051f237957bd35c4c56f11193e0594cfd5117c

在--link的帮助下，container4也可以使用别名名称c5到达container5。 请注意，在创建container4**，时，我们链接到一个名为** container5 的容器，该容器尚未创建。 这是默认网桥网络中遗留链路与用户定义网络中新链路功能之间的行为差异之一。- -遗留链接本质上是静态的，它是硬绑定容器的别名，它不允许链接容器重新启动。 -尽管用户定义的网络中的新链接功能本质上是动态的，并且支持链接容器重新启动，包括容忍链接容器上的ip地址更改。

您将在新的码头1.10有两个选择：

• 或者有一个固定的NGiNX配置，对一个可能尚未创建的容器( c1、c2、c3)的固定列表进行反向代理。每次创建新容器时，都使用适当的链接--link c2:myNewContainer2重新启动您的--link c2:myNewContainer2容器。
• 或者您的NGiNX容器主进程实际上监视用户定义的网络，对于检测到的每个新容器，重新生成NGiNX conf，并优雅地重新启动NGiNX守护进程。