对 docker 组合进行版本控制

Question

我通常使用简单的生产映像组合来管理我的生产部署，因此完全依赖 docker-compose。

我没有使用 Kubernetes 或其他工具，因为我想让我的简单应用程序保持简单（我不部署在多个主机上、管理负载平衡或执行 CD/CI）

这是我的作品组合的样子：

version: '3'

services:
    php:
        image: ${CONTAINER_REGISTRY_BASE}/php:${VERSION}
        depends_on:
          - db
        env_file:
          - ./api.env

    api:
        image: ${CONTAINER_REGISTRY_BASE}/api:${VERSION}
        depends_on:
          - php
          - db

    db:
        image: mariadb:10.2

    client:
        image: ${CONTAINER_REGISTRY_BASE}/client-prod:${VERSION}
        env_file:
          - ./client.env

    admin:
        image: ${CONTAINER_REGISTRY_BASE}/admin-prod:${VERSION}
        env_file:
          - ./admin.env

在.env 文件中为应用程序堆栈保留一个全局版本，当我更新此版本时，我只需要这样做：

docker-compose build
docker-compose push

在生产服务器中（更新版本后）

docker-compose up -d

正如您可以想象的那样，问题是我要交付整个堆栈，即使其中一项服务有非常小的修改。

我曾考虑为每个服务设置不同的版本，但维护起来似乎相当复杂，因为我们无法确定每个服务的最新版本是什么。

我看错了吗？我不应该在生产中使用 docker-compose 吗？在这种情况下我应该使用什么？

有人可以建议我一种基于 docker 注册表的简单部署方式吗？

Answer 1

简答： 实际上，您应该为每个服务提供单独的服务，我建议您从仅用于生产的普通 Docker 服务器转移到 Swarm。

长答案： 如果您迁移到 Docker Swarm，您可以使用相同的 compose 文件并进行一些更改，以使其成为堆栈文件。它的作用是创建一系列服务，由 Swarm 单独维护。

在您的构建过程中，我建议为每个新构建分配一个特定的版本号，然后将其专门标记为最新或开发。将最新或开发版本推送到存储库。

原因有两个：

1. 更新堆栈文件时，您需要指定要使用的映像的离散版本。 IE 1.2.3 或您刚刚更改的服务的最新版本。这是因为如果您尝试使用“最新”，那么 Swarm 甚至不会尝试提取图像，因为在部署时会有一个很好的变化。我一直发现最好避免生产意义上的歧义
   1. 对于开发人员而言，无论何时开始工作，或在本地环境中工作时，他们始终可以通过 composer 覆盖（基本上依次调用两个 compose 文件，第一个具有核心定义，第二个有更改或添加等）

每当您进行 docker stack deploy 时，它只会查看服务中的差异以进行更改。我会玩弄它，但我认为它会更适合您的工作流程。

旁注： 我从来没有真正为 Docker 中存在的数据库找到一个好的用例，因为 (1) 缺乏资源或 (2) 集成测试。