terraform - 强制Terraform仅从本地磁盘安装提供程序，从而禁用Terraform Registry

Question

自1995年以来，我们使用了一种更新机制，

彻底更新并删除了

软件

在内部集中存储所有软件元数据，以管理来自单一事实来源的需求和工件

永远不会任意触发自己。

尽管我们了解terraform已经开始勇敢地重新发明了注册表，但没有任何这些功能，但我们希望完全禁用它。我们当前的工具包仅包含一个插件:

terraform-0.13.0-1.el7.harbottle.x86_64
golang-github-terraform-provider-vsphere-1.13.0-0.1.x86_64

目标是

从不检查注册表

如果未安装给定模块，则

返回错误

我非常感谢您为此提供的良好建议。是否有我忽略的设置，还是我们可以通过告诉它看起来空白处来伪造它？是否有停留在车道上的开关？
澄清:

附加软件包是一个go-build软件包，它提供单个工件/usr/bin/terraform-provider-vsphere而没有其他内容。这对于以前的所有版本都非常有效，并且可能在v13中才开始发挥作用。

更新:这些事情失败了:

terraform init -plugin-dir=/dev/shm

terraform init -get-plugins=false

terraform init -get=false

设置terraform::required_providers::vsphere::source=""

echo "disable_checkpoint = true" > ~/.terraformrc

$ terraform init -get-plugins=false

Initializing the backend...

Initializing provider plugins...
- Finding latest version of -/vsphere...
- Finding latest version of hashicorp/vsphere...

更新:我仍然有点:

rpm -qlp golang-github-terraform-provider-vsphere
/usr/share/terraform/plugins/registry.terraform.io/hashicorp/vsphere/1.14.0/linux_amd64/terraform-provider-vsphere

我觉得我真的很近。/usr/share/位于XDG的默认搜索路径中，它似乎确实找到了该位置，但似乎首先/全部检查了注册表，这是意外的。

Initializing provider plugins...
- Finding latest version of hashicorp/vsphere...
- Finding latest version of -/vsphere...
- Installing hashicorp/vsphere v1.14.0...
- Installed hashicorp/vsphere v1.14.0 (unauthenticated)

Error: Failed to query available provider packages

我们确定它会停止检查它是否具有本地内容，并且默认情况下会执行此操作吗？我没看错吗？

Answer 1

您在此处描述的内容听起来像the Provider Installation settings中的Terraform's CLI configuration file的意图。
具体来说，您可以将提供程序文件放在您选择的本地文件系统目录中–就本例而言，我将随意选择/usr/local/lib/terraform，然后在CLI配置文件中写入以下内容:

provider_installation {
  filesystem_mirror {
    path = "/usr/local/lib/terraform"
  }
}

如果您还没有CLI配置文件，可以将其放在文件 ~/.terraformrc中。
使用以上配置，您的 golang-github-terraform-provider-vsphere-1.13.0-0.1.x86_64包将需要将提供程序的可执行文件放置在以下路径中(假设您使用的是Linux系统): /usr/local/lib/terraform/registry.terraform.io/hashicorp/vsphere/1.30.0/linux_amd64/terraform-provider-vsphere_v1.13.0_x4(上面的文件名是官方的vSphere提供程序版本中的文件名，但是，如果您是从源代码自己构建的，则只要以 terraform-provider-vsphere开头，它的确切名称都没有关系。)
您似乎正在完成从Terraform v0.12升级的过程，因此Terraform也在尝试安装此提供程序的旧版(未命名空间) -/vsphere。由于您不会在本地目录中找到该提供程序，因此安装将会失败，但是由于知道此提供程序已在 hashicorp/vsphere上发布，因此我们可以通过在状态中手动迁移该提供程序来避免这种情况，从而避免Terraform进行推断这会自动在下一个 terraform apply上:

terraform state replace-provider 'registry.terraform.io/-/vsphere' 'registry.terraform.io/hashicorp/vsphere'

运行此命令后，您的最新状态快照将不再与Terraform 0.12兼容，因此，如果您选择中止升级并返回到0.12，则需要从备份中还原以前的版本。如果您的州没有存储在自然保留历史版本的位置，则获得这种备份的一种方法是使用Terraform 0.12可执行文件运行 terraform state pull并将结果保存到文件中。 (默认情况下，Terraform推迟执行此操作，直到 terraform apply为止，以避免升级状态格式，直到它无论如何都要进行其他更改为止。)

如果您希望将来对Terraform的所有使用都做到这一点，则上面的 provider_installation配置是一个答案，这似乎是您的目标，但出于完整性考虑，我还想指出，以下命令应以与结果等效的方式运行如果要仅对 terraform init的特定调用强制本地目录，请执行上述配置: terraform init -plugin-dir=/usr/local/lib/terraform
由于您似乎要从Terraform 0.12升级，因此您可能还想知道 Terraform 0.13's default installation behavior(无任何特殊配置)与Terraform 0.12相同，不同之处在于现在期望使用与以前不同的本地目录结构来表示分层提供程序命名空间。 (也就是说，要区分 hashicorp/vsphere和假设的 othernamespace/vsphere。)
具体来说，Terraform 0.13(与Terraform 0.12一样)将跳过与远程注册表的联系，以免其可以发现本地文件系统中至少一个可用版本的任何提供程序。
听起来您的代表提供者的软件包以前在Terraform 0.12可以找到和使用它的地方放置了 terraform-provider-vsphere可执行文件。您可以通过将可执行文件放在以下位置来使该策略适应Terraform 0.13: /usr/local/share/terraform/plugins/registry.terraform.io/hashicorp/vsphere/1.30.0/linux_amd64/terraform-provider-vsphere_v1.13.0_x4(同样，此处的确切文件名并不重要，只要它以 terraform-provider-vsphere开头即可。)
此处的 /usr/local/share假设是 the XDG Base Directory specification的默认数据目录之一，但是如果您的系统上覆盖了 XDG_DATA_HOME/ XDG_DATA_DIRS，则Terraform应该尊重这一点并查看您列出的其他位置。
假设您没有使用显式的 provider_installation块覆盖默认行为，则该文件的存在将导致Terraform的行为就像您在CLI配置中编写了以下内容一样:

provider_installation {
  filesystem_mirror {
    path    = "/usr/local/share/terraform/plugins"
    include = ["hashicorp/vsphere"]
  }
  direct {
    exclude = ["hashicorp/vsphere"]
  }
}

这种形式的配置仅强制为 hashicorp/vsphere提供程序进行本地安装，从而模仿了Terraform 0.12使用本地插件文件 terraform-provider-vsphere会执行的操作。您可以获得更彻底的行为，从不使用与我打开此答案所用的配置类似的配置联系远程注册表，而该配置根本不包含 direct {}块。