【问题标题】:What is the correct way to identify production & development environment in AWS CDK?在 AWS CDK 中识别生产和开发环境的正确方法是什么?
【发布时间】:2021-09-22 13:18:17
【问题描述】:

我正在学习 AWS 云开发工具包 (CDK)。

作为学习的一部分,我试图了解我应该如何正确处理生产和开发环境。

我知道 AWS CDK 提供了 environment 参数以允许将堆栈部署到特定账户。

但是,如何为开发和生产堆栈提供特定选项? AWS CDK 似乎没有默认提供它,还是我遗漏/误解了什么?

一个非常简单的示例是,我想要一个名为 my-s3-bucket-dev 的 S3 存储桶用于我的开发帐户,一个名为 my-s3-bucket-prod 的存储桶用于我的生产帐户。但是然后如何拥有例如在 AWS CDK 中正确处理的变量 stage

我知道我可以在 cdk.json 文件中添加参数,但我不知道如何正确使用此文件来依赖已部署的堆栈,即生产与开发。

感谢支持

【问题讨论】:

    标签: aws-cdk


    【解决方案1】:

    欢迎使用 AWS CDK。 享受车程。 ;)

    实际上,帐户本身没有语义(在您的情况下是阶段)。 这与 CDK 或 Cloud Formation 无关。 您需要注意这一点。

    您是对的,您可以在cdk.json 中使用CDK 上下文。 除了 CDK 内部使用的一些变量外,上下文中没有模式强制执行。 您可以在其中定义 devprod 对象。 defining the context还有其他方式。 这是一个示例,它可能是什么样子:

    {
      "app": "node app",
      // usually there's some internal definition for your CDK project
      "context": {
        "dev": {
          "accountId" : "prod_account",
          "accountRegion" : "us-east-1",
          "name": "dev",
          "resourceConfig":
          {
           // here you could differentiate the config per AWS resource-type
           // e.g. dev has lower hardware specs
          }
        },
        "prod": {
          "accountId" : "prod_account",
          "accountRegion" : "us-east-1",
          "name": "prod",
          "resourceConfig":
          {
           // here you could differentiate the config per AWS resource-type
           // prod has higher hardware specs or more cluster nodes
          }
        }
    
      }
    }
    

    定义好之后,您需要使用-c 标志运行您的CDK 应用程序,以指定您想要拥有的配置对象(dev 或prod)。 例如,您可以使用cdk synth -c stage=prod 运行它。 这会在您的上下文中设置 stage 变量并使其可用。 成功后,您可以再次重新访问上下文并获取相应的配置对象。

    const app = new cdk.App();
    const stage = app.node.tryGetContext('stage');
    // the following step is only needed, if you have a different config per account 
    const stageConfig = app.node.tryGetContext(stage );
    // ... do some validation and pass the config to the stacks as constructor argument
    
    

    正如我所说,上下文是执行此操作的一种方式。 但是,它也有缺点。 它是 JSON,没有代码。

    我更喜欢为每个资源配置(例如 S3)设置 TypeScript 类型,并将它们作为一个普通对象连接在一起。 该对象映射账户/区域信息和对应的资源配置。

    【讨论】:

      猜你喜欢
      • 2020-10-03
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2018-06-04
      • 1970-01-01
      • 2012-08-21
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多