Docker 最佳实践：如何使用CI/CD将flask webapp部署到digital ocean？

我正在自学如何使用Jenkins和Docker制作CI/CD并部署到digital ocean。我在某些步骤上遇到了困难，我对CI/CD的最佳实践特别感兴趣

我目前拥有的流程/管道：

带有Flask web app和docker-compose.yml的本地代码（包括dockerfile）

将代码推送到github

CI:Local jenkins（稍后将传输到主机）测试代码

如果测试成功运行，我将登录到droplet，克隆repo，停止运行docker容器，执行docker撰写

我的应用程序又上线了

我想自动化第4步，我可能有两个计划如何做到这一点（关于最佳实践的建议非常感谢！）

计划1:
1.在Jenkins管道中编写一个步骤，该步骤将
4.1. 自动启动新液滴
4.2使用ssh登录it
4.3从github提取代码
4.4从docker compose开始
4.5 IP浮动至新液滴时的重新路由

计划2:
2.在Jenkins管道中编写一个步骤，该步骤将
4.1构建代码并以某种方式将图像推送到“某处”
4.2开始新的液滴
4.3使用ssh登录droplet
4.4从“某处”提取图像
4.5从docker compose开始
4.6 IP浮动至新液滴时的重新路由

我想听听您对这些步骤的看法：
1.哪个计划更好？ 2.我还能做得更好吗？
3.我可以使用哪些最佳实践？
4.在哪里可以推送图像，以便将其拉入新的液滴

编辑：

我想听听你对以下问题的回答：
1.哪个计划更好？

---

2.为什么Kubernetes在生产环境中比docker compose更好

我建议在生产环境中使用Kubernetes而不是docker compose。如果不是Kubernetes，你真的只想要Docker，那么至少让它成为Docker Swarm

• docker compose对于生产来说是不可靠的，因为首先它只适用于单个节点。如果您想扩大规模，您肯定会有停机时间，因为您将依赖垂直规模（增加节点资源）
• Kubernetes和Docker Swarm是编排工具。这意味着您可以添加更多服务器来扩展应用程序，即水平扩展。此编排允许将容器分配给其他液滴，并且它们可以自由地与其他容器通信，即使它们位于不同的液滴中docker compose单靠它是做不到的。我会向初学者推荐Docker Swarm，因为Kubernetes非常复杂

通常情况下，您只需在云中设置基础设施，然后您的CI/CD将在Jenkins上进行持续映像构建，至少然后自动部署到您的服务器

• 我在这里说的是。。当您将代码合并到源代码存储库（如Github或Bitbucket）的特定分支（如master）中时，将运行自动Jenkins构建，然后执行CI/CD。。所以，基本上每次主程序有一个更新，然后它也会更新你的图像内液滴，从而有最新的源代码

在您使用数字海洋的情况下。。您可以在droplet上创建一个API，用于接受Webhook以触发自动部署

• 这是我在使用数字海洋时可以想到的方法。DIgital Ocean非常便宜，但与您尝试GCP和AWS不同，它是手动完成的。在GCP和AWS中，实现部署自动化的方法比创建自己的webhook API更多。关于您的上一句话“如果我可以使用Jenkins克隆代码，在新的液滴中运行容器，并使用IP浮动重新路由”，但我认为这太多了，而且速度很慢。仅此过程可能需要10分钟？我们使用Kubernetes进行部署自动化的时间可能只有30秒。我们的整个CI/CD只需2分钟

---

关于你的第四个问题。。Dockerhub应该适合您的图像存储库

谢谢您的回答！我有几个后续问题。1.为什么Kubernetes而不是docker在production env上创作？为什么Docker蜂拥而至？2.我不确定你的第二段是在解决什么问题。我让Jenkins在本地运行，因为我只是想测试它是如何工作的，并将它部署到服务器上。我完成这个项目后，一切都会乱七八糟的。3.如果我可以使用Jenkins克隆代码，在新的液滴中运行容器，并使用IP浮动重新路由，为什么我需要在我的液滴上创建API？看起来你是CI/CD的初学者。我以前也有同样的问题。。我会更新我的答案，请等我更新我的答案。请随便检查