Azure Blueprints-dən Deployment Stacks-a keçid

Azure Blueprints üçün əsas mesaj sadədir: retirement yalnız “bir gün portal yox olacaq” hadisəsi deyil, mərhələli governance capability erosion prosesidir. Microsoft-un 26 İyun 2026 retirement sənədi göstərir ki, 31 İyul 2026-dan sonra yeni blueprint definition və version yaradıla bilməyəcək, 31 Oktyabr 2026-dan sonra mövcud definition-lar dəyişdirilə və yeni assignment-lar yaradıla bilməyəcək, 31 Dekabr 2026-dan sonra assignment update-ləri də dayanacaq, 31 Yanvar 2027-də isə xidmət tam retire olacaq. Ən kritik məqam odur ki, Blueprint locks, yəni deny assignment-lar retirement-də avtomatik çıxarılacaq. Bu da real idarəetmə boşluğu yarada bilər.

Biznes və platforma təsiri xüsusilə landing zone və governance-heavy tenant-lərdə yüksəkdir. Əgər Blueprints sizin guardrail modelinizin bir hissəsidirsə, retirement zamanı resursların özü qalacaq, amma onları qoruyan management-plane enforcement mexanizmi aradan qalxacaq. Microsoft həm FAQ-də, həm də retirement sənədində recommended replacement kimi iki ayrı capability təklif edir: template specs artifact storage և versioning rolunu, deployment stacks isə assignment, lifecycle və deny-setting rolunu əvəz edir. Başqa sözlə, indiyə qədər Blueprints-in bir obyekt daxilində verdiyi iki işi siz artıq iki məqsədli xidmətlə əvəz etməlisiniz.

Arxitektura və Dəyişikliyin Mahiyyəti.
Deployment Stacks-in məğzi odur ki, resurs kolleksiyasını unit kimi idarə edir, update/delete lifecycle saxlayır və deny settings vasitəsilə Blueprint locks-a ekvivalent management-plane qoruma verir. Template specs isə ARM/Bicep artefaktlarını Azure içində versiyalamağa imkan verir. Migrate blueprint sənədi migration addımlarını açıq verir: blueprint definition JSON-larını export edin, policy assignment, role assignment və deployment artefaktlarını ARM/Bicep sintaksisinə çevirin, sonra lazımdırsa template spec kimi publish edin və onu deployment stack ilə yerləşdirin. Bu split model daha “platform engineering friendly”dir, çünki GitOps, CI/CD və multi-scope deployment-larla daha yaxşı inteqrasiya olunur.

Deny settings tərəfdə deployment stacks bir neçə rejim verir: none, denyDelete, denyWriteAndDelete. Əlavə olaraq stack owner və contributor rolları deny assignment idarəçiliyi baxımından fərqli imkanlar verir. Bu vacibdir, çünki migration zamanı ən böyük səhv Blueprints lock davranışını sadəcə ARM template deployment ilə təkrarlaya biləcəyini düşünməkdir. Əslində deny enforcement üçün deployment stack səviyyəsində ayrıca idarəetmə lazımdır. Child resources üçün müdafiə genişlənməsi də ayrıca parametr və policy dizayn mövzusudur.

Adım-adım Tətbiq və Konfiqurasiya.
Praktik migration ardıcıllığı belə olmalıdır: əvvəl Blueprint definitions və assignments export edilir; sonra artefaktlar vahid Bicep və ya ARM modelinə çevrilir; sonra ya birbaşa deployment stack-dən deploy edilir, ya da əvvəl template spec yaradılıb deployment stack onun üzərindən işlədilir. Microsoft-un migration nümunəsində role assignments, policy assignments və modul əsaslı deployment artefaktlarının eyni Bicep faylında birləşdirilməsi göstərilir. Bu pattern xüsusilə subscription-scope governance üçün çox əlverişlidir.

targetScope = 'subscription'

param principalId string
param policyDefinitionId string
param rgName string = 'lz-network-rg'
param rgLocation string = deployment().location

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid('lz-owner', principalId)
  properties: {
    principalId: principalId
    roleDefinitionId: subscriptionResourceId(
      'Microsoft.Authorization/roleDefinitions',
      'b24988ac-6180-42a0-ab88-20f7382dd24c'
    )
  }
}

resource policyAssignment 'Microsoft.Authorization/policyAssignments@2025-03-01' = {
  name: 'enforceTags'
  properties: {
    policyDefinitionId: policyDefinitionId
  }
}

resource rg 'Microsoft.Resources/resourceGroups@2025-04-01' = {
  name: rgName
  location: rgLocation
}

Deployment stack yaradılması üçün Azure CLI pattern-i belədir. Burada action-on-unmanage və deny-settings-mode migration semantikasının mərkəzində dayanır. Əgər məqsəd əvvəlcə təhlükəsiz keçiddirsə, detachAll və denyDelete kombinasiyası daha konservativ başlanğıcdır.

az stack sub create \
  --name lz-governance-stack \
  --location westeurope \
  --template-file main.bicep \
  --action-on-unmanage detachAll \
  --deny-settings-mode denyDelete \
  --deny-settings-excluded-principals "<objectId1> <objectId2>"

PowerShell tərəfdə eyni semantics New-AzSubscriptionDeploymentStack və ya scope-a uyğun New-AzResourceGroupDeploymentStack ilə verilir. Microsoft-un PowerShell sənədlərində deny mode və action-on-unmanage parametrləri açıq göstərilir.

Mümkün Problemlər və Troubleshooting Ssenariləri.
Ən böyük edge case deny settings və delete semantics-in səhv başa düşülməsidir. Deployment stacks sənədi vurğulayır ki, default davranış unmanaged resursları detach etməkdir; siz ayrıca delete semantics seçməsəniz, stack scope-dan çıxan resurslar fiziki silinməyə də bilər. Digər tərəfdən, remove/update əməliyyatlarında deleteResources və deleteAll sərt nəticələr verə bilər. Platforma komandasının migration əvvəlində konservativ detach yanaşması seçməsi daha rasionaldır.

İkinci problem policy və template error-larıdır. Blueprint artefaktlarını Bicep/ARM modelinə çevirəndə RequestDisallowedByPolicy, InvalidTemplate və ResourceNotFound kimi klassik ARM səhvləri ilə qarşılaşmaq gözləniləndir. Burada ճիշտ yanaşma deployment stack-i günahlandırmaq deyil; əvvəl compiled template-i və scope-u ayrı yoxlamaq, sonra deny layer-i aktiv etməkdir. Microsoft-un ARM troubleshooting sənədləri bu xətt üzrə hərəkəti tövsiyə edir.

Üçüncü problem non-deletable resource-lardır. Deployment stacks known issues sənədində Key Vault secrets kimi bəzi resursların birbaşa silinməsində problemlər ola biləcəyi və bu halda detach mode ilə stack update/delete əməliyyatının daha təhlükəsiz olduğu qeyd olunur. Bu çox vacibdir, çünki governance komandasının “stack silinsin, hər şey də getsin” yanaşması bəzi resurs tiplərində gözlənilməz failure yaradacaq.

Ən Yaxşı Təcrübələr.
Migration-u “definition export”, “artifact conversion”, “template spec publishing”, “stack enforcement” və “deny verification” mərhələlərinə bölün. Retirement tarixindən əvvəl bütün definition və assignment-ları export edin. İlk dalğada detachAll, ikinci dalğada deny enforcement, üçüncü dalğada isə delete management semantics-i aktiv edin. Child-scope deny tələbləri ayrıca sənədləşdirilsin. Və nəhayət, Blueprint-lərin tenant-də harada işlədiyini Azure Advisor və portal inventory ilə çıxarın; bu visibility olmadan migration proqramı yarımçıq qalacaq.