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. 随着已建成集装箱你是开放的，立即多种选择：
   • 动态可扩展性。一旦你发现你有大量的用户，你所要做的就是筹集新的虚拟机并将容器拉到那里。甚至在同一台主机上启动另一个容器并对其进行平衡。
   • 修补程序部署。有可能在重负载下出现一些错误。而当您尝试同时服务大量用户和构建新的bugfix容器时，生产服务器可能会资源不足。
   • 灾难恢复。如果您的生产主机突然死机，您只需在其他任何地方运行码头集装箱。在这种情况下，您可能会遇到未优化的环境，但至少您不必为用户写关于N小时宕机时间的解释电子邮件。

我能跟上，但总结：这一切都取决于你有多少用户，你怎么打算通过时间来成长，你有多少资源，有，有多少人需要到构建，如何容忍停机时间等等。当然，您可以在prod服务器上构建容器并将其上传到docker repo，并且可以愉快地生活，以防这是一个小型非关键内部门户。但是，如果你是某种社交网络初创公司，你最好开始分离环境并创建各种关于可伸缩性和恢复的计划。并且在单独的服务器上构建应用程序是此类计划的重要组成部分。