AWS云形成应该排除什么

AWS云形成应该排除什么

我们目前有一个 Web UI 配置的基础设施,由于其复杂性不断增加,我想将其迁移到云中。我们使用带有多个 Docker 容器、RDS、负载均衡器、SNS 等的 ECS。

我希望得到一些建议,告诉大家应该在哪里划出云层形成的界线(或者在哪里找到信息),哪些云层不应该形成。特别是在

  • IAM 规则适用于开发人员权限,但不包括从云形成中部署堆栈所需的权限
  • RDS 数据库——您是否面临破坏生产数据库并在没有数据的情况下重新部署的风险
  • 附加到网络负载均衡器的弹性 IP 地址

提前致谢

答案1

我通常遵循以下几条(任意)规则:

  1. 将您的模板拆分为更小的块并将可能经常发生变化的事物(ECS 任务)与几乎从不发生变化的事物(VPC、子网)或很少发生变化的事物(RDS)分开部署。

  2. 使用CloudFormation 导出/导入值在堆栈之间传递变量。这有助于减少每个模板所需的参数数量。

  3. 保持安全组和 IAM 角色 靠近资源需要它们。有些人倾向于在一个模板中创建所有 SG,然后在另一个模板中将它们用作资源。不要这样做,ALB SG 应该在 ALB CFN 模板中定义。

  4. 通过 CI/CD 更新 CFN 堆栈部署任何新的资源变化。

    例如,当您构建 ECS 容器的新版本时,CI/CD 会将其推送到 ECR,然后调用 CloudFormation 来更新堆栈以指向新的 ECR 映像 ID。这将有助于保持漂移在您的模板中最小化。

    与 Lambda 类似 - 你可以使用CloudFormation 打包/部署从 CI/CD 部署新版本。

  5. 你也可以使用 Ansible 部署 CloudFormation 模板,它非常智能,因为它不会尝试更新模板或参数自上次运行以来没有发生变化的堆栈。

本质上一切都应该通过 CloudFormation 完成。事实上,在某些账户中,我们不允许通过控制台进行任何手动更改,只允许通过 CloudFormation 进行部署。一种可能的方法是使用CFN 服务角色

希望有帮助:)

相关内容