Azure上用Terraform部署azurerm_data_factory_linked_service_azure_databricks报错求助

问题诊断 #

你的配置存在三个核心问题：

1. Databricks工作区引用错误：使用了databricks_workspace（名称）而非官方要求的databricks_workspace_id（资源ID），导致ADF无法定位目标工作区。
2. 缺少必要的认证配置：ADF访问Databricks工作区必须提供合法的认证方式，你的配置完全缺失认证块，触发参数验证失败。
3. 冗余参数冲突：linked_service_name并非该Terraform资源的合法参数，与name字段重复定义会导致配置无效。

修正后的配置示例 #

以下是使用服务主体认证的完整有效配置，你可以根据实际认证方式调整：

resource "azurerm_data_factory_linked_service_azure_databricks" "example" {
  name                    = "exampleDatabricksLinkedService"
  data_factory_id         = azurerm_data_factory.example.id
  databricks_workspace_id = azurerm_databricks_workspace.example.id

  # 服务主体认证（生产环境常用方式）
  authentication {
    type           = "ServicePrincipal"
    client_id      = "<你的服务主体Client ID>"
    client_secret  = "<你的服务主体Client Secret>"
    tenant_id      = "<你的Azure租户ID>"
  }

  # 可选：指定实例池或现有集群ID，二选一即可
  instance_pool_id = azurerm_databricks_instance_pool.example.id
  # cluster_id = "<现有Databricks集群ID>"
}

关键配置说明 #

• 工作区引用：必须使用databricks_workspace_id关联Databricks工作区的资源ID，不能用名称。
• 认证方式：支持三种主流认证类型：
  • ServicePrincipal：需要提前创建有权限访问Databricks工作区的服务主体。
  • ManagedServiceIdentity：使用ADF的系统分配或用户托管身份，需确保该身份已被授予Databricks工作区权限。
  • AccessToken：使用Databricks个人访问令牌（适合测试场景）。
• 资源名称：仅需通过name字段定义链接服务的名称，移除多余的linked_service_name参数。

额外检查项 #

• 确认用于认证的身份（服务主体/托管身份）已被添加到Databricks工作区的访问控制列表中，至少拥有Contributor级别权限。
• 验证Databricks工作区与ADF处于同一Azure租户，且网络连接正常（无防火墙/NSG限制）。

内容的提问来源于stack exchange，提问作者Nature