Docker Swarm - 跨主机部署具有共享代码库的堆栈
Docker Swarm - Deploying stack with shared code base across hosts
我有一个关于基于 docker 群将应用程序部署到生产环境的最佳实践的问题。
为了简化与此相关的讨论 question/issue 让我们考虑以下场景：
我们的群体包含：
- 6台服务器（不同主机）
- 在这些服务器中的每一个上，我们将有一个服务
- 每个服务将只有一个 task/replica docker 运行ning
- Memcached1 和 Memcached2 使用 public 来自 docker hub
的图像
- "Recycle data 1" 和 "Recycle data 2" 使用私有存储库中的自定义图像
- "Client 1" 和 "Client 2" 使用私有存储库中的自定义图像
所以最后，对于我们的示例应用程序，我们在 6 个不同的服务器上有 6 个 dockers 运行ning。 2 dockers 是 memcached，其中 4 个是与 memcached 通信的客户端。
"Client 1" 和 "Client 2" 将根据某种规则在 memcached 中插入数据。 "Recycle data 1" 和 "Recycle data 2" 将根据某种规则更新或删除 memcached 中的数据。就这么简单。
我们与 memcached 通信的应用程序是自定义应用程序，它们是我们编写的。这些应用程序的代码驻留在 github（或任何其他存储库）中。将此应用程序部署到生产环境的最佳方式是什么：
- 构建镜像，在镜像中包含复制的代码，您可以使用这些代码将东西部署到 swarm
- 构建将使用代码驻留在图像外部的卷的图像。
考虑到我是第一次将 swarm 部署到生产环境中，我可以看到方法 1 存在很多问题。将代码合并到图像中对我来说似乎不合逻辑，请记住在 99% 的时间里，即将发生的更新将基于代码。每当您想更新 运行 特定 docker 上的代码时（无论更改有多么小），这都需要构建图像。
方法 2. 对我来说似乎更合乎逻辑。但在这个特定时刻，我不确定这可能吗？所以这里有很多问题：
- 如果我们要托管多个 docker 将在后台 运行 相同代码的情况下，最好的方法是什么？
- 是否有可能在 docker swarm 上拥有一个中央主机、服务器（管理器，任何地方），我们可以在其中克隆我们的存储库并将这些存储库作为卷共享到 docker 蜂拥而至？ （在我们的示例中，所有 4 个客户服务都将在我们托管代码的位置安装卷）
- 如果这是可能的，docker-compose.yml 实现是什么？
在更深入地挖掘并使用 docker 和 docker 集群模式 3 个月后，这些是上述问题的答案：
答案 1： 通常，您应该将 docker 映像视为程序的 "compiled" 版本。您的图像应包含代码库或程序的编译版本（取决于您使用的编程语言），并且该特定图像代表您的应用程序版本。每次要部署下一个版本时，都会生成新映像。
这可能是 99% 将由 docker 托管的应用程序的最佳方法（开发环境和应用程序除外，您确实想要 bash 并直接控制事物来自 docker 容器本身）。
答案2：有可能，但这是非常糟糕的做法。正如答案一中提到的，最好的方法是将应用程序代码直接复制到图像中，然后 "consider" 您的图像（运行 容器）作为 "app by itself".
一开始我无法理解这个概念，因为这个概念不允许您简单地转到服务器（或您托管 docker 的任何地方）并更改应用程序并重新启动 docker（很明显，因为容器将在重新启动后再次使用相同的图像，您使用该图像部署的相同代码库）。任何类型的更改 应该并且需要 部署为具有不同版本的不同图像。这就是 docker 的意义所在。
此外，跨多个群服务共享相同代码库的最初想法是可能的，但这完全破坏了跨 docker 群进行版本控制的目的。
考虑将 3 项服务用作冗余服务（故障转移），并且您想在其中一项上使用新版本作为 Beta 测试。这对于共享代码库是不可能的。
我有一个关于基于 docker 群将应用程序部署到生产环境的最佳实践的问题。
为了简化与此相关的讨论 question/issue 让我们考虑以下场景：
我们的群体包含：
- 6台服务器（不同主机）
- 在这些服务器中的每一个上，我们将有一个服务
- 每个服务将只有一个 task/replica docker 运行ning
- Memcached1 和 Memcached2 使用 public 来自 docker hub 的图像
- "Recycle data 1" 和 "Recycle data 2" 使用私有存储库中的自定义图像
- "Client 1" 和 "Client 2" 使用私有存储库中的自定义图像
所以最后，对于我们的示例应用程序，我们在 6 个不同的服务器上有 6 个 dockers 运行ning。 2 dockers 是 memcached，其中 4 个是与 memcached 通信的客户端。 "Client 1" 和 "Client 2" 将根据某种规则在 memcached 中插入数据。 "Recycle data 1" 和 "Recycle data 2" 将根据某种规则更新或删除 memcached 中的数据。就这么简单。
我们与 memcached 通信的应用程序是自定义应用程序，它们是我们编写的。这些应用程序的代码驻留在 github（或任何其他存储库）中。将此应用程序部署到生产环境的最佳方式是什么：
- 构建镜像，在镜像中包含复制的代码，您可以使用这些代码将东西部署到 swarm
- 构建将使用代码驻留在图像外部的卷的图像。
考虑到我是第一次将 swarm 部署到生产环境中，我可以看到方法 1 存在很多问题。将代码合并到图像中对我来说似乎不合逻辑，请记住在 99% 的时间里，即将发生的更新将基于代码。每当您想更新 运行 特定 docker 上的代码时（无论更改有多么小），这都需要构建图像。
方法 2. 对我来说似乎更合乎逻辑。但在这个特定时刻，我不确定这可能吗？所以这里有很多问题：
- 如果我们要托管多个 docker 将在后台 运行 相同代码的情况下，最好的方法是什么？
- 是否有可能在 docker swarm 上拥有一个中央主机、服务器（管理器，任何地方），我们可以在其中克隆我们的存储库并将这些存储库作为卷共享到 docker 蜂拥而至？ （在我们的示例中，所有 4 个客户服务都将在我们托管代码的位置安装卷）
- 如果这是可能的，docker-compose.yml 实现是什么？
在更深入地挖掘并使用 docker 和 docker 集群模式 3 个月后，这些是上述问题的答案：
答案 1： 通常，您应该将 docker 映像视为程序的 "compiled" 版本。您的图像应包含代码库或程序的编译版本（取决于您使用的编程语言），并且该特定图像代表您的应用程序版本。每次要部署下一个版本时，都会生成新映像。
这可能是 99% 将由 docker 托管的应用程序的最佳方法（开发环境和应用程序除外，您确实想要 bash 并直接控制事物来自 docker 容器本身）。
答案2：有可能，但这是非常糟糕的做法。正如答案一中提到的，最好的方法是将应用程序代码直接复制到图像中，然后 "consider" 您的图像（运行 容器）作为 "app by itself".
一开始我无法理解这个概念，因为这个概念不允许您简单地转到服务器（或您托管 docker 的任何地方）并更改应用程序并重新启动 docker（很明显，因为容器将在重新启动后再次使用相同的图像，您使用该图像部署的相同代码库）。任何类型的更改 应该并且需要 部署为具有不同版本的不同图像。这就是 docker 的意义所在。
此外，跨多个群服务共享相同代码库的最初想法是可能的，但这完全破坏了跨 docker 群进行版本控制的目的。
考虑将 3 项服务用作冗余服务（故障转移），并且您想在其中一项上使用新版本作为 Beta 测试。这对于共享代码库是不可能的。