Consul
ContainerPilot使用Hashicorp的consul在作为服务的容器中注册工作。 Watches查询consul找出其他服务的状态。
Client configuration
ContainerPilot配置文件中的consul域配置ContainerPilot的Consul客户端。 要使用领事的ACL系统，请使用CONSUL_HTTP_TOKEN环境变量。
如果您正在通过TLS与Consul进行沟通，则可以包含该方案（例如：https：// consul：8500 ）。 请注意，一般来说，领事客户端将与本地主机上的代理进行通信，因此TLS可能不是必需的。
如果您需要TLS的额外配置选项，可以使用以下可选字段（或consul文档中描述的环境变量选项），而不是简单的字符串：
consul: {
address: "consul.example.com:8500",
scheme: "https",
token: "aba7cbe5-879b-999a-07cc-2efd9ac0ffe", // or CONSUL_HTTP_TOKEN
tls: {
cafile: "ca.crt", // or CONSUL_CACERT
capath: "ca_certs/", // or CONSUL_CAPATH
clientcert: "client.crt", // or CONSUL_CLIENT_CERT
clientkey: "client.key", // or CONSUL_CLIENT_KEY
servername: "consul.example.com", // or CONSUL_TLS_SERVER_NAME
verify: true, // or CONSUL_HTTP_SSL_VERIFY
}
}
Consul agent configuration
在诸如Joyent的Triton 基础架构容器或虚拟机之类的典型应用程序部署中，最终用户将在每个主机（基础架构容器或VM）上部署Consul代理。 该主机上的所有应用程序将在主机上的本地主机或桥接网络中找到代理。
这在Triton Elastic Docker主机或其他最终用户无法部署主机本地服务的其他容器即服务部署环境中不起作用。 在这种部署中，用户可能会尝试在每个底层主机上部署Consul代理（使用部署API提供的任何主机关联选项），但容器通常不会有一种方法来查找该代理。
在这种情况下，我们建议在每个容器内部署一个Consul代理。 所有进程（包括ContainerPilot）都可以通过localhost与代理进行通信，代理可以通过基础架构支持的DNS（如Triton CNS ）找到consul服务器。
Consul客户端的建议配置和Consul代理的job如下，假设环境变量CONSUL代表领事服务器的DNS名称：
consul: "localhost:8500",
jobs: [
{
name: "consul-agent",
exec: [
"consul", "agent",
"-config-file=/etc/consul/consul.json",
"-rejoin",
"-retry-join", "{{ .CONSUL }}",
"-retry-max", "10",
"-retry-interval", "10s"
],
restarts: "unlimited"
}
]