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

问题描述

自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

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

解决方法

您在此描述的内容听起来像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-provider-vsphere可执行文件中放置了Terraform 0.12可以找到并使用它的位置。您可以通过将可执行文件放在以下位置来使该策略适应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 {}块。

automatic-updates out-of-band terraform