Terraform AzureRM Provider版本集中化管控咨询：无需PowerShell的替代实现方案

Great question! Ditching external scripts like PowerShell for version management is totally achievable using native Terraform features. Here are the most practical approaches tailored to your scenario of split component pipelines:

1. Centralized Version Variable with Shared tfvars File #

This method lets you define the provider version once in a single file, then reference it across all your component configurations—no string replacement needed.

Step 1: Create a shared variable file #

In a common location accessible to all your pipeline components (e.g., a configs directory in your repo), create a common.tfvars file:

azure_rm_version = "3.74.0" # Update this value once to sync all components

Step 2: Reference the variable in each component's provider block #

In every component's Terraform config, define a variable and use it in the provider block:

variable "azure_rm_version" {
  type        = string
  description = "Fixed version for the AzureRM provider"
}

provider "azurerm" {
  version                   = "=${var.azure_rm_version}"
  skip_provider_registration = true
  features {}
}

Step 3: Pass the tfvars file in your pipeline steps #

When running terraform plan or apply for each component, include the shared variable file:

terraform plan -var-file=../configs/common.tfvars
terraform apply -var-file=../configs/common.tfvars

This keeps version control centralized—update the common.tfvars once, and all components pick up the new version on their next pipeline run.

2. Shared Provider Module #

If your components are structured as Terraform modules, you can create a reusable provider module that enforces the version, then reference this module in every component.

Step 1: Build the shared provider module #

Create a module (e.g., modules/azure-providers) with the fixed provider definition:

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "=3.74.0" # Centralized version here
    }
  }
}

provider "azurerm" {
  skip_provider_registration = true
  features {}
}

Step 2: Reference the module in each component #

In every component's config, call the shared provider module:

module "azure_providers" {
  source = "../modules/azure-providers"
}

# Rest of your component resources (e.g., App Service, SQL DB)

Terraform will inherit the provider version from the shared module, so you only need to update the version in one place to sync all components.

3. Terraform Cloud/Enterprise (For Team Environments) #

If your team uses Terraform Cloud or Enterprise, you can set organization-level provider version constraints that apply to all workspaces (each component can be a separate workspace). This removes the need to manage versions in code entirely—you set the version once in the Terraform Cloud UI, and all workspaces adhere to it.

Key Benefits of These Approaches #

• No external tools: All logic uses native Terraform functionality
• Single source of truth: Update versions in one place instead of every component
• Auditability: Version changes are tracked in your repo (for tfvars/module methods) or Terraform Cloud logs

For your scenario of independent component pipelines, the shared tfvars file is probably the simplest to implement right away, since it doesn't require restructuring your existing component configs into modules.

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