使用 Python 的 'fabric' 运行 docker-compose up

Question

我正在使用 Docker（+ Docker Compose）。 所有docker-compose交互都通过 Python ' fabric ' 包（v1）发生。

例子：

def runserver():
    local('docker-compose up')

和：

$ fab runserver

一切正常，直到我尝试^C退出正在运行的docker-compose up ：

1. docker-compose在开始停止我的容器时似乎收到^C ( SIGINT ?) 信号 - 例如：

Stopping celery-export ... done
Stopping celery        ...

但是，在容器停止过程中（如果容器没有正确响应信号，有时长达 10 秒），我可以按 Enter / Return 并查看 / 与我的 shell 交互（好像该过程已经结束）。

虽然在这个阶段容器还没有完成停止（每个Stopping ...行旁边没有done ）。 就好像我过早地获得了访问我可以自由使用的 shell 的权限。 如果迟到的容器最终停止（通常在 10 秒后），它会在我当前在终端中执行的done绘制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。

Answer 1

我想回答，我的回答是我对你的问题的看法：

1. 结构通过配置运行命令并停止。
2. docker-compose up 命令：为服务构建、（重新）创建、启动和附加到容器。 当关键字为attach 时。 当你运行时：

docker-compose up

然后最后一个操作是attach到容器（服务）。 例如下一个 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

然后您的服务将作为服务运行。 对于停止，您应该使用：

1. docker-compose 停止或
2. docker-compose 杀死或
3. 码头工人组合

结论：就您而言，一切都按设计工作。 Fabric 运行 docker-compose 命令并停止。 docker-compose创建容器，运行它们并停止。 容器行为是由他自己的内容打包到容器中。

Answer 2

正如其他人所提到的，在您的情况下，使用 Ctrl+C 似乎会杀死 Fabric。 SSH 命令仍然在后台运行，您将其输出发送到控制台，直到它完成。

不要这样做，我建议您使用docker-compose up -d以便在所有容器都启动后 Fabric 完成。 如果您想跟踪日志，您应该添加另一个将执行docker-compose logs Fabric 命令。 当你按 Ctrl+C 时，它应该很快结束，而不是像up那样在后台运行。 当您想停止容器时，请使用docker-compose stop 。

Answer 3

Fabric 1.x 已拆分为两个项目，'Invoke' ( inv ) 是用于运行本地命令的替换包，以及此处相关的内容。

Invoke 在这方面做了很大的改进，现在已经没有这个问题了。 从 Fabric 1.x 迁移到 Invoke 相对容易。 我看不到 Fabric 1.x 中任何修复的潜力。 我的解决方案是改用 Invoke。

Answer 4

我在测试时使用docker-compose up （在 Fabric 之外）。 通常，当我 ctrl+C 返回到命令提示符之前，并非所有图像都被终止。 事实上，Redis 经常保持在后台运行。 重新运行docker-compose up甚至会导致显示自 ctrl+C 以来累积的 Redis 消息。

在我的情况下，一个合适的解决方法来确保一切都“死了”，我使用docker kill $(docker ps -q) 。 这会杀死任何正在运行的图像。