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 部署事物的方式，我知道如果我应用暂存环境并且一切正常，那么应用生产环境也将继续进行好好工作。对于第二个模型，有人可能会在应用暂存环境后将更改应用到 application，然后您可能会将更改部署到尚未部署到暂存的生产环境。

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