Azure IaC door middel van ARM-templating

Posted on Posted in BCONN Nieuws

Veel IT-organisaties worstelen met het probleem van documenteren, iets wat niet bepaald door het bloed van een IT’er stroomt. Waarom combineren we dit dan niet in de techniek? Op die manier blijft het voor de gemiddelde engineer namelijk ook “leuk” en vooral uitdagend!

In mijn vorige blog heb ik het al gehad over het inzetten van Azure DevOps voor het uitrollen van resources naar je infrastructuur. In deze blog zal ik hier wat meer in het (technische) diepe duiken, door in het kort uit te leggen hoe je Azure DevOps en Azure kunt combineren. Want een platform als Azure leent zich natuurlijk uitermate goed voor Infra-as-Code!

Tooling Azure
Allereerst is het goed om te weten dat er diverse manieren zijn om resources naar Azure te deployen. Dit kan door middel van scripts, templates of gewoon door ouderwets via de GUI te klikken. Enkele voorbeelden hiervan zijn:

  • Azure PowerShell
  • Azure CLI
  • ARM Templates
  • Terraform
  • Ansible

ARM Templates
Voor het uitrollen van resources kun je het beste gebruik maken van ARM-templates, deze worden voor nagenoeg alle onderdelen binnen Azure door Microsoft aangeleverd én onderhouden. ARM-templates worden aangeleverd in JSON formaat, waardoor ze makkelijk te bewerken zijn met een editor als Visual Studio Code. Grote voordeel van ARM-templates is dat ze herbruikbaar zijn, je kunt dus eenvoudig veel resources uitrollen met hetzelfde template waardoor ze qua configuratie helemaal gelijk zijn!! Je parameteriseert in een template wat jij wil en levert dit aan via een parameter file, dit bespreken we verderop. Want hoe ziet zo’n template er dan uit? Deze bestaat in feite uit 3 onderdelen:

  • Parameters -> hierin staan de “variabele” delen van het template welke worden gevuld door de parameter file.
  • Variables -> In de variables sectie kun je manipulaties toepassen op bijvoorbeeld parameter waardes.
  • Resources -> hier gebeurt het daadwerkelijke uitrollen van de resources, waarbij we gebruik maken van de parameters die eerder zijn gedefinieerd.

 

Maar hoe ziet zo’n template er in de praktijk dan uit? Onderstaand een voorbeeld voor het uitrollen van een vNet met bijbehorend subnet:

Zoals je kunt zien hebben we in bovenstaand template een aantal zaken geparameteriseerd; de naam van het vNet met prefix en de naam van het subnet met prefix wat we hierin aan willen maken.
De uiteindelijke waardes voor deze template parameters kun je dan mee geven via een aparte parameter file:

Uiteindelijk heb je dus een tweetal bestanden (template- en parameter-file) welke je kunt gaan gebruiken voor jouw deployment. Natuurlijk kun je dit lekker handmatig gaan aftrappen, maar hoe mooi is het als je dit ook nog een geautomatiseerd kunt doen met een tool als Azure DevOps?

 

 

Azure DevOps > Azure
Zoals in mijn vorige blog ook al aangegeven sla je jouw code en/of template op in een Azure Repos (bijvoorbeeld Git). Deze gebruik je dan vervolgens in de CI/CD pipelines (of misschien wel multi-stage?) om uit te rollen richting het platform waar je aan werkt. In het geval wanneer je Azure als hosting platform gebruikt, zul je hier ook een connectie naar toe moeten leggen. Dit kun je doen door middel van een Service connection binnen Azure DevOps, waarbij je een Service Principal aan moet maken binnen Azure met de juiste rechten binnen Azure (op Subscription of Resource Group niveau).

Door middel van deze Service connection kun je vervolgens vanuit jouw (CI)CD pipeline een deployment starten richting Azure, waarbij je de eerder aangemaakte ARM-templates (.json files) gebruikt als input:

In bovenstaand voorbeeld maken we een eenvoudig vNet aan, maar zoals ook eerder vermeld… alles is te deployen vanuit Azure DevOps! Op die manier kun je de gehele Azure infrastructuur vanuit Azure DevOps deployen en beheren en komt er geen regel documentatie aan te pas!!

Uitdagingen
Dat is allemaal leuk en aardig, maar zijn er dan helemaal geen valkuilen?

  • Helaas kunnen we op dit moment nog niet alles “ver-templaten” binnen Azure, denk hierbij aan 3rd party software en/of complexe componenten. In dat geval zul je dus terug moeten vallen op scripts (PowerShell of Azure CLI).
  • Het grote voordeel van generieke templates is ook gelijk een nadeel. Bij een generiek template is het logisch dat deze in de loop van de tijd veel afhankelijkheden creëert. Voornamelijk in een Enterprise-organisatie dien je goede afspraken te maken over het beheer van deze templates!
  • Azure DevOps werkt standaard met Hosted-agents die door Microsoft worden aangeboden, en dus ook in de Microsoft infrastructuur draaien. Wanneer je vanuit Security oogpunt hier bezwaar tegen hebt, kun je ook gebruik maken van Private-agents. Dat resulteert natuurlijk wel weer een extra beheer component!
  • Theoretisch zou je bij gebruik van Azure DevOps alléén “read-only” rechten nodig hebben voor beheerders… maar het blijven natuurlijk beheerders die niet graag zonder God-rechten zitten 🙂

De belangrijkste conclusie is dat wanneer je met IaC op Azure wilt gaan starten, je goed over de strategie na moet denken. Eenmaal gestart met een bepaalde architectuur binnen Azure DevOps, is het niet eenvoudig dit nog te finetunen. Wij als BCONN ICT hebben ruime ervaring met het opzetten van dit soort omgevingen en helpen hier graag bij!

Meer informatie?

Niek Verspaget
Technisch Consultant Modern Datacenter & Cloud
niek.verspaget@bconn.nl