微服务持续交付的环境策略
这是微服务持续集成(CD) 系列的第四篇。在上一篇中,我们深入探讨了持续集成 (CI) 实践,特别是基于主干的部署和功能切换。在这篇文章中,我们将讨论环境策略。
环境计划
在某些组织中,人们直到拥有太多环境并且维护它们变得难以承受时才意识到环境计划的重要性。
环境规划会传达生产路径中涉及的各种环境及其预期用途。它还会传达您的工件的推广方式以及这些环境中的切换状态。
您可以先思考需要预先创建哪些环境,并讨论这些环境的预期用例。组织中不同的团队会有不同的需求。您的环境规划应该兼顾各方的需求。
神器推广
工件是软件开发过程中产生的众多有形副产品之一。其中一些工件是文本文件,例如测试报告和覆盖率报告。还有一些工件是二进制文件,例如 npm 包、jar 文件和 AMI 机器镜像,它们只需构建一次,即可沿着持续交付 (CD) 流水线传播,以便在下游环境中部署。
持续交付 (CD) 流水线会生成大量的工件。不知不觉中,生成的工件数量就达到了数 TB,甚至数十 TB。因此,务必仔细思考工件的推广策略,该策略要考虑这些工件的存储位置、保留数量以及如何进行清理。
上图展示了一个环境规划,其中考虑了工件提升策略。从规划中,您可以看到持续交付 (CD) 流水线中存在的环境,不同颜色的箭头表示不同的工件提升策略。在此流水线的早期阶段,我们生成的工件会被放入一个具有更积极清理策略的工件存储库中,因此我们实际上不会保留太多此类环境。随着流水线的深入,工件会得到验证,并且更加健壮,您可能希望保留它们更长时间,因此您可以将它们保存在具有不同保留策略的存储库中。
动态环境
环境维护成本高昂且繁琐。简化流程并降低成本的一种方法是动态创建环境。例如,在运行功能测试时,您可以按需配置功能测试环境,然后在测试完成后立即清理。
为此,您需要使用IaaC技术来编写环境配置的各个方面。这样做的好处如下:
与生产环境一致如果您基于自动化动态创建所有环境,则您将使用完全相同的方式创建测试和暂存环境。基础设施的规模和性质可能有所不同,但环境的占用空间保持不变。
防止偏差如果您采用手动流程和手动安装,则无法真正确保两个环境完全相同。但使用脚本创建短暂的动态环境可以防止偏差。
高效利用硬件和基础设施仅在需要时创建环境并动态清理,以优化利用率并节省基础设施成本。
如今,诸如容器调度器之类的技术在部署和运行应用程序方面风靡一时。下图是一个基于 Docker 的 Kubernetes 构建工作流示例。
此流水线的 CI 部分(即左侧的构建流水线)会生成 Docker 镜像。来自此流水线的构件(即 Docker 镜像)存储在 Docker 注册表中。再往下游,部署环境会直接部署到 Kubernetes。您可以利用 Kubernetes 的功能(例如其标签概念)来动态配置环境。
概括
这是我们“微服务CD”博客系列的第四部分。我们已经讨论了环境策略,包括工件推广以及如何利用现代基础设施来构建动态环境。在下一篇文章中,我们将讨论第四个考虑因素:配置策略。
文章来源:https://dev.to/gocd/environment-strategy-for-continuous-delivery-of-microservices-5bki