2

我们有几个应用程序是更大应用程序的一部分。

这些应用程序中的每一个都有一个在每次提交时构建的 Docker 映像。

我希望您使用 docker swarm 模式和 docker stacks 来自动部署/更新这个更大的应用程序。

让我们假装我有这个撰写文件（留下不相关的部分）

version: '3'
services:
    product_service:
       image: myregistry.com/product_service:c8372d
       ..
    cart_service:
       image: myregistry.com/cart_service:ee7f32
       ..

当我对购物车服务存储库进行更改时，我希望堆栈仅更新cart_service，但将其product_service固定在当前版本。此外，当产品服务更新时，我希望能够仅更新该服务，但将购物车服务保留为当前固定版本。

在这种情况下我有什么选择？

我能想到的：

  • 做一些花哨的事情并在提交时重新生成撰写文件，只更改我需要更改的部分
  • 不要使用docker stack deploy，而是使用旧的docker service create
  • 某种类型的环境变量传递到 compose 文件中（这里的问题是每个服务仍然必须知道其他服务的当前版本对吗？）
  • 为每个服务使用不同的堆栈（这有什么问题或问题吗？）

我忽略了什么吗？这样的建筑不是故意的吗？这里有什么更好的方法？

4

1 回答 1

1

我发现使用最后一个选项最容易，将每个服务拆分到自己的堆栈中，而不涉及其他任何内容。然后你提升单个服务的堆栈。为此，我将添加两个先决条件：

  • 提前定义您的网络。然后在您的撰写中，将它们定义为外部以允许服务相互连接。当您将服务拆分为单独的堆栈时，这是您损失的最大部分。

  • 运行您自己的注册表。对我来说，这比仅仅依靠固定版本更安全。Pinning 将确保您在 swarm 中的所有节点上拉取相同的版本，但如果您从 dev 升级到 test 到 prod，这些将是单独的堆栈，并且可能完全独立的 swarm。对我来说，依赖 repo 中仅以受控方式（CI/CD 脚本）更新的标签要容易得多。

单独的堆栈具有独立更新每个服务而不会破坏其他任何内容的优点。但另一方面，缺点是当发生影响一切的更改时，您需要独立更新每个服务。这可能意味着您需要更多的脚本/自动化来管理环境。

于 2017-02-10T02:22:39.880 回答