【问题标题】:AWS CloudFormation - ignore changes in property - `ignore_changes` from Terraform equivalent?AWS CloudFormation - 忽略属性的变化 - 来自 Terraform 等效项的“ignore_changes”?
【发布时间】:2020-11-17 07:05:46
【问题描述】:

假设我创建了

    CognitoUserPoolIdentityProviderGoogle:
      Type: AWS::Cognito::UserPoolIdentityProvider
      Properties:
        ProviderName: Google
        AttributeMapping:
          email: emailAddress
        ProviderDetails:
          client_id: xxxx
          client_secret: yyyy
          authorize_scopes: profile email openid phone
        ProviderType: Google
        UserPoolId:
          Ref: CognitoUserPoolUserPool

后来有人手动将client_id 和client_secret 更新为1111 和2222。重新运行 CloudFormation 将导致覆盖手动更改并将值恢复为 xxxx 和 yyyy。

如何避免这种情况? AWS::Cognito::UserPoolIdentityProvider 只是一个例子 - 这可以是任何资源。

我正在寻找的基本上是 Terraform 中 ignore_changes 的功能

【问题讨论】:

    标签: amazon-web-services amazon-cloudformation


    【解决方案1】:

    在 CFN 中没有“忽略更改”。在 CFN 无法控制的情况下手动修改任何由 CFN 管理的资源是一种不好的做法。手动更改可能会导致很多问题,您所描述的就是其中之一。

    您所观察到的技术术语是stack drift。管理它的方法很少。但是,当您怀疑它是在任何更新之前在您的堆栈上运行 drift detection 时,您要做的第一件事。

    由于在您的情况下漂移并没有那么糟糕,您有两个选择:

    • 手动更新 CFN 模板以匹配手动更改,并更新堆栈
    • 手动将资源修改回其原始状态,然后通过 CFN 应用所有更新。

    【讨论】:

    • 虽然我同意并尽可能避免手动更改,但我觉得有时它们是必要的。 ASG 的期望容量或 SSM 的参数值都是恰当的例子,至少在 Trrraform 的世界里是这样。谢谢你的回答。
    猜你喜欢
    • 2019-08-22
    • 2019-11-21
    • 2021-12-22
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-02-06
    • 2018-06-22
    • 1970-01-01
    相关资源
    最近更新 更多