Terraform环境特定变量

时间:2017-08-09 10:04:49

标签: terraform

任何人都知道是否有办法根据环境/工作空间填充Terraform中的变量?

最好是一个
  • 填充var命名空间(即不是外部数据源),
  • 不需要包装器
    • 喜欢.row { width:calc(100%/3); }
  • 通过更改terraform env / workspace生效,无需任何额外的手动步骤(即不是通过运行tf(){ terraform --var-file=$(get_tf_env).tfvars触发的步骤)?

4 个答案:

答案 0 :(得分:4)

填充var命名空间,不需要包装器,并通过更改工作空间生效:

variable "ami_id" {
  type = "map"

  default = {
    stg = "ami-foo28929"
    prd = "ami-bar39b12"
  }
}

image_id = "${lookup(var.ami_id, terraform.workspace)}"

答案 1 :(得分:3)

Terraform workspaces

  

工作空间是Terraform状态的命名容器。通过多个工作区,Terraform配置的单个目录可用于管理多个不同的基础架构资源集。

     

在Terraform版本的0.9系列中,这个概念被称为" environment"。根据有关“环境”字样超载引起的混淆的反馈,它在0.10中重命名。 Terraform本身以及使用Terraform的组织内部。

     

引用当前工作空间对于根据工作空间更改行为很有用。例如,对于非默认工作空间,调整较小的簇大小可能很有用。例如:

resource "aws_instance" "example" {
  count = "${terraform.workspace == "default" ? var.default : var.min}"

  # ... other arguments
}

答案 2 :(得分:1)

我所知道的Terraform没有本地方式。如果你在周围搜索,你会看到很多人会有不同的文件夹结构用于TF配置的入口点,每个不同的文件夹在tfvars文件中可以有不同的值。一个选项可能会让您使用Terraform Workspaces,在0.10中引入。

我已经实现了类似于您使用OctopusDeploy建议的内容。如果您以前没有使用它,Octopus适用于管理特定于环境的变量。我有一个默认的tfvars文件和Octopus中每个环境的相应变量值列表。

我有一个基本步骤,遍历tfvars中的每个变量,并查找具有相同名称的Octopus变量,并在找到它时替换它。

我发现这是一种不错的工作方式,因为它可以很好地分离Terraform tfvars文件(需要什么值)和Octopus中的变量值(实际值是什么)。

E.g。如果我有一个包含

的tfvars文件
instance_size = "Medium"

我在Octopus,Staging和Production中有2个环境。我可以在Octopus中添加一个名为'instance_size'的变量,并为每个环境设置一个不同的值(例如分别为“Big”和“Biggest”)。

我写的步骤模板会找到“instance_size”的相应值,所以这意味着当我运行它进行分段时,我会得到:

instance_size = "Big"

和生产

instance_size = "Biggest"

答案 3 :(得分:1)

我建议您为Terraform项目采用“基于堆栈”的方法,以便您可以配置和管理“堆栈”和每个工作区的远程状态(也称为环境)。这从风险角度限制了更改的爆炸半径,简化了工作流程,并提供了更清晰,更易维护的代码库。

什么能让你的一天变得更好?

  • 客观简单的设计,让您可以推断平台及其活动部件。 (又名Stacks)
  • 为您提供灵活性同时限制更改风险的实施方案。 (又名限制爆炸半径)
  • 一种解决方案,它可以提供今天的价值,并在长期建立动力的同时不断改进。 (又名模式,工作流程)

以下是良好做法的快速列表

  • 分别为“工作区”中的“堆栈”管理“状态”

  • 在“工作区”中实施“堆栈”以实现一致的“配置”

  • 通过良好的“模式”和“工作流程”保持客观和简单。

使用基于堆栈的方法的示例Terraform项目

/
  /scripts
     <shell scripts>
     <terraform wrapper functions>

  /stacks
    /application_1   # Provisions Application 1 and its dependencies
    /application_2   # Provisions Application 2 and its dependencies
    /application_n   # Provisions Application N and its dependencies
        backend.tf       # Remote State
        data.tf          # Data Sources
        stack.tf         # Stack Variables and Defaults
        aws_resource.tf 
        ...
        ...    
    /network    # Provisions VPC, Subnets, Route Tables, Route53 Zones
    /security   # Provisions Security Groups, Network ACLs, IAM Resources
    /storage    # Provisions Storage Resources like S3, EFS, CDN

  global.tf     # Global Variables
  dev.tfvars    # Development Environment Variables
  tst.tfvars    # Testing Environment Variables
  stg.tfvars    # Staging Environment Variables
  prd.tfvars    # Production Environment Variables
  terraform.sh  # Wrapper Script for Executing Terraform (Workflow)

更多想法

随着实现的增长,将未来需求合并到现有堆栈中或者如果它们是共享依赖项则作为新堆栈更加简单。

Terraform允许将远程状态用作数据源。每个堆栈配置自己的输出变量使配置和使用导出的资源属性变得更加清晰。

设置项目以便您可以在堆栈级别定义变量和合理的默认值,允许您根据需要在工作区级别覆盖它们,以满足不同环境(如开发,测试,生产等)的要求。同时保持配置一致,远程状态按环境单独管理。

这些是我们在团队中开发和部署的一些实践,旨在改善我们使用Terraform管理AWS平台的经验。

干杯!