# 手动scp扛不住了：小团队用AWS三件套把Flask部署自动化跑通

- 发布日期: 2024-01-28 · 分类: DevOps

前阵子我手上有个 Flask 项目要上生产，团队就五六个人，但发布频率不低，手动 scp 加重启已经扛不住了。我花了一周时间在 AWS 上把 CodePipeline、CodeBuild、CodeDeploy 三件套串起来，中间踩了几个坑，但跑通之后确实省心。这里把整个搭建思路和我实际的做法记下来，供你参考。

## 三个服务各自干什么

先说清楚分工，免得后面看流程时混淆。

- **CodePipeline**：全托管的持续交付编排器。你定义好"源码 → 构建 → 测试 → 部署"这条链路，它负责按顺序驱动每一步。除了原生 AWS 服务，它也接 GitHub、Bitbucket 这些第三方代码源。
- **CodeBuild**：全托管的持续集成。你给它一个构建脚本，它帮你拉代码、跑编译、跑测试、产出 artifact。不用自己维护构建机。
- **CodeDeploy**：自动化部署执行器。它把上一步产出的软件包推到你指定的目标上——Amazon EC2、AWS Fargate、AWS Lambda 都支持。

## 我实际怎么串起来的

我的流水线分四个阶段，对应关系很简单：

- 源码阶段：从代码仓库拉取变更，触发流水线。
- 构建阶段：交给 CodeBuild。我配置了一个 CodeBuild 项目，buildspec 里写好了 `pip install -r requirements.txt` 加上 pytest 那套。CodeBuild 自动拉源码、执行脚本、把产物打成 tar 包。
- 测试阶段：和构建合在同一个 CodeBuild 项目里跑，没单独拆。
- 部署阶段：CodePipeline 检测到构建产物就绪后，自动触发 CodeDeploy，把包推到目标 EC2 实例上。

## 审批环节：我为什么加、怎么加

纯自动化听起来很爽，但生产环境我始终觉得"人看一眼"不能省。所以在构建和部署之间我插了一个审批动作：

- 在 CodePipeline 里加一个 Approval 类型的 action，指向一个 SNS topic。
- 每次流水线走到这一步，指定的审批者会收到 Amazon SNS 的通知邮件，里面有变更摘要和流水线详情链接。
- 审批者点"批准"，流水线继续往下走，CodeDeploy 开始部署；点"拒绝"，流水线直接停住，等团队排查或回滚代码。

## 跑通之后的感受

![walking](https://aicyber.de5.net/sites/blog-252d6582/shared/images/screenshot-20240128-devops-aws-codepipeline-example.webp)

整套东西跑稳之后，从 git push 到生产环境更新，中间不需要人手动介入（除了审批那一下）。交付周期确实缩短了，而且因为每次构建都走同一套脚本，环境漂移的问题基本消失。AWS 这套 DevOps 工具链给我的感觉是：单看每个服务都"够用"，但编排起来之后才真正形成闭环，敏捷性和可控性同时在线。

## References

- 统一DevOps流程：供应商协作的关键
- 实现 GitLab 与 AWS CodeCommit 的流畅集成
- 探索DevOps之旅：自动化运维、治理与运营的协调融合