在Terraform中如何在一个template_cloudinit_config对象中继承另一个template_cloudinit_config对象

104次阅读

问题描述

在使用Terraform时，想知道是否可以在一个template_cloudinit_config对象中继承另一个template_cloudinit_config对象。他希望能够声明一个核心的template_cloudinit_config，其中包含一些应该在每个机器上运行的shell脚本。然后，他希望声明一个第二个template_cloudinit_config，它可以继承核心的脚本，并定义一个额外的脚本。这样，从计算的角度来看，他可以轻松创建具有自定义脚本的专门实例，但仍然继承一些基本配置。他知道可以使用remote-exec provisioners来实现，但他想避免使用它们，因为Terraform说它们应该作为最后的手段使用。

解决方案

请注意以下操作注意版本差异及修改前做好备份。

方案1

在Terraform中，可以使用cloudinit_config数据源来构建一个包含多个part对象的序列，并将它们一起传递给cloudinit_config数据源。以下是一个示例：

locals {
  core_config = tolist([
    {
      content_type = "text/x-shellscript"
      content      = file("${path.module}/scripts/core_script1.sh")
    },
    {
      content_type = "text/x-shellscript"
      content      = file("${path.module}/scripts/core_script2.sh")
    },
  ])

  custom_config = tolist([
    {
      content_type = "text/x-shellscript"
      content      = file("${path.module}/scripts/custom_script.sh")
    },
  ])
}

data "cloudinit_config" "core" {
  dynamic "part" {
    for_each = local.core_config

    content {
      content_type = part.value.content_type
      content      = part.value.content
    }
  }
}

data "cloudinit_config" "custom" {
  dynamic "part" {
    for_each = concat(
      local.core_config,
      local.custom_config,
    )

    content {
      content_type = part.value.content_type
      content      = part.value.content
    }
  }
}

resource "aws_instance" "vm1" {
  instance_type = "t2.small"
  ami           = data.aws_ami.ubuntu_ami.image_id

  # ...

  user_data = data.cloudinit_config.core.rendered
}

resource "aws_instance" "vm2" {
  instance_type = "t2.small"
  ami           = data.aws_ami.ubuntu_ami.image_id

  # ...

  user_data = data.cloudinit_config.custom.rendered
}

在上面的示例中，我们首先使用tolist函数定义了core_config和custom_config本地变量，它们分别包含核心脚本和自定义脚本的配置。然后，我们使用dynamic块来根据列表中的元素数量动态生成part块，这意味着您只需要确保列表中有必要的项，并使用任何动态表达式来决定它们，Terraform会自动将其投影到零个或多个part块中。

请注意，上面的示例使用了hashicorp/cloudinit提供程序，而不是hashicorp/template提供程序。因为hashicorp/template提供程序已被弃用，并且仅用于向后兼容。因此，我将上面的示例修改为使用hashicorp/cloudinit提供程序。它的cloudinit_config数据源基于以前的template_cloudinit_config。

方案2

使用脚本或工具来管理容器的启动顺序可能会增加复杂性，并且需要确保容器A和容器B之间的依赖关系正确设置。
另一种方法是编写脚本或使用工具来控制容器的运行顺序。你可以使用docker run命令来手动控制容器的启动顺序，或者使用一些第三方工具来管理容器的依赖关系。

示例：

以下是一个简单的bash脚本示例，可以在容器A启动后启动容器B：

#!/bin/bash
# 启动容器A
docker run -d --name container_a your_image_a
# 等待容器A完全启动
while ! docker exec container_a echo "Container A is ready"; do
  sleep 1
done
# 启动容器B
docker run -d --name container_b your_image_b

在这个示例中，我们首先使用docker run命令启动容器A，并将其命名为container_a。然后，使用一个循环来等待容器A完全启动（这里是通过在容器内运行echo命令来测试）。一旦容器A就绪，我们再使用docker run命令启动容器B，并将其命名为container_b。

正文完