【免费下载链接】aws-cdk-examplesExample projects using the AWS CDK项目地址https://gitcode.com/gh_mirrors/aw/aws-cdk-examples点击查看免费下载本文以 aws-cdk-examples 仓库中的typescript/cdkpipeline-ecs示例为主线剖析如何用少量 CDK 代码将「GitHub 源码拉取 → TypeScript 编译 → CloudFormation 合成 → 多区域 ECS Fargate 应用部署」整合为一条自愈式self-mutatingCI/CD 流水线。读完本文你将掌握 CDK Pipelines 的核心构造CodePipeline、ShellStep、Wave/Stage与ApplicationLoadBalancedFargateService的落地用法并可直接照搬到自己的项目中。一、示例定位先搭好流水线再谈应用本身cdkpipeline-ecs的核心思路在 README 中表达得很明确本示例重点展示的是「构建一条开箱即用的流水线所需的最少代码量」而不是 ECS Fargate 服务本身的复杂度因此容器应用刻意保持为 hello world 级别的 Flask 服务。具体来说该示例用 CDK Pipelines 这个「有主见opinionated」的构造库完成两件事部署一个ApplicationLoadBalancedFargateService应用负载均衡器 Fargate 任务在流水线中自动构建应用容器镜像ContainerImage.fromAsset从本地app/目录构建 Docker 镜像。整个示例的源码都放在仓库中包括流水线定义、基础设施定义、应用代码与 Dockerfile你可以一次性看到从「代码提交」到「多区域服务上线」的完整链路。二、仓库结构与各文件职责示例位于 typescript/cdkpipeline-ecs目录结构如下cdkpipeline-ecs/ ├── bin/cdkpipe.ts # CDK 应用入口实例化 PipelineStack ├── lib/ │ ├── pipeline-stack.ts # 流水线栈CodePipeline Synth Wave/Stage │ ├── infra-stack.ts # VPC 栈VpcStack │ └── ecs-stack.ts # ECS 栈ECSStackFargate 服务 ├── app/ │ ├── Dockerfile # 应用容器镜像定义 │ ├── app.py # Flask hello-world 应用 │ └── requirements.txt # Python 依赖flask ├── assets/cdk-pipeline-ecs.jpg # 架构图 ├── cdk.json # CDK 应用配置入口命令、上下文特性开关 ├── package.json # npm 脚本与依赖版本 ├── tsconfig.json # TypeScript 编译配置 └── DO_NOT_AUTOTEST # 仓库标记本示例需真实云资源不参与 CI 自动测试三个 Stack 的分层关系一目了然PipelineStack负责编排流水线流水线通过Stage打包VpcStackECSStack并发布到多个区域。仓库根目录下的DO_NOT_AUTOTEST文件说明该示例依赖真实的 AWS 账号、GitHub Connection 等资源因此被排除在仓库的自动化测试之外——这也提示读者运行本示例前必须先完成前置条件。三、前置条件创建 GitHub Connection在 AWS 账号中创建到 GitHub 的Connection在 AWS Developer Tools 控制台的 Settings → Connections 中创建并将连接 ARN 提供给流水线的connectionArn属性。该 Connection 用于拉取源码。随后在 lib/pipeline-stack.ts 中替换三处信息connectionArn上面创建的 Connection ARNorg/reponame你的 GitHub 组织/仓库名branchname要监听的分支名如main。如果你不想使用 GitHub Connection也可以改用 CodeCommit 作为源码源CodePipelineSource提供了一系列可选源对应 CDK 中aws-cdk-lib/pipelines.CodePipelineSource的多种构造可根据团队实际托管平台选择。四、流水线定义详解pipeline-stack.tspipeline-stack.ts 是整个示例的灵魂仅有三十余行代码却完整定义了源、合成、自愈、多区域部署四件事。核心代码如下import * as cdk from aws-cdk-lib; import { Construct } from constructs; import * as pipelines from aws-cdk-lib/pipelines; import { ECSStack } from ./ecs-stack; import { VpcStack } from ./infra-stack; export class PipelineStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); const pipeline new pipelines.CodePipeline(this, Pipeline, { synth: new pipelines.ShellStep(Synth, { input: pipelines.CodePipelineSource.connection(org/reponame, branchname, { connectionArn: arn:aws:codestar-connections:us-east-1:123456789012:connection/abcdefg, }), commands: [ npm ci, npm run build, npx cdk synth, ], }), selfMutation: true, }); const wave pipeline.addWave(DeployWave); wave.addStage(new AppStacks(this, AppsUS, { env: { account: props?.env?.account, region: us-east-1 } })); wave.addStage(new AppStacks(this, AppsEU, { env: { account: props?.env?.account, region: eu-west-1 } })); } } export class AppStacks extends cdk.Stage { constructor(scope: Construct, id: string, props?: cdk.StageProps) { super(scope, id, props); const vpcStack new VpcStack(this, VPCStack, { env: props?.env }) const ecsStack new ECSStack(this, ECSStack, { env: props?.env, vpc: vpcStack.vpc }); } }4.1 合成步骤ShellStepShellStep是流水线的「合成synth」步骤它指定了流水线的输入源码与合成命令commands: [ npm ci, npm run build, npx cdk synth, ],npm ci按package-lock.json做干净的依赖安装保证环境一致性npm run build执行 TypeScript 编译对应 package.json 中的build: tsc把lib/下的.ts编译为.jsnpx cdk synth合成 CloudFormation 模板产物供后续部署阶段使用。合成步骤产出的cdk.out目录会被 CDK Pipelines 自动解析流水线会读取其中包含的所有 Stack 与 Stage把它们转换为 CodePipeline 中实际的部署动作。4.2 源码源CodePipelineSource.connectioninput: pipelines.CodePipelineSource.connection(org/reponame, branchname, { connectionArn: arn:aws:codestar-connections:us-east-1:123456789012:connection/abcdefg, }),CodePipelineSource.connection基于 AWS CodeStar Connections 服务支持 GitHub、GitLab、Bitbucket 等第三方代码托管平台。流水线每次运行都会从指定仓库的指定分支拉取最新代码。示例中的123456789012与abcdefg均为占位符必须替换为你自己的账号与连接 ID。4.3 selfMutation流水线自愈selfMutation: true,这是 CDK Pipelines 的标志性能力流水线本身也是一个 CDK 应用。开启selfMutation后每次部署前CDK 会先检查流水线定义本身是否发生变化若有变化则先自动更新流水线再继续执行后续部署。这意味着你只需要把更新后的流水线代码推送到源码仓库流水线下次运行就会自己「升级」自己无需手工重建。4.4 Wave Stage一次提交多区域并行部署const wave pipeline.addWave(DeployWave); wave.addStage(new AppStacks(this, AppsUS, { env: { ..., region: us-east-1 } })); wave.addStage(new AppStacks(this, AppsEU, { env: { ..., region: eu-west-1 } }));StageAppStacks继承自cdk.Stage代表一组在独立环境中部署的 Stack 集合。本例中AppStacks内部按顺序创建了VpcStack与ECSStack并把 VPC 对象显式传给 ECS 栈vpc: vpcStack.vpc体现跨栈引用WaveDeployWave把多个 Stage 打包成「一波」并行部署。这里AppsUSus-east-1与AppsEUeu-west-1处于同一 Wave 中因此两个区域会并行部署若把多个 Stage 依次addStage不放入 Wave则会串行执行。注意env.account继承自props?.env?.account当 bin/cdkpipe.ts 未显式指定 env 时CDK 会回退到当前 CLI 的默认账号CDK_DEFAULT_ACCOUNT区域则由每个 Stage 各自固定为us-east-1与eu-west-1。这种写法让你只需一次推送就能把同一套应用发布到两个区域。五、基础设施层infra-stack.ts 中的 VPCinfra-stack.ts 极其精简只负责创建 VPCexport class VpcStack extends cdk.Stack { public readonly vpc: ec2.Vpc; constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); this.vpc new ec2.Vpc(this, Vpc, { natGateways: 1, }); } }通过public readonly vpc对外暴露 VPC 对象供ECSStack以构造对象方式引用而非字符串引用这是 CDK 推荐的跨栈资源传递方式natGateways: 1只创建一个 NAT 网关。CDK 默认每个可用区一个 NAT 网关这里显式收窄为 1用于控制成本——本示例以演示流水线为目的无需高可用级别的网络出口。六、应用服务层ecs-stack.ts 中的 Fargate 服务ecs-stack.ts 通过aws-ecs-patterns的高层模式快速落地服务const cluster new ecs.Cluster(this, Cluster, { vpc: props?.vpc }); const loadBalancedFargateService new ecsPatterns.ApplicationLoadBalancedFargateService(this, Service, { cluster, memoryLimitMiB: 512, desiredCount: 1, cpu: 256, taskImageOptions: { image: ecs.ContainerImage.fromAsset(app, {}), }, }); loadBalancedFargateService.targetGroup.configureHealthCheck({ path: /health, });各参数含义与取值说明参数示例值说明memoryLimitMiB512每个 Fargate 任务的内存上限MiB此处为 0.5 GiBdesiredCount1期望运行的任务副本数示例取最小值 1 以节省资源cpu256每个任务的 CPU 配额256 即 0.25 vCPUFargate 最小规格taskImageOptions.imageecs.ContainerImage.fromAsset(app, {})从本地app/目录构建容器镜像并推送到 ECR路径相对项目根目录即cdk.json所在目录ApplicationLoadBalancedFargateService这个模式会自动创建ECS 集群、任务定义、应用负载均衡器ALB、目标组、安全组、以及必要的 IAM 角色——一条语句即可获得完整的负载均衡 Fargate 服务。最后一行configureHealthCheck({ path: /health })把 ALB 目标组健康检查路径指向/health与 app/app.py 中定义的健康检查路由一一对应。七、容器应用app/ 目录流水线在部署阶段会使用ContainerImage.fromAsset(app)构建镜像因此app/目录必须包含完整的容器化应用。Dockerfile 采用 Python 基础镜像FROM python:3 WORKDIR / COPY requirements.txt . RUN pip3 install --no-cache-dir -r requirements.txt COPY . . CMD [ python3, ./app.py ] EXPOSE 80app.py 是极简 Flask 服务提供两个路由app.route(/, methods[GET]) def default_get(): return json.dumps({message: Hello from ECS container}) app.route(/health, methods[GET]) def health_check(): return json.dumps({message: Health Check pass})/业务路由返回Hello from ECS container/health健康检查路由返回Health Check pass与上一节configureHealthCheck的路径匹配。依赖仅一个flask见 app/requirements.txt。整个应用刻意保持最小正如 README 所述本示例的价值在流水线而非业务代码读者可随时替换为自己的应用。八、部署前必改的四处配置在运行示例前结合 pipeline-stack.ts 与 bin/cdkpipe.ts 的源码你需要修改四处connectionArn替换为你在 AWS 中创建的 GitHub Connection ARNorg/reponame替换为你的 GitHub 组织/仓库branchname替换为要监听的分支env可选bin/cdkpipe.ts中默认不指定 env部署目标为 CLI 默认账号/区域如需固定目标可取消env: { account: 123456789012, region: us-east-1 }一行的注释并填入真实值。其中第 13 项是必须项第 4 项按需配置。修改完成后把代码推送到上述仓库分支流水线即会自动触发。九、常用命令与本地验证README 列出了该示例的常用命令结合 package.json 与 cdk.json 的实际配置说明如下命令作用npm run build用tsc将 TypeScript 编译为 JavaScriptnpm run watchtsc -w监听文件变化并自动编译npm run testREADME 声明为执行 jest 单元测试需要说明的是当前仓库的package.json未定义test脚本devDependencies中虽已引入jest、types/jest、swc/jest但示例并未随附测试用例文件使用时需自行补充测试脚本与用例npx cdk deploy将栈部署到默认 AWS 账号/区域首次部署会同时创建 CodePipeline 及相关资源npx cdk diff对比已部署栈与当前代码状态的差异npx cdk synth合成 CloudFormation 模板输出到cdk.outcdk.json中的app: npx tsc npx tsx bin/cdkpipe.ts说明每次执行cdk命令时CDK 都会先编译 TypeScript再用tsx运行入口文件 bin/cdkpipe.ts 来实例化PipelineStack随后由npx cdk synth完成模板合成。本地验证建议按「先 synth、再 diff、最后 deploy」的顺序进行先用npm run build确认编译无误再用npx cdk synth检查生成的 CloudFormation 模板是否符合预期确认无误后执行npx cdk deploy。十、部署流程推演与注意事项结合源码结构可以推演出该示例的完整运行链路开发者把修改推送到 GitHub 指定分支CodePipeline 通过 Connection 拉取源码执行npm ci→npm run build→npx cdk synth由于开启了selfMutation若流水线定义有更新则先自动重部署流水线本身流水线解析合成产物中的DeployWave将AppStacks含VpcStackECSStack并行发布到us-east-1与eu-west-1两个区域每个区域的部署先创建 VPC再创建 ECS 集群与 ALB 负载均衡的 Fargate 服务并从app/目录构建镜像推送到该区域 ECR 后启动任务ALB 目标组按/health路径执行健康检查检查通过后流量接入。需要注意的几点运行前提本示例需要真实 AWS 账号、GitHub Connection 以及可访问的网络环境仓库用DO_NOT_AUTOTEST标记排除了它的自动化测试依赖版本示例当前使用的依赖版本以仓库 package.json 为准aws-cdk-lib为 2.x、aws-cdkCLI 为 2.xCDK 的特性开关集中在 cdk.json 的context中升级 CDK 版本时建议保留这些特性开关以维持行为一致成本提示示例通过natGateways: 1、desiredCount: 1、cpu: 256等参数刻意压低资源用量但它会创建跨两个区域的完整流水线与 ECS 服务实际运行时会产生相应云资源费用验证完毕应及时清理栈。十一、小结cdkpipeline-ecs用不到 40 行流水线代码演示了 CDK Pipelines 的完整价值ShellStep定义合成、CodePipelineSource.connection接入第三方源码、selfMutation实现流水线自愈、WaveStage完成多区域并行发布。配合ApplicationLoadBalancedFargateService的「一条语句落地负载均衡 Fargate 服务」能力开发者从「写好代码」到「多区域上线」之间只需维护一份随代码仓库演进的 CDK 定义——这正是 AWS CDK 将基础设施代码化、把部署流程也纳入版本管理的核心实践。赞分享【免费下载链接】aws-cdk-examplesExample projects using the AWS CDK项目地址https://gitcode.com/gh_mirrors/aw/aws-cdk-examples点击查看免费下载相关推荐使用 AWS CDK 构建 CodePipeline 流水线将 Docker 镜像自动构建并部署到 ECS Fargate使用 AWS CDK 构建 CodePipeline 流水线将 Docker 镜像自动构建并部署到 ECS Fargate 导读 本文基于 aws cdk e使用 AWS CDK 构建 CodePipeline 流水线CodeCommit 到 ECS Fargate 的 Docker 镜像构建与蓝绿部署实战使用 AWS CDK 构建 CodePipeline 流水线CodeCommit 到 ECS Fargate 的 Docker 镜像构建与蓝绿部署实战 本篇技Triplex架构深度解析理解可视化React Three Fiber编辑器原理Triplex架构深度解析理解可视化React Three Fiber编辑器原理 Triplex是一个革命性的开源可视化工作空间专门为React Three上一篇5个高效场景Mermaid Live Editor如何改变技术图表创作方式下一篇Mermaid Live Editor零基础小白也能轻松上手的在线图表制作神器 创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考