领事没有注销僵尸服务答案

【问题标题】：Consul not deregistering zombie services领事没有注销僵尸服务
【发布时间】：2015-11-22 10:09:15
【问题描述】：

我正在用马拉松部署一个简单的 hello world nginx 容器，一切似乎都运行良好，除了我有 6 个不会从 consul 注销的容器。 docker ps 显示没有容器在运行。

我尝试使用/v1/catalog/deregister 端点取消注册服务，但它们不断返回。然后我杀死了注册器容器，并再次尝试取消注册。他们回来了。

我正在使用

运行注册器

docker run -d --name agent-registrator -v /var/run/docker.sock:/tmp/docker.sock --net=host gliderlabs/registrator consul://127.0.0.1:8500 -deregister-on-success -cleanup

有 1 个领事代理正在运行。

重启机器（这是本地虚拟机上的单节点安装）不会使服务消失。

如何让这些容器消失？

【问题讨论】：

docker ps -a 是否为您显示所有现有容器？
@meoww 它显示了声称存在的容器。我删除了所有容器，然后注销。 Consul 仍将服务报告为现有

标签： docker registration marathon consul

【解决方案1】：

使用 http api 删除服务是另一个更好的解决方案。在弄清楚如何使用 https api 之前，我只是想出了如何手动删除服务。

要使用 http api 删除服务，请使用以下命令： curl -v -X PUT http://<consul_ip_address>:8500/v1/agent/service/deregister/<ServiceID>

请注意，您是三件事的组合：运行容器的主机的 IP 地址、容器的名称和容器的内部端口（即 80 用于 apache，3000 用于节点 js，8000对于 django 等）全部由 colins 分隔 :

以下是实际情况的示例： curl -v -X PUT http://1.2.3.4:8500/v1/agent/service/deregister/192.168.1.1:sharp_apple:80

如果您想要一种简单的方法来获取 ServiceID，那么只需 curl 包含僵尸的服务： curl -s http://<consul_ip_address>:8500/v1/catalog/service/<your_services_name>

这是一个名为 someapp 的服务的真实示例，该服务将返回其下的所有服务： curl -s http://1.2.3.4:8500/v1/catalog/service/someapp

【讨论】：

【解决方案2】：

这里是你绝对删除所有僵尸服务的方法：进入你的领事服务器，找到包含僵尸的json文件的位置并删除它们。

例如我在容器中运行 consul：

docker run --restart=unless-stopped -d -h consul0 --name consul0 -v /mnt:/data \
    -p $(hostname -i):8300:8300 \
    -p $(hostname -i):8301:8301 \
    -p $(hostname -i):8301:8301/udp \
    -p $(hostname -i):8302:8302 \
    -p $(hostname -i):8302:8302/udp \
    -p $(hostname -i):8400:8400 \
    -p $(hostname -i):8500:8500 \
    -p $(ifconfig docker0 | awk '/\<inet\>/ { print $2}' | cut -d: -f2):53:53/udp \
    progrium/consul -server -advertise $(hostname -i) -bootstrap-expect 3

注意标志-v /mnt:/data 这是所有数据领事存储的位置。对我来说，它位于/mnt。在此目录下，您将找到其他几个目录。

config raft serf services tmp

进入services，你会看到包含你服务的json信息的文件，找到任何包含僵尸信息的文件并删除它们。然后重启领事。然后对集群中存在僵尸的每个服务器重复此操作。

【讨论】：

重启 consul 可能无法在 HA 部署中工作。

【解决方案3】：

不要使用目录，而不是使用代理，原因是目录由代理维护，即使您从目录中删除它也会由代理重新同步，删除僵尸服务shell脚本：

leader="$(curl http://ONE-OF-YOUR-CLUSTER:8500/v1/status/leader | sed 

's/:8300//' | sed 's/"//g')"
while :
do
serviceID="$(curl http://$leader:8500/v1/health/state/critical | ./jq '.[0].ServiceID' | sed 's/"//g')"
node="$(curl http://$leader:8500/v1/health/state/critical | ./jq '.[0].Node' | sed 's/"//g')"
echo "serviceID=$serviceID, node=$node"
size=${#serviceID}
echo "size=$size"
if [ $size -ge 7 ]; then
curl --request PUT http://$node:8500/v1/agent/service/deregister/$serviceID
else
break
fi
done
curl http://$leader:8500/v1/health/state/critical

json解析器jq用于字段检索

【讨论】：

【解决方案4】：

在 Consul 集群中，代理被认为是权威的。如果您使用 HTTP Api /v1/catalog/deregister 端点取消注册服务，只要其他代理知道该服务，它就会不断返回。这就是 Gossip 协议的工作方式。

如果您希望服务立即消失，您需要在终止节点上的服务之前发出consul leave 正确注销主机代理。

【讨论】：

这个方法对我不起作用。我发consul leave，重启registrator，再发consul join，服务还在
@peter klipfel。服务是否仍然存在，但 serfHealth 很关键？我不会在 Consul 中使用注册器。我只需将服务直接注册到节点或容器中的 Consul 代理即可。
但这无济于事 - OP 在尝试注销服务时遇到问题。

【解决方案5】：

这是 Consul 和 registrator 的问题之一，如果服务没有与之关联的检查，则服务将一直存在，直到它被取消注册并处于“活动状态”。因此，最好让服务也注册健康检查。这样，如果注册者搞砸并忘记取消注册服务（我看到这种情况经常发生），它们至少会变得至关重要。亚历克斯的回答是，删除领事的数据/服务目录中的文件（然后领事重新加载）肯定可以删除服务，但如果容器仍然存在并正在运行，注册者将重新添加它们。显然，较新的注册器版本更擅长清理，但我的成功参差不齐。现在我根本不使用 registrator，因为它没有添加健康检查。我使用 nomad 来运行我的容器（也来自 hashcorp），它会创建服务并创建运行状况检查，并且可以很好地自行清理。

【讨论】：

这很有趣。我发现寻找注册人的替代品时遇到了极大的麻烦。我还通过阅读有关注册者的信息（http://gliderlabs.com/projects/ gliderlabs 认为 beta）注意到需要做更多的工作。

【解决方案6】：

尝试切换到 v5

docker run -d --name agent-registrator -v /var/run/docker.sock:/tmp/docker.sock gliderlabs/registrator:v5 -internal consul://172.16.0.4:8500

【讨论】：