强制Terraform只从本地磁盘安装提供程序，禁用Terraform注册表

Question

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

• 干净地更新和删除软件
• 在内部集中存储所有软件元数据，以管理来自单一真相源的需求和工件。
• 不会任意触发自己。

尽管我们了解到，地形已经开始在没有任何这些功能的情况下勇敢地重新创造出一个注册表，但我们希望完全禁用它。我们目前的工具包只包含一个插件：

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

目标是

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

为此，我将非常感谢大家提出好的建议。有没有我忽略的设置，或者我们可以通过让它去找一个空的地方来假装它？在你的车道上有开关吗？

澄清：

• 外接程序包是一个去构建包，它只交付一个工件，/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

您在这里描述的内容听起来像是提供程序安装设置 in Terraform的CLI配置文件的意图。

具体来说，您可以将提供程序文件放在您选择的本地文件系统目录中--为了本例，我将任意选择/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开头，它的确切名称就无关紧要了。)

看起来您正在完成Terraformv0.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，则需要从备份恢复以前的版本。如果您的状态没有存储在自然保留历史版本的位置，那么获得这种备份的一种方法是使用Terraform0.12可执行文件运行terraform state pull并将结果保存到文件中。(默认情况下，Terraform会将此操作推迟到terraform apply，以避免升级状态格式，直到它做出其他更改。)

上面的provider_installation配置是一个答案，如果您想在以后所有Terraform的使用中实现这一点，这似乎是您在这里的目标，但为了完整起见，我还想指出，如果您希望强制本地目录只针对特定的terraform init调用，那么下面的命令的行为方式应该与上述配置的结果相当。

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

由于您似乎正在从Terraform0.12升级，您可能还会感兴趣地知道，Terraform 0.13的默认安装行为 (没有任何特殊配置)与Terraform0.12是相同的，除了现在期望有一个与以前不同的本地目录结构来表示分层提供程序命名空间。(也就是说，将hashicorp/vsphere与假想的othernamespace/vsphere区分开来。)

具体来说，Terraform0.13(与Terraform0.12一样)将跳过与任何提供者的远程注册表联系，因为它可以在本地文件系统中发现至少一个可用的版本。

听起来，表示提供者的包之前在Terraform0.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在这里假设了来自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提供程序进行本地安装，从而模仿Terraform0.12对本地插件文件terraform-provider-vsphere所做的操作。您可以获得更彻底的行为，即永远不与远程注册中心联系，使用像我打开这个答案那样的配置，这一点根本不包括direct {}块。