Azure DevOps流水线中Terraform Plan/Apply任务执行停滞问题排查求助
首先,我注意到你的Terraform配置里有一个明显的错误,这可能是导致问题的诱因之一,先修正这个:
在azurerm_app_service资源定义中,resource_group_name字段错误地引用了azurerm_app_service_plan.dev.location,应该改为引用资源组名称:
resource "azurerm_app_service" "dev" { name = var.appservicename location = azurerm_app_service_plan.dev.location resource_group_name = azurerm_app_service_plan.dev.resource_group_name # 修正此处 app_service_plan_id = azurerm_app_service_plan.dev.id }
接下来针对流水线停滞的问题,从日志和配置来看,有几个关键排查点:
1. 工作目录配置错误(最可能的原因)
从你的日志中可以看到:workingDirectory=C:\hostedtoolcache\windows\terraform,这个路径是Azure DevOps托管代理中Terraform工具的安装目录,根本没有你的Terraform配置文件。Terraform找不到tf文件时,会陷入无输出的停滞状态。
解决方法:
在Azure DevOps的Terraform任务(Plan/Apply)中,找到"Working Directory"配置项,设置为你的Terraform文件所在的路径。比如如果你的tf文件在代码仓库的terraform子目录下,应该填写:
$(System.DefaultWorkingDirectory)/terraform
可以先添加一个命令行任务验证路径是否正确:
cd $(System.DefaultWorkingDirectory)/terraform dir
确保能看到webapp.tf和var.tf文件。
2. Terraform状态存储的权限问题
你的配置使用了Azure Blob Storage作为Terraform后端存储状态文件,流水线使用的服务主体(日志中environmentServiceNameAzureRM对应的服务主体)需要拥有该存储账户的Storage Blob Data Contributor权限,否则无法读取/写入状态文件,导致任务停滞。
解决方法:
- 登录Azure Portal,找到你的Terraform状态存储账户
- 进入Access Control (IAM) → 添加角色分配
- 选择角色
Storage Blob Data Contributor,将其分配给流水线使用的服务主体
3. 禁用Terraform Init的风险
你提到禁用了Terraform Init任务,但Init是Terraform初始化后端和provider的必要步骤,尤其是第一次运行或后端配置有变化时。禁用Init会导致Terraform无法正确连接状态存储或初始化Azure provider,进而停滞。
解决方法:
重新启用Terraform Init任务,并确保正确配置后端参数(比如将__terraformstorageaccount__替换为实际的存储账户名称,可以通过流水线变量或替换令牌实现)。
4. 服务主体资源权限不足
流水线使用的服务主体需要拥有足够的权限在目标订阅中创建资源组、App Service Plan和App Service。如果权限不足,Terraform会卡在资源创建步骤,无明显输出。
解决方法:
给服务主体分配Contributor角色到目标订阅(或预先创建的资源组),确保它能执行所需的资源操作。
5. 变量传递验证
确保所有var.tf中定义的变量都在Azure DevOps流水线变量中正确配置,并且Terraform任务能正确读取这些变量。可以通过在Terraform任务中添加-var参数显式传递,或者利用Terraform自动读取TF_VAR_前缀环境变量的特性(比如将流水线变量client_id映射为环境变量TF_VAR_client_id)。
按照以上步骤排查后,应该能解决Terraform任务停滞的问题。
内容的提问来源于stack exchange,提问作者Pallab

