当我使用具有 API 网关资源的模板运行 CloudFormation deploy 时，我第一次运行它时，它会创建并部署到阶段。随后我运行它时，它会更新资源但不会部署到阶段。
这种行为是否符合预期？如果是，我如何让它在更新时部署到阶段？
（Terraform 提到了类似的问题：https://github.com/hashicorp/terraform/issues/6613）
【问题讨论】：
标签： amazon-web-services aws-api-gateway amazon-cloudformation
通读这篇文章，我并没有立即得出结论，因为这里的信息来自多个来源。我尝试将此处（和链接来源）的所有发现总结为我的个人测试，以帮助其他人避免追捕。
重要的是要知道每个 API 总是有一个专用的 URL。相关的阶段只有一个单独的后缀。更新部署不会更改 URL，重新创建 API 会。
API
├─ RestAPI (incl. Resource, Methods etc)
├─ Deployment
├─ Stage - v1 https://6s...com/v1
├─ Stage - v2 https://6s...com/v2
关系阶段和部署：
要通过 CloudFormation (Cfn) 部署 AWS API Gateway，您需要一个 RestApi-Cfn-Resource 和一个 Deployment-Cfn-Resource。如果您为 Deployment-Resource 指定阶段名称，则部署会在“正常”创建的基础上自动创建部署。如果您忽略它，API 将在没有任何阶段的情况下创建。无论哪种方式，如果您有一个部署，您可以通过链接两者来将 n 阶段添加到部署中，但一个阶段及其 API 始终只有一个部署。
更新简单 API：
现在，如果您想更新这个仅由 RestAPI 和部署组成的“简单 API”，您将面临一个问题，即如果部署有阶段名称 - 它无法更新，因为它已经“存在”。要检测部署必须首先更新，您必须在 CloudFormation 中为部署资源名称添加时间戳或哈希，否则甚至不会触发更新。
解决部署更新：
现在要启用更新部署，您必须将部署拆分并升级为单独的 Cfn 资源。这意味着，您从 Deployment-Cfn-Resource 中删除阶段名称并创建一个引用部署资源的新 Stage-Cfn-Resource。这样您就可以更新部署。尽管如此，舞台 - 您通过 URL 引用的部分 - 不会自动更新。
将更新从部署传播到您的阶段：
现在我们可以更新部署 - 也就是 API 的蓝图 - 我们可以将更改传播到其各自的阶段。据我所知，此步骤无法使用 CloudFormation。因此，要触发更新，您需要手动添加“自定义资源”。 @Athi 的回答 above 总结了其他“无”CloudFormation 方式，但我想限制使用的工具，因此没有解决方案。
如果有人有 Lambda 更新的示例，请随时联系我 - 我会在此处添加。到目前为止我发现的链接只引用了一个普通的模板。
我希望这有助于其他人更好地理解上下文。
来源：
【讨论】：
如果您有事情要做 $TIMESTAMP$ 替换，我可能会选择它，因为它更干净而且您不必进行任何手动 API 网关管理。
我发现此处发布的其他解决方案大部分在完成这项工作时有一个主要警告 - 您无法在 CloudFormation 中分别管理 Stage 和 Deployment，因为无论何时部署 API网关，在部署 API 和辅助流程（自定义资源/lambda、代码管道，你有什么）创建新部署之间，你有某种停机时间。此停机时间是因为 CloudFormation 仅将初始部署绑定到阶段。因此，当您对 Stage 进行更改并进行部署时，它会恢复为初始部署，直到您的辅助流程创建新部署为止。
*** 请注意，如果您在 Deployment 资源上指定 StageName，而不是显式管理 Stage 资源，则其他解决方案将起作用。
就我而言，我没有$TIMESTAMP$ 替换件，我需要单独管理我的Stage，以便我可以执行诸如启用缓存之类的操作，因此我必须找到另一种方法。所以工作流程和相关的CF片段如下
在触发 CF 更新之前，请查看您要更新的堆栈是否已经存在。设置stack_exists: true|false
将 stack_exists 变量传递到您的 CF 模板，一直到创建 Deployment 和 Stage 的堆栈
以下条件：
Conditions:
StackExists: !Equals [!Ref StackAlreadyExists, "True"]
Deployment和Stage： # Only used for initial creation, secondary process re-creates this
Deployment:
DeletionPolicy: Retain
Type: AWS::ApiGateway::Deployment
Properties:
Description: "Initial deployment"
RestApiId: ...
Stage:
Type: AWS::ApiGateway::Stage
Properties:
DeploymentId: !If
- StackExists
- !Ref AWS::NoValue
- !Ref Deployment
RestApiId: ...
StageName: ...
# looks up `apiId` and `stageName` and sets variables
CURRENT_DEPLOYMENT_ID=$(aws apigateway get-stage --rest-api-id <apiId> --stage-name <stageName> --query 'deploymentId' --output text)
aws apigateway create-deployment --rest-api-id <apiId> --stage-name <stageName>
aws apigateway delete-deployment --rest-api-id <apiId> --deployment-id ${CURRENT_DEPLOYMENT_ID}
【讨论】：
这对我有用：
cfn.yml
APIGatewayStage:
Type: 'AWS::ApiGateway::Stage'
Properties:
StageName: !Ref Environment
DeploymentId: !Ref APIGatewayDeployment$TIMESTAMP$
RestApiId: !Ref APIGatewayRestAPI
Variables:
lambdaAlias: !Ref Environment
MethodSettings:
- ResourcePath: '/*'
DataTraceEnabled: true
HttpMethod: "*"
LoggingLevel: INFO
MetricsEnabled: true
DependsOn:
- liveLocationsAPIGatewayMethod
- testJTAPIGatewayMethod
APIGatewayDeployment$TIMESTAMP$:
Type: 'AWS::ApiGateway::Deployment'
Properties:
RestApiId: !Ref APIGatewayRestAPI
DependsOn:
- liveLocationsAPIGatewayMethod
- testJTAPIGatewayMethod
bitbucket-pipelines.yml
脚本： - python3 deploy_api.py
deploy_api.py
import time
file_name = 'infra/cfn.yml'
ts = str(time.time()).split(".")[0]
print(ts)
with open(file_name, 'r') as file :
filedata = file.read()
filedata = filedata.replace('$TIMESTAMP$', ts)
with open(file_name, 'w') as file:
file.write(filedata)
================================================ ==========================
阅读本文了解更多信息：https://currentlyunnamed-theclassic.blogspot.com/2018/12/mastering-cloudformation-for-api.html
【讨论】：
我可能迟到了，但是如果 API 资源发生变化，您可以重新部署这些选项，这可能对仍在寻找选项的人有所帮助 -
尝试将 AutoDeploy 设置为 true。如果您使用的是 V2 版本的部署。请注意，您需要通过 V2 创建 APIGW。 V1 和 V2 互不兼容。 https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-apigatewayv2-stage.html#cfn-apigatewayv2-stage-autodeploy
Lambda 支持的自定义资源，Lambda 反过来调用 createDeployment API - https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html
具有调用 Lambda 函数的操作的 CodePipeline 与自定义资源非常相似 - https://docs.aws.amazon.com/codepipeline/latest/userguide/actions-invoke-lambda-function.html
SAM（无服务器应用程序模型）遵循与 CloudFormation 类似的语法，它将资源创建简化为抽象，并使用这些抽象来构建和部署普通的 CloudFormation 模板。 https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html
如果您正在使用任何抽象层来实现像 Sceptre 这样的 cloudformation，则可以在对资源 https://sceptre.cloudreach.com/2.3.0/docs/hooks.html 进行任何更新后调用 createDeployment
我选择了第三个选项，因为我一直使用 Scepter 进行 Cloudformation 部署。在 sceptre 中实现钩子也很容易。
【讨论】：
这里的答案是使用 Stage 的 AutoDeploy 属性：
Stage:
Type: AWS::ApiGatewayV2::Stage
Properties:
StageName: v1
Description: 'API Version 1'
ApiId: !Ref: myApi
AutoDeploy: true
请注意，使用“AutoDeploy”时必须未指定“DeploymentId”属性。
在此处查看文档：https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-apigatewayv2-stage.html
【讨论】：
我使用了上述方法，但部署 API 网关对我来说看起来很复杂。如果我们要更改资源的名称，则删除和重新创建资源需要时间，这会增加您的应用程序的停机时间。
我正在按照以下方法使用 AWS CLI 将 API 网关部署到阶段，它不会影响使用 Cloudformation 堆栈的部署。
我正在做的是，在 API Gateway 的部署完成后，在 AWS CLI 命令下运行。它将使用最新更新更新现有阶段。
aws apigateway create-deployment --rest-api-id tztstixfwj --stage-name stg --description 'Deployed from CLI'
【讨论】：
使用 SAM
AWS::Serverless::Api
它在进行转换时为您进行部署
【讨论】：
从 TheClassic 链接的 blogspot 帖子中（迄今为止的最佳答案！），您必须记住，如果您没有使用可以插入有效时间戳来代替 $TIMESTAMP$ 的东西生成模板，则必须使用时间戳或其他唯一 ID 手动更新。这是我的功能示例，它成功删除了现有部署并创建了一个新部署，但是当我想创建另一个更改集时，我必须手动更新这些唯一值：
rDeployment05012019355:
Type: AWS::ApiGateway::Deployment
DependsOn: rApiGetMethod
Properties:
RestApiId:
Fn::ImportValue:
!Sub '${pApiCoreStackName}-RestApi'
StageName: !Ref pStageName
rCustomDomainPath:
Type: AWS::ApiGateway::BasePathMapping
DependsOn: [rDeployment05012019355]
Properties:
BasePath: !Ref pPathPart
Stage: !Ref pStageName
DomainName:
Fn::ImportValue:
!Sub '${pApiCoreStackName}-CustomDomainName'
RestApiId:
Fn::ImportValue:
!Sub '${pApiCoreStackName}-RestApi'
【讨论】：
当您的模板指定部署时，CloudFormation 将仅在该部署尚不存在时创建该部署。当您尝试再次运行它时，它会观察到部署仍然存在，因此不会重新创建它，因此没有部署。您需要一个新的资源 ID 用于部署，以便它创建一个新的部署。阅读本文了解更多信息：https://currentlyunnamed-theclassic.blogspot.com/2018/12/mastering-cloudformation-for-api.html
【讨论】：
用亚马逊的话来说，CloudFormation 是：
AWS CloudFormation 负责为您预置和配置这些资源 http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html
API 的重新部署不是一项供应任务...它是一种推广活动，是您的软件发布过程中某个阶段的一部分。
AWS CodePipeline 是一种持续交付服务，可用于对发布软件所需的步骤进行建模、可视化和自动化。 http://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html
CodePipeline 还支持从管道中的操作执行 Lambda 函数。因此，如前所述，创建一个 Lambda 函数来部署您的 API，但从 Codepipeline 而不是 CloudFormation 调用它。
详情请参阅此页面： http://docs.aws.amazon.com/codepipeline/latest/userguide/actions-invoke-lambda-function.html
【讨论】：
每当您的 Cloudformation 资源之一发生变化时，似乎都无法轻松创建新部署。
解决此问题的一种方法是使用 Lambda 支持的自定义资源（请参阅http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html）。
仅当您的资源之一已更新时，Lambda 才应创建新部署。要确定您的资源之一是否已更新，
您可能必须围绕此 API 调用实现自定义逻辑：http://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_DescribeStackEvents.html
为了触发自定义资源的更新，我建议您提供一个 Cloudformation 参数，该参数将用于强制更新您的自定义资源（例如当前时间或版本号）。
请注意，您必须将DependsOn 子句添加到您的自定义资源中，该子句将包含与您的 API 相关的所有资源。否则，您的部署可能会在您的所有 API 资源更新之前创建。
希望这会有所帮助。
【讨论】：