我已经创建了一些(远程执行和文件)配置程序来引导正在创建的(GCP)VM,我希望将其应用于所有VM,但是似乎无法弄清楚如何重用它们...?
模块似乎是显而易见的答案,但是创建一个模块来创建VM意味着我需要为要在每个VM上具体配置的所有内容创建输入变量。
虽然似乎无法与供应商一起使用代码片段?
答案 0 :(得分:0)
Terraform的Provisioner功能旨在作为一种万不得已的方法,用于无法将SSH SSH到计算机并在其上远程运行命令的情况,但是通常我们应该首先探索其他选项。
理想的情况是设计您的机器映像,以便已经针对它们需要进行正确配置,因此它们可以立即在启动时开始进行该工作。如果您使用HashiCorp Packer,则可能会在映像构建时运行与在供应商处使用Terraform创建时可能运行的步骤非常相似的步骤,也许使您可以轻松地调整已经完成的工作。
如果他们需要Terraform的一些配置参数才能开始工作,则可以使用GCP实例metadata
参数之类的功能来传递这些值,以便映像中的软件可以尽快对其进行访问。系统启动。
第二好的选择是使用GCP startup scripts之类的功能来传递脚本以通过metadata
运行,以便再次在启动时就可以使用它,而无需等待SSH服务器启动并可用。
在这两种情况下,其想法都是依靠计算平台提供的功能将计算实例视为一种“设备”,因此Terraform(和您)可以认为它们类似于资源。为托管服务建模。 Terraform仅关注启动和停止此黑盒基础结构并将其与其他基础结构连接,并且实例自行处理其实现细节。对于适合水平缩放的用例,这也可以与google_compute_instance_group
之类的托管自动缩放功能很好地配合,因为新实例可以由该系统启动,而不是直接由Terraform启动。
因为预配器被设计为无法使用上述方法时的最后手段,所以它们的设计不包含任何用于常规重用的方法。预计每个供应商将针对与其相关的资源内联的特定问题量身定制解决方案,而不是您在许多单独的调用方之间系统地使用的解决方案。
话虽如此,如果您特别使用file
和remote-exec
,则可以通过分解出要上传的特定文件和要执行的远程命令来达到目的,在这种情况下,您的资源块将仅包含声明样板,同时避免重复实现细节。例如,如果您有一个导出输出local_file_path
,remote_file_path
和remote_commands
的模块,则可以编写如下内容:
module "provisioner_info" {
source = "./modules/provisioner-info"
}
resource "any" "example" {
# ...
provisioner "file" {
source = module.provisioner_info.local_file_path
destination = module.provisioner_info.remote_file_path
}
provisioner "remote-exec" {
inline = module.provisioner_info.remote_commands
}
}
这是在当前版本的Terraform中排除配置者详细信息的限制。