如何解决docker将流量路由到已删除的容器
最近几次我观察到一个非常奇怪的情况。
我的设置是这样：
- Nginx将443端口反向代理到localhost：800x（x == 1或2，具体取决于配置文件）
- Docker容器中的Python Flask应用程序。该应用程序位于容器内部的8000端口和容器外部的localhost端口8001/2中。
基本上，在任何给定时间，都有一个Nginx配置反向代理到一个Docker容器（在端口8001或8002上）。
有两个正在运行的Docker容器。一个由Nginx提供服务，另一个则不提供。
当我要部署新版本的应用程序时，我docker stop和docker rm不再提供该应用程序，请站起来，在本地主机上对其进行测试，交换Nginx配置，以便新的将被提供，告诉Nginx重新加载其配置并在外部进行测试。
到那时，新的应用程序版本将被提供，并且没有停机时间！
我知道还有其他工具可以做到这一点，例如Kubernetes，但是我的设置要轻得多。这是一个内部使用的应用程序，因此我需要能够可靠运行的东西。直到最近。
问题
当我使用上述方法部署新应用时，发生了一件奇怪的事情。让我们来设置场景...
正在运行的应用程序
- v1（Nginx不在：8001上投放）
- v2（由Nginx在8002上提供）
...我运行交换脚本...
- v1（已杀死并RM（以前为：8001 ）
- v2（Nginx不在8002上投放）
- v3（应该由Nginx在8001上提供）
当我测试部署时，发现正在提供v1 ！！！
v1的容器在docker ps或docker ps -a中不可见。
尝试通过localhost卷曲到该应用程序（避免使用Nginx）击中了幽灵般的Docker容器。
我可以通过docker logs查看新容器的日志。它正在运行，但没有收到任何流量。
当我从外部访问该应用程序时，在浏览器中看到的内容与v1中的内容一致。所有迹象都表明正在投放v1！
为了调和我的情况systemctl restart docker。
当恢复后，冲突的端口（在上面的示例中：8001）不起作用，即使v3仍然显示自身暴露在该端口上。
有趣的是，当Docker根本不提供特定端口时，您会立即尝试Connection refused尝试将其卷曲。但是，卷曲到曾经为虚幻服务的端口，现在应该永远为新版本的应用程序块提供服务。
如果我停止了，rm并重新运行该版本（请注意：仅，在重新启动docker守护程序之后），一切将恢复正常。
我在运行Docker版本19.03.5的Ubuntu 16.04上，内部版本633a0ea838。
这似乎是docker守护程序消除了容器的所有外部可见性，从而允许部署一个新容器（具有相同的名称，我应该提一下），使其使用与死容器相同的端口，但是以某种方式来说，所谓的死进程是仍在运行并提供流量。
重新启动盒子并不理想，因为那里正在运行其他东西。
出于相同的原因，升级OS / Docker版本并不理想，但可能是个好主意。
以前有人听说过吗？
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。