In de blogserie neem ik je mee in de wereld van Terraform, Azure DevOps, Azure Repos en Infrastructure as Code (IaC). We gaan in deze blogserie samen infrastructuur uitrollen met behulp van Terraform en Azure Pipelines, waarbij we onze code opslaan in Azure Repos.
Dit gaan we stap-voor-stap doen zodat we aan het einde van de serie een werkende “Continuous Integration / Continuous Deployment” straat hebben staan waarbij onze code met behulp van een GIT repository in Azure Repos staat en automatisch wordt uitgerold via Azure Pipelines op onze Azure omgeving.
In deze eerste blog gaan we beginnen om een stukje basis om deze techniek onder de knie te krijgen. We gaan een resource group en storage account uitrollen op Azure en daarna een kleine aanpassing doorvoeren.
In de opvolgende blogs gaan we verder met Azure Pipelines, Azure Repos en eindigen we de blogserie in het combineren van de twee.
Wat is Terraform?
Terraform is een software oplossing waarmee je cloud omgevingen kunt opzetten en beheren met behulp van “Infrastructure as Code” (IaC). Je definieert je gewenste infrastructuur (Denk aan Virtuele machines, beleidsregels, en Storage accounts) in een configuratie bestand, waarna Terraform ervoor zorgt dat deze staat wordt gerealiseerd op het door jou gekozen (cloud) platform. Hiermee kun je gemakkelijk en met minder kans op menselijke fouten, een volledige infrastructuur creëren.
Terraform is daarnaast een zogenaamde “Idempotente” oplossing. In de Informatica betekent Idempotentie dat het eindresultaat niet wijzigt wanneer dezelfde opdracht (En In dit geval de Terraform configuratie) meerdere malen wordt verzonden. Doordat je configuratie “declaratief” is, vergelijkt Terraform de gewenste met de daadwerkelijke staat en past deze indien nodig aan.
Hebben de Cloud providers hier geen eigen oplossing voor?
Zeker wel! Bij Azure kun je bijvoorbeeld gebruik maken van de ARM-Sjablonen en bij Amazon is dat AWS CloudFormation. Het “nadeel” hiervan is dat ze enkel voor hun eigen cloudomgeving bedoeld zijn. Terraform geeft je een extra abstractie laag waardoor je “Cloud-agnostisch” te werk gaat. Beheers je de Terraform taal? Dan kun je infrastructuur uitrollen op de meeste bekende Cloud providers evenals fysieke infrastructuur. Zie de volledige lijst van “providers” de pagina bij Terraform.
Voorbereiding
We gaan daadwerkelijk software installeren en infrastructuur uitrollen op Azure. Zorg daarom dat je een computer tot je beschikking hebt waar je software op kunt installeren. Heb je geen Azure omgeving tot je beschikking waar je resources uit kunt rollen? Pak dan je credit-card en vraag een Azure trial aan.
Voordat we kunnen beginnen met het uitrollen van de resources, gaan we de benodigde software installeren. We beginnen met de Azure CLI welke we gebruiken om in te loggen bij Azure en de opdrachten te sturen.
Download het Azure CLI installatie pakket via https://aka.ms/installazurecliwindows en installeer deze.
Zodra deze geïnstalleerd is, gaan we verder met Visual studio Code (VS Code). Dit is een gratis en open-source code editor van Microsoft. Deze editor ondersteunt zowel Microsoft, Linux en macOS en zullen we in deze en opvolgende blogs gebruiken om de code te maken.
Ga naar de website https://code.visualstudio.com en download het installatie pakket en voltooi de installatie.
Nu deze klaar is met installeren, gaan we verder met Terraform.
In deze eerste blog draaien we Terraform lokaal en daarom is het noodzakelijk dat we deze installeren. Terraform krijgt regelmatig nieuwe versies. In dit blog maken we gebruik van versie 0.12.28. Ga hiervoor naar https://releases.hashicorp.com/terraform/0.12.28 en download de juiste versie.
Terraform heeft geen installatie zoals Azure CLI en VS Code. In plaats daarvan downloaden we een .zip bestand en pakken we die uit naar C:\Terraform.
De locatie waar we Terraform hebben uitgepakt moeten we toevoegen aan de omgevingsvariabelen van Windows. Open de systeemeigenschappen van Windows door te klikken op start en vervolgens sysdm.cpl in te typen. Klik op het gevonden resultaat.
In het nieuwe Systeemeigenschappen scherm dat naar voren komt, openen we het tabblad Geavanceerd en vervolgens klikken we op omgevingsvariabelen.
In het scherm omgevingsvariabelen selecteren we de variabele Path en klikken we op Bewerken.
Hier voegen we een nieuwe variabele toe door op “Nieuw” te klikken en de folder in te typen waar we Terraform hebben uitgepakt. Dit is C:\Terraform in mijn geval.
Nu we Terraform “geïnstalleerd” staat op de computer, is het tijd om VS Code te starten.
Na het starten gaan we de Terraform plug-in installeren om het typen van de code gemakkelijker te maken. Links klikken we op het “Extensions” icoon en zoeken we op “Terraform”. Er zijn meerdere plugins gemaakt voor en zelfs door Terraform die je kan gebruiken. In dit blog gebruiken we de versie van “Anton Kulikov”. Klik op “install” onder deze plugin om hem te installeren. Dit duurt een paar seconden waarna de plugin is geïnstalleerd en geactiveerd.
VS Code code is er nu bijna klaar voor. Als laatste stap maken we een nieuwe folder aan op de C:\ schijf genaamd “Source” en stellen we deze in als de map waarin VS Code zijn bestanden gaat opslaan. Druk in VS Code linksboven op de “Explorer” knop en klik op “Open Folder”.
Hier maken de nieuwe map aan, selecteren deze en klikken vervolgens op “Map selecteren”
Mooi! We hebben de benodigdheden geïnstalleerd, ingesteld en zijn nu klaar om onze eerste Terraform configuratie file aan te maken, waarmee we ons nieuwe storage account gaan uitrollen.
Klik onder source op new File en geef deze de naam storage-main.tf
Het nieuwe storage-main.tf bestand opent aan de rechterkant. Hier gaan we ons eerste bestand aanmaken. Dit Terraform bestand gaat ervoor zorgen dat we een resource groep aanmaken, met in deze resource group een storage account. Deze komen in de regio West Europa te draaien.
De naam van het storage account moet uniek binnen Azure zijn. (Gebruik dus niet dezelfde naam als in mijn voorbeeld).
Collega Bas van der Kruijssen sprak in de whitepaper “Azure Well Managed” over het Cloud Adoption Framework. Een van de onderdelen is een overzicht met Best Practices voor de naamgeving van resources.
Deze richtlijnen gebruiken we en samen met de limitaties van de naamgeving voor storageaccounts, geef ik hem de naam “stblogweu648343”. De laatste 6 cijfers zijn willekeurig ingetypt.
Dit geeft het volgende eindresultaat:
provider "azurerm" {
version = "~> 2.18"
features {}
}
resource "azurerm_resource_group" "demogroup"{
name = "rg-dev-tfstorage"
location = "West Europe"
tags = {
environment = "dev"
}
}
resource "azurerm_storage_account" "storageaccount"{
name = "stblogweu648343"
resource_group_name = azurerm_resource_group.demogroup.name
location = azurerm_resource_group.demogroup.location
account_tier = "Standard"
account_replication_type = "LRS"
tags = {
purpose = "blog"
}
}Laten we kort de opzet van de code doornemen. Onze code bestaat in dit geval uit 3 blokken. 1 Provider blok en 2 Resource blokken.
Een Provider kun je zien als “plug-in” welke we gaan gebruiken om de configuratie toe te passen. Deze zorgt op de achtergrond dat Terraform weet hoe die moet communiceren met het Azure plaform. De waarde achter version geeft aan welke versie van de plugin gebruikt moet worden. Door deze vast te zetten in de configuratie, voorkom je dat mogelijke wijzigingen in toekomstige versies van de plug-in, onverhoopt problemen veroorzaken.
De resource blokken geven aan welke infrastructuur objecten je wilt creëren. De eerste naam achter resource geeft het type aan. Deze is opgebouwd uit de provider (azurerm), gevolgd door het type resource (storage_group).
Het type resource wordt gevolgd door een naam die enkel Terraform kent. Dit is niet de naam van de resource zoals hij in dit geval in Azure te zien zal zijn.
In het resource blok van het storage account refereren we aan de daarvoor aangemaakt resourcegroup. Hierdoor zorgen we ervoor dat het storage account in de resource group komt en in dezelfde locatie.
In de resource blokken staan enkele instellingen voor deze resources, zoals een naam, locatie en Tags.
Nu we de code hebben gemaakt, gaan we Terraform klaar maken om deze toe te passen op de omgeving. We beginnen door in te loggen binnen Azure via de hiervoor geïnstalleerde Azure CLI. Het Terminal venster is nog niet open. Deze openen we door te klikken op View en vervolgens op Terminal.
In het terminal venster tikken we Az Login en drukken op Enter.
Een browser venster opent en hier loggen we in met ons Microsoft account welke rechten heeft op de Azure omgeving.
Nu het inloggen voltooid is, sluiten we de browser en keren we terug naar VS Code. In het terminal venster zie je informatie voorbij komen van alle Azure abonnementen waar je account rechten op heeft.
Als je meerdere Azure abonnementen tot je beschikking hebt, is het belangrijk om de juiste te selecteren. Hierdoor zorgen we ervoor dat we de resources straks onder het juiste abonnement uitrollen.
We typen az account list –output table in en krijgen zo een nette tabel te zien. In mijn geval is het abonnement “3fifty Production” al mijn standaard en hoef ik niets aan te passen.
Wil je het actieve abonnement wisselen, Typen dan het commando az account set –subscription “3fifty Production”. Hierbij verander je wat tussen haakje staat voor de naam van het abonnement, of het SubscriptionId.
De volgende stap is het “initialiseren” van de Terraform map. Type “terraform init” en druk op enter. Terraform zal ons configuratie bestand doornemen en alle benodigdheden downloaden en klaarzetten.
Nu dat gedaan is, laten we Terraform het “uitvoeringsplan” maken. Terraform vergelijkt in dit geval het configuratie bestand met wat we werkelijk in Azure hebben staan. Omdat zowel de resource group als het storageaccount beide niet bestaan, gaat het plan aangeven dat er 2 resources aangemaakt zullen worden.
We typen nu “Terraform plan” in en drukken op enter. We geven de machine even wat tijd totdat hij klaar is. Uiteindelijk geeft het resultaat “2 to add” weer.
Dat was precies wat we verwachten! Tijd om het daadwerkelijk uit te voeren. We typen nu “Terraform apply -auto-approve” en maken daarmee daadwerkelijk onze resource group en storage account. We wachten totdat Terraform aangeeft dat hij klaar is.
Apply Complete! Althans, dat zegt Terraform. Laten we inloggen op de Azure portal en controleren of er daadwerkelijk een resource group is aangemaakt.
Die staat er, samen met de tag “environment” en we zien daar ons storageaccount staan. Als we deze openen, zien we daar ook netjes onze tag “Purpose”.
Terug naar VS Code. Links bij de bestanden hebben we nu een bestand genaamd terraform.tfstate erbij gekregen. In dit bestand bewaart Terraform de staat van de managed infrastructuur en gebruikt deze bij het maken van een “uitvoeringsplan”. Voor het maken van een plan. Voor elke actie controleert Terraform eerst wat hij “weet” van de omgeving via de statefile, met de daadwerkelijke infrastructuur.
Nu gaan we zonder een wijziging door te voeren aan ons storage-main.tf bestand, nogmaals een terraform plan opdracht uitvoeren.
Het resultaat; “No Changes. Infrastructure is up-to-date”.
Terraform heeft geconcludeerd dat de daadwerkelijke infrastructuur in Azure, hetzelfde is als dat wij hebben gedeclareerd in ons Terraform configuratiebestand.
Wat gebeurd er als we nu een aanpassing doen aan een van de resources?
Om dit te testen voegen we en extra tag toe aan de resourcegroup, namelijk;
Owner = “leonboers@3fifty.eu”
Wanneer we nu terraform plan opnieuw uitvoeren, wordt de nieuwe wijziging gedetecteerd en weergegeven als “1 to change”.
Vervolgens gaan we deze wijziging toepassen via terraform apply -auto-approve en is deze zichtbaar in de portal.
En na een refresh van de portal is hij daar ook zichtbaar.
Wat als iemand de tag aanpast in de Azure Portal? Aangezien de Terraform configuratie declaratief is, gaat de wijziging in de portal overschreven worden..
We passen de “owner” tag aan naar een ander e-mail adres. In dit voorbeeld maar ik er leonboerz@3fifty.eu van.
Wanneer we wederom een Terraform plan uitvoeren, zul je zien dat er weer “1 to change” klaarstaat. In de tekst erboven zie je dat de tag die we net hebben aangepast via de Azure Portal, weer teruggezet zal worden naar wat er in de configuratie staat.
We hebben nu een eerste stap gezet met Terraform door een resource group en een storage account aan te maken. Daarnaast hebben we de Idempotentie van Terraform in actie gezien en de declaratieve eigenschap van Terraform.
In de volgende blog maken we een kleine zijstap en duiken we in Azure Repos en Pipelines voor het uitrollen en onderhouden van IaC.
