在本文中我们会探究创建可对接网络的各种方式,以及一些潜在的应用案例,并且向大家演示如何使用新的 docker stack 命令。
Docker 网络可以通过 Docker CLI、API 或者在 Docker Compose 文件里定义的方式创建。
Docker CLI 有几个管理网络的命令例如 create, ls, rm 和 inspect。可对接网络是 swarm overlay 网络的类型:
- $ docker network create --driver=overlay --attachable core-infra
- zhxv6ymxhf2u0983x132hvzxf
- $ docker network ls
- NETWORK ID NAME DRIVER SCOPE
- d1b84196c831 bridge bridge local
- zhxv6ymxhf2u core-infra overlay swarm
Scope 列表明可对接网络只对在 swarm 的 Docker 主机可用。它可以是一个单节点 swarm 或者大规模 swarm 集群,因为 attackable 是 overlay 网络的一个类型。
现在可以创建一个 Swarm 服务并指定网络:
- $ docker service create --publish 80:80 --network=core-infra --name nginx nginx
- ufs0fhipmxgh4w8wdf04sbkz3
这和通常情况下在默认 ingress 网络创建服务一样。可对接选项很有用因为它意味着可以在这个新网络范围内使用 docker run 来创建容器。
所以让我们使用 docker run 来创建一个 Alpine Linux 容器,安装 curl 来检测 nginx 实例:
我们可以通过名称访问 nginx 服务,这在主机是无法完成的;还可以访问 swarm 上没有 published 的部分,非常方便进行调试。
一旦创建了容器,docker network inspect core-infra 会展示网络的 Subnet 和其他特征信息。
在 swarm 模式下如果运行 docker-compose up,Docker Compose 会报错,但是在 1.13Docker 核心项目加入了一个名叫 stack 的新功能。stack 使用已经实践测试过的 Docker Compose 格式在 swarm 上部署服务。
docker stack deploy 命令相当于 Docker Compose(一个 Python 应用)用 Golang 重写。
这是一个部署 compose 文件作为 stack 的例子:
- $ docker stack deploy webtier --compose-file=./docker-compose.yml
stack 命令不能创建新的可对接网络。为了能够让可对接网络使用 stack,必须通过 docker network create 提早定义它,然后把网络指定为 external:
- version: "3"
- services:
- nginx:
- image: nginx
- networks:
- - core-infra
- networks:
- core-infra:
- external: true
---
- $ docker stack deploy webtier --compose-file=./docker-compose.yml
- Creating service webtier_nginx
- $ docker stack ls
- NAME SERVICES
- webtier 1
- $ docker stack ps ex1
- ID NAME IMAGE NODE DESIRED STATE
- sxj04xh2z29j webtier_nginx.1 nginx:latest moby Running
stack 包括一系列被标签分组到一起的 Swarm 服务,可以通过 stack 文件创建的服务上运行 docker inspect 命令看到:
要更新一个已经使用的 stack,只需要再次输入 docker stack deploy。
现在来看几个如何使用可对接网络的例子。
总有各种理由让人们想要创建一个 Privileged 容器。
管理硬件的例子——目前来说我还没有想到让它对 Swarm 服务可用的方法。
可对接网络提供了从 swarm 服务中分离并调度 Privileged 容器的能力,并且可以让它们保持通信。
可对接网络帮助 Docker Swarm 服务与以前称为 Swarm 的编排版本进行交互操作。这一点对用户来说很重要,因为他们已经用 Docker 数据中心更早期的版本建立了一套解决方案。
老的 Swarm 和 Swarm 服务的关键不同在于前者允许容器以一种苛刻的规则方式被调度。声明式 swarm 服务允许定义一个我们想要实现的最终状态,之后 swarm 会进行应用并维持这个状态。
这意味着团队可以开始接受并向 Swarm 服务转移,享受声明式服务在完全 ad-hoc 容器上的各种好处。
无服务 framework
无服务和基于功能的 framework 可以利用一系列声明式服务,同时调度 ad-hoc 容器按需执行无服务的功能。
Ad-hoc 任务 / 调试
如果不直接使用 Docker API,Ad-hoc 任务很难通过 Swarm 服务来调度。这种交互操作允许我们进行维护和诊断的工作。
这有几个例子:
作者:Alex Ellis
来源: http://www.tuicool.com/articles/EFBziym