如何将现有的CloudFormation堆栈拆分为单独的嵌套堆栈，如何在嵌套堆栈下移动现有资源 [英] How to break existing CloudFormation stack into separate nested stacks, moving existing resources under nested stack
问题描述
问题:
最近，我们在单个CloudFormation模板中可以声明的最大资源数量方面遇到了问题.一个模板最多可以支持200个资源，我们已经很接近达到这个极限.
Recently we encountered a problem with respect to maximum number of resources that you can declare in a single CloudFormation template. A template can support a maximum of 200 resources and we are very close to reach that limit.
To specify more resources, we need to separate our template into multiple templates by using Nested Stacks, We are evaluating a best approach to breakdown the template.
我们的方法:
我们已经从主堆栈中创建了一个嵌套堆栈，并从主堆栈中删除了一些资源，并将它们添加到新的嵌套堆栈中.
We have created a nested stack from our main stack and removed some of the resources from main stack and added them into new nested stack.
错误:
我们在嵌套堆栈中遇到了一个错误，例如
We encountered an error in nested stack e.g.
资源已在根堆栈中
Resource already exists in Root stack
1..是否可以将我们的主模板分解为具有现有资源的嵌套堆栈?即将我们现有的资源移到嵌套堆栈下?还是只需要向嵌套堆栈中添加新资源，并使我们的主堆栈与现有资源保持原样?
1. Is it possible to break our main template into nested stacks with existing resources? i.e move our existing resources under nested stack? or we just need to add new resources into nested stack and keep our main stack as it is with existing resources ?
2..我们已经达到200个资源限制，因此也很难添加更多的嵌套堆栈.
2. We already reached 200 resource limit so it's difficult to add more nested stacks as well.
模板中的资源
我们大约有100个CloudWatch警报，DynamoDB表，Lambda，ES，KMS，S3和其他资源，我们不会将它们分为特定于资源类型的嵌套堆栈.
We roughly have 100 CloudWatch alarms, DynamoDB tables, Lambda's, ES, KMS, S3 and other resources, we wan't to separate them into nested stacks specific to resource types.
推荐答案
您不能将现有资源整合"到新的CloudFormation堆栈中.如果将资源移到嵌套堆栈中并将嵌套堆栈添加到根模板中，它将首先尝试在嵌套堆栈中创建新资源，然后在清理过程中删除根堆栈中的旧资源.这样，如果新资源具有相同的名称(并且不允许重复的名称)，则更新将失败.
You can't 'incorporate' existing resources into new CloudFormation stacks. If you move resources into a nested stack and add the nested stack to your root template, it will try to create new resources in the nested stack first, then delete the old resources in the root stack as part of the cleanup process. As such if the new resources have the same names (and duplicate names are not allowed) then the update will fail.
解决方案是分两个阶段部署堆栈，首先从根堆栈中删除资源，然后将它们添加到嵌套堆栈中.当您的环境中缺少这些资源时，这将导致很短的时间，但是如果您保持较小的迁移，则只需几分钟.
The solution to this is to deploy the stack in two stages, first removing the resources from the root stack, and then adding them to the nested stack. This will result in a short time when those resources are missing from your environment, but if you keep the migrations small it should only be for a few minutes.
包含状态的资源(例如DynamoDB，KMS，S3等)很难以这种方式进行迁移，因为删除数据时显然会丢失数据.您要么需要执行一个完整的迁移过程，要么在嵌套堆栈中创建一个具有不同名称的新资源，然后迁移数据，更新您的应用程序以使用新资源，最后删除旧资源，或者接受那可能也太过分了.内部重构需要做很多工作，并将这些资源留在根模板中.
Resources which contain state (like DynamoDB, KMS, S3, etc) are much harder to migrate in this fashion because the data is obviously lost when you delete them. You either need to do a full migration process, creating a new resource with a different name in the nested stack, migrating data over, updating your application to use the new resource, and finally deleting the old resource, or accept that that's probably far too much work for an internal refactor and leave those resources in the root template.
这篇关于如何将现有的CloudFormation堆栈拆分为单独的嵌套堆栈，如何在嵌套堆栈下移动现有资源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
