企业官网建设流程全解析

AWS CDK Python 项目搭建完整实战：从空目录到 cdk deploy 的最快路径

【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot

本文以 awesome-copilot 仓库中的 AWS CDK 技能为参照，带你用最短路搭建一个 AWS CDK Python 项目：用 Python 代码定义基础设施，由 CloudFormation 完成真实部署。读完即可独立完成环境自检、cdk init、cdk synth到cdk deploy的全流程。

一、环境自检：四个工具一次过

CDK 的链路横跨两个运行时：CLI 跑在 Node.js 上，应用代码跑在 Python 上，再叠加 AWS 凭据与版本控制。开写之前先逐项验证，比部署中途报错再回头排查要快得多。

凭据验证失败是最常见的拦路虎：aws sts get-caller-identity是仓库内多个 AWS 技能（如 skills/aws-resource-query/SKILL.md）统一采用的身份确认入口，它通过就意味着后续cdk命令的云端调用有合法身份。

二、最短路径：5 条命令跑通项目骨架 🚀

在空目录中依次执行：

mkdir my-cdk-project && cd my-cdk-project # 建空目录并进入 cdk init app --language python # 生成 Python 应用骨架与 .venv 虚拟环境 source .venv/bin/activate # 激活虚拟环境（Windows 用 .venv\Scripts\activate） pip install -r requirements.txt # 安装 aws-cdk-lib 与 constructs cdk synth # 验证：向 cdk.out/ 输出 CloudFormation 模板

最后一条命令若打印合成成功信息并生成cdk.out/目录，说明骨架已可运行。只想跑通的读者看到这里即可，下面两节解释每条命令背后的机制。

三、每步为何必要：init、venv 与依赖的分工

cdk init到底做了什么。它按 Python 语言模板生成一套约定俗成的工程结构，并预建虚拟环境。核心产物如下：

aws-cdk-lib 与 constructs 的分工。CDK 应用的本质是一棵 Construct 树：constructs包提供树的基类（IConstruct），aws-cdk-lib则基于它实现全部 AWS 服务的构造类（aws_s3、aws_lambda、aws_ec2……）。你在 Stack 里add_的每个资源都是树上的一个节点，cdk synth的工作就是遍历这棵树，把节点翻译为 CloudFormation 模板。

虚拟环境为何不能省。直接装到全局 Python 会让aws-cdk-lib的版本随项目漂移，团队和 CI 之间不可复现。激活后提示符出现(.venv)前缀，后续所有cdk/pip命令都在隔离环境中执行。

cdk.json的双重身份。它不仅是配置，还是自动化工具识别"这是不是 CDK 工程"的标记。仓库里的 skills/aws-cost-optimize/SKILL.md 会扫描**/cdk.json来发现 IaC 资产，skills/aws-well-architected-review/SKILL.md 则结合cdk.json与lib/**/*.ts定位 CDK 资产。保留模板默认布局（app.py+ 同名包 +cdk.json），这些扫描才能命中。完整技能说明见 skills/aws-cdk-python-setup/SKILL.md。

四、部署前校验闭环：synth → diff → bootstrap → deploy

• cdk synth：纯本地操作，不触碰任何云端资源。用它提前暴露语法错误与非法资源属性，成本几乎为零，所以应养成"改完就 synth"的习惯。
• cdk diff：把变更摊开在生效之前。它能抓住最危险的场景——一次重构意外删掉了带数据的资源。
• cdk bootstrap：当 Stack 含 Lambda 代码包、自定义资源等需上传的资产时，CDK 需要目标区域中一个专用的资产存储桶与配套角色，bootstrap 负责创建它们。同一账号 + 区域组合只需执行一次，换区域才需再来一遍。
• cdk deploy：提交模板前会先打印变更摘要并等待确认。目标账号与区域取自aws configure的默认值，可用--profile、--context收窄范围。

⚠️--require-approval never会跳过部署确认，只建议用于 CI 等自动化场景；首次部署一律在开发账号 / 非生产区域验证，不要直接打生产。

五、部署自检清单 ✅

按下 deploy 之前，过一遍这份清单：

• □ 虚拟环境已激活，提示符带(.venv)前缀
• □cdk synth无报错，cdk.out/模板已生成
• □cdk diff已运行，资源增减列表与预期完全一致
• □ 目标账号 + 区域已执行过cdk bootstrap
• □ 首次验证发生在开发账号 / 区域，而非生产
• □requirements.txt用==精确锁定aws-cdk-lib与constructs版本
• □ 代码已提交 Git，且cdk.out/与.venv/在.gitignore中
• □ Stack 代码里没有硬编码密钥；敏感值走 Secrets Manager 或 SSM

六、常见报错速查 🔍

排查无果时，cdk doctor是环境诊断首选：它一次性收集 Node / Python 版本、CDK CLI 版本、AWS 凭据与配置并输出诊断结论，比逐条猜版本要高效。

七、生态联动：让仓库里的 AWS 技能接管 CDK 之后

搭好工程只是起点。plugins/aws-cloud-development/plugin.json 声明的 AWS 技能集群（关键词覆盖cdk、cloudformation、serverless、devops）正好接住部署后的环节：

• 资源核对：skills/aws-resource-query/SKILL.md 以自然语言查询 EC2、S3、Lambda 等已部署资源，严格只读，适合 deploy 之后核对云端真实状态是否与模板一致。
• 成本治理：skills/aws-cost-optimize/SKILL.md 扫描仓库 IaC（含cdk.json）叠加云端资源，产出优化建议并转成 Issue 跟踪。
• 架构审查：skills/aws-well-architected-review/SKILL.md 按 Well-Architected 六大支柱逐条检查，其 CDK 资产识别依赖cdk.json与lib/**/*.ts——这正解释了第三节中"保持模板默认结构"的价值：布局不规范，扫描就落空。
• 架构咨询：agents/aws-principal-architect.agent.md 作为专家 Agent，在设计阶段给出 CDK 方案与取舍分析，其准则坚持"一切资源皆 IaC"，手动控制台操作会被标记为技术债。

部署后的运行态问题（CloudWatch 日志与指标层面的诊断）还可以参考 skills/aws-resource-health-diagnose/SKILL.md。

八、附录 · 命令速查表

安装

初始化

日常

部署

排错

九、小结

AWS CDK 把基础设施变成可合成、可 diff、可回滚的 Python 代码，synth管正确性，diff管安全性，deploy管落地。技能原文与更多细节在 skills/aws-cdk-python-setup/SKILL.md。下一步：挑一个开发账号跑通cdk deploy，再用资源查询技能核对云端资源，把闭环真正走一遍。

【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot