如果要作单点端口映射，则需要结合constraint和label来定位具体的proxy机器吧。

如果不用这种模式，，ingress确实又太浪费集群端口了。。

纠结，，看看如何和compose v3作很好的结合吧。。

阿西巴~~~~

=================

https://blog.lab99.org/post/docker-2016-11-14-what-is-new-in-docker-1-13.html#yun-xu-docker-service-create-ying-she-su-zhu-duan-kou-er-bu-shi-bian-jie-fu-zai-jun-heng-wang-luo-duan-kou

=================

网络 

允许 docker run 连入指定的 swarm mode 的网络 

在 Docker 1.12 发布新的 Swarm Mode 之后，很多人都问过这样的问题，怎么才能让 docker run 的容器连入 Swarm Mode 服务的 overlay 网络中去？答案是不可以，因为 swarm 的 overlay 网络是为了 swarm mode service 准备的，相对更健壮，而直接使用 docker run，会破坏了这里面的安全模型。

但是由于大家需求很多，于是提供了一种折衷的办法。1.13 允许建立网络的时候，设定该网络为 attachable，允许之后的 docker run 的容器连接到该网络上。

我们创建一个默认的、不允许之后 attach 的网络：

然后再创建一个允许 attach 的网络，这里会使用 1.13 新加入的 --attachable 参数：

然后我们启动一个 web 服务，连入这两个网络：

现在我们用 docker run 启动一个容器连入第一个网络：

由于 mynet1 不允许手动 attach 所以这里报错了。

在 1.12 的情况下，会报告该网络无法给 docker run 使用：

不过，--attachable 实际上是将网络的安全模型打开了一个缺口，因此这不是默认设置，而且并不推荐使用。用户在使用这个选项建立网络的时候，一定要知道自己在做什么。

允许 docker service create 映射宿主端口，而不是边界负载均衡网络端口 

docker service create 中的 --publish 格式有进一步的变化。（在 1.13 的 RC 期间，曾经去掉 --publish，改为 --port，经过讨论后，决定保持一致性，继续使用 --publish，不使用新的 --port 选项。）

在 1.12 中，docker service create 允许使用参数 --publish 80:80 这类形式映射边界(ingress)网络的端口，这样的映射会享受边界负载均衡，以及 routing mesh。

从 1.13 开始，增加另一种映射模式，被称为 host 模式，也就是说，用这种模式映射的端口，只会映射于容器所运行的主机上。这就和一代 Swarm 中一样了。虽然失去了边界负载均衡，但是确定了映射点，在有的时候这种情况是需要的。

现在 --publish 的新的参数形式和 --mount 差不多。参数值为 , 逗号分隔的键值对，键值间以 = 等号分隔。目前支持 4 项内容：

• protocol： 支持 tcp 或者 udp
• mode： 支持 ingress 或者 host
• target： 容器的端口号
• published： 映射到宿主的端口号

比如，与 -p 8080:80 等效的 --publish 新格式选项为：

当然我们可以继续使用 -p 8080:80，但是新的选项格式增加了更多的可能。比如，使用 1.13 开始加入的 host 映射模式：

运行成功后，查看一下服务容器运行的节点：

我们可以看到，集群有3个节点，而服务就一个副本，跑到了 d3 上。如果这是以前的使用边界负载均衡的网络 ingress 的话，那么我们访问任意节点的 80 端口都会看到页面。

但是，host 模式不同，它只映射容器所在宿主的端口。因此，如果我们 curl d1 的话，应该什么看不到网页，而 curl d3 的话就会看到页面：