Infrastructuur als Code (IAC) in DevOps Pipelines

Deze blogpost is een hoofdstuk uit het eBook Van Admin tot DevOps: De No-BS Manier om DevOps te doen in Azure. Neem zeker een kijkje als je dieper wilt ingaan op wat er nodig is om succesvol te zijn in DevOps in Microsoft Azure door Infrastructure as Code te leren.

Als je ooit een soort cloud- of virtuele infrastructuur on-premises hebt gemaakt, weet je dat er veel geklikt of getypt moet worden. Infrastructure as Code (IaC) zorgt daarvoor.

Om iets te provisionen, moet je onthouden welk scherm je moet openen of welk commando je moet uitvoeren. Als je gewoon wat aan het spelen bent om Azure te leren, is dat prima, maar zodra dat spelen overgaat in bedrijfskritieke, productieprocessen waar tijd geld is, moet er iets veranderen.

Zodra je organisatie serieus wordt over het provisionen en beheren van infrastructuur, zul je te maken krijgen met veel nieuwe uitdagingen.

Je zult onnodige duplicatie van werk tegenkomen, herhaalde gevallen van typfouten, problemen met veranderingsbeheer, configuratiedrift en meer. Hoe groter de organisatie en het team, hoe groter de problemen. Al deze kwesties kunnen worden geëlimineerd of op zijn minst worden verminderd met een concept genaamd Infrastructure as Code (IaC).

Infrastructure as Code (IaC): Een Voorbeeld

IaC is een branche-term die verwijst naar het opslaan van alles wat nodig is om infrastructuurcomponenten te bouwen in code. Die code is meestal gedefinieerd in JSON- of YAML-bestanden die weergeven hoe jouw infrastructuur eruit zou moeten zien.

Zodra alle componenten zijn gedefinieerd in een gestructureerd bestand, komt er een ander proces langs, begrijpt de code en begint onmiddellijk dat document te gebruiken als instructies om de infrastructuur op te bouwen.

Om een generiek, pseudocode-achtig voorbeeld te geven, stel dat je een VM moet maken. Die VM heeft behoeften zoals rekenkracht, opslag en netwerken. Een ruwe IaC-benadering zou zijn om de VM en al zijn componenten te beschrijven in een sjabloon.

De Sjabloon

In het volgende codefragment kun je een voorbeeld zien van hoe elk component wordt afgebroken door een hiërarchie met attributen die zijn gedefinieerd over elk component. Dit fictieve voorbeeld is gemaakt in een JSON-bestand dat de meeste services een sjabloon zouden noemen.

{
	"VM": {
        "Name": "MYVM",
        "Disk": {
            "Size": "100GB"
        },
        "Networking": {
            "IPAddress" : "10.0.0.1"
        }
    }
}

Deze sjabloon definieert de VM en alle bijbehorende attributen van die VM. Het heeft een specifiek schema waaraan sjabloonmakers zich houden om te definiëren hoe die VM eruitziet. Stel dat deze sjabloon vervolgens wordt opgeslagen in een bestand genaamd myvm.json.

Versiebeheer

Je hebt nu alles wat een VM vormt opgeslagen in één bestand. Zoals elke goede DevOps-professional, controleer je dat bestand in versiebeheer. Je hebt nu een manier om wijzigingen in het bestand bij te houden.

De Tool

Nu het bestand is gemaakt, heb je een tool of service nodig om dat bestand te lezen dat begrijpt wat je probeert te bouwen. Die tool gebruikt de sjabloon als invoer en bouwt de VM volgens die exacte specificaties zonder enige andere interactie.

> [some command line tool] -File myvm.json

Een goede deal, toch? Dat is nog niet alles.

Bestrijden van configuratie-afwijking

Nu stel dat je het statische IP-adres moet wijzigen dat aan die VM’s NIC is toegewezen. Je zou kunnen RDP’en naar de VM en het IP-adres wijzigen, maar dat wil je niet doen. Waarom?

1. Je voert de wijziging handmatig uit, wat tijd verspilt en fouten door mensen mogelijk maakt.
2. Er is geen controletraject van wie het IP-adres heeft gewijzigd en wanneer.
3. Er is geen geautomatiseerde manier om de wijziging ongedaan te maken als je het IP-adres verkeerd invoert.

Infrastructuur als Code (IaC) kan al deze uitdagingen verhelpen. Met, letterlijk, een paar toetsaanslagen, kun je die wijziging maken op een manier waar je manager en auditor dol op zullen zijn.

Open myvm.json, wijzig het IPAddress-attribuut, commit de wijziging naar de broncontrole en voer het gereedschap opnieuw uit. Klaar.

{
	"VM": {
        "Name": "MYVM",
        "Disk": {
            "Size": "100GB"
        },
        "Networking": {
            "IPAddress" : "10.0.0.2"
        }
    }
}

> [some command line tool] -File myvm.json

Het gereedschap weet slim genoeg wat er moet veranderen. Het zal de NIC niet loskoppelen of de hele VM opnieuw opbouwen. Alle IaC-tools en -services zijn slim genoeg om te begrijpen hoe de wijziging moet worden aangebracht. Magie!

Maar nu heb je net gemerkt dat je het verkeerde IP hebt gebruikt en terug moet draaien. Geen probleem. Maak de wijziging ongedaan in de broncontrole, commit, voer het gereedschap uit en je bent weer aan de slag.

Maar wacht, er is meer.

De Beginfase van Continue Levering

Wanneer u infrastructuur opgeslagen heeft in sjablonen onder versiebeheer, heeft u een set ingrediënten voor het starten van een geautomatiseerde release- of continue levering-pijplijn.

Onthoud dat u die tool elke keer moest uitvoeren wanneer u het sjabloon wijzigde. In een geautomatiseerde pijplijn/workflow wordt die tool automatisch uitgevoerd. Zodra het proces om de omgeving te maken of te wijzigen geautomatiseerd is, komt de infrastructuur overeen zodra u een wijziging aan het sjabloon commit.

Bouw genoeg sjablonen en uiteindelijk kan uw gehele infrastructuur vertegenwoordigd worden in code of als code.

Conclusie

IaC is een DevOps-methodologie die operations de mogelijkheid geeft om een bladzijde uit het speelboek van de softwareontwikkelaar te nemen. IaC brengt veel voordelen met zich mee waarvan softwareontwikkelaars al jaren gebruikmaken en geeft die in handen van systeembeheerders.