使用 docker-compose 文件版本 3 优于 shell 脚本的优势？答案

【问题标题】：Advantage of using docker-compose file version 3 over a shellscript?使用 docker-compose 文件版本 3 优于 shell 脚本的优势？
【发布时间】：2017-07-18 19:05:37
【问题描述】：

我创建 docker-compose.yml 的最初原因是利用 build: 和 depends-on: 等功能来创建一个文件，用于构建我的所有图像并在容器中运行它们。但是，我注意到版本 3 贬低了大多数这些功能，我很好奇为什么我会在构建 shellscript 时使用它。

这是我目前运行所有容器的 shellscript（我假设这是版本 3 docker-compose 文件将替换的内容，如果我要使用它）：

echo "Creating docker network net1"
docker network create net1

echo "Running api as a container with port 5000 exposed on net1"
docker run --name api_cntr --net net1 -d -p 5000:5000 api_img

echo "Running redis service with port 6379 exposed on net1"
docker run --name message_service --net net1 -p 6379:6379 -d redis

echo "Running celery worker on net1"
docker run --name celery_worker1 --net net1 -d celery_worker_img

echo "Running flower HUD on net1 with port 5555 exposed"
docker run --name flower_hud --net net1 -d -p 5555:5555 flower_hud_img

docker-swarm 是否依赖于使用堆栈？如果是这样，那么我可以看到 docker-compose 和 stacks 的用途，但我似乎无法在网上找到答案。我会使用第 3 版，因为它与 swarm 兼容，与第 2 版不同，如果我读过的话。也许我完全错过了 docker-compose 的意义，但我对它带来的东西有点困惑。

【问题讨论】：

构建系统通常会构建图像并正确标记它们。如果我使用docker run 进行设置，那将是一团糟。有些命令可能会跨越几行。

标签： docker docker-compose dockerfile docker-swarm docker-stack

【解决方案1】：

可读性

将您的示例 shell 脚本与相同的 YAML 版本进行比较：

services:
  api_cntr:
    image: api_img
    network: net1
    ports:
      - 5000:5000
  message_service:
    image: redis
    network: net1
    ports:
      - 6379:6379
  celery_worker1:
    image: celery_worker_img
    network: net1
  flower_hud:
    image: flower_hud_img
    network: net1
    ports:
      - 5555:5555

至少在我看来，通过读取 YAML 来确定应用程序的整体架构要比通过读取 shell 命令容易得多。

清理

如果您使用 docker-compose，则运行 docker-compose down 将停止并清理所有内容，删除网络等。要在您的 shell 脚本中执行此操作，您必须单独编写一个删除部分来停止和删除所有容器和网络。

多个继承 YAML 文件

在某些情况下，例如对于开发和测试，您可能需要一个主 YAML 文件和另一个覆盖开发/测试工作的某些值的另一个文件。

例如，我有一个应用程序，其中有 docker-compose.yml 和 docker-compose.dev.yml。第一个包含我的应用程序的所有生产设置。但是“开发”版本的功能更有限。它使用相同的服务名称，但有一些不同。

将我的代码目录的装载添加到容器中，覆盖图像中内置的代码版本
在外部公开 postgres 端口（因此我可以连接到它以进行调试） - 这不会在生产中公开
使用另一个挂载来伪造用户数据库，这样我就可以轻松地拥有一些测试用户，而无需为了开发而将东西连接到我的真实身份验证服务器

服务通常只使用docker-compose.yml（在生产中）。但是当我做开发工作时，我是这样运行的：

docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d

它将首先从docker-compose.yml 加载正常参数，然后读取docker-compose.dev.yml，然后仅覆盖在dev 文件中找到的参数。其他参数都保留在生产版本中。但我不需要两个完全独立的 YAML 文件，我可能需要在这两个文件中更改相同的参数。

易于维护

我在最后几段中描述的一切都可以使用 shell 脚本来完成。这样做的工作量更大，而且可能更难维护，更容易出错。

您可以通过让您的 shell 脚本读取配置文件等来使其更容易...但在某些时候您必须询问您是否只是重新实现自己的 docker-compose 版本，以及这对您是否值得.

【讨论】：