View a markdown version of this page

自动检测变化并为 monorepo 启动不同的 CodePipeline 管道 CodeCommit - AWS 规范指引

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

自动检测变化并为 monorepo 启动不同的 CodePipeline 管道 CodeCommit

Helton Ribeiro、Petrus Batalha 和 Ricardo Morais,Amazon Web Services

Summary

注意: AWS Cloud9 已不再向新客户开放。的现有客户 AWS Cloud9 可以继续照常使用该服务。了解详情

这种模式可以帮助您自动检测基于 monorepo 的应用程序的源代码的更改,然后在其中启动运行持续集成 AWS CodeCommit 和持续交付(管道)的CI/CD) automation for each microservice. This approach means that each microservice in your monorepo-based application can have a dedicated CI/CD管道,从而确保更好的可见性、更轻松的代码共享以及改进的协作、标准化和可发现性。 AWS CodePipeline

此模式中描述的解决方案不会在 monorepo 内部的微服务之间执行任何依赖关系分析。它仅检测源代码中的更改并启动匹配的 CI/CD 管道。

该模式 AWS Cloud9 用作集成开发环境 (IDE),并使用两个 CloudFormation 堆栈 AWS Cloud Development Kit (AWS CDK) 来定义基础架构:MonoRepoStackPipelinesStackMonoRepoStack堆栈在中创建 monorepo AWS CodeCommit 和启动管道的 AWS Lambda 函数。 CI/CD PipelinesStack 堆栈定义了管道基础设施。

重要

此模式的工作流是概念验证(PoC)。我们建议您仅将其用在测试环境中。如果您想在生产环境中使用此模式的方法,请参阅 AWS Identity and Access Management (IAM) 文档中的 IAM 中的安全最佳实践,并对您的 IAM 角色和进行必要的更改 AWS 服务。 

先决条件和限制

先决条件

架构

下图显示了如何使用 AWS CDK 来定义具有两个 AWS CloudFormation 堆栈的基础架构:MonoRepoStack和。PipelinesStack

使用 AWS CDK 定义包含两个 CloudFormation 堆栈的基础设施的工作流程。

下图显示了如下工作流:

  1. 引导过程使用创建 AWS CloudFormation 堆栈和MonoRepoStack。 AWS CDK PipelinesStack

  2. MonoRepoStack堆栈会为您的应用程序创建 CodeCommit 存储库,并在每次提交后启动的 monorepo-event-handler Lambda 函数。

  3. PipelinesStack堆栈在 CodePipeline 其中创建由 Lambda 函数启动的管道。每项微服务都必须有定义的基础设施管道。

  4. 的管道microservice-n由 Lambda 函数启动,并根据中的源代码启动其隔离 CI/CD 阶段。 CodeCommit

  5. 的管道microservice-1由 Lambda 函数启动,并根据中的源代码启动其隔离 CI/CD 阶段。 CodeCommit

下图显示了 AWS CloudFormation 堆栈MonoRepoStack和账户PipelinesStack中的部署情况。

在 AWS 账户 MonoRepoStack PipelinesStack 中部署 CloudFormation 堆栈。
  1. 用户在其中一个应用程序微服务中更改代码。

  2. 用户将更改从本地存储库推送到 CodeCommit 存储库。

  3. 推送活动启动 Lambda 函数,该函数接收所有到存储库的推送。 CodeCommit

  4. Lambda 函数在 Parameter Store( AWS Systems Manager的一项功能)中读取参数,以检索最新的提交 ID。此参数的命名格式为:/MonoRepoTrigger/{repository}/{branch_name}/LastCommit。如果未找到该参数,Lambda 函数会从 CodeCommit 存储库中读取最后一次提交 ID,并将返回的值保存在参数存储中。

  5. 识别提交 ID 和更改的文件后,Lambda 函数会识别每个微服务目录的管道并启动所需的管道。 CodePipeline

工具

  • AWS Cloud Development Kit (AWS CDK)是一个软件开发框架,用于在代码中定义云基础架构并通过它进行配置 CloudFormation。

  • Python 是一种可让您快速工作并更高效地集成系统的编程语言。

代码

此模式的源代码和模板可在 GitHub AWS CodeCommit monorepo 多管道触发器存储库中找到。

最佳实践

操作说明

Task说明所需技能

创建虚拟 Python 环境。

在 AWS Cloud9 IDE 中,通过运行以下命令创建虚拟 Python 环境并安装所需的依赖项:

make install

开发者版

Bootstrap AWS 账户 和 f AWS 区域 or. AWS CDK

通过运行以下命令引导所需的 AWS 账户 区域和区域:

make bootstrap account-id=<your-AWS-account-ID> region=<required-region>

开发者版
Task说明所需技能

将示例代码添加至应用程序目录。

将包含您的示例应用程序代码的目录添加到克隆的 GitHub AWS CodeCommit monorepo 多管道触发器存储库中的monorepo-sample目录中。

开发者版

编辑 monorepo-main.json 文件。

将应用程序代码目录名称和管道名称添加至克隆的存储库中的 monorepo-main.json 文件。

开发者版

创建管道。

在适用于存储库的 Pipelines 目录中,为您的应用程序添加管道 class。该目录包含两个示例文件:pipeline_hotsite.pypipeline_demo.py。每个文件都有三个阶段:源、构建和部署。

您可以复制其中一个文件,并根据应用程序要求对其进行更改。 

开发者版

编辑 monorepo_config.py 文件。

service_map 中,添加应用程序的目录名称和为管道创建的分类。

例如,以下代码显示了 Pipelines 目录中的管道定义,该定义使用名为 pipeline_mysample.pyMySamplePipeline 类文件:

... # Pipeline definition imports from pipelines.pipeline_demo import DemoPipeline from pipelines.pipeline_hotsite import HotsitePipeline from pipelines.pipeline_mysample import MySamplePipeline ### Add your pipeline configuration here service_map: Dict[str, ServicePipeline] = { # folder-name -> pipeline-class 'demo': DemoPipeline(), 'hotsite': HotsitePipeline(), 'mysample': MySamplePipeline() }
开发者版
Task说明所需技能

部署 AWS CloudFormation 堆栈。

通过运行make deploy-core命令将带有默认参数值的 AWS CloudFormation MonoRepoStack堆栈部署到克隆存储库的根目录中。

您可以通过运行 make deploy-core monorepo-name=<repo_name> 命令更改存储库名称。

注意

您可以使用 make deploy monorepo-name=<repo_name> 命令同时部署两个管道。

开发者版

验证 CodeCommit 存储库。

通过运行 aws codecommit get-repository --repository-name <repo_name> 命令验证资源是否已创建。

重要

由于 CloudFormation 堆栈会创建存储 monorepo 的存储 CodeCommit 库,因此如果您已开始向其中推送修改,请不要运行该cdk destroy MonoRepoStack 命令。

开发者版

验证 CloudFormation 堆栈结果。

通过运行以下命令验证 CloudFormation MonoRepoStack堆栈的创建和配置是否正确:

aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE --query 'StackSummaries[?StackName == 'MonoRepoStack']'
开发者版
Task说明所需技能

部署 CloudFormation 堆栈。

AWS CloudFormation PipelinesStack堆栈必须在部署堆MonoRepoStack栈后部署。当将新微服务添加至 monorepo 的代码库中时,堆栈的大小会增加,并在加入新微服务时重新部署。

通过运行make deploy-pipelines命令部署 PipelinesStack 堆栈。

注意

您也可以通过运行 make deploy monorepo-name=<repo_name> 命令同时部署两个管道。

以下示例输出显示了PipelinesStacks部署在 URLs 实现结束时如何打印微服务的内容:

Outputs: PipelinesStack.demourl = .cloudfront.net PipelinesStack.hotsiteurl = .cloudfront.net
开发者版

验证 AWS CloudFormation 堆栈结果。

通过运行以下命令验证 AWS CloudFormation PipelinesStacks堆栈的创建和配置是否正确:

aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE --query 'StackSummaries[?StackName == 'PipelinesStack']'
开发者版
Task说明所需技能

删除您的 AWS CloudFormation 堆栈。

运行 make destroy命令。

开发者版

删除管道的 S3 存储桶。

  1. 登录 AWS 管理控制台,并打开 Amazon Simple Storage Service(Amazon S3)控制台

  2. 删除与您的管道关联且使用以下名称的 S3 存储桶:pipelinesstack-codepipeline*

开发者版

问题排查

问题解决方案

我遇到了 AWS CDK 问题。

请参阅 AWS CDK 文档中的常见 AWS CDK 问题疑难解答

我推送了我的微服务代码,但微服务管道未运行。

设置验证

验证分支配置:

  • 确保您已将代码推送至正确的分支。此管道配置为仅在对 main 分支进行更改时运行。除非经过专门配置,否则推送到其他分支的行为不会启动管道。

  • 推送代码后,请检查提交是否在中可见, AWS CodeCommit 以确保推送成功且本地环境与存储库之间的连接完好无损。如果推送代码时出现问题,请刷新您的凭证。

验证配置文件:

  • 确认 monorepo_config.py 中的 service_map 变量准确反映了微服务的当前目录结构。此变量在将您的代码推送映射到相应的管道方面起着至关重要的作用。

  • 确保更新了 monorepo-main.json 以包含微服务的新映射。该文件对于管道识别和正确处理微服务的更改至关重要。

在控制台上排查问题

AWS CodePipeline 支票:

  • 在上 AWS 管理控制台,确认您 AWS 区域 所在的管道所在地。打开CodePipeline 控制台,检查与您的微服务对应的管道是否已启动。

    错误分析:如果管道已启动但失败,请查看提供的任何错误消息或日志 CodePipeline ,以了解出了什么问题。

AWS Lambda 疑难解答:

  • AWS Lambda 控制台上,打开 monorepo-event-handler Lambda 函数。验证该函数是为了响应代码推送而启动。

    日志分析:检查 Lambda 函数的日志中是否存在任何问题。这些日志可以提供关于函数运行时发生的事情的详细见解,并帮助确定函数是否按预期方式处理事件。

我需要重新部署我所有的微服务。

有两种方法可强制重新部署所有微服务。选择适合您要求的选项。

方法 1:删除 Parameter Store 中的参数

此方法涉及删除 Systems Manager Parameter Store 中的特定参数,该参数跟踪上次用于部署的提交 ID。删除此参数后,系统将被迫在下次触发时重新部署所有微服务,因为它会将其视为刷新状态。

步骤:

  1. 找到包含您的 monorepo 的提交 ID 或相关部署标记的特定 Parameter Store 条目。参数名称有以下形式:"/MonoRepoTrigger/{repository}/{branch_name}/LastCommit"

  2. 如果参数值至关重要,或者您希望在重置之前保留部署状态的记录,请考虑备份参数值。

  3. 使用 AWS 管理控制台 AWS CLI、或 SDKs 删除已识别的参数。此操作会重置部署标记。

  4. 删除后,下一次向存储库推送会导致系统部署所有微服务,因为它会寻找要考虑部署的最新提交。

优点:

  • 只需最少的步骤即可简单快捷地实施。

  • 不需要进行任意代码更改即可启动部署。

缺点:

  • 对部署过程的控制不那么精细。

  • 如果使用 Parameter Store 来管理其他关键配置,则可能存在风险。

方法 2:在每个 monorepo 子文件夹中推送一个提交

此方法涉及进行细微的更改,然后将其推送到 monorepo 中的每个微服务子文件夹中,以启动其各自的管道。

步骤:

  1. 列出 monorepo 中所有需要重新部署的微服务。

  2. 对于每项微服务,在其子文件夹中进行最小、无影响的更改。这可以是更新 README 文件、在配置文件中添加注释或任何不影响服务功能的更改。

  3. 使用明确的消息(例如“启动微服务重新部署”)提交这些更改,然后将其推送到存储库。确保将更改推送到启动部署的分支。

  4. 监控每项微服务的管道,以确认它们已启动并成功完成。

优点:

  • 精细地控制重新部署哪些微服务。

  • 更加安全,因为它不涉及删除可能用于其他用途的配置参数。

缺点:

  • 更加耗时,尤其是在使用大量微服务时。

  • 需要进行不必要的代码更改,这可能会使提交历史记录混乱。

相关资源