Docker Swarm - 跨主机部署具有共享代码库的堆栈

Question

我有一个与基于docker swarm将应用程序部署到生产的最佳实践相关的问题.

为了简化与此问题/问题相关的讨论,请考虑以下方案:

我们的群包含:

• 6台服务器(不同主机)
• 在每个服务器上,我们将提供一项服务
• 每个服务只有一个任务/副本docker运行
• Memcached1和Memcached2使用来自docker hub的公共映像
• "回收数据1"和"回收数据2"使用来自私有存储库的自定义映像
• "客户端1"和"客户端2"使用来自私有存储库的自定义映像

所以最后,对于我们的示例应用程序,我们有6个docker在6个不同的服务器上运行.memcached有2个docker,其中4个是与memcached通信的客户端."客户端1"和"客户端2"将根据某种规则在memcached中插入数据."回收数据1"和"回收数据2"将根据某种规则更新或删除memcached中的数据.就那么简单.

我们与memcached通信的应用程序是自定义的,它们是由我们编写的.这些应用程序的代码驻留在github(或任何其他存储库)上.将此应用程序部署到生产中的最佳方法是什么:

1. 构建图像,其中包含图像中的复制代码,您可以使用这些代码将内容部署到群组中
2. 构建将使用代码位于图像之外的卷的图像.

考虑到我是第一次将swarm部署到生产环境中,我可以看到很多问题的方法都是第1号.将代码合并到图像中对我来说似乎不合逻辑,记住99%的时间,即将发生的更新将基于代码.每当您想要更新在特定docker上运行的代码时(无论更改有多小),这都需要构建映像.

方式2对我来说似乎更符合逻辑.但在这个具体时刻,我不确定这是否可能？所以这里有很多问题:

1. 如果我们要托管多个将在后台运行相同代码的docker,最好的方法是什么？
2. 是否有可能在docker swarm上有一个中央主机,服务器(管理器,任何地方)我们可以克隆我们的存储库并将这些存储库作为跨泊坞群的卷共享？(在我们的示例中,所有4个客户服务将在我们托管代码的地方安装卷)
3. 如果这是可能的,那么docker-compose.yml的实现是什么？

Answer 1

在过去 3 个月更深入地挖掘并使用 docker 和 docker swarm 模式之后，以下是上述问题的答案：

Answer 1: In general, you should consider your docker image as "compiled" version of your program. Your image should contain either code base, or compiled version of the program (depends which programming language you are using), and that specific image represents your version of the app. Every single time when you want to deploy your next version, you will generate the new image.

This is probably best approach for 99% of the apps which are going to be hosted with the docker (exceptions are development environments and apps where you really want to bash and control things directly from the docker container by itself).

Answer 2: It is possible but it is extremely bad approach. As mentioned in answer one, the best one is to copy the app code directly into the image and "consider" your image (running container) as "app by itself".

I was not able to wrap my head around this concept at the begging, because this concept will not allow you to simply go to the server (or where ever you are hosting your docker) and change the app and restart docker (obviously because container will be at the same beginning again after restart using the same image, same base of code you deployed with that image). Any kind of change SHOULD and NEEDS to be deployed as different image with different version. That is what docker is all about.

Additionally, initial idea for sharing same code base across multiple swarm services is possible, but it totally ruins purpose of the versioning across docker swarm.

Consider having 3 services which are used as redundant services (failover), and you want to use new version on one of them as beta test. This will not be possible with the shared code base.