Question

是否存在可以管理Terraform根的提供程序？某种编排将多个根/部署组件映射在一起？

例如，如果我想在AWS中创建一个分布式平台，则可能要为配置VPC，子网，路由等的核心/网络创建一个根。然后再一个提供kubernetes的根。在ec2 / asg / kubernetes / lambda / etc等中运行的许多微服务也可能有其自己的根源。对于常规的微服务部署，然后可以使用单个根目录来部署对服务的更新，但是如果我想提供整个平台，是否有提供商可以应用具有依赖关系的多个根目录？

代码可能类似于：

resource "terraform_root" "core" {
  root_location: core/network
}

resource "terraform_root" "kubernetes" {
    depends: [terraform_root.core]
    root_location: git@github.com:myorg/myrepo?ver=1.2.1
    variables : { something }
}

resource "terraform_root" "microservice_x" {
    depends: [terraform_root.kubernetes]
    root_location: some_location
}

如果没有一个，创建像这样的自定义提供程序是否会成为带有tf的某种反模式？会有什么问题？

Answer 1

您可能对Terragrunt（Terraform的包装器）感兴趣，该包装器使您可以在模块之间创建依赖关系并最大程度地减少重复代码。使用Terragrunt，您可以一次执行多个模块，但仍保持状态分离。您还可以在Terraform运行之前和之后执行挂钩，并且可以轻松使用多个AWS账户。参见this repo进行演示。

Answer 2

使用Terraform进行建模的预期方法是使用use Terraform modules，它可以让您一次管理多个资源集合，同时又使它们彼此保持命名空间。

拥有一个运行Terraform子实例的Terraform提供程序，主要只是使用Terraform模块的更复杂的版本。但是，它会有一个明显的不同行为：每个“配置根”都将有自己的后端，因此也有自己的状态集（每个工作区）。虽然通常建议将Terraform管理的基础架构划分为多个状态，但这样做的理由是您可以分别terraform plan和terraform apply将其管理，以管理跨范围的广泛变更产生意外影响的风险整个堆栈。通过一次运行terraform apply来管理多个单独的“配置根目录”似乎会削弱该优势，因此只能降低单个配置中模块的作用。

对于已将系统分解为多个单独的Terraform配置的情况，the provider named terraform可以从一种配置的状态中检索输出，以在访问控制允许的情况下用于另一种配置。因此，从某种意义上说，有一个是“元Terraform提供程序”，但在您的意图上却不是。

抛开做这件事的价值，看来实现包装Terraform的Terraform提供程序在技术上是可能的，如下所示：

当要求提供者创建计划时，运行terraform plan -out=tempfile，然后运行terraform show -json tempfile以获取该计划的机器可读版本，然后以某种方式将其合并到提供者的计划响应中。据推测，最终可能会将计划的资源更改显示为表示整个子配置的单个资源的属性更改，也许是这样的：

 ~ resource "terraform_config" "example" {
   ~ resources = {
       ~ "aws_instance.example[0]" = {
             ami           = "ami-abc123"
           ~ instance_type = "t2.micro" -> "m3.medium"
         }
       ~ "aws_instance.example[1]" = {
             ami           = "ami-abc123"
           ~ instance_type = "t2.micro" -> "m3.medium"
         }
     }
     root_dir  = "./child_thingy"
     variables = {
       example = "baz"
     }
 }

当要求提供者应用更改时，运行terraform apply tempfile以应用更改。为了可靠地执行此操作，我想它需要将内部terraform plan中保存的二进制计划文件嵌入外部terraform plan结果中，以便可以确保应用正确的计划。

上面的确显示了该模型与Terraform模块的内置概念的至少一个可见差异：其他配置的所有更改都将被外部Terraform视为对单个资源的更新，而如果使用Terraform模块，则会在顶层显示所有更改。

这里要处理的另一个复杂性是如何处理需要替换资源的嵌套配置中的更改。 Terraform当前无法让提供程序发出信号，表明需要“替换”对象的一个嵌套部分，因此提供程序要么需要将其建模为destroy，然后重新创建整个配置，要么以更新的形式呈现，但是然后在内部以静默方式替换对象。这些声音都不适合日常使用。

是否有“ terraform”或“ meta”地形提供者？

2 个答案: