Terraform环境特定变量

任何人都知道是否有方法根据环境/工作区是什么来填充Terraform中的变量？优选一个Terraform环境特定变量

填充VAR命名空间（即，不是外部数据源），
不需要包装
- 像tf(){ terraform --var-file=$(get_tf_env).tfvars
通过改变terraform生效环境/工作区，没有任何额外的手动步骤（即步骤不是由运行terraform env触发）？

2017-08-09 Rory Browne

我不知道用Terraform做的本地方法。如果你四处搜索，你会看到很多人将不同的文件夹结构用于TF配置的入口点，每个不同的文件夹可以在tfvars文件中具有不同的值。有一种方法可以帮助你在0.10中引入Terraform Workspaces。

我已经实施了一些与您建议使用OctopusDeploy的建议类似的内容。如果您以前没有使用过，八达通可以很好地管理特定于环境的变量。我有一个默认的tfvars文件和八达通内的相应变量值列表，每个环境。

我有一个基本步骤，遍历tfvars中的每个变量，然后查找具有相同名称的Octopus变量，并在找到该变量时将其替换。

我发现这是一个体面的工作方式，因为它在Terraform tfvars文件（需要什么值）和八达通中的变量值（实际值是什么）之间给出了很好的分隔。

E.g.如果我有一个tfvars文件，其中包含

instance_size = "Medium"

而且在Octopus，Staging和Production中有2个环境。我可以将一个变量添加到名为“instance_size”的Octopus中，并为每个环境设置不同的值（例如分别为“Big”和“Biggest”）。

我写会发现“instance_size”一corrresponding值，这意味着，当我运行它的分期我会得到步骤模板：

instance_size = "Big"

和生产

instance_size = "Biggest"

来源

2017-08-09 10:20:07 Fermin

谢谢费尔明;我特别想避免使用任何形式的包装;我已经有了文件夹/符号链接场设置，但这样我就可以拥有不同的模块集（实现相同的接口）来实现操作。在这种情况下，我们的AWS工具已被分解出来，因此可以使用来自Azure或GCE的等效工具来实施。工作区本质上是以前版本中称为环境的0.10版本。如果terraform 0.10.0有一种反映工作区名称的方法，但是我不认为它是有用的。 –

我将Octopus步骤作为部署管道的一部分，因此不要将其看作是包装本身。不确定我是否通过具有相同接口的不同模块获得了您的意思 - 相同的参数要求，但Azure/AWS之间的实现切换？ – Fermin

Terraform workspaces

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

在0.9版的Terraform版本中，这个概念被称为“环境”。根据Terraform本身和使用Terraform的组织内部“环境”这个词超负荷所造成的混淆的反馈，它被重新命名为0.10。

引用当前工作空间是用于改变基于所述工作区的行为是有用的。例如，对于非默认工作区，可能需要调整较小的簇大小。例如：

resource "aws_instance" "example" { 
    count = "${terraform.workspace == "default" ? 5 : 1}" 

    # ... other arguments 
}

来源

2017-08-10 13:53:07 strongjz

我使用上面描述的工作空间，以及变量映射，这些变量映射允许您根据环境（工作空间）名称为各种资源保留不同的变量。然后查看资源就可以这样完成：“$ {lookup（var.vpc_cidr，terraform.workspace）}”。这将为您提供varialbe映射'vpc_cidr'的值与等于工作空间名称的密钥，例如ecommerce-dev – Mattec

我会建议采取“栈”为您Terraform项目为基础的方法，使您可以配置和管理中的“栈”和每个工作区的远程状态（又名环境）。这从风险的角度限制了更改的爆炸半径，简化了工作流程，并且还提供了更清洁，更易维护的代码库。

什么让你一天好？

一个客观简单的设计，可以让你推论平台及其运动部件。（aka Stacks）
一个实现，为您提供了灵活性，同时限制了更改的风险。（aka限制爆炸半径）
一种解决方案，可以在今天提供价值，并在持续改进的同时长期提供动力。（又名模式，工作流程）

这里是一个很好的做法

管理 “国家” 的快速列表分别为 “堆栈” 跨越 “工作区”
实施的“栈“为一致‘’跨越‘工作区配置’
保持它客观和简单的用好‘模式’和‘工作流程’。

例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允许使用远程国家作为数据源。为每个堆栈配置自己的输出变量使配置和使用导出的资源属性变得更加简洁。

设置您的项目，以便您可以在堆栈级别定义变量和合理的默认值，使您可以根据需要在工作区级别覆盖它们，以满足Dev，Test，Production等不同环境的需求。同时保持配置的一致性和远程状态分别在每个环境下进行管理。

这些都是一些我们已经开发并部署在我们的队伍，提高我们的经验与Terraform合作来管理我们的AWS平台的做法。

干杯！

来源

2017-08-30 19:34:01 FellowHobbyist

Terraform环境特定变量

回答

相关问题