amazon-web-services - 同一应用程序下具有多个环境的 Terraform 和 Elastic Beanstalk

Question

我正在使用 Terraform 创建 Elastic Beanstalk 应用程序和两个关联的环境，但设置时遇到一些困难。具体来说，我有两个适用于我的两个环境(生产环境和登台环境)的 Terraform 配置，以及一个 Elastic Beanstalk 模块。像这样的事情:

├── environments
│   ├── production
│   │   ├── main.tf
│   │   └── variables.tf
│   └── staging
│       ├── main.tf
│       └── variables.tf
└── modules
    └── elastic_beanstalk
        ├── main.tf
        └── variables.tf

对于 Elastic Beanstalk，惯例是应用程序 > 环境 > 应用程序版本，因此 EB 应用程序将类似于“elastic_beanstalk”，然后将有用于生产和暂存的 EB 环境。

问题:我不知道如何使用 TF 处理 EB 应用程序创建，因为它需要在两个 TF 环境之间共享。如果我在从暂存配置调用的模块内部处理 EB 应用程序创建，则从生产配置调用该模块会引发错误，因为它无法识别 EB 应用程序已创建并且应该使用。也许某种全局配置可以处理这个问题并输出，以便它在模块中可用？

Answer 1

Terraform 通常不处理 AWS 处理的某些版本化资源，相反，创建代表这些阶段的完全解耦的资源通常更容易。对于像 AWS 的 API Gateway 这样的东西尤其如此，它具有 Terraform 根本不能很好处理的阶段概念。

使用 Elastic Beanstalk，您可以选择忽略 EB 提供的环境功能，而只是为每个生产和登台环境创建单独的应用程序和环境，因此一个非常基本的模块可能如下所示:

variable "environment" {}

resource "aws_elastic_beanstalk_application" "application" {
  name        = "my-application-${var.environment}"
}

resource "aws_elastic_beanstalk_environment" "environment" {
  name                = "my-application-${var.environment}"
  application         = "${aws_elastic_beanstalk_application.application.name}"
  solution_stack_name = "64bit Amazon Linux 2015.03 v2.0.3 running Go 1.4"
}

然后，您可以调用相同的模块，但传入不同的环境名称，以在 AWS 中获取一个完全独立的 EB 应用程序，该应用程序恰好由环境命名。

或者，如果您想坚持 EB 的环境模型，您可以单独定义应用程序，然后仅在环境级别部署环境。

因此，在这种情况下，您的布局可能类似于:

.
├── application
│   ├── main.tf
│   └── variables.tf
├── environments
│   ├── production
│   │   ├── main.tf
│   │   └── variables.tf
│   └── staging
│       ├── main.tf
│       └── variables.tf
└── modules
    └── elastic_beanstalk_environment
        ├── main.tf
        └── variables.tf
    └── elastic_beanstalk_application
        ├── main.tf
        └── variables.tf

并且您必须先应用 application 目录，然后再部署环境目录。

如果没有任何 Elastic Beanstalk 的经验，我可能会倾向于第一个模型，因为它简化了我使用 Terraform 部署事物的方式，知道如果我应用临时环境并且一切正常，那么应用生产环境也会进行好好工作。对于第二种模型，有人可能会在应用暂存环境后对应用程序应用更改，然后您可能会将尚未部署到暂存的更改部署到生产中。

使用 API Gateway 和 Lambda(也支持某种形式的内部版本控制)，我发现通常最好忽略此版本控制并创建完全不同的资源，并使用 Terraform 模块和符号链接(symbolic link)配置来保持事物正确排列。