När en ändring av ett lagringskonto eller ett nätverk ska ut i Azure vill du kunna granska vad som händer innan distributionen körs. Azure Bicep passar bra när miljön är Azure-baserad, men hur tryggt arbetsflödet blir beror på hur du validerar ändringar och hanterar resurser som inte längre finns i koden.
Bicep ger tydlig Azure-kod, men säker distribution kräver en genomtänkt pipeline
- Azure-fokus: Bicep är ett deklarativt språk för att beskriva Azure-resurser genom Azure Resource Manager.
- Granska först: kör lintning, bygg och what-if innan en ändring distribueras.
- Moduler: dela upp återanvändbara delar, men bestäm hur versioner ska låsas och uppdateras.
- Deployment stacks: kan hantera resurser som en samlad enhet, men har begränsningar som påverkar förhandsgranskningen.
Bicep passar bäst när Azure är den gemensamma nämnaren
Om teamet arbetar nästan uteslutande i Azure slipper du ofta ett extra lager mellan infrastrukturen och plattformens egna resurstyper. Bicep beskriver önskat sluttillstånd deklarativt, och Azure Resource Manager sköter distributionen. Jag tycker att den tydliga kopplingen till Azure är språkets främsta styrka, men den blir också en avgränsning om du vill styra flera moln med samma verktyg.
Jämfört med ARM-mallar i JSON är Bicep lättare att läsa och skriva, samtidigt som filerna kompileras till ARM-mallar vid distribution. Terraform är ett närliggande alternativ när organisationen behöver ett verktyg för flera moln eller vill använda dess ekosystem. Väljer du Bicep bör det vara ett medvetet val av en Azure-nära lösning, inte ett antagande om att samma kod senare flyttas oförändrad till en annan plattform. Microsoft Learn-dokumentationen om Bicep beskriver språket och dess distributionsomfattningar.
En pull request bör fånga fel innan någon trycker på deploy
Ett lyckat bygge säger att Bicep-filen kan kompileras. Det bevisar inte att en ändring blir lämplig i den valda miljön. Därför bör pipeline-stegen ge olika skydd: lintning och bygg fångar kodproblem, medan validering och what-if hjälper teamet att bedöma distributionen.
- Kör Bicep-lintern och bygg filerna i pull requesten. Rätta varningar som pekar på exempelvis saknade beroenden eller olämpliga resursdefinitioner.
- Kör validering mot rätt Azure-omfattning och kontrollera att pipeline-identiteten har de behörigheter distributionen kräver.
- Kör
what-ifoch granska ändringarna, särskilt sådant som kan påverka nätverk, åtkomst eller beständiga data. - Distribuera först efter godkännande och spara resultatet så att ändringen går att följa i efterhand.
Här är det lätt att övertolka förhandsgranskningen. Microsoft beskriver i sin vägledning för what-if olika förändringstyper, däribland Modify, NoChange och Deploy. Det sista betyder att verktyget inte kan avgöra om egenskaper ändras, så resultatet är inte alltid ett entydigt besked om vad som kommer att ske.
För ett litet team räcker ofta ett godkännandesteg efter what-if. Om flera miljöer eller känsliga resurser ingår bör pull requesten dessutom visa vilka parametrar som används, så granskningen gäller rätt miljö och inte bara rätt Bicep-fil.
Moduler hjälper först när gränsen mellan dem är tydlig
En modul kan kapsla in en återanvändbar uppsättning resurser, exempelvis ett lagringskonto med tillhörande inställningar. Den gör huvudfilen mer lättöverskådlig, men för många små moduler kan i stället göra det svårt att följa var parametrar kommer ifrån. Dela därför efter en begriplig ansvarsenhet, inte efter varje enskild resurs.
En lokal modul är smidig när flera delar utvecklas tillsammans i samma kodbas. En modul från ett privat Azure Container Registry passar bättre när team behöver distribuera en gemensam komponent oberoende av applikationsrepo. Microsofts dokumentation om Bicep-moduler beskriver bland annat registry-referenser och hur moduler används.
Bestäm samtidigt hur versionsändringar ska hanteras. Om en produktionsdistribution automatiskt tar den senaste modulversionen kan en ändring i ett centralt bibliotek få följder utan att applikationens egen kod ändras. Lås därför modulversionen i distributionen och uppdatera den genom en granskad ändring.
Deployment stacks har en viktig begränsning vid förhandsgranskning
Det låter tryggt att samla resurser i en deployment stack och låta Azure hantera deras livscykel som en enhet. Men om planen är att först granska ändringar med what-if finns en hake: Microsofts aktuella dokumentation anger att what-if ännu inte stöds direkt för deployment stacks.
Det påverkar särskilt borttagningar. En vanlig what-if-körning kan användas som separat förhandsgranskning, men den visar inte nödvändigtvis exakt samma effekt som när en stack hanterar resurser som inte längre finns i mallen. Microsoft listar också undantag för resurser som Key Vault-hemligheter, vilka stacken inte kan ta bort på vanligt sätt. Se kända begränsningar för deployment stacks innan du låter automatisk rensning ingå i ett produktionsflöde.
| Situation | Trolig följd | Gör så här |
|---|---|---|
What-if visar Deploy i stället för en tydlig egenskapsändring |
Resultatet räcker inte för att avgöra exakt vad som ändras. | Granska resursen och distributionens parametrar innan godkännande. |
| En resurs tas bort ur stackens mall | Stackhantering kan påverka resurser som inte längre deklareras. | Kontrollera stackens hantering av ohanterade resurser och granska listan före distribution. |
| En Key Vault-hemlighet tas bort ur mallen | Stacken kan inte ta bort själva hemligheten på vanligt sätt. | Använd detach-läget där det behövs och hantera borttagningen separat. |
För resurser där oavsiktlig radering vore allvarlig bör stackens rensningsbeteende vara uttryckligt granskat och testat. En fin förhandsgranskning i en parallell distribution är inte en garanti för att stackens slutliga hantering blir identisk.
Parametrar och hemligheter behöver egna skydd
En parameterfil är en bra plats för miljöspecifika värden som region, SKU eller resursnamn. Hemligheter hör däremot inte hemma som vanliga parametrar i kod eller loggar. Märk känsliga outputs med @secure(), och låt hemliga värden hämtas från en lämplig säker källa i stället för att bäddas in i repot.
Microsofts rekommenderade arbetssätt för Bicep tar också upp parameterbeskrivningar, säkra standardvärden och implicita beroenden. I praktiken gör en kort beskrivning av varje parameter det lättare att granska om till exempel produktionsmiljön av misstag får en testinställning eller en oväntat dyr SKU.
När en parameter bara gäller en miljö, håll dess värde utanför den återanvändbara modulen och låt miljökonfigurationen leverera det. Då blir modulens ansvar tydligare, och en ändring för utvecklingsmiljön behöver inte skapa en oavsiktlig produktionsändring.
Bygg arbetsflödet kring den risk som faktiskt finns
Om Azure är den enda plattformen och teamet vill beskriva resurser nära ARM är Bicep ett rimligt val. Om samma IaC-lösning måste omfatta flera moln kan Terraform passa bättre. Jag skulle välja Bicep för en Azure-fokuserad miljö, men bara med versionsstyrda moduler, granskad what-if och tydliga regler för vad som får tas bort.
Börja med en liten, verklig distribution, till exempel ett testresurskonto med nätverksregler. Låt pipeline bygga och validera koden, visa ändringarna i pull requesten och kräva ett aktivt godkännande innan distribution. Då märks det tidigt om teamet har en språkfråga, en behörighetsfråga eller en brist i själva ändringsprocessen.