在CI/CD中的Docker图像是否只对多主机有用？

Question

我们是两个人在Docker中开发一个主机应用程序，在那里我们想要减少一些测试时间并使用CI/CD。

许多文章都是关于使用付费服务来运行测试和构建Docker映像，然后部署映像。

在多主机环境中，我可以看到部署映像的优点，但是单主机又如何呢？

在单个主机情况下，部署映像仅仅是一层额外的复杂性吗？

更新

我们现在所做的是将更改推到Git上，然后手动测试应用程序，如果没有问题，那么合并到主服务器并登录到生产服务器并执行git pull && docker-compose build。

当我在问题中谈到部署Docker映像时，在生产中部署几乎只是docker pull。关键的区别在于，不是在生产服务器上构建的，而是在其他地方构建的坞映像。

这就是我要问的。如果映像只部署在单个主机/机器/服务器/节点上，那么在其他地方构建映像有什么好处吗？

Answer 1

我正在回答已经更新的问题：

在其他地方建立<...>图像有什么好处吗？

是的，有一些.

1. 您的不需要更新生产服务器上的构建工具；实际上，您根本不需要它们。这减少了dev/QA/prod环境之间可能出现版本错配的可能性，减少了在服务器上发现一些0天漏洞的可能性，等等。一般来说，生产服务器上的附加软件越少，越好。
2. 对于已经构建的容器，您可以立即使用许多选项：
   • 动态可伸缩性。一旦您发现您有大量的用户，您所要做的就是提高新的VM并在那里拉出容器。甚至在同一台主机上启动另一个容器并平衡它们。
   • 修补程序部署。在沉重的负荷下，可能会出现一些错误。当您试图同时为大量用户服务并构建新的bugfix容器时，生产服务器可能就没有资源了。
   • 灾难恢复。如果您的生产主机突然死亡，您所要做的就是运行其他任何地方的码头容器。在这种情况下，您可能会受到未经优化的环境的影响，但至少您不必向用户发送关于N小时停机时间的电子邮件解释。

​

我可以跟上，但总结一下:这一切都取决于你有多少用户，你打算如何在时间中成长，你有多少资源，需要建立多少资源，你对停机时间有多宽容等等。当然，你可以在prod服务器上构建容器，然后上传到码头回购系统，然后在这是一个小型的非关键的内部门户网站的情况下快乐地生活。但是，如果你是一家社交网络的初创公司，你最好开始分离不同的环境，并创建关于可伸缩性和恢复的各种计划。而将应用程序构建在单独的服务器上也是此类计划的一个重要部分。