我正在使用Docker（+ Docker Compose）。所有docker-compose交互都通过Python'fabric'包（v1）进行。
例：
def runserver():
local('docker-compose up')
和：
$ fab runserver
一切都表现正常，直到我尝试从运行的^C docker-compose up：
docker-compose似乎收到^C（SIGINT？）信号，因为它开始停止我的容器 - 例如：Stopping celery-export ... done
Stopping celery ...
但是在容器停止过程中（如果容器没有正确响应信号，有时长达10秒），我可以按回车/返回并查看/与我的shell交互（就好像过程已经结束）。
虽然在这个阶段容器还没有完成停止（每个done线旁边没有Stopping ...）。好像我过早地被允许访问我的shell，我可以自由使用它。如果一个后期整理容器最终停止（通常在10秒之后），它将绘制done线，而不是我正在终端中进行的操作。
例：
Stopping celery-export ... done
Stopping celery ...
Stopping redis ...
$ uptime
10:54 up 1 day, 17:22, 2 users, load averages: 1.73 1.94 1.92
Stopping celery ... done
Stopping redis ... done
当我直接调用docker-compose up（在结构之外）时不会发生这种情况，因此我怀疑它与包装执行命令的结构有关。
预期的行为是，在容器停止过程完成之前，我无法访问我的shell。
原谅我缺乏适当的术语来描述这个问题，如果这更适合超级用户而不是SO。
我想回答，我的回答是我对你问题的看法：
docker-compose up
然后最后一个操作是attach到容器（服务）。例如next docker-compose.yaml：
version: "3.6"
services:
nginx:
image: nginx:latest
ports:
- "8080:80"
如果你运行docker-compose up，你会看到下一个输出：
Starting fabric_nginx_1 ... done
Attaching to fabric_nginx_1
当Attaching to fabric_nginx_1成功结束附加到nginx服务器。发送到此控制台的Ctrl-C或SIGINT将停止nginx进程和容器（服务）。
对于作为守护程序运行进程/容器/服务，您应该运行docker-compose detached并使用-d / - detach开关。
docker-compose up -d
然后您的服务将作为服务运行。停止时，你应该使用：
结论：在您的情况下，所有工作都按设计进行。 Fabric运行docker-compose命令并停止。 docker-compose创建容器，运行它们并停止。容器行为是由他自己的内容打包到容器中。
正如其他人所提到的，使用Ctrl + C似乎在你的情况下杀死了Fabric。 SSH命令仍在后台运行，您将其输出到控制台，直到完成为止。
我没有这样做，我建议你使用docker-compose up -d，这样一旦所有容器都装满，Fabric就会完成。如果要拖尾日志，则应添加另一个将执行docker-compose logs的Fabric命令。当您按Ctrl + C时，它应该快速结束，而不是像up那样在后台运行。如果要停止容器，请使用docker-compose stop。
我在测试时使用docker-compose up（在Fabric之外）。通常，当我按ctrl + C时，并不是所有图像都在我返回命令提示符之前终止。实际上，Redis经常在后台运行。重新运行docker-compose up甚至会导致显示自ctrl + C以来累积的Redis消息。
在我的情况下，一个合适的解决方法，以确保一切都“死”，我使用docker kill $(docker ps -q)。这会杀死任何正在运行的图像。