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服务的紧密集成选项
• 触发repo操作上的事件，例如发送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模板，并带来所有好处。