项目背景介绍
要想使用容器集群来启动自动化测试，那么我们就必须要了解容器的 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一样，但使用不同的标签。
