问题
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?
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?
回答1:
There's no easy answer, but several important points to keep in mind:
when you write several small templates, write a master template which will call the small ones (nested stacks). When you want to update a small one, do the change in the file, and update the master one. Only the resources that have changed will be updated, and the result of the stack update will be atomic (all clear or rollback everything). CloudFormation will still run the nested stacks in parallel, so it's not that slower.
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!
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.
I've been able to write huge CloudFormation templates with this system, without any maintenance nightmare...
回答2:
We started out with everything in one large template but eventually refactored it a bit to include a nested stack with some resources to avoid duplicating it in other templates.
One of the biggest challenges I've found is that having a monolithic stack makes it more difficult to update things piecemeal, and also makes it awkward when there are other stacks that depend on the resources in the monolith (e.g. security groups).
There was a session at re:Invent 2014 with a number of useful tips: APP304 - AWS CloudFormation Best Practices. Slides / Video
They recommend breaking stacks up based on a combination of layers or shared bits such as: identity, base network, shared services, backend services, frontend services.
While I'm loathe to deal with a lot of parameters and outputs (feeding them between stacks is annoying), it seems like a more flexible way of composing desired infrastructure.
回答3:
I know I am late for this discussion, but I want to share cfpack.js CLI tool that allows you to create multiple small CloudFormation templates that will be combined into the big one and deployed to a CloudFormation stack.
回答4:
I'm not sure about any official guidance on this but my feeling is that if you are going to go the CloudFormation path it makes sense to put the entire stack into one template. That way, as you mention, you get the transactional nature of CloudFormation working for you and the entire stack will either be created or not.
来源：https://stackoverflow.com/questions/25273580/aws-cloudformation-one-big-template-file-or-many-small-ones