Marathon<\/a><\/noindex>\u00a0<\/li>\n<\/ul>\n<\/p>\n
7. Infrastruktur som kod (IaC)<\/h2>\n
<\/p>\n
Kort beskrivning av tekniken<\/h3>\n
\n Och h\u00e4r har vi kommit till den sista delen. Vanligtvis faller denna teknik och relaterade uppgifter utanf\u00f6r ansvarsomr\u00e5det f\u00f6r automatiseringsingenj\u00f6rer. Och det finns anledning till det. F\u00f6r det f\u00f6rsta ligger infrastrukturella fr\u00e5gor under DevOps-avdelningens kontroll i m\u00e5nga organisationer, och utvecklingsteamet bryr sig inte s\u00e5 mycket om vad som driver pipeline eller hur man ska underh\u00e5lla allt som h\u00f6r till den. F\u00f6r det andra, l\u00e5t oss vara \u00e4rliga, praktiken \"Infrastruktur som kod (IaC)\" till\u00e4mpas fortfarande inte i m\u00e5nga f\u00f6retag. Men det har definitivt blivit en popul\u00e4r trend och det \u00e4r viktigt att f\u00f6rs\u00f6ka vara involverad i de relaterade processerna, metoderna och verktygen. Eller \u00e5tminstone h\u00e5lla sig informerad om vad som h\u00e4nder.<\/p>\n
L\u00e5t oss b\u00f6rja med motivationen f\u00f6r att anv\u00e4nda detta tillv\u00e4gag\u00e5ngss\u00e4tt. Vi har redan diskuterat att f\u00f6r att k\u00f6ra tester i GitlabCI beh\u00f6ver vi minst resurser f\u00f6r att k\u00f6ra Gitlab Runner. Och f\u00f6r att starta containrar med webbl\u00e4sare\/emulatorer m\u00e5ste vi reservera en VM eller en kluster. F\u00f6rutom resurserna f\u00f6r testning beh\u00f6ver vi \u00e4ven betydande kapacitet f\u00f6r att uppr\u00e4tth\u00e5lla utvecklings-, staging- och produktionsmilj\u00f6er, vilket \u00e4ven inkluderar databaser, automatiska scheman, n\u00e4tverkskonfigurationer, lastbalanserare, anv\u00e4ndarr\u00e4ttigheter och s\u00e5 vidare. Det centrala problemet \u00e4r de n\u00f6dv\u00e4ndiga insatserna f\u00f6r att st\u00f6dja allt detta. Det finns flera s\u00e4tt att g\u00f6ra \u00e4ndringar och implementera uppdateringar. Till exempel, i kontexten av GCP kan vi anv\u00e4nda UI-konsolen i webbl\u00e4saren och utf\u00f6ra alla \u00e5tg\u00e4rder genom att klicka p\u00e5 knappar. Ett alternativ kan vara att anv\u00e4nda API-anrop f\u00f6r att interagera med molnentiteter eller att anv\u00e4nda kommandoradsverktyget gcloud f\u00f6r att utf\u00f6ra n\u00f6dv\u00e4ndiga manipulationer. Men med en verkligt stor m\u00e4ngd olika entiteter och infrastrukturkomponenter blir det sv\u00e5rt eller till och med om\u00f6jligt att utf\u00f6ra alla operationer manuellt. Dessutom \u00e4r alla dessa manuella \u00e5tg\u00e4rder okontrollerade. Vi kan inte skicka dem p\u00e5 granskning innan de genomf\u00f6rs, anv\u00e4nda versionskontrollsystem och snabbt \u00e5terst\u00e4lla \u00e4ndringar som ledde till en incident. F\u00f6r att l\u00f6sa s\u00e5dana problem har ingenj\u00f6rer skapat och forts\u00e4tter att skapa automatiska bash\/shell-skript, vilket inte \u00e4r mycket b\u00e4ttre \u00e4n de tidigare metoderna, eftersom de inte \u00e4r l\u00e4tta att snabbt l\u00e4sa, f\u00f6rst\u00e5, underh\u00e5lla och modifiera i procedurstil.<\/p>\n
I den h\u00e4r artikeln och den praktiska guiden anv\u00e4nder jag 2 verktyg som relaterar till praktiken IaC. Dessa \u00e4r Terraform och Ansible. Vissa anser att det inte \u00e4r meningsfullt att anv\u00e4nda dem samtidigt, eftersom deras funktionalitet \u00e4r liknande och de \u00e4r utbytbara. Men saken \u00e4r den att de ursprungligen st\u00e4lls inf\u00f6r helt olika uppgifter. Faktumet att dessa verktyg ska komplettera varandra har bekr\u00e4ftats vid en gemensam presentation av utvecklare fr\u00e5n f\u00f6retagen HashiCorp och RedHat. Den konceptuella skillnaden \u00e4r att Terraform \u00e4r ett provisioning-verktyg f\u00f6r att hantera sj\u00e4lva servrarna. Medan Ansible \u00e4r ett verktyg f\u00f6r hantering av konfigurationer, vars uppgift \u00e4r att installera, konfigurera och hantera mjukvara p\u00e5 dessa servrar.<\/p>\n
En annan nyckelskillnad mellan dessa verktyg \u00e4r kodskrivningsstilen. Till skillnad fr\u00e5n bash och Ansible, anv\u00e4nder Terraform en deklarativ stil, baserad p\u00e5 beskrivningen av det \u00f6nskade slutgiltiga tillst\u00e5ndet som m\u00e5ste uppn\u00e5s som resultat av utf\u00f6randet. Till exempel, om vi k\u00e4nner f\u00f6r att skapa 10 VMs och till\u00e4mpa f\u00f6r\u00e4ndringar genom Terraform, s\u00e5 f\u00e5r vi 10 VMs. Om vi k\u00f6r skriptet igen, h\u00e4nder ingenting, eftersom vi redan har 10 VMs, och Terraform vet detta, eftersom det lagrar det aktuella tillst\u00e5ndet av infrastrukturen i en state-fil. Men Ansible anv\u00e4nder ett proceduralt tillv\u00e4gag\u00e5ngss\u00e4tt och, om vi ber det att skapa 10 VMs, s\u00e5 f\u00e5r vi 10 VMs vid f\u00f6rsta k\u00f6rningen, p\u00e5 samma s\u00e4tt som med Terraform. Men efter att ha k\u00f6rt det igen, kommer vi att ha 20 VMs. Detta utg\u00f6r den viktiga skillnaden. I den procedurala stilen lagrar vi inte det aktuella tillst\u00e5ndet utan beskriver helt enkelt sekvensen av steg som m\u00e5ste utf\u00f6ras. Naturligtvis kan vi hantera olika situationer, l\u00e4gga till n\u00e5gra kontroller f\u00f6r att kontrollera resurser och aktuellt tillst\u00e5nd, men det \u00e4r meningsl\u00f6st att sl\u00f6sa v\u00e5r tid och energi p\u00e5 att kontrollera denna logik. Dessutom \u00f6kar det risken f\u00f6r att g\u00f6ra misstag.\u00a0<\/p>\n
Sammanfattningsvis kan vi dra slutsatsen att det mer l\u00e4mpliga verktyget f\u00f6r provisioning av servrar \u00e4r Terraform och deklarativ notation. \u00c5 andra sidan \u00e4r det b\u00e4ttre att delegera konfigureringens hantering till Ansible. N\u00e4r vi har f\u00f6rst\u00e5tt detta, l\u00e5t oss ta en titt p\u00e5 exempel p\u00e5 anv\u00e4ndning i kontexten av automatisering.<\/p>\n
V\u00e4rde f\u00f6r automatiseringsinfrastruktur<\/h3>\n
\n H\u00e4r \u00e4r det viktigt att f\u00f6rst\u00e5 att testautomatiseringsinfrastrukturen b\u00f6r ses som en del av hela f\u00f6retagets infrastruktur. Det betyder att alla IaC-praktiker b\u00f6r till\u00e4mpas globalt p\u00e5 resurserna i hela organisationen. Vem som \u00e4r ansvarig f\u00f6r detta beror p\u00e5 era processer. DevOps-teamet har mer erfarenhet inom dessa fr\u00e5gor, de ser hela bilden av vad som p\u00e5g\u00e5r. Men QA-ingenj\u00f6rer \u00e4r starkare involverade i processen f\u00f6r att bygga automatisering och strukturen f\u00f6r pipeline, vilket g\u00f6r att de b\u00e4ttre kan se alla n\u00f6dv\u00e4ndiga f\u00f6r\u00e4ndringar och m\u00f6jligheter till f\u00f6rb\u00e4ttring. Den b\u00e4sta l\u00f6sningen \u00e4r att arbeta tillsammans, dela kunskap och id\u00e9er f\u00f6r att n\u00e5 det f\u00f6rv\u00e4ntade resultatet.\u00a0<\/p>\n
Jag ger n\u00e5gra exempel p\u00e5 anv\u00e4ndning av Terraform och Ansible i sammanhanget av testautomatisering och verktyg som vi diskuterat tidigare:<\/p>\n
1. Beskriv de n\u00f6dv\u00e4ndiga egenskaperna och parametrarna f\u00f6r VMs och kluster via Terraform.<\/p>\n
2. Installera n\u00f6dv\u00e4ndiga testverktyg med hj\u00e4lp av Ansible: docker, Selenoid, Selenium Grid och ladda ner de n\u00f6dv\u00e4ndiga versionerna av webbl\u00e4sare\/emulatorer.<\/p>\n
3. Beskriv via Terraform egenskaperna hos VM:n d\u00e4r GitLab Runner kommer att k\u00f6ras.<\/p>\n
4. Installera GitLab Runner och n\u00f6dv\u00e4ndiga tillh\u00f6rande verktyg med hj\u00e4lp av Ansible, ange inst\u00e4llningar och konfigurationer.<\/p>\n
Illustration av det nuvarande tillst\u00e5ndet f\u00f6r infrastrukturen<\/h3>\n
\n![\"DevOps-verktyg](\"\/wp-content\/uploads\/2020\/04\/5d793a800a4ef62e181e6cb3a3f0544e.png\")
<\/p>\n
Resurser f\u00f6r studier:<\/h3>\n
<\/p>\n