我是CloudFormation的菜鸟。但是,在阅读有关CloudFormation的文档时,Amazon似乎认为这是我们用于一致,重复地部署给定AWS服务实例拓扑的方法。但是,AWS已经存在了十多年,而AWS对CF的推动似乎只是在最近五年之内。
我偶然发现了一篇很棒的文章AWS OpsWorks vs AWS Beanstalk vs AWS CloudFormation?,探讨了各种AWS部署产品的优势。考虑到我组织对灵活且可重复的IaaS / PaaS部署的需求,CF似乎很合适。
我想知道的是:与其他"template"部署技术相比,CF的使用普遍吗?您的团队使用什么来部署重复的AWS服务配置?
它的可用性/学习性如何?如果我采用CF,AWS上的现有开发人员已经很可能熟悉它并能够立即使用它了? CF似乎已经支持许多或大多数AWS服务,但人们是否真的在使用它来反复标记出配置完全相同的服务拓扑?
还是大多数团队都喜欢一个更简单,更容易配置的选项?如果是这样,为什么?
使用CloudFormation模板时,我需要注意哪些陷阱? CF不能处理什么,它真正应该处理什么?
最佳答案
我将根据我的个人经验尝试回答您的大多数问题:
我不能断言特定的用法分布,但是我知道使用Terraform的人。尽管Terraform支持CF,但是我的团队决定不仅仅因为CF已经满足我们的需求就不使用它。
我的团队使用CloudFormation(无Terraform)将我们的整个基础架构部署到AWS
挺容易。从一个小的模板开始(最好是YAML),然后从那里开始构建。 aws cloudformation deploy
将加快您的反馈循环。
我认为对AWS熟悉的开发人员可以轻松选择CF。如果您可以找到有关AWS文档的方法,CF则是另一个需要学习的服务。我无法肯定现有的AWS开发人员熟悉CF的可能性。
我的团队使用它来提供具有相同拓扑的测试和生产环境。使用共享的CF模板复制了基础架构的某些部分以实现冗余。
您必须注意一些CF limits,即模板主体的最大大小,上限为46KB。我们已经多次达到此限制,尤其是在为EC2实例配置较大的用户数据脚本时。话虽这么说,您不应该尽早达到此极限,并且有许多解决方法
从我的头开始:弹性代码转换器,EC2 AMI,API网关VPC链接。我们的团队使用Lambda-backed custom resources规避了这些限制,使您可以将CF扩展到您的需求。
总体而言,我的团队对CloudFormation非常满意。无疑,这可以帮助我们按顺序维护我们的AWS账户。
希望这可以帮助!