强制 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

目标是

1. 从不检查注册表
2. 如果未安装给定模块，则返回错误

我将非常感谢为此提供好的建议。是否有我忽略的设置，或者我们可以通过告诉它看起来某个地方是空的来伪造它吗？是否有 -stay-in-your-lane 开关？

澄清：

• 附加包是一个 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

你所描述这里听起来像是意向的供应商安装设置在Terraform的CLI配置文件。

具体来说，您可以将您的 provider 文件放在您选择的本地文件系统目录中——为了这个例子，我将任意选择/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 state pull使用 Terraform 0.12 可执行文件运行并将结果保存到文件中。（默认情况下，Terraform 会推迟执行此操作，terraform apply以避免升级状态格式，直到它无论如何都会进行其他更改。）

provider_installation上面的配置是一个答案，如果你想在所有未来使用 Terraform 时实现这一点，这似乎是你在这里的目标，但为了完整起见，我还想注意以下命令的行为应该与结果相同如果您只想为以下特定调用强制使用本地目录，请使用上述配置terraform init：

terraform init -plugin-dir=/usr/local/lib/terraform

由于您似乎是从 Terraform 0.12 升级，因此您可能还想知道Terraform 0.13 的默认安装行为（没有任何特殊配置）与 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这里假设XDG 基本目录规范中的默认数据目录之一，但是如果您在系统上有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 {}块。