AWS Cloudformation模板存储

Question

我们目前有许多资源部署到AWS dev和prod帐户。 这些包括lambda函数，kinesis流，dynamo db表和RDS实例。 其中一些资源使用我们的ci工具和cloudformation进行部署，有些是手动完成的。 出于多种原因，我们希望在cloudformation中定义所有内容。 大多数资源都是较大系统或堆栈的一部分。 即连接到lambda函数的api网关，该函数可能消耗由另一个lambda函数填充的kinesis流。 问题是，在这种情况下，云形态模板应该存在于何处？ 在第一个lambda的回购？ 第二个lambda？ 中央云信息仓库或其他地方？

Answer 1

将模板存储在任何源代码控制中是一个很好的开始，可以获得集中和版本化代码的好处。

但是 ，如果您主要在AWS云中投资自动化，则应考虑在AWS CodeCommit git服务中存储模板（和其他代码）。

这样做的主要原因和好处是：

• 与其他AWS服务紧密集成的选项
• rep事件上的事件触发器，例如发送SNS通知或触发Lambda操作的pull请求和提交。
• 能够使用IAM策略和角色与开发人员以及其他服务和应用程序共享repo访问权限。

CodeCommit提供了一种非常精细且安全的方式来分离谁可以做什么，以及哪些应用程序可以访问repo，因此您可以分割生产和登台环境。

Answer 2

我见过的最佳实践是将您的模板开发/提交到源代码存储库（通常是Git），然后利用CI工具（如Jenkins，Travis CI，Bamboo等）将这些工具复制到您的帐户所拥有的S3存储桶中读取权限（NOT PUBLIC）。 引用其S3网址中的所有模板，并使用CI工具使这些网址保持最新。

例如， master分支最终到http://bucket-name-here.s3.amazonaws.com/project-name/template.json并develop分支结束于http://bucket-name-here.s3.amazonaws.com/project-name/template-develop.json 。 您可以扩展功能/发布分支​​以遵循http://bucket-name-here.s3.amazonaws.com/project-name/template-release-v1.0.json或类似内容。

当您在其他资源中引用这些内容时，您将始终违反所需的任何代码级别（引用template.json作为生产级代码）。

Answer 3

我们在GitLab中拥有大量Jenkins CI / CD环境的所有源代码。 并考虑添加管道步骤以触发AWS CodeCommit + CodePipeline从专用GitLab repos拉出以亚马逊专用方式执行CloudFormation模板，并带来所有好处。