Marathon<\/a><\/noindex>\u00a0<\/li>\n<\/ul>\n<\/p>\n
7. Infrastruktur som kode (IaC)<\/h2>\n
<\/p>\n
Kort beskrivelse af teknologien<\/h3>\n
\n Og nu er vi n\u00e5et til det sidste afsnit. Normalt falder denne teknologi og de tilknyttede opgaver ikke inden for automatiseringsingeni\u00f8rernes ansvarsomr\u00e5de. Der er gode grunde til dette. For det f\u00f8rste er infrastrukturelle sp\u00f8rgsm\u00e5l i mange organisationer under kontrol af DevOps-afdelingen, og udviklingsteams bekymrer sig ikke meget om, hvad der f\u00e5r pipeline til at fungere, og hvordan man skal vedligeholde alt, hvad der relaterer sig til det. For det andet, lad os v\u00e6re \u00e6rlige, praksis med \"Infrastruktur som kode (IaC)\" anvendes stadig ikke i mange virksomheder. Men det er bestemt blevet en popul\u00e6r trend, og det er vigtigt at fors\u00f8ge at v\u00e6re involveret i de processer, tilgange og v\u00e6rkt\u00f8jer, der er forbundet med dette. Eller i det mindste v\u00e6re informeret om udviklingen.<\/p>\n
Lad os starte med motivationen for at bruge denne tilgang. Vi har allerede dr\u00f8ftet, at vi for at k\u00f8re tests i GitlabCI mindst har brug for ressourcer til at k\u00f8re Gitlab Runner. Og for at starte containere med browsere\/emulatorer skal vi reservere en VM eller et cluster. Udover ressourcerne til testning har vi brug for et betydeligt antal kapaciteter til at underst\u00f8tte udviklings-, staging- og produktionsmilj\u00f8er, hvilket ogs\u00e5 inkluderer databaser, automatiske tidsplaner, netv\u00e6rkskonfigurationer, belastningsfordelere, brugerrettigheder og s\u00e5 videre. Det centrale problem er den n\u00f8dvendige indsats for at st\u00f8tte det hele. Der er flere m\u00e5der, hvormed vi kan foretage \u00e6ndringer og implementere opdateringer. For eksempel, i konteksten af GCP kan vi bruge UI-konsollen i browseren og udf\u00f8re alle handlinger ved at klikke p\u00e5 knapper. En alternativ metode kan v\u00e6re at bruge API-opkald til at interagere med cloud-enkeltheder eller anvende kommandolinjev\u00e6rkt\u00f8jet gcloud til at udf\u00f8re de n\u00f8dvendige manipulationer. Men med et virkelig stort antal forskellige enheder og infrastrukturelementer bliver det sv\u00e6rt eller endda umuligt at udf\u00f8re alle operationer manuelt. Desuden er alle disse manuelle handlinger ukontrollerede. Vi kan ikke sende dem til gennemgang f\u00f8r udf\u00f8relse, bruge versionskontrolsystemer og hurtigt rulle \u00e6ndringer tilbage, som har f\u00f8rt til en h\u00e6ndelse. For at l\u00f8se s\u00e5danne problemer har ingeni\u00f8rer skabt og skaber automatiserede bash\/shell-scripts, hvilket ikke er meget bedre end de tidligere metoder, da de ikke er s\u00e5 lette at l\u00e6se, forst\u00e5, vedligeholde og modificere hurtigt i procedurem\u00e6ssig stil.<\/p>\n
I denne artikel og praktiske vejledning bruger jeg to v\u00e6rkt\u00f8jer, der relaterer sig til IaC-praksis. Dette er Terraform og Ansible. Nogle mener, at det ikke giver mening at bruge dem samtidig, da deres funktionalitet ligner hinanden, og de kan erstatte hinanden. Men sagen er, at de oprindeligt stilles forskellige opgaver. Og det faktum, at disse v\u00e6rkt\u00f8jer skal supplere hinanden, blev bekr\u00e6ftet ved en f\u00e6lles pr\u00e6sentation af udviklere repr\u00e6senterende virksomhederne HashiCorp og RedHat. Den konceptuelle forskel er, at Terraform er et provisioning-v\u00e6rkt\u00f8j til at administrere selve serverne. Mens Ansible er et v\u00e6rkt\u00f8j til konfigurationsstyring, hvis opgave er at installere, konfigurere og administrere softwaren p\u00e5 disse servere.<\/p>\n
En anden afg\u00f8rende forskel mellem disse v\u00e6rkt\u00f8jer er kodestilen. I mods\u00e6tning til bash og Ansible bruger Terraform en deklarativ stil, der er baseret p\u00e5 beskrivelsen af den \u00f8nskede endelige tilstand, som skal opn\u00e5s som f\u00f8lge af udf\u00f8relsen. For eksempel, hvis vi har t\u00e6nkt os at oprette 10 VMs og anvende \u00e6ndringerne gennem Terraform, f\u00e5r vi 10 VMs. Hvis vi anvender scriptet igen, vil der ikke ske noget, da vi allerede har 10 VMs, og Terraform ved dette, fordi det gemmer den nuv\u00e6rende tilstand af infrastrukturen i en state-fil. Ansible bruger derimod en procedurebaseret tilgang, og hvis vi beder det om at oprette 10 VMs, f\u00e5r vi 10 VMs ved f\u00f8rste k\u00f8rsel, ligesom med Terraform. Men efter en gentagen k\u00f8rsel vil vi allerede have 20 VMs. Dette er den vigtige forskel. I den procedurebaserede stil opbevarer vi ikke den nuv\u00e6rende tilstand og beskriver blot r\u00e6kkef\u00f8lgen af de skridt, der skal udf\u00f8res. Selvf\u00f8lgelig kan vi h\u00e5ndtere forskellige situationer, tilf\u00f8je nogle kontroller for eksisterende ressourcer og den nuv\u00e6rende tilstand, men der er ikke meget mening i at bruge vores tid og kr\u00e6fter p\u00e5 at kontrollere denne logik. Desuden \u00f8ger det risikoen for fejl.\u00a0<\/p>\n
Sammenfattende kan vi konkludere, at Terraform og deklarativ notation er det mere passende v\u00e6rkt\u00f8j til provisioning af servere. Mens konfigurationsstyring bedre overlades til Ansible. N\u00e5r vi har forst\u00e5et dette, lad os se p\u00e5 eksempler p\u00e5 anvendelse i konteksten af automatisering.<\/p>\n
V\u00e6rdi for automatiseringsinfrastruktur<\/h3>\n
\n Det er vigtigt at forst\u00e5, at infrastrukturen til testautomatisering skal betragtes som en del af hele virksomhedens infrastruktur. Det betyder, at alle IaC-praksisser skal anvendes globalt p\u00e5 ressourcerne i hele organisationen. Hvem der er ansvarlig for dette, afh\u00e6nger af jeres processer. DevOps-teamet har mere erfaring med disse emner, og de har et overordnet billede af situationen. QA-ingeni\u00f8rer er dog mere involveret i processen med at opbygge automatisering og strukturen af pipeline, hvilket giver dem en bedre forst\u00e5else af de n\u00f8dvendige \u00e6ndringer og forbedringsmuligheder. Den bedste l\u00f8sning er at arbejde sammen, dele viden og id\u00e9er for at opn\u00e5 det \u00f8nskede resultat.\u00a0<\/p>\n
Lad mig give nogle eksempler p\u00e5 brugen af Terraform og Ansible i konteksten af testautomatisering og de v\u00e6rkt\u00f8jer, vi har diskuteret tidligere:<\/p>\n
1. Beskrive de n\u00f8dvendige egenskaber og parametre for VMs og klynger gennem Terraform.<\/p>\n
2. Installere de n\u00f8dvendige testv\u00e6rkt\u00f8jer med Ansible: docker, Selenoid, Selenium Grid og downloade de n\u00f8dvendige versioner af browsere\/emulatorer.<\/p>\n
3. Beskrive egenskaberne for den VM, hvor GitLab Runner skal k\u00f8res, gennem Terraform.<\/p>\n
4. Installere GitLab Runner og n\u00f8dvendige tilh\u00f8rende v\u00e6rkt\u00f8jer med Ansible, og indstille indstillinger og konfigurationer.<\/p>\n
Illustration af den nuv\u00e6rende tilstand af infrastrukturen<\/h3>\n
\n![\"DevOps](\"\/wp-content\/uploads\/2020\/04\/5d793a800a4ef62e181e6cb3a3f0544e.png\")
<\/p>\n
Links til studier:<\/h3>\n
<\/p>\n