Een van de uitdagingen in standaard Azure Resource Manager (ARM) deployments is dat resources kunnen worden toegevoegd of gewijzigd, maar oude resources niet kunnen worden verwijderd. Dit kan leiden tot overbodige kosten, bijvoorbeeld door ongebruikte databases die blijven bestaan. Met de standaard Azure-tools was het moeilijk om deze overbodige resources automatisch te verwijderen. Vaak wijken we hiervoor uit naar tools zoals Teraform, die de state tussen deployments bij houdt. Maar deze tools lopen vaak technologisch achter, brengen extra kosten en vragen extra configuratie.
Wat zijn Azure Deployment Stacks?
Hier komen Azure Deployment Stacks om de hoek kijken. Azure Deployment Stacks houden bij wat er tijdens een deployment is aangemaakt en welke resources gebruikt worden. Hierdoor kunnen ze bij een nieuwe deployment detecteren welke resources niet meer nodig zijn en deze automatisch verwijderen. Dit maakt het beheer van resources efficiënter en voorkomt onnodige kosten. Dit alles kan met je bestaande ARM of Bicep templates en minimale aanpassingen aan je CI/CD pipeline.
Daarnaast brengen Deployment Stacks ook mogelijkheden om je resources te beschermen tegen verwijderen en zelfs tegen configuratie aanpassingen. Dit voorkomt dat die database die je dacht te hebben weggegooid, toch per ongeluk in productie is. Of dat die web app die je uit had gezet, toch nog gebruikt wordt.
Gebruikersrechten en Azure Deployment Stacks
Een belangrijke functie van Azure Deployment Stacks is het beheer van gebruikersrechten. Om per ongeluk verwijderde resources te voorkomen, of inconsistentie in omgevingen, wil je graag aangeven wie welke rechten heeft.
Dit doe je door de ‘deny-settings-mode’ tijdens de deployment in te stellen. De opties zijn:
none
Doe niks, de resources mogen verwijderd en bewerkt worden.
denyDelete
Blokkeer het verwijderen van resources, maar de dingen als een SKU (bijvoorbeeld “Standard_S1” voor webapps) kunnen nog steeds worden aangepast.
denyWriteAndDelete
Blokkeer het verwijderen en aanpassen van resources.
Een deployment van een template ziet er dan als volgt uit:
az stack group create --name 'stack3' --resource-group 'stacks' --template-file './originals/deployment_3.bicep' --deny-settings-mode denyWriteAndDelete
Praktische voorbeelden van Azure Deployment Stacks
Laten we een praktisch voorbeeld bekijken van hoe Azure Deployment Stacks werken binnen een project.
In een van onze projecten, genaamd Serverless Benchmark, meten wij de cold en warm start performance van verschillende run times in Azure Functions.
In basis werkt de app vrij simpel, een Azure Function genaamd de “Test Runner” doet 1 keer per uur een request naar een test Azure Functions en houdt bij hoelang dit duurt. Dit is de “cold-start” tijd. Na 20 seconden voert de Test Runner nog een aantal requests uit, om te bepalen hoelang een request duurt als er al een instance beschikbaar is. Dit is de “warm-start” tijd.
Om te bepalen welke test apps moeten worden aangeroepen, kijkt de Test Runner naar een app configuration service waarin de tests op deployment zichzelf aan de configuratie toevoegen. Nadat de Test Runner klaar is met een test ronde, schrijft deze de resultaten weg in Table Storage. De Api kan deze vervolgens weer oppakken en aan de gebruiker serveren. Dit alles ziet er ongeveer zo uit.
Ieder wit blok in dit figuur is een losse deployment. In het Azure portal ziet dat er zo uit:
Iedere test en de core app hebben hun eigen deployment stack.
Als we in een van de tests kijken, zien we dat we heel veel keyvalue pairs in de app ‘configuration service’ hebben, maar niet de app configuration service zelf. Dit komt omdat het bicep template dat wordt gebruikt een ‘existing’ keyword gebruikt bij de referentie naar de app configuration service. Hierdoor wordt de app configuration service niet aangepast en wordt het dus geen resultaat van de deployment.
Dit heeft voor ons als voordeel dat, mocht een test offline moeten worden gehaald (bijvoorbeeld omdat de .NET versie End Of Life is), is het zo simpel als de deployment stack weggooien. En we kunnen meteen alle resources voor die specifieke test, inclusief de configuratie weghalen.
Conclusie: Waarom Azure Deployment Stacks mijn leven makkelijker maken
Voor mij maakt deze aanpak het werk niet alleen efficiënter, maar ook betrouwbaarder. Je hoeft je geen zorgen meer te maken over inconsistenties tussen verschillende omgevingen of overbodige kosten door ongebruikte resources. Azure Deployment Stacks bieden de flexibiliteit en controle die je nodig hebt om meer succesvolle en kostenefficiënte deployments uit te voeren.
Heb je vragen over dit stuk, of ben je benieuwd hoe wij jouw leven makkelijker kunnen maken met onze slimme Azure oplossingen? Neem contact met ons op.
