ficusio/consul

Docker中的Consul Agent

该项目是Consul的Docker容器。它是一个略带倾向性的预配置Consul Agent，专门为在Docker生态系统中工作而设计。

获取容器

该容器体积非常小（虚拟大小50MB，基于https://github.com/progrium/busybox%EF%BC%89%EF%BC%8C%E5%8F%AF%E5%9C%A8Docker Index上获取：

bash
$ docker pull progrium/consul

使用容器

尝试使用Consul

如果只想运行单个Consul Agent实例来试用其功能：

bash
$ docker run -p 8400:8400 -p 8500:8500 -p 8600:53/udp -h node1 progrium/consul -server -bootstrap

可以通过添加-ui-dir标志启用Web UI：

bash
$ docker run -p 8400:8400 -p 8500:8500 -p 8600:53/udp -h node1 progrium/consul -server -bootstrap -ui-dir /ui

我们发布了8400（RPC）、8500（HTTP）和8600（DNS）端口，以便您可以尝试所有三个接口。我们还为容器指定了主机名node1。设置容器主机名是为Consul Agent节点命名的预期方式。

推荐使用HTTP接口，可通过curl访问：

bash
$ curl localhost:8500/v1/catalog/nodes

也可以使用dig与DNS接口交互：

bash
$ dig @0.0.0.0 -p 8600 node1.node.consul

此外，如果在主机上安装了Consul，可以使用CLI与容器化的Consul Agent交互：

bash
$ consul members

在单主机上测试Consul集群

如果想在单主机上启动Consul集群以实验集群动态（复制、 leader选举），推荐以下方式启动3节点集群。

这里启动第一个节点时不使用-bootstrap，而是使用-bootstrap-expect 3，这将等待3个对等节点连接后自行引导并成为工作集群。

bash
$ docker run -d --name node1 -h node1 progrium/consul -server -bootstrap-expect 3

通过检查容器可以获取容器的内部IP，并将其存储在环境变量JOIN_IP中：

bash
$ JOIN_IP="$(docker inspect -f '{{.NetworkSettings.IPAddress}}' node1)"

然后启动node2并告诉它使用$JOIN_IP加入node1：

bash
$ docker run -d --name node2 -h node2 progrium/consul -server -join $JOIN_IP

以同样方式启动node3：

bash
$ docker run -d --name node3 -h node3 progrium/consul -server -join $JOIN_IP

现在我们在单主机上运行了一个真正的三节点集群。注意我们也将容器命名为与其内部主机名/节点名相同。

我们没有发布任何端口来访问集群，但可以以此为契机运行第四个"客户端"模式的代理节点（不使用-server）。这意味着它不参与共识仲裁，但仍可用于与集群交互，也不需要磁盘持久化。

bash
$ docker run -d -p 8400:8400 -p 8500:8500 -p 8600:53/udp --name node4 -h node4 progrium/consul -join $JOIN_IP

现在可以通过这些发布的端口与集群交互，如果需要，可以尝试终止、添加和重启节点，观察集群如何处理这些情况。

在生产环境中运行真正的Consul集群

在独立主机上设置真正的集群与单主机集群设置过程非常相似，但有一些区别：

• 假设主机之间存在私有网络，每个主机应在该私有网络上有一个IP
• 将通过-advertise标志将此私有IP传递给Consul
• 将在此IP上发布所有端口，包括Consul内部端口（8300、8301、8302）
• 设置/data卷用于持久化，例如将主机的/mnt目录绑定挂载

假设我们在私有IP为10.0.1.1的主机上，docker桥接docker0的IP为172.17.42.1，可以启动第一个主机代理：

bash
$ docker run -d -h node1 -v /mnt:/data \
    -p 10.0.1.1:8300:8300 \
    -p 10.0.1.1:8301:8301 \
    -p 10.0.1.1:8301:8301/udp \
    -p 10.0.1.1:8302:8302 \
    -p 10.0.1.1:8302:8302/udp \
    -p 10.0.1.1:8400:8400 \
    -p 10.0.1.1:8500:8500 \
    -p 172.17.42.1:53:53/udp \
    progrium/consul -server -advertise 10.0.1.1 -bootstrap-expect 3

在第二个主机上，运行相同的命令，但通过-join指定第一个节点的IP。假设该主机的私有IP为10.0.1.2：

bash
$ docker run -d -h node2 -v /mnt:/data  \
    -p 10.0.1.2:8300:8300 \
    -p 10.0.1.2:8301:8301 \
    -p 10.0.1.2:8301:8301/udp \
    -p 10.0.1.2:8302:8302 \
    -p 10.0.1.2:8302:8302/udp \
    -p 10.0.1.2:8400:8400 \
    -p 10.0.1.2:8500:8500 \
    -p 172.17.42.1:53:53/udp \
    progrium/consul -server -advertise 10.0.1.2 -join 10.0.1.1

第三个主机的IP为10.0.1.3：

bash
$ docker run -d -h node3 -v /mnt:/data  \
    -p 10.0.1.3:8300:8300 \
    -p 10.0.1.3:8301:8301 \
    -p 10.0.1.3:8301:8301/udp \
    -p 10.0.1.3:8302:8302 \
    -p 10.0.1.3:8302:8302/udp \
    -p 10.0.1.3:8400:8400 \
    -p 10.0.1.3:8500:8500 \
    -p 172.17.42.1:53:53/udp \
    progrium/consul -server -advertise 10.0.1.3 -join 10.0.1.1

完成！一旦最后一个节点连接，集群将引导完成。现在您在私有网络上拥有一个可在生产环境中运行的工作集群。

特殊功能

Runner命令

由于生产环境中的docker run命令很长，提供了一个命令来生成该命令。运行cmd:run <advertise-ip>[::<join-ip>[::client]] [docker-run-args...]将输出一个可定制的docker run命令，您可以在子shell中运行。例如：

bash
$ docker run --rm progrium/consul cmd:run 10.0.1.1 -d

输出：

bash
eval docker run --name consul -h $HOSTNAME 	\
    -p 10.0.1.1:8300:8300 \
    -p 10.0.1.1:8301:8301 \
    -p 10.0.1.1:8301:8301/udp \
    -p 10.0.1.1:8302:8302 \
    -p 10.0.1.1:8302:8302/udp \
    -p 10.0.1.1:8400:8400 \
    -p 10.0.1.1:8500:8500 \
    -p 172.17.42.1:53:53/udp \
    -d 	\
    progrium/consul -server -advertise 10.0.1.1 -bootstrap-expect 3

默认情况下，它会将容器的主机名设置为您的主机名，将容器命名为consul（可覆盖），将53端口绑定到Docker桥接，其余端口绑定到advertise IP。如果未提供join IP，它将以-bootstrap-expect模式运行，默认预期3个对等节点。另一个示例，指定join IP并设置更多docker run参数：

bash
$ docker run --rm progrium/consul cmd:run 10.0.1.1::10.0.1.2 -d -v /mnt:/data

输出：

bash
eval docker run --name consul -h $HOSTNAME 	\
    -p 10.0.1.1:8300:8300 \
    -p 10.0.1.1:8301:8301 \
    -p 10.0.1.1:8301:8301/udp \
    -p 10.0.1.1:8302:8302 \
    -p 10.0.1.1:8302:8302/udp \
    -p 10.0.1.1:8400:8400 \
    -p 10.0.1.1:8500:8500 \
    -p 172.17.42.1:53:53/udp \
    -d -v /mnt:/data \
    progrium/consul -server -advertise 10.0.1.1 -join 10.0.1.2

注意它只允许使用bootstrap-expect或join，不能同时使用。使用cmd:run假设您将使用第一个节点引导并预期3个节点。可以通过设置EXPECT环境变量更改引导前的预期对等节点数。

要使用此便利功能，只需将cmd:run输出包装在子shell中。运行以下命令查看效果：

bash
$ $(docker run --rm progrium/consul cmd:run 127.0.0.1 -it)

客户端标志

客户端节点允许您扩展集群而不影响底层 gossip协议的性能（它们将请求代理到其中一个服务器节点，因此是无状态的）。

要使用runner命令启动客户端节点，在<advertise-ip>::<join-ip>参数后附加字符串::client。例如：

bash
$ docker run --rm progrium/consul cmd:run 10.0.1.4::10.0.1.2::client -d

将生成与上述相同的输出，但没有-server consul参数。

Docker健康检查

Consul允许指定shell脚本进行健康检查，类似于Nagios。作为容器，这些脚本在该容器环境中运行，这是一个包含bash和curl的最小Busybox环境。对于某些场景，这相当有限，因此添加了一些内置便利脚本来在Docker系统中正确执行健康检查。

这些都要求运行Consul容器时将主机的Docker socket挂载到/var/run/docker.sock。

使用check-http

check-http <container-id> <port> <path> [curl-args...]

此工具基于容器ID或名称、内部端口（服务在容器内实际监听的端口）和路径执行基于curl的HTTP健康检查。您可以选择提供curl的额外参数。

HTTP请求在附加到目标容器网络命名空间的单独临时容器中执行。该工具自动确定要运行请求的内部Docker IP。成功的请求将响应头输出到Consul。不成功的请求将输出请求失败的原因并将检查设置为critical。默认情况下，curl以--retry 2运行以覆盖本地瞬态错误。

使用check-cmd

check-cmd <container-id> <port> <command...>

此工具在基于目标容器镜像的单独临时容器中执行指定命令，该容器附加到目标容器的网络命名空间。通常，这预期是健康检查脚本，但也可以是可在此容器镜像上运行的任何命令。为方便起见，环境变量SERVICE_ADDR设置为指定的内部Docker IP和端口。

使用docker

上述健康检查工具需要Docker二进制文件，因此已内置到容器中。如果上述工具都不满足您的需求，且容器环境过于受限，您可以直接执行Docker操作来执行任何容器化健康检查。

DNS

此容器设计为在其他容器中用作DNS，因此在容器内监听53端口以提高兼容性并通过链接访问。它还启用了DNS递归查询，使用Google 8.8.8.8名称服务器。

使用cmd:run运行时，它在Docker桥上发布DNS端口。您可以在docker run中使用--dns标志，或者更好地与Docker守护进程选项一起使用。以下命令可在Ubuntu系统上运行，告诉Docker使用桥接IP进行DNS，否则使用Google DNS，并使用service.consul作为搜索域。

bash
$ echo "DOCKER_OPTS='--dns 172.17.42.1 --dns 8.8.8.8 --dns-search service.consul'" >> /etc/default/docker

如果在OS/X上使用http://boot2docker.io/%EF%BC%8C%E8%80%8C%E4%B8%8D%E6%98%AFUbuntu%E4%B8%BB%E6%9C%BA%EF%BC%8C%E5%AE%83%E6%9C%89%E4%B8%80%E4%B8%AA%E8%BF%90%E8%A1%8Cdocker%E5%AE%B9%E5%99%A8%E7%9A%84Tiny Core Linux VM。使用以下命令设置额外的Docker守护进程选项（boot2docker v1.3.1及以上），这也使用OS/X机器用于boot2docker外部名称解析的第一个DNS名称服务器。

bash
$ boot2docker ssh sudo "ash -c \"echo EXTRA_ARGS=\'--dns 172.17.42.1 --dns $(scutil --dns | awk -F ': ' '/nameserver/{print $2}' | head -1) --dns-search service.consul\' > /var/lib/boot2docker/profile\""

设置这些额外选项后，在Docker容器内，/etc/resolv.conf文件中会自动设置适当的条目。要测试，启动一个安装了dig工具的Docker容器（此示例使用https://registry.hub.docker.com/u/aanand/docker-dnsutils/%EF%BC%8C%E8%BF%99%E6%98%AF%E5%AE%89%E8%A3%85%E4%BA%86dnsutils%E7%9A%84Ubuntu%E9%95%9C%E5%83%8F%EF%BC%89%E3%80%82

bash
$ docker run --rm aanand/docker-dnsutils dig -t SRV consul +search

运行时配置

尽管您可以扩展此镜像以添加配置文件来定义服务和检查，但此容器设计用于可通过HTTP API在运行时配置服务和检查的环境。

建议保持检查逻辑简单，例如使用内联curl或ping命令。否则，请记住默认shell是Bash，但运行在Busybox中。

如果确实需要自定义启动配置，可以通过基于此镜像创建新的Dockerfile并包含包含配置JSON文件的config目录来扩展此镜像。它们将通过ONBUILD钩子添加到您构建的镜像中。您还可以使用opkg添加包。有关更多信息，请参见https://github.com/progrium/busybox%E3%80%82

使用相同IP快速重启节点的问题

测试集群场景时，您可能会终止容器并在同一主机上再次重启，发现它难以重新加入集群。

当您将节点作为新容器使用相同的发布端口重启时，会导致心跳失败，节点将出现波动。这是ARP表缓存问题。如果等待约3分钟再启动，应该可以正常工作。您也可以手动重置缓存。

赞助商

本项目得益于DigitalOcean的支持。

许可证

BSD