Infrastructure as Code testing

Introductie

Infrastructuur testen als code: een beginnershandleiding
Dit bericht is voor testers die meer willen weten over het testen van Infrastructure as Code en een diepgaande uitbreiding willen hebben van hun cloud technische skills op het gebied van testen.

Infrastructure as Code Testing

Ik heb ruim 20 jaar als functioneel/technisch tester/manager gewerkt in verschillende rollen. Naast eigenaar werk ik sinds 2 jaar als tester binnen een DevOps-team bij een klant, waar we o.a. AWS stacks moeten onderhouden. Doordat ik een SDET ben, en een hoge mate van interesse heb in techniek ben ik in aanraking gekomen met de AWS CDK en de wereld van Infrastructure as code. Ons team integreert alle codewijzigingen in het product en implementeert een gedistribueerde stack die teams bijv. kunnen gebruiken voor integratietesten/ applicatieve testen. Mijn team is deels verantwoordelijk voor het implementeren van de infrastructuur en we testen nu middels een 2 ogen principe of de implementatie goed is verlopen zodat we het kunnen gebruiken. We voeren controles na de implementatie uit, lossen infrastructuurproblemen op en voeren een beperkte reeks tests uit.

Wat houdt dat nou in

Stel je hebt gedistribueerde applicaties die over verschillende delen van de infrastructuur bestaat - meerdere servers, containers, lambda’s, cloudservices, databases, enz. Het creëren van een dergelijke gedistribueerde infrastructuur is een vervelend en foutgevoelig proces. Wijzigingen aanbrengen is nog moeilijker. De meeste softwareteams slaan in dergelijke situaties hun infrastructuur liever op als code. Dit maakt het implementatieproces voorspelbaarder en minder foutgevoelig. Het geeft vertrouwen dat als iets niet werkt zoals verwacht, je altijd terug kunt draaien. Door uw infrastructuur als code op te slaan, krijgt het hele team meer inzicht en kun je sneller wijzigingen aanbrengen. Infrastructure as Code gebruik van beschrijvende talen en door mensen leesbare formaten – YAML, JSON, etc. Denk bijv. bij AWS aan Cloudformation templates. Je hebt wel tools als Terraform, Ansible en AWS CDK overigens nodig om die templates te genereren, aangezien handmatig dit erg complex en error-prone is.

Wanneer wordt Infrastructure as Code testing belangrijk

Naarmate het aantal integraties en ketens groeit, is dit handmatige proces tijdrovend. De kans op menselijke fouten neemt toe en het vergt vaak veel communicatie en stakeholdermanagement om zaken op te lossen En het ergste van alles, het is omslachtig! Dus de oplossing die de tech industrie heeft bedacht, is om infrastructuur op te slaan als code.

Voor management: Waarom is het testen van infrastructure as code belangrijk:

Pijlers zijn complexiteit,tijd en foutgevoeligheid

Het inrichten van infrastructuur met verschillende componenten is een complex proces. Bedrijven geven enorm veel geld uit om meerdere omgevingen te bouwen. De testteams voeren hun integratietests uit op deze geïmplementeerde infrastructuur. Hoe vaak hoor ik wel niet dat de connectiviteit van A naar B niet op orde is. Dat kan met allerlei oorzaken te maken hebben, zoals een afhankelijkheid van een on-premise applicatie waarop een nog complexer en tijdrovend change management proces is opgetuigd.

Maar als de uitgangssituatie is dat je eigenaar bent van de infrastructuur en implementeert zonder te testen, is de kans groot dat testteams bugs opmerken vanwege een slechte implementatie. Dit verspilt de tijd van alle betrokken teams!

Wat kan er dan zowel misgaan:
-Connectiviteit issues, bijv. rest apis die niet goed opgezet zijn.
-Security checks die verkeerd geïmplementeerd zijn waardoor je je lambda functie en bijv een server niet kan bereiken
-Poorten, SLL etc die niet goed opgezet zijn.

Het testen van de infrastructuur zal een sleutelrol spelen bij het verminderen van problemen met betrekking tot slechte implementaties en verkeerde configuraties. Dit geeft de testers het vertrouwen dat ontdekte problemen te wijten zijn aan de toepassing en niet aan de omgeving. Aangezien het testen van de infrastructuur en de kwaliteit van de implementatie veel tijd bespaart van alle betrokken teams, is het economisch zinvol om deze stap goed uit te voeren.

Het testen van de infrastructuur zal een sleutelrol spelen bij het verminderen van problemen met betrekking tot slechte implementaties en verkeerde configuraties. Dit geeft de testers het vertrouwen dat ontdekte problemen te wijten zijn aan de toepassing en niet aan de omgeving. Aangezien het testen van de infrastructuur en de kwaliteit van de implementatie veel tijd bespaart van alle betrokken teams, is het economisch zinvol om deze stap goed uit te voeren.

In een ander blog geef ik een samenvatting van de populaire tools voor static code checks, deployment, unit testing voor verficatie en validatie, en locale “systeem test” met een mock om te zien of de infrastructure goed is opgezet als proces

Ervaring als DevOps-tester

Ik heb dit document voor mezelf beschreven heb om voor mezelf de kennis op te doen wat nodig is om infrastructuur te testen in mijn geval AWS CDK met jest en AWS Rspec. Echt gebruikt heb ik het nog niet in de praktijk, maar ik heb wel een R&D trajectje ermee gedaan. Mijn gevoel is dat de niche die ik nu test potentieel heeft aangezien ik zie dat heel organizaties hier mee struggelen. Een nog grotere verbetering zou zijn om vanuit die infrastructure reallive praatplaten te genereren voor commmunicatie Ik wil mijn ervaringen delen voor het geval het andere mensen ten goede komt die misschien ook interesse hebben willen wisselen.

Zelf kan inmiddels ook CDK apps creeren en zou ook als een devops developer mee kunnen werken in het bouwen van stacks (javascript). Dat moet je uberhaupt begrijpen om de testen te kunnen maken. Tevens ben ik bezig met een AWS developer certificate om infrastructure zaken beter te snappen. Als je de waarom vraag niet begrijpt, wat ik studenten en medewerkers uitleg dan zal je nooit goed kunnen testen. of dat nu functioneel, automatisch testen of infra betreft. Ik denk dat ik nu wel de kennis heb om infra te kunnen testen en ook tevens management uit te leggen waarom het belangrijk is. Maar al met al ben ik nog steeds lerende