共计 4241 个字符,预计需要花费 11 分钟才能阅读完成。
导读 | 我们在之前提到过一个示例,即一款由前端与多项后端服务共同构成的微服务应用。其中前端为 Traefik HTTP 代理,负责将各项请求路由至后端服务。而后端则非常简单,是一套基于 Go 的 HTTP Web 服务器,负责返回其运行所在的容器 ID。 |
新的 Docker Swarm 不再需要为应用容器设置独立的 HTTP 代理。如上图所示的原有架构现在被精简为下图所示的形式:
移动部件更少了——赞!
另外,我们还为后端服务内置了负载均衡机制。我们甚至能够立足于集群内的任一节点访问这些服务。Docker Swarm 还集成有一种内置网状路由机制,用于将各请求路由至适合的后端容器当中。
面对这些新功能,有些朋友可能认为 Docker Swarm 集群的设置过程会比原本更为复杂。事实上,整个流程反而更加简单。
仍然半信半疑?下面一起来看。
没错,这次我们仍然使用 Raspberry Pi 集群。我使用的是 Docker 1.12 内部版本,并将其安装在 Raspberry Pi 上。当 Docker 1.12 推出正式版后,我们会对内容做出针对性更新。
下面看看当前配置:
root@pi6 $ docker version Client:
Version: 1.12.0-rc1
API version: 1.24
Go version: go1.6.2
Git commit: 1f136c1-unsupported
Built: Wed Jun 15 15:35:51 2016
OS/Arch: linux/arm
Server:
Version: 1.12.0-rc1
API version: 1.24
Go version: go1.6.2
Git commit: 1f136c1-unsupported
Built: Wed Jun 15 15:35:51 2016
OS/Arch: linux/arm
很好,Docker 1.12 RC1 已经准备就绪。下面启动各项必要服务。首先看看我们能否在 Docker CLI 中找到隐藏的各项新功能。
root@pi6 $ docker Usage: docker [OPTIONS] COMMAND [arg...]
docker [--help | -v | --version]
A self-sufficient runtime for containers.
... service Manage Docker services ... stats Display a live stream of container(s) resource usage statistics ... swarm Manage Docker Swarm ... update Update configuration of one or more containers Run 'docker COMMAND --help' for more information on a command.
我直接去掉了其中与上代版本完全一致的部分,而只留了不同之处。现在我们可以使用 docker swarm 命令了。
查询其具体作用:
root@pi6 $ docker swarm Usage: docker swarm COMMAND
Manage Docker Swarm
Options:
--help Print usage Commands:
init Initialize a Swarm. join Join a Swarm as a node and/or manager. update update the Swarm. leave Leave a Swarm. inspect Inspect the Swarm Run 'docker swarm COMMAND --help' for more information on a command.
就是说其用于“初始化一套 Swarm”。看起来正是我们需要的。首先启动该命令。
root@pi6 $ docker swarm init Swarm initialized: current node (1njlvzi9rk2syv3xojw217o0g) is now a manager.
现在我们的 Swarm 管理节点已经开始运行,接下来为集群添加更多节点。
前往集群中的另一节点并执行:
root@pi1 $ docker swarm join pi6:2377 This node joined a Swarm as a worker.
使用上述命令,我们在刚刚创建的初始 Swarm 集群中声明了应当加入该 Swarm 管理节点的各个新节点。Docker Swarm 会在后台执行相关操作。
举例来说,其会为不同集群节点设置经过加密的彼此通信通道。我们不再需要自行管理 TLS 证书。
每位曾经设置过 Docker Swarm 集群的朋友,都会意识到新的流程有多么简单。不过到这儿还没有结束。
Swarm 管理节点中的一条“docker info”带来了一些有趣的提示。我仍然删去其中不必要的部分:
root@pi6 $ docker info ... Swarm: active
NodeID: 1njlvzi9rk2syv3xojw217o0g
IsManager: Yes
Managers: 1
Nodes: 2
CACertHash: sha256:de4e2bff3b63700aad01df97bbe0397f131aabed5fabb7732283f044472323fc
... Kernel Version: 4.4.10-hypriotos-v7+
Operating System: Raspbian GNU/Linux 8 (jessie)
OSType: linux
Architecture: armv7l
CPUs: 4
Total Memory: 925.4 MiB
Name: pi6
...
如大家所见,我们现在已经在“docker info”输出结果中有了新的“Swarm”部分,其告诉我们当前节点属于一套 Swarm 管理节点,且该集群由两个集群节点构成。
在第二个节点上,其输出结果与管理节点稍有不同:
Swarm: active NodeID: 3fmwt4taurwxczr2icboojz8g
IsManager: No
到这里,我们已经拥有了一套有趣但仍然空空如也的 Swarm 集群。
我们还需要了解 Docker 1.12 中的 service 这项全新抽象定义。大家可能在前面的输出结果中注意到了 docker service 命令。所谓 docker service,是指运行在容器当中且负责为外部世界提供运行在 Swarm 集群内的“service”的软件片段。
这样的一项服务可以由单一或者多套容器构成。在后一种情况下,我们可以确保服务拥有高可用性及 / 或负载均衡能力。
下面使用之前创建的“whoami”镜像建立这样一项服务。
root@pi6 $ docker service create --name whoami -p 80:8000 hypriot/rpi-whoami buy0q65lw7nshm76kvy5imxk3
在“docker swarm ls”命令的帮助下,我们可以检查这项新服务的状态。
root@pi6 $ docker service ls ID NAME SCALE IMAGE COMMAND
buy0q65lw7ns whoami 1 hypriot/rpi-whoami
下面检查我们是否能够通过 curl 命令向 eth0 网络接口发送 l http 命令,从而请求目录页面。
root@pi6 $ curl http://192.168.178.24
I'm 1b6df814c654
一切顺利,鼓掌!有些朋友可能注意到,“docker swarm ls”命令的标题行中存在“SCALE”部分,这似乎意味着我们可以对服务进行扩展。
root@pi6 $ docker service scale whoami=5
whoami scaled to 5
那就来实际验证一下吧:
root@pi6 $ docker service ls ID NAME SCALE IMAGE COMMAND
buy0q65lw7ns whoami 5 hypriot/rpi-whoami
root@pi6 $ for i in {1..5}; do curl http://192.168.178.24; done
非常简单。
但这种方式与原有 Swarm 其实差不多,只不过在使用感受上更便捷也更快速。请注意,我们使用的是 Raspberry Pi 而非强大的服务器,所以要对性能拥有较为保守的估计。
下面从单一 Docker 引擎的角度来看看目前的运行状态:
root@pi6 $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
如大家所见,已经启动的容器有 5 套,其中 3 套驻留于“pi6”中。下面看看是否能够找到其它容器:
root@pi1 docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
db411a119c0a hypriot/rpi-whoami:latest "/http" 6 minutes ago Up 6 minutes 8000/tcp whoami.2.2tf7yhmx9haol7e2b7xib2emj
0a4bf32fa9c4 hypriot/rpi-whoami:latest "/http" 6 minutes ago Up 6 minutes 8000/tcp whoami.3.2r6mm091c2ybr0f9jz4qaxw9k
那么如果我们将这套 Swarm 集群驻留在“pi1”上,结果又会如何?
root@pi1 docker swarm leave Node left the default swarm.
下面看看另一节点上的运行情况:
docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
这里的情况相当于“pi1”节点发生故障,此时“pi1”中运行的全部容器都会被自动迁移至另一集群节点。这项机制在实际生产当中无疑非常重要。
那么下面我们回顾一下之前了解到的信息:
我们创建了一款小型动态微服务应用,完全由 Docker 构成。Docker Swarm 现在被整合至 Docker-Engine 当中,而不再以独立软件形式存在。在多数情况下,这能够为应用后端服务建立起独立的代理机制。不再需要使用 nginx、HAProxy 或者 Traefik。
尽管活动部件数量有所减少,但我们现在反而拥有了内置的高可用性与负载均衡功能。我非常期待未来 Docker Swarm 正式版本中会带来哪些新的惊喜,又如何与 Docker Compose 进行协作。
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)