terraform - 为什么 terraform 会从 Hashicorp 中拉出供应商，我无处声明？

Question

我正在尝试为 terraform 提供程序测试一些新代码，由于我不明白的原因，它似乎想尝试使用 hashcorp 找到资源定义，即使它是在此提供程序中专门定义的。显然我错过了一些东西:
[提供者][1] 的代码:
这就是我构建和安装它的方式:

christianb@unifi terraform-provider-artifactory % rm -fR .terraform                                                               
christianb@unifi terraform-provider-artifactory % go build && mkdir -p .terraform/plugins/registry.terraform.io/jfrog/artifactory/2.2.6-alpha/darwin_amd64 && mv terraform-provider-artifactory .terraform/plugins/registry.terraform.io/jfrog/artifactory/2.2.6-alpha/darwin_amd64

现在运行它

christianb@unifi terraform-provider-artifactory % TF_LOG=trace terraform init
2021/02/25 13:12:56 [INFO] Terraform version: 0.13.5  
2021/02/25 13:12:56 [INFO] Go runtime version: go1.14.10
2021/02/25 13:12:56 [INFO] CLI args: []string{"/usr/local/bin/terraform", "init"}
2021/02/25 13:12:56 [DEBUG] Attempting to open CLI config file: /Users/christianb/.terraformrc
2021/02/25 13:12:56 [DEBUG] File doesn't exist, but doesn't need to. Ignoring.
2021/02/25 13:12:56 [DEBUG] ignoring non-existing provider search directory terraform.d/plugins
2021/02/25 13:12:56 [DEBUG] ignoring non-existing provider search directory /Users/christianb/.terraform.d/plugins
2021/02/25 13:12:56 [DEBUG] ignoring non-existing provider search directory /Users/christianb/Library/Application Support/io.terraform/plugins
2021/02/25 13:12:56 [DEBUG] ignoring non-existing provider search directory /Library/Application Support/io.terraform/plugins
2021/02/25 13:12:56 [INFO] CLI command args: []string{"init"}

Initializing the backend...
2021/02/25 13:12:56 [TRACE] Meta.Backend: no config given or present on disk, so returning nil config
2021/02/25 13:12:56 [TRACE] Meta.Backend: backend has not previously been initialized in this working directory
2021/02/25 13:12:56 [DEBUG] New state was assigned lineage "b7f7e5b9-b88c-6195-aaaf-e38b3008b8e5"
2021/02/25 13:12:56 [TRACE] Meta.Backend: using default local state only (no backend configuration, and no existing initialized backend)
2021/02/25 13:12:56 [TRACE] Meta.Backend: instantiated backend of type <nil>
2021/02/25 13:12:56 [DEBUG] checking for provisioner in "."
2021/02/25 13:12:56 [DEBUG] checking for provisioner in "/usr/local/bin"
2021/02/25 13:12:56 [INFO] Failed to read plugin lock file .terraform/plugins/darwin_amd64/lock.json: open .terraform/plugins/darwin_amd64/lock.json: no such file or directory
2021/02/25 13:12:56 [TRACE] Meta.Backend: backend <nil> does not support operations, so wrapping it in a local backend
2021/02/25 13:12:56 [TRACE] backend/local: state manager for workspace "default" will:
 - read initial snapshot from terraform.tfstate
 - write new snapshots to terraform.tfstate
 - create any backup at terraform.tfstate.backup
2021/02/25 13:12:56 [TRACE] statemgr.Filesystem: reading initial snapshot from terraform.tfstate
2021/02/25 13:12:56 [TRACE] statemgr.Filesystem: snapshot file has nil snapshot, but that's okay
2021/02/25 13:12:56 [TRACE] statemgr.Filesystem: read nil snapshot

2021/02/25 13:12:56 [TRACE] providercache.fillMetaCache: scanning directory .terraform/plugins
2021/02/25 13:12:56 [TRACE] getproviders.SearchLocalDirectory: .terraform/plugins is a symlink to .terraform/plugins
Initializing provider plugins...
2021/02/25 13:12:56 [TRACE] getproviders.SearchLocalDirectory: found registry.terraform.io/jfrog/artifactory v2.2.6-alpha for darwin_amd64 at .terraform/plugins/registry.terraform.io/jfrog/artifactory/2.2.6-alpha/darwin_amd64
2021/02/25 13:12:56 [TRACE] providercache.fillMetaCache: including .terraform/plugins/registry.terraform.io/jfrog/artifactory/2.2.6-alpha/darwin_amd64 as a candidate package for registry.terraform.io/jfrog/artifactory 2.2.6-alpha
2021/02/25 13:12:56 [DEBUG] Service discovery for registry.terraform.io at https://registry.terraform.io/.well-known/terraform.json
2021/02/25 13:12:56 [TRACE] HTTP client GET request to https://registry.terraform.io/.well-known/terraform.json
- Using previously-installed jfrog/artifactory v2.2.6-alpha
- Finding latest version of hashicorp/xray...
2021/02/25 13:12:56 [DEBUG] GET https://registry.terraform.io/v1/providers/hashicorp/xray/versions
2021/02/25 13:12:56 [TRACE] HTTP client GET request to https://registry.terraform.io/v1/providers/hashicorp/xray/versions
2021/02/25 13:12:57 [TRACE] providercache.fillMetaCache: using cached result from previous scan of .terraform/plugins
2021/02/25 13:12:57 [DEBUG] GET https://registry.terraform.io/v1/providers/-/xray/versions
2021/02/25 13:12:57 [TRACE] HTTP client GET request to https://registry.terraform.io/v1/providers/-/xray/versions

Error: Failed to install provider

Error while installing hashicorp/xray: provider registry registry.terraform.io
does not have a provider named registry.terraform.io/hashicorp/xray

terraform 运行:

# Required for Terraform 0.13 and up (https://www.terraform.io/upgrade-guides/0-13.html)
terraform {
  required_providers {
    artifactory = {
      source  = "registry.terraform.io/jfrog/artifactory"
      version = "2.2.6-alpha"
    }
  }
}
provider "artifactory" {
  url = "http://localhost:8082/artifactory"
  username = "admin"
  password = "password"
}

resource "xray_policy" "test" {
  name  = "test-policy-name"
  description = "test policy description"
  type = "security"

  rules {
    name = "rule-name"
    priority = 1
    criteria {
      min_severity = "High"
    }
    actions {
      block_download {
        unscanned = true
        active = true
      }
    }
  }
}

resource "xray_watch" "test" {
  name = "test-watch-name"
  description = "test watch description"
  resources {
    type = "all-repos"
    name = "All Repositories"
  }
  assigned_policies {
    name = xray_policy.test.name
    type = "security"
  }
  watch_recipients = ["test@example.com"]
}

我发现它是基于资源类型的名称 - 所以，它不以 artifactory 开头有所作为。我想知道的是这个查找背后的逻辑
[1]: https://github.com/ryndaniels/terraform-provider-xray

Answer 1

Terraform v0.13 引入了第三方提供者的想法，这些提供者属于不受 HashiCorp 直接控制的其他命名空间，但为了最大限度地向后兼容为 Terraform v0.12 和更早版本编写的模块，Terraform 将提供一种回退行为假设任何未明确声明的提供程序要求旨在使用现在位于注册表中“hashicorp”命名空间中的官方提供程序之一，因为对于 Terraform v0.12 和更早的第三方提供程序根本无法自动安装。
为 Terraform v0.13 或更高版本编写模块时，您应该明确包含 provider requirements为您的模块使用的每个提供程序指定完整的源地址，如下所示:

terraform {
  required_providers {
    artifactory = {
      source = "jfrog/artifactory"
    }
    xray = {
      source = "ryndaniels/xray"
    }
  }
}

不幸的是，在我写这篇文章时，您在这里尝试使用的“xray”提供程序还没有发布在 the Terraform Registry 中。 .源地址 ryndaniels/xray我上面使用的是如果作者按原样将其发布到注册表时此提供程序将使用的地址，因为 Terraform 注册表使用有条不紊的命名方案从 GitHub 存储库地址生成提供程序源地址。
但除非该提供程序稍后在注册表中发布，否则您需要手动将其安装在本地系统上，以便 Terraform 找到并使用它。为此，请参阅 Implied Local Mirror Directories查看 Terraform 在您的平台上搜索插件的目录，然后您可以为 Terraform 创建必要的目录结构以查找提供程序。
作为示例，我将使用 $HOME/.terraform.d/plugins/ Terraform 在 Linux 上支持的前缀，但请注意 Windows 和 macOS 上的路径不同，因此您需要在这些操作系统上调整为不同的路径前缀:

$HOME/.terraform.d/plugins/registry.terraform.io/ryndaniels/xray/0.0.1/linux_amd64/terraform-provider-xray

关于上述内容的更多注意事项:

registry.terraform.io/ryndaniels/xray部分是 Terraform 与 source 匹配的内容您在 provider_requirements 中设置堵塞。 registry.terraform.io是不包含主机名的源地址的默认主机名，所以 ryndaniels/xray是 registry.terraform.io/ryndaniels/xray 的缩写.

此特定提供程序没有任何标记的版本，因此没有要使用的特定版本号。因为 Terraform 期望所有提供者都有一个版本号，所以我随意选择了 0.0.1作为上面路径中的版本号。仅当您编写显式 version 时，这才有意义。模块中的参数以限制允许的版本。

我用了linux_amd64作为此处的目标平台，继续我使用 Linux 样式镜像路径的示例。您可以通过运行 terraform version 找出适合您的平台。 ，在最近的 Terraform 版本中，它包含您的 Terraform CLI 可执行文件所构建的平台的名称:

Terraform v0.14.4
on linux_amd64

在启动时，Terraform 将为您当前的平台扫描所有隐含的本地镜像目录，并记录它在那里找到的任何提供程序，并假设您打算从本地文件系统而不是注册表安装这些提供程序。因此只要目录结构如上正确， terraform init会看到你有 ryndaniels/xray安装在本地，并将使用那里的副本，而不是询问 Terraform Registry 哪些版本可用于该提供程序。
如果提供者作者稍后将此提供者发布到 Terraform 注册表，并且他们这样做没有重命名存储库或将其移动到不同的 GitHub 帐户，它应该在注册表中显示为 ryndaniels/xray因此 terraform init将能够从那里自动安装它，而无需对您的模块进行任何进一步的修改。