又一个 E2E 解决方案已交付。本次使用 CI/CD、AWS EventBridge 和 ECS Fargate

Source: Dev.to

解决方案概述

为了给今年画上句号，我构建了最新的端到端（E2E）项目。它是一个副项目，但能帮助我们在工作中解决问题。我们有一个服务从第三方系统上传文档。该集成需要身份验证，且系统强制每月更换密码。当密码过期时，上传和下载会失败，迅速演变为运维问题。

为消除手动更新以及忘记更换密码的风险，我创建了一个自动化流程来处理整个过程。

该解决方案是一个使用 Selenium 与无头 Chromium 的 Python 工作器。它按计划运行，并由完整的 CI/CD 流水线支撑。每次向 main 分支推送代码时，GitHub Actions 通过 OIDC（无访问密钥）假设一个 AWS IAM 角色，构建 Docker 镜像并推送到 Amazon ECR。随后工作流注册一个新的 ECS 任务定义修订，仅更新容器镜像。

架构设计

CI/CD

• GitHub Actions：在推送到 main 时触发。
• OIDC 认证：在不使用静态凭证的情况下假设 AWS IAM 角色。
• Docker 构建与推送：镜像被构建并存储在 Amazon ECR。
• 任务定义更新：使用更新后的镜像注册新的 ECS 任务定义修订。

执行（EventBridge）

• Amazon EventBridge 每 29 天触发一次任务。
• 该调度确保密码在月度过期前完成轮换。

ECS 集群

• 任务在 ECS Fargate 的公共子网中运行，拥有公共 IP 并允许出站流量。
• 触发后，Fargate 启动容器，运行 automation.py，启动 Selenium 与 Chromium 和 Chromedriver，登录系统，执行密码轮换，然后退出。
• 成功时，任务自动以退出码 0 结束。
• 若出现异常，日志会发送至 CloudWatch，错误会报告到 Slack 警报频道。

架构决策

选择 ECS Fargate 而非 AWS Lambda 是有意为之。 在 Lambda 上运行 Selenium 与 Chromium 通常需要自定义层并进行细致调优，且容易受到内存、包大小或执行时间限制的影响。 使用 Fargate，整个环境都打包在 Docker 镜像中，提供可预测的运行时行为和灵活的 CPU/内存分配，使此类工作负载的运维更加简便。

最终，这只是一个简单的批处理工作器：按计划运行，执行单个任务，然后退出。 对于无头浏览器自动化，这种方式被证明更直接、更可靠。