دیپلوی همزمان در چند Azure Subscription با Terraform
خلاصهٔ کاملتر
وقتی سازمانت چند Azure Subscription داره — مثلاً یکی برای توسعه، یکی برای staging و یکی برای production — شاید اول به نظر برسه باید برای هر کدوم یه پروژهی Terraform جداگانه داشته باشی. این یعنی چند state file، چند بار اجرای terraform apply و کلی config موازی که باید همگام نگهشون داری. اما یه راه بهتر وجود داره.
Provider Alias یکی از قابلیتهای Terraformه که بهت اجازه میده چند نمونه از یه provider رو با تنظیمات مختلف در کنار هم تعریف کنی. هر نمونه یه alias (نام مستعار) منحصربهفرد داره و به یه subscription جداگانه اشاره میکنه. وقتی terraform init میزنی، Terraform هر سه session رو همزمان راهاندازی میکنه، نه بهصورت ترتیبی.
در فایل providers.tf اینطوری سه نمونه از provider رو تعریف میکنیم:
provider "azurerm" {
alias = "sub1"
subscription_id = var.subscription_id_1
storage_use_azuread = true
features {}
}
provider "azurerm" {
alias = "sub2"
subscription_id = var.subscription_id_2
storage_use_azuread = true
features {}
}تنظیم storage_use_azuread = true هم به provider میگه که برای احراز هویت به storage از Azure AD استفاده کنه، نه کلیدهای اشتراکی — که در بسیاری از سازمانها به دلایل امنیتی غیرفعاله.
بعد از تعریف provider، کافیه در فایل main.tf هر resource رو با آرگومان provider به نمونهی درستش وصل کنی. مثلاً provider = azurerm.sub1 یعنی این resource باید داخل Subscription 1 ساخته بشه. همین یه خط تکلیف رو روشن میکنه:
resource "azurerm_resource_group" "sub1" {
provider = azurerm.sub1
name = module.naming_sub1.resource_group.name
location = var.location_1
}نکتهی مهم اینه که Terraform اصلاً بین subscriptionها «سوئیچ» نمیکنه. هر سه session بهطور موازی فعالاند و هر resource بر اساس مقدار provider مستقیماً به session مربوطهاش هدایت میشه. تمام اینها هم در یک state file واحد ثبت میشه.
این الگو بهترین گزینهست وقتی تعداد subscriptionهات کم و ثابته و میخوای همه چیز رو از یه جا مدیریت کنی. اگه subscriptionهای زیادی داری یا محیطهات خیلی پویا هستند، بهتره به سراغ Terraform modules با for_each و ارسال صریح provider بری.
نکات کلیدی:
- alias در تعریف provider، یه نمونهی مجزا با تنظیمات اختصاصی میسازه
- provider = azurerm. روی هر resource مشخص میکنه که به کدوم subscription تعلق داره
- هر سه provider instance موازی کار میکنن، نه ترتیبی
- همه چیز در یک state file ذخیره میشه، نیازی به workspace جداگانه نیست
- برای تعداد زیاد subscription یا محیطهای داینامیک، از modules با for_each استفاده کن




