★ FEATURED ARTICLE 【免费下载链接】aws-cdk-examplesExample projects using the AWS CDK项目地址https://gitcode.com/gh_mirrors/aw/aws-cdk-examples点击查看免费下载本文基于开源仓库 aws-cdk-examples 中的typescript/aws-codepipeline-ecs-lambda示例系统讲解如何用 AWS CDK 从零搭建一套面向初创团队的生产级 CI/CD 平台包含 VPC 网络、Aurora Serverless v2 数据库、ECS Fargate 容器服务、API Gateway Lambda 的 REST 端点以及由 SQS、SNS、EventBridge 驱动的异步事件架构并通过 CodePipeline 实现从 GitHub 私有仓库到多区域多环境的自动化部署。读完本文你将掌握该示例六大 Stack 的组织方式、每个文件的职责边界以及如何替换为自己的 GitHub 仓库和 AWS 账号完成端到端部署。架构总览该示例的核心定位是为从单体 EC2 架构迁移到云原生方案提供一套生产级 CDK 模板。整个系统以 CodePipeline 为中枢把基础设施代码CDK和应用代码Docker 镜像、Lambda 函数统一纳入持续集成与持续部署流程。从源码看CI/CD 流水线本身运行在独立的“Pipeline 账号/区域”通过cdk.Stage把六类资源以“应用阶段”的形式批量部署到开发账号的多个区域并在流水线中加入人工审批环节——这正是一套典型的“单账号构建、多账号/多区域发布”的企业级发布模型。关键特性一览README 中明确列出的核心能力如下每一项目标都能在源码中找到对应实现CI/CD 流水线基于 AWS CodePipelineaws-cdk-lib/pipelines模块实现代码变更后的自动构建、合成与部署Lambda 函数双形态既有通过 API Gateway 暴露的 REST 端点也有由 SQS / SNS / EventBridge 事件异步触发的后台函数ECS Fargate 服务容器化服务随流水线自动构建镜像、自动部署并内置应用负载均衡与自动扩缩私有 GitHub 仓库集成通过 Codestar Connections 连接 GitHub / GitHub Enterprise CloudCDK 创建的 VPC网络资源全部由 CDK 声明式创建无需手工配置RDS 数据库创建 Aurora Serverless v2 集群凭据由 AWS Secrets Manager 托管事件驱动架构SQS、SNS、EventBridge 串联 Lambda并配备 DLQ死信队列、重试与批量配置。开始前的准备工作按 README 的说明部署前需要完成三件事准备 GitHub 私有仓库将typescript/aws-codepipeline-ecs-lambda目录中的源码推送到你自己的私有 GitHub 仓库示例代码引用了仓库aws-codepipeline-ecs-lambda。创建 GitHub 连接在 AWS 开发工具控制台Developer Tools Console为 GitHub 或 GitHub Enterprise Cloud 创建连接Codestar Connections以获得一个形如arn:aws:codestar-connections:region:account:connection/uuid的 ARN。替换流水线参数修改 pipeline-stack.ts 中的connectionArn以及githubOrg、githubRepo、githubBranch为你私有仓库的实际信息。实际上这些配置在入口文件 app.ts 中全部支持通过环境变量覆盖默认值如下表环境变量默认值用途PIPELINE_ACCOUNT_ID111111111111流水线所在账号 IDPIPELINE_REGIONus-east-1流水线所在区域GITHUB_ORGaws-6w8hnxGitHub 组织/用户名GITHUB_REPOaws-codepipeline-ecs-lambdaGitHub 仓库名GITHUB_BRANCHmain监听的分支DEV_ENVdev环境标识部署阶段名DEV_ACCOUNT_ID222222222222目标开发账号 IDPRIMARY_REGIONus-west-2主部署区域SECONDARY_REGIONeu-west-1备部署区域项目结构与六大 Stack示例代码按职责划分为六个 Stack对应六类基础设施资源VpcStack—— 网络基础设施资源DataStoresStack—— 数据库资源PubSubStack—— 事件基础设施SQS、SNS、EventBridgeAsyncLambdasStack—— 异步触发的 Lambda 函数LambdaApisStack—— 作为 API Gateway 背后 REST 端点的 LambdaEcsFargateStack—— ECS Fargate 服务、集群、任务与容器。README 提示可通过修改或移除 stage-app.ts 中的某个 Stack 实例轻松裁剪不需要的基础设施。说明README 中提到的lib/pipeline-stage.ts与lib/PubSubStack.ts在当前仓库中对应的实际文件为 lib/stage-app.ts 与 lib/stage-app-async-lambda-stack.ts功能定位一致后者承担 PubSub 职责。逐文件剖析解决方案1. 流水线定义lib/pipeline-stack.ts流水线是整个 CI/CD 的中枢。核心组件是aws-cdk-lib/pipelines提供的CodePipeline构造pipeline-stack.ts 中的关键配置selfMutation: true允许流水线在自身定义发生变化时自我更新crossAccountKeys: true为跨账号部署使用独立的 KMS 密钥reuseCrossRegionSupportStacks: true复用跨区域支持栈减少重复资源synth使用ShellStep从 GitHub 连接的指定分支拉取源码依次执行npm ci、npm run buildTypeScript 编译、npx cdk synth完成合成synthCodeBuildDefaults.rolePolicy为合成阶段授予ec2:DescribeAvailabilityZones权限用于获取可用区信息。部署编排部分体现了多环境发布模型const devStage pipeline.addStage(new pipelineAppStage(this, ${props.devEnv}, { env: { account: ${props.pipelineAccountId}, region: ${props.pipelineRegion} } })); devStage.addPost(new ManualApprovalStep(approval)); // 以 Wave 形式并行部署到主、备区域 const devWave pipeline.addWave(${props.devEnv}Wave); devWave.addStage(new pipelineAppStage(this, ${props.devEnv}-${props.primaryRegion}, { env: { account: ${props.devAccountId}, region: ${props.primaryRegion} } })); devWave.addStage(new pipelineAppStage(this, ${props.devEnv}-${props.secondaryRegion}, { env: { account: ${props.devAccountId}, region: ${props.secondaryRegion} } }));可以看到第一阶段devStage部署在流水线账号内并在其后插入ManualApprovalStep人工审批随后通过addWave将同一套应用阶段并行部署到PRIMARY_REGION与SECONDARY_REGION两个区域——这是多区域灾备发布的标准打法。2. 应用阶段编排lib/stage-app.tsstage-app.ts 继承cdk.Stage是流水线每次部署的“应用单元”。它实例化五个 Stack并为每个 Stack 打上统一的资源标签const vpc_stack new vpcStack(this, VpcStack); cdk.Tags.of(vpc_stack).add(managedBy, cdk); cdk.Tags.of(vpc_stack).add(environment, dev);五个 Stack 之间存在依赖关系EcsFargateStack与rdsAuroraStack都以vpc_stack.vpc作为输入参数体现了“网络先行、资源挂靠 VPC”的组织方式。若需要裁剪资源直接注释掉对应 Stack 的实例化代码即可。3. 网络lib/stage-app-vpc-stack.tsstage-app-vpc-stack.ts 创建一个可供其他 Stack 引用的 VPC并开放vpc作为公开只读属性CIDR10.0.0.0/16IpAddresses.cidr可用区maxAzs: 3NAT 网关natGateways: 1控制成本启用 DNS 主机名与 DNS 解析三类子网public/24、private/24PRIVATE_WITH_EGRESS带出口、ioslated/28PRIVATE_ISOLATED完全隔离。这种“公有子网放 ALB、私有子网跑任务、隔离子网留给数据库”的三层网络模型是生产环境的标准布局。4. 数据库lib/stage-app-datastore-stack.tsstage-app-datastore-stack.ts 创建 Aurora Serverless v2 集群并结合 KMS 实现静态加密KMS 密钥enableKeyRotation: true轮换周期Duration.days(180)CDK 默认 365 天此处主动缩短引擎DatabaseClusterEngine.auroraMysql版本VER_3_03_0写入实例ClusterInstance.provisioned(writer)机型R6G.4xlarge内存优化型Serverless v2 容量min 6.5 / max 64ACU弹性伸缩只读副本reader1scaleWithWriter: true随写入实例联动扩缩位于 promotion tier 1与reader2独立扩缩tier 2凭据credentials: { username: clusteradmin }——注意凭据由 Secrets Manager 自动托管不会明文落盘可观测cloudwatchLogsExports: [error]错误日志写入 CloudWatch删除策略RemovalPolicy.DESTROY示例环境可安全销毁生产环境应评估。5. ECS Fargatelib/stage-app-ecs-fargate-stack.tsstage-app-ecs-fargate-stack.ts 负责构建 Docker 镜像并部署容器服务创建 ECSCluster开启containerInsights: true容器级可观测性通过DockerImageAsset将 src 目录打包为镜像资产流水线合成时自动构建、推送到 ECR使用ApplicationLoadBalancedFargateService一行式模式创建“Fargate 服务 应用负载均衡”组合cpu: 256、memoryLimitMiB: 512、desiredCount: 1publicLoadBalancer: true任务跑在PRIVATE_WITH_EGRESS子网enableExecuteCommand: true启用 ECS Exec便于运维进入容器调试自动扩缩autoScaleTaskCount设定minCapacity: 1 / maxCapacity: 6并分别以 CPU 利用率 50%、内存利用率 50% 作为扩缩触发阈值健康检查目标组健康检查路径为/。6. Lambda REST APIlib/stage-app-lambda-api-stack.tsstage-app-lambda-api-stack.ts 演示最小化的“API Gateway Lambda”组合Lambda 运行时可选择NODEJS_24_X使用InlineCode内联一段返回Hello from Lambda!的处理器LambdaRestApi开启proxy: false非代理模式允许显式定义方法与路由随后通过api.root.addMethod(GET)挂载根路径的 GET 方法。该 Stack 是所有 Lambda REST 端点的骨架模板——实际业务中把InlineCode换成Code.fromAsset指向真实函数代码即可。7. 异步事件架构lib/stage-app-async-lambda-stack.tsstage-app-async-lambda-stack.ts 是事件驱动部分的精华一条 EventBridge 规则source: [aws.ecs]即监听所有 ECS 事件同时驱动三条消费链路链路一EventBridge → Lambda规则直接将事件投递给events_handler.handler并通过事件目标参数配置deadLetterQueueDLQ、maxEventAge: 2 分钟、retryAttempts: 2。链路二EventBridge → SNS → Lambda规则将事件转发到 SNSTopic同样带 DLQ、最大事件年龄与重试次数随后topicFunction通过SnsEventSource订阅该 Topic 异步消费。链路三EventBridge → SQS → Lambda规则把事件推入JobQueuequeueFunction通过SqsEventSource消费配置了batchSize: 5、maxBatchingWindow: 5 秒并开启reportBatchItemFailures: true部分批量失败上报配合处理器的batchItemFailures返回结构实现精确重试。三个处理函数共用 assets/lambda-functions 目录作为代码资产包括events_handler.ts接收 EventBridge 事件并打印日志topic_message_handler.ts遍历 SNS 记录并异步处理消息queue_message_handler.ts以SQSBatchResponse返回batchItemFailures实现 SQS 部分失败重试的标准写法。8. 容器内的业务应用src/flask-appsrc 目录存放被 ECS 部署的 Flask 应用基于python:3.12-slim-buster的 Dockerfile 安装依赖并以python3 app.py启动app.py 的首页渲染当前 UTC 时间并读取CUSTOM_ENVVAR、BG_COLOR两个环境变量控制文案与页面背景色index.html 直接以 Jinja2 语法内联这些值——你可以通过 ECS 任务环境变量轻松验证部署是否生效。部署与验证流程该目录带有 package.json依赖aws-cdk-lib与constructs和 cdk.json入口为npx tsc npx tsx lib/app.ts典型操作步骤如下安装依赖并编译npm ci npm run buildbuild脚本执行tsc设置环境变量按上表导出PIPELINE_ACCOUNT_ID、GITHUB_ORG等或直接修改 app.ts 中的默认值在 pipeline-stack.ts 中替换为你自己的connectionArn合成模板检查npx cdk synth部署流水线npx cdk deploy。部署完成后向 GitHub 仓库的监听分支推送代码即可触发整条流水线npm ci → npm run build → cdk synth随后自动进入“开发环境部署 → 人工审批 → 主/备区域 Wave 部署”的发布流程。该示例在仓库中被标记为DO_NOT_AUTOTEST见 DO_NOT_AUTOTEST即它依赖真实的 GitHub 连接与多账号环境不适合在无云资源的 CI 中自动回归测试本地按上述步骤验证即可。小结aws-codepipeline-ecs-lambda示例的价值在于它把“基础设施代码化”与“应用交付自动化”统一到了同一套 CDK 工作流中且六大 Stack 边界清晰、可单独裁剪非常适合初创团队作为从 EC2 单体迁移到云原生架构的起点模板。你可以以此为蓝本将 VPC 子网规划、Aurora Serverless v2 弹性容量、Fargate 自动扩缩、事件消费链路的 DLQ/重试/批处理配置等生产级细节直接复用到自己的业务系统中。赞分享【免费下载链接】aws-cdk-examplesExample projects using the AWS CDK项目地址https://gitcode.com/gh_mirrors/aw/aws-cdk-examples点击查看免费下载相关推荐使用 AWS CDK 构建 CodePipeline 流水线CodeCommit 到 ECS Fargate 的 Docker 镜像构建与蓝绿部署实战使用 AWS CDK 构建 CodePipeline 流水线CodeCommit 到 ECS Fargate 的 Docker 镜像构建与蓝绿部署实战 本篇技使用 AWS CDK 构建 CodePipeline 流水线将 Docker 镜像自动构建并部署到 ECS Fargate使用 AWS CDK 构建 CodePipeline 流水线将 Docker 镜像自动构建并部署到 ECS Fargate 导读 本文基于 aws cdk e使用 AWS CDK Java 构建 ECS Fargate 负载均衡服务fargate-load-balanced-service 实战指南使用 AWS CDK Java 构建 ECS Fargate 负载均衡服务fargate load balanced service 实战指南 本文基于 aw上一篇web3.js 配置指南从全局到包级别的 Web3Config 参数详解与实战下一篇Apollo Client 贡献指南从 Issue 到合并发布的完整参与流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
