【实战演练】快速获取容器VIPs，解决集群自动化测试难题

项目背景介绍

要想使用容器集群来启动自动化测试，那么我们就必须要了解容器的 VIPs 。文章作者 Marcos Tenrero 一直在尝试使用 Docker 内部的服务发现功能来识别在 Docker Swarm 集群上部署的 Docker 服务中容器的VIPs ，但是一直没有成功。经过反复尝试我终于找到一种快速、便捷的方法来查找容器的VIPs。

这个项目上使用的是 Apache Jmeter 压力测试工具，所以我们需要将工作节点列表作为参数传递，以便它可以与分布式负载测试环境一起工作。

第一次尝试：Docker 内部的DNS服务发现

Docker使用DNS服务器来保持注册列表和其容器的更新。

实验需要用到下列物品：

两台服务器：
- 一台 (jd_master)只有一个副本的Master；
- 另一台服务名称(jd_slave_) 下有多个副本的Workers（Slaves）；
Docker compose；
Docker swarm 集群（至少有3台机器用于Raft的一致性工作）；

docker-compose.yml文件内容

尝试从jd_master容器中用“dig jd_slave”命令将jd_slave作为目标向Docker DNS服务器发出查询请求，但是它只返还了一个自动的负载均衡IP来指向活动的jd_slave容器。

所以这种方法不符合我们的需求。

第二次尝试：研究Docker覆盖网络

在相同的情况下，我使用“less /etc/hosts”命令进行查询，希望在覆盖网络当中获得容器的VIPs。

这个尝试是成功的！

第三次尝试：设计外部的服务发现

我们不仅需要服务发现功能，还需要知道容器的状态：

容器镜像名称；
容器测试的执行状态：等待测试/测试/完成；
容器健康检测和监视；
根据测试执行状态来测试观察者和协调者；
在Master上必须向docker.socket 或 docker API 发出指令；

考虑到需求因素，我们需要一个定制的服务发现来处理所有需求。

Flight Controller

默认情况下，在Flight Controller模式中启动自动化测试队列。

它将在一个预先定义的端口上监听HTTP REST请求，所有容器都要调用这个请求来加入测试集群。

从现在起， Flight Controller 将管理和监视所有容器的生命周期和状态。密切关注其健康状况来维持最新的注册表。

WORKER CONTAINER (Alpine)

一旦控制器启动，Flight Controller将作为第一个运行脚本来公布其VIP：

/etc/hosts —> VIP and CONTAINER NAME

在同一覆盖网络中的任何容器都可以访问VIP，可以应用测试重试策略，以便在出现故障时重试测试。

MASTER CONTAINER

同Worker Container一样，但使用不同的标签。