我正在使用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应用程序已经创建并应该被使用。也许某种全局配置处理这个并输出,因此它在模块中可用?
答案 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模块和符号链接配置使事情保持正确