是否有" terraform“或"meta”terraform提供程序？

Question

有没有可以管理terraform root的提供程序？将多个根/部署组件映射到一起的某种编排？

例如，如果我想在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可以从一个配置的状态中检索输出，以便在访问控制允许的情况下在另一个配置中使用。因此，在这种意义上，有一个"meta Terraform provider"，但不是您想要的意义。

抛开这样做的价值不谈，从技术上看，实现一个包装Terraform的Terraform提供程序在技术上是可行的，如下所示：

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

~ resource "terraform_config“示例”{~ resources ={~ "aws_instance.example“={ ami = " ami -abc123”~ instance_type = "t2.micro“->”m3.media“}~ "aws_instance.example1”={ami= "ami-abc123“~ instance_type = "t2.micro“->”m3.media“}} root_dir = "./child_thingy”variables ={ example = "baz“}}

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

上面确实显示了该模型与Terraform模块内置概念的至少一个明显区别:外部Terraform会将其他配置的所有更改视为对单个资源的更新，而对于模块，Terraform将在顶层显示所有更改。

这里要处理的另一个复杂性是如何处理需要资源替换的嵌套配置中的更改。Terraform目前无法通知提供者需要“替换”对象的一个嵌套部分，因此提供者需要将其建模为销毁，然后重新创建整个配置，或者将其呈现为更新，然后在内部静默替换对象。这些听起来都不适合日常使用。