简化容器部署 - 使用 AWS App Runner 实现零配置部署
详解使用 AWS App Runner 部署容器化 Web 应用的方法。涵盖与 ECS/Fargate 的选型对比、自动扩缩容、VPC 集成以及 CI/CD 流水线联动的实践内容。
App Runner 的定位与容器部署的挑战
将容器化的 Web 应用部署到 AWS 时，传统做法是使用 ECS (Elastic Container Service) 或 EKS (Elastic Kubernetes Service)。但这些服务需要配置集群管理、任务定义、服务定义、负载均衡器、目标组、安全组等大量资源，要求具备基础设施知识。AWS App Runner 是 2021 年发布的全托管容器应用服务，完全抽象化了这些复杂性。只需指定源代码仓库 (GitHub) 或容器镜像 (ECR)，App Runner 就会自动处理构建、部署、扩缩容、负载均衡和 TLS 终止。开发者可以专注于应用代码，只要有 Dockerfile 就能在无需基础设施知识的情况下部署到生产环境。
部署方式与源配置
App Runner 支持两种源类型。第一种是容器镜像源，指定 ECR（公共或私有）中的镜像。也可配置检测到 ECR 镜像推送后自动部署。第二种是源代码仓库，连接 GitHub 仓库后 App Runner 从构建到部署一体化执行。提供 Python 和 Node.js 的托管运行时，无需 buildspec.yml，只需指定构建命令和启动命令即可运行。 ```yaml # CloudFormation 中的 App Runner 服务定义 Resources: AppRunnerService: Type: AWS::AppRunner::Service Properties: ServiceName: my-web-app SourceConfiguration: AuthenticationConfiguration: AccessRoleArn: !GetAtt AppRunnerAccessRole.Arn AutoDeploymentsEnabled: true ImageRepository: ImageIdentifier: !Sub '${AWS::AccountId}.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest' ImageRepositoryType: ECR ImageConfiguration: Port: '8080' RuntimeEnvironmentVariables: - Name: NODE_ENV Value: production InstanceConfiguration: Cpu: '1024' Memory: '2048' ``` 实例配置可组合选择 vCPU (0.25 / 0.5 / 1 / 2 / 4) 和内存 (0.5 至 12 GB)。无需像 ECS Fargate 那样分别配置任务定义、服务定义、ALB、监听器和目标组，一个资源定义即可完成部署。
GitHub 集成与源代码部署实践
源代码部署方式连接 GitHub 仓库后，App Runner 自动从代码构建容器镜像并完成部署。支持的托管运行时包括 Python、Node.js、Java、Go 和 .NET，选择这些运行时后无需编写 Dockerfile 即可完成部署。在仓库根目录放置 apprunner.yaml 文件，可以声明式定义构建命令、启动命令、运行时版本和环境变量，实现基础设施配置与代码的统一版本管理。GitHub 集成提供自动部署和手动部署两种模式。启用自动部署后，向指定分支 push 代码时会自动触发构建和部署，无需另外搭建 CI/CD 流水线。选择手动部署时，通过控制台或 API 显式触发部署。自动构建费用约为每分钟 0.005 美元，push 频繁的仓库需注意构建费用的累积。
自定义域名与可观测性
自定义域名的配置只需在控制台输入域名，然后在 DNS 提供商 (Route 53 或外部 DNS) 中添加 CNAME 记录即可完成。ACM (AWS Certificate Manager) 证书会自动签发和续期，配置的自定义域名即可通过 HTTPS 访问。使用 VPC 连接器时会创建 ENI (弹性网络接口)，因此指定的子网需要有充足的 IP 地址空间。在可观测性方面，启用 X-Ray 追踪可以可视化请求延迟和错误的分布式追踪。访问日志和应用日志会自动发送到 CloudWatch，HTTP 2xx/4xx/5xx 计数和响应时间作为指标被记录。健康检查可通过 HTTP 路径或 TCP 配置，异常实例会被自动替换。
自动扩缩容与成本结构
App Runner 标准提供基于请求数的自动扩缩容。在 Auto Scaling Configuration 中可设置并发请求数阈值（默认 100）、最小实例数（1 至 25）和最大实例数（最大 25）。流量减少时自动缩减实例，直至最小实例数。使用暂停 (Pause) 功能可将实例降为零，仅收取内存费用。定价为 vCPU 每小时 0.064 美元、内存每 GB 每小时 0.007 美元。活跃实例收取 vCPU + 内存费用，预置（待机）实例仅收取内存费用。例如 1 vCPU / 2 GB 内存配置运行 730 小时/月，约 56.9 美元/月。ECS Fargate 同等配置（1 vCPU / 2 GB）约 44.3 美元/月，但 App Runner 无需 ALB（约 22.3 美元/月起），因此小规模服务中 App Runner 的总成本可能更有优势。
VPC 集成与安全
App Runner 默认提供公共端点，但通过 VPC 连接器可访问私有子网中的资源（RDS、ElastiCache、DynamoDB VPC 端点等）。VPC 连接器通过指定子网和安全组创建，并关联到 App Runner 服务。仅出站通信经过 VPC，入站仍通过 App Runner 的托管端点接收。通过与 WAF (Web Application Firewall) 集成，可将 WAF WebACL 关联到 App Runner 端点，应用 IP 限制和速率限制等安全规则。与 Secrets Manager 和 Systems Manager Parameter Store 集成后，可安全管理数据库凭证和 API 密钥，并作为环境变量注入。IAM 访问控制、CloudWatch 指标监控（请求数、延迟、HTTP 状态码）、应用日志输出到 CloudWatch Logs 也是标准功能。 如需拓展容器技术知识，也可参考Amazon 上的专业书籍。
与 ECS/Fargate 的选型对比
App Runner 和 ECS/Fargate 都运行容器工作负载，但目标用例不同。App Runner 专注于 HTTP/HTTPS 的 Web 应用和 API，请求驱动的扩缩容是标准功能。而 ECS/Fargate 支持批处理、Worker 进程、gRPC、WebSocket、Sidecar 模式等广泛的工作负载。 选型判断标准如下。应选择 App Runner 的场景：希望快速部署 HTTP/HTTPS Web 应用或 API、希望最小化基础设施管理、团队缺乏容器编排专业知识。应选择 ECS/Fargate 的场景：需要 Sidecar 容器或服务网格、使用 TCP/UDP 协议、需要精细控制任务放置策略和容量提供者、批处理或队列 Worker 等非 HTTP 工作负载。EKS 适用于需要 Kubernetes 生态兼容性或多云策略中重视工作负载可移植性的场景。App Runner 是构建在 ECS/Fargate 之上的更高抽象层，是控制灵活性与简洁性之间的权衡。Elastic Beanstalk 也提供简化部署，但底层的 EC2 和 ALB 资源是可见且可管理的，定制化空间更大，但管理对象也相应增多。如果希望跳过 Dockerfile、CI/CD 搭建以及 VPC/ALB 配置，App Runner 是最佳选择。
总结 - App Runner 使用指南
AWS App Runner 是一项以最少配置部署和运维容器化 Web 应用的服务。只需指定源代码或容器镜像，构建、部署、TLS、负载均衡和 Auto Scaling 即自动配置。VPC 连接器访问私有资源、WAF 集成增强安全、Secrets Manager 联动管理凭证等生产运维所需功能一应俱全。与 ECS/Fargate 相比控制灵活性较低，但无需配置 ALB 和目标组，对于中小规模 Web 应用在总成本和运维负担两方面都更有优势。作为容器部署的第一步或原型快速发布的手段，App Runner 是有力的选择。