Deze blog is door een LLM vertaald vanuit het engels.

Het Probleem: ARM Template Groottebeperkingen Bereiken

Twee jaar geleden bouwden we een Bicep deployment systeem dat automatisch alerts creëert op basis van ontdekte resources in onze Azure tenant. De architectuur was clean: een enkele main.bicep file orchestreerde meerdere modules, deployede snel, en werkte prima voor kleinere klanten.

Maar toen we opschaalden naar grotere klanten, liepen we tegen een harde muur: de 4MB ARM template groottebeperking. Ondanks het gebruik van modules om onze Bicep code georganiseerd te houden, werden de gecompileerde ARM templates enorm groot door de overhead die Bicep modules creëren in de uiteindelijke ARM JSON.

Het Complete Mode Dilemma

Onze deployment strategie is gebaseerd op complete mode deployments om ervoor te zorgen dat resource groups exact in sync blijven met onze code. Dit creëert een catch-22 wanneer je grote deployments moet splitsen:

• Enkele grote deployment: Raakt de 4MB limiet
• Meerdere losse deployments: Laatste deployment wint in complete mode, verwijdert resources van eerdere deployments
• Incremental mode: Verliest de garantie dat je resource group overeenkomt met je code

We hadden een manier nodig om onze deployment op te splitsen in meerdere files terwijl we complete mode gedrag behielden over de hele resource group.

Azure Deployment Stacks: De Oplossing

Azure Deployment Stacks lossen dit exacte probleem op. Ze laten je:

1. Meerdere templates deployen naar dezelfde resource group terwijl je complete mode semantiek behoudt
2. Outputs delen tussen stacks zonder complexe parameter passing
3. Dependencies beheren tussen verschillende delen van je infrastructuur

Implementatie: Main Stack met Gedeelde Resources

Onze main stack deployt gedeelde infrastructuur zoals action groups die andere stacks moeten refereren:

 1// Main Stack - Action Group
 2@description('Environment name')
 3param environment string = 'test'
 4
 5@description('Location for resources')
 6param location string = resourceGroup().location
 7
 8@description('Action group name')
 9param actionGroupName string = 'ag-${environment}-alerts'
10
11@description('Email address for notifications')
12param emailAddress string
13
14resource actionGroup 'Microsoft.Insights/actionGroups@2023-01-01' = {
15  name: actionGroupName
16  location: 'Global'
17  properties: {
18    groupShortName: 'alerts'
19    enabled: true
20    emailReceivers: [
21      {
22        name: 'emailReceiver'
23        emailAddress: emailAddress
24        useCommonAlertSchema: true
25      }
26    ]
27  }
28}
29
30@description('Action Group Resource ID')
31output actionGroupId string = actionGroup.id
32
33@description('Action Group Name')
34output actionGroupName string = actionGroup.name

Outputs Refereren in Sub-Stacks

De echte kracht komt van het direct refereren van outputs uit andere deployment stacks:

 1// Refereer naar de main deployment stack om outputs te krijgen
 2resource mainStack 'Microsoft.Resources/deploymentStacks@2024-03-01' existing = {
 3  name: mainStackName
 4}
 5
 6// Haal outputs op van main stack
 7var mainStackOutput = mainStack.properties.outputs
 8var actionGroupId = mainStackOutput.actionGroupId.value
 9
10// Refereer naar bestaande Action Group met output van main stack
11resource existingActionGroup 'Microsoft.Insights/actionGroups@2023-01-01' existing = {
12  name: last(split(actionGroupId, '/'))
13  scope: resourceGroup(split(actionGroupId, '/')[2], split(actionGroupId, '/')[4])
14}

Belangrijkste Voordelen

Groottebeperking Oplossing: Splits grote deployments over meerdere stacks terwijl je onder de 4MB limiet per stack blijft.

Complete Mode Behouden: Elke stack kan complete mode gebruiken, maar ze werken samen om de hele resource group te beheren.

Directe Output Referentie: Geen behoefte om outputs door te geven via parameters of externe storage - refereer ze direct vanuit andere stacks.

Dependency Management: Deploy stacks in volgorde, waarbij latere stacks automatisch bijgewerkte outputs krijgen van eerdere stacks.

Geleerde Lessen

Deployment stacks veranderen fundamenteel hoe je grote Azure deployments architectureert. In plaats van vechten tegen ARM template groottebeperkingen, kun je je infrastructuur ontwerpen in logische chunks die naadloos samenwerken.

De mogelijkheid om outputs direct te refereren tussen stacks elimineert de complexiteit van parameter chains en maakt dependencies expliciet en beheersbaar.

Volgende post: Ik ga behandelen hoe we Bicep User Defined Types (UDTs) gebruiken om deze output-naar-input mapping nog cleaner te maken en betere IDE ondersteuning te bieden.

Reacties