具有多个环境的Terraform和Elastic Beanstalk在同一个应用程序下

时间:2018-03-12 22:27:35

标签: amazon-web-services elastic-beanstalk terraform

我正在使用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,约定是Application>环境>应用程序版本,因此EB应用程序将类似于“elastic_beanstalk”,然后将有EB环境用于生产和登台。

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

1 个答案:

答案 0 :(得分:3)

Terraform通常不会处理AWS处理的某些版本化资源,而是通常更容易创建代表这些阶段的完全分离的资源。对于像AWS这样的事情来说尤其如此。 API网关具有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进行部署的方式,因为我知道如果我应用staging环境并且事情很好,那么应用生产环境是也会运作良好。使用第二个模型时,有人可能会在应用暂存环境后将更改应用于application,然后您可能会将更改部署到尚未部署到暂存的生产中。

使用API​​ Gateway和Lambda,它也支持某种形式的内部版本控制,我发现通常更好的做法是忽略这个版本并创建完全不同的资源,并使用Terraform模块和符号链接配置使事情保持正确