AWS cloudformation:一个大模板文件还是许多小模板文件? [英] AWS cloudformation: One big template file or many small ones?

查看:75
本文介绍了AWS cloudformation:一个大模板文件还是许多小模板文件?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我将重写许多aws部署代码,以使用boto控制的cloudformation启动所有内容,而不是使用boto单独启动每个元素.有谁知道它的最佳实践"是使用一个巨大的模板文件(可以将所有内容放在一起),还是使用许多较小的模板文件?

I'm about to rewrite a lot of my aws deployment code to launch everything with cloudformation controlled by boto, instead of bringing up each element on its own with boto. Does anyone know if its "best practice" to use one giant template file, which kicks everything off together, or a lot of smaller ones?

一个大公司的优势似乎在于,AWS为您处理了所有依赖关系,因此会稍微加快速度.明显的缺点是,维护它似乎是一场噩梦.

The advantage of one giant one seems to be that AWS handles all the dependancies for you so will bring things up slightly faster. The clear disadvantage is that it seems like a nightmare to maintain.

是否有人尝试在运行时合并其模板文件,以便将它们视为一个大文件,还是很难维护?

Has anyone tried combining their template files at run time so that they are treated as one large one, or does that get difficult to maintain?

推荐答案

没有简单的答案,但要牢记以下几个要点:

There's no easy answer, but several important points to keep in mind:

  • 编写多个小模板时,请编写一个主模板,该模板将调用这些小模板(嵌套堆栈).当您要更新一个较小的文件时,请在文件中进行更改,然后更新主文件.仅已更改的资源将被更新,并且堆栈更新的结果将是原子的(全部清除或回滚所有内容). CloudFormation仍将并行运行嵌套堆栈,因此 并不慢.

CloudFormation在资源数量(每堆栈200个资源)方面存在限制.例如,如果您有SecurityGroupIngress/Egress规则,则很容易达到.不确定支持人员是否可以更新此限制.

there's a limitation in CloudFormation regarding the number of resources (200 resources per stack). It's very easy to reach, if you've got SecurityGroupIngress/Egress rules for example. Not sure this limit can be updated by the support.

另一方面,将参数馈送到嵌套堆栈可能会导致包含很多信息的大文件...考虑这一点:您必须将所有参数馈送到调用中,您必须在嵌套堆栈内部再次声明所有参数.相信我,两个层次的嵌套是一个真正的痛苦!

on the other hand, feeding parameters to nested stacks can result in big files with not that many information... consider this: you have to feed all the parameters to the call, inside the nested stack you have to declare all the parameters again. Two levels of nesting is a real pain, believe me!

我发现的最佳解决方案是使用CloudFormation模板前端(我在Python中使用对流层- ),这样您就可以将基础架构真正描述为代码,并具有代码的所有优点(循环,条件,外部文件,函数),最后,您可以获得真正的CloudFormation模板.

The best solution I've found is using a CloudFormation template frontend (I use troposphere - in python), so that you really describe infrastructure as code, with all the advantages of code (loops, conditionals, external file, functions) and in the end, you've got a genuine CloudFormation template.

我已经能够使用此系统编写庞大的CloudFormation模板,而无需进行任何维护噩梦...

I've been able to write huge CloudFormation templates with this system, without any maintenance nightmare...

这篇关于AWS cloudformation:一个大模板文件还是许多小模板文件?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆