我有一个docker compose文件，它创建了3个Hello World应用程序，并使用nginx来平衡不同容器之间的流量。
docker组成代码如下：
version: '3.2'
services:
backend1:
image: rafaelmarques7/hello-node:latest
restart: always
backend2:
image: rafaelmarques7/hello-node:latest
restart: always
backend3:
image: rafaelmarques7/hello-node:latest
restart: always
loadbalancer:
image: nginx:latest
restart: always
links:
- backend1
- backend2
- backend3
ports:
- '80:80'
volumes:
- ./container-balancer/nginx.conf:/etc/nginx/nginx.conf:ro
我想验证restart: always策略是否确实有效。
我尝试的方法如下：
- 首先，我使用
docker-compose up运行我的应用程序 - 我用
docker container ps识别容器ID - 我用
docker stop ID_Container或docker kill ID_Container杀死/停止其中一个容器
我原以为在第三步(停止/终止容器。这使它存在于代码137中)之后，重新启动策略会再次启动并创建一个新容器。
然而，这并没有发生。我读到这是有意的，因为有一种方法可以手动停止具有重新启动策略的容器。
尽管如此，我还是想知道如何杀死一个容器，使其触发重新启动策略，以便我能够真正验证它是否工作。
谢谢你的帮助。
如果在主机上运行ps，您将能够看到所有Docker容器中的实际进程。一旦找到容器的主进程的进程ID，就可以sudo kill它(您必须是root)。这看起来更像是一个"崩溃"，尤其是如果您kill -13发送SIGSEGV。
对于这样的验证场景，偶尔会有一个端点使应用程序崩溃，这是非常有用的，您可以在测试构建和其他类似的愚蠢事情中启用它。只要确保你有一个门，这样这些端点就不会存在于生产构建中。(在老派C中，#ifdef TEST就可以了；有些语言有对等语言，但很多没有。)
您可以将docker exec放入正在运行的容器中并终止进程。如果你的入口点进程(pid 1)启动了一个子进程，找到它并杀死它
docker exec -it backend3 /bin/sh
ps -ef
找到pid 1是其父进程，kill -9是其父进程的进程。
如果您在唯一进程(pid 1)中的入口点，则kill命令无法杀死它。考虑用一个调用实际流程的脚本替换您的入口点，这将允许您使用我上面建议的想法。
这应该模拟一个崩溃的容器，并且应该启动重新启动过程。
注意：
- 请参阅中的说明https://unix.stackexchange.com/questions/457649/unable-to-kill-process-with-pid-1-in-docker-container
- 查看为什么不在中以pid 1运行NodeJShttps://www.elastic.io/nodejs-as-pid-1-under-docker-images/