Vi er i vores virksomhed i gang med at onboarde SRE-teamet. Jeg kom ind i det hele fra udviklersiden. Undervejs har jeg fået nogle tanker og indsigter, som jeg gerne vil dele med andre udviklere. I denne artikel-refleksion taler jeg om, hvad der sker, hvordan det sker, og hvordan vi alle skal leve med det fremover.
Fortsettelse af serien af artikler skrevet med inspiration fra præsentationer ved vores interne arrangement. :
2. Infrastruktur som kode. (Du er her)
3. Generering af Typescript-kontrakter fra C#-modeller. (Under behandling…)
4. Introduktion til Raft-konsensusalgoritmen. (Under behandling…)
…
Vi besluttede at danne et SRE-team og implementere idéerne fra . Vi rekrutterede programmører fra vores egne udviklere og sendte dem på træning i flere måneder.
Teamet stod overfor følgende undervisningsopgaver:
- At beskrive vores infrastruktur, som for det meste er i Microsoft Azure, som kode (Terraform og alt relateret).
- At lære udviklerne at arbejde med infrastrukturen.
- At forberede udviklerne til vagter.
Vi indfører begrebet Infrastruktur som kode.
I den normale verdensmodel (klassisk administration) findes viden om infrastrukturen to steder:
- Enten i form af viden i hovedet på eksperterne.
- Eller disse oplysninger findes på nogle maskiner, hvor dele af dem kendes af eksperterne. Men det er ikke sikkert, at en person udefra (i tilfælde af at hele vores team pludselig dør) kan finde ud af, hvad der fungerer og hvordan. Der kan være mange oplysninger på maskinen: adgangsrettigheder, cron-jobs, en underlært (se. ) disk og bare en endeløs liste over alt, hvad der kan ske. Det er svært at forstå, hvad der i virkeligheden foregår.
I begge tilfælde havner vi i en fælde, hvor vi bliver afhængige:
- enten af en person, der er dødelig, udsat for sygdomme, forelskelser, humørsvingninger og simpelthen banal fratræden;
- eller af en fysisk fungerende maskine, der også kan gå ned, blive stjålet, byde på overraskelser og ubehageligheder.
Det står klart, at idealet er, at alt bør oversættes til menneskelig læsbar, vedligeholdt og kvalitetskode.
Således er infrastruktur som kode (Infrastructure as Code – IaC) en beskrivelse af al eksisterende infrastruktur i form af kode samt tilknyttede værktøjer til at arbejde med det og realisere den faktiske infrastruktur.
Hvorfor oversætte alt til kodeMennesker er ikke maskiner. De kan ikke huske alt. Reaktionen hos et menneske og en maskine er forskellig. Alt automatiseret fungerer potentielt hurtigere end alt, hvad et menneske gør. Det vigtigste er én sandhedskilde (single source of truth).
Hvor kommer nye SRE-ingeniører fraSå vi har besluttet at onboarde nye SRE-ingeniører, men hvor finder vi dem? Bogen med de rigtige svar () fortæller os: fra udviklerne. For de arbejder med kode, og du når det ideelle niveau.
Vi har søgt længe og grundigt efter dem på arbejdsmarkedet uden for vores virksomhed. Men vi må erkende, at vi ikke fandt nogen, der passede til vores krav. Vi måtte undersøge internt blandt vores egne.
Problemer med infrastruktur som kode
Lad os nu se eksempler på, hvordan infrastruktur kan være indlejret i kode. Koden er godt skrevet, af høj kvalitet, med kommentarer og indrykninger.
Kodeeksempel fra Terraform.
Kodeeksempel fra Ansible.
Mine damer og herrer, men hvis alt var så enkelt! Vi lever i den virkelige verden, og den er altid klar til at overraske dig med overraskelser og problemer. Ikke uden problemer her heller.
1. Det første problem er, at IaC i de fleste tilfælde er en form for DSL.
Og DSL, på sin side, er en beskrivelse af strukturen. Mere præcist, hvad du skal have: Json, Yaml, modificationer fra større virksomheder, der har opfundet deres egen DSL (HCL anvendes i Terraform).
Problemet er, at der måske mangler nogle af de velkendte ting, som:
- variabler;
- betingelser;
- der er steder uden kommentarer, for eksempel er kommentarer ikke forudset i Json som standard;
- funktioner;
- og det er slet ikke for at nævne sådanne højniveaufunktioner som klasser, arv og alt det der.
2. Det andet problem med denne kode er, at det oftest er et heterogent miljø.. Normalt sidder du og arbejder med C#, dvs. et sprog, en stack, et økosystem. Og her har du et stort udvalg af teknologier.
En ret realistisk situation er, når en bash med Python starter en proces, hvori der indgår JSON. Du analyserer det, og derefter genererer en eller anden generator endnu 30 filer. For alt dette kommer indgangsvariabler fra Azure Key Vault, som er trukket ind af et plugin til drone.io, skrevet i Go, og disse variabler går gennem yaml, som er blevet genereret fra skabelonmotoren jsonnet. Det er ret svært at have en strengt veldokumenteret kode, når du har et så forskelligartet miljø.
Traditionel udvikling inden for en enkelt opgave foregår med ét sprog. Her arbejder vi derimod med mange forskellige sprog.
3. Det tredje problem – det er værktøjerne.. Vi er vant til flotte redaktører (Ms Visual Studio, Jetbrains Rider), som gør alt for os. Og selv hvis vi går i stå, fortæller de os, at vi tager fejl. Det føles normalt og naturligt.
Men lige ved siden af er VSCode, hvor der er nogle plugins, som på en eller anden måde installeres, understøttes eller ikke understøttes. Nye versioner blev udgivet, men de blev ikke understøttet. Et simpelt skift til implementeringen af en funktion (selv hvis den findes) bliver en kompleks og ikke-trivial opgave. En simpel omdøbning af en variabel – det er en erstatning i projektet, der strækker sig over dusinvis af filer. Du er heldig, hvis det erstatter det, du behøver. Der er selvfølgelig nogle steder med farvefremhævning, auto completion, og nogle steder er der formatering (selv om det ikke virkede for mig i terraform på Windows).
På tidspunktet for skrivningen af artiklen er endnu ikke blevet frigivet til understøttelse af version 0.12, selvom den allerede er blevet udgivet for 3 måneder siden.
Det er tid til at glemme…
- Fejlfinding.
- Refactoring-værktøj.
- Auto completion.
- Opdagelse af fejl ved compilering.
Det er morsomt, men det øger tiden til udvikling og øger antallet af de fejl, som uundgåeligt opstår.
Det værste er, at vi bliver tvunget til ikke at tænke på, hvordan vi skal designe, organisere filer i mapper, dekomponere, gøre koden vedligeholdelsesmæssig, læsbar og så videre, men om hvordan jeg korrekt skriver denne kommando, fordi jeg på en eller anden måde skrev den forkert.
Som nybegynder forsøger du at forstå terraform, men IDE'en hjælper dig slet ikke med det. Når der er dokumentation – så går du ind, kigger. Men hvis du skulle lære et nyt programmeringssprog, ville IDE'en have foreslået, at der fandtes en sådan type, men ikke denne. I det mindste på niveauet int eller string. Det er ofte nyttigt.
Men hvad med testene?
Du spørger: „Hvordan står det til med testene, mine herrer programmører?” Seriøse folk tester alt i produktion, og det er hårdt. Her er et eksempel på en enhedstest for et Terraform-modul fra hjemmesiden. .
De har en god dokumentation. Microsoft har altid været imponerende i deres tilgang til dokumentation og uddannelse. Men man behøver ikke at være onkel Bob for at se, at koden her ikke er perfekt. Bemærk valideringen, der er placeret til højre.
Problemet med enhedstesten er, at vi kan kontrollere korrektheden af Json på udgangen. Jeg sendte 5 parametre, og jeg fik en Json-streng på 2000 linjer. Jeg kan analysere, hvad der sker her, validere testresultatet…
Det er svært at analysere Json i Go. Man bør skrive i Go, fordi Terraform er skrevet i Go – det er en god praksis at teste i det sprog, man skriver i. Selve organiseringen af koden er meget svag. Til gengæld er dette den bedste biblioteker til testning.
Selv Microsoft skriver deres moduler ved at teste dem på denne måde. Selvfølgelig er det Open Source. Alt, hvad jeg taler om, kan du komme og reparere. Jeg kan sætte mig ned og fikse alt på en uge, open source plugins til VS Code, Terraform, lave et plugin til Rider. Måske skrive et par analysatorer, implementere linters, bidrage til et testbibliotek. Jeg kan gøre det hele. Men det er ikke det, jeg skal beskæftige mig med.
Bedste praksis for Infrastructure as Code
Lad os gå videre. Hvis der ikke er tests i IaC, og IDE og værktøjer er dårlige, så bør der i det mindste være bedste praksis. Jeg gik bare ind i Google Analytics og sammenlignede to søgeforespørgsler: Terraform bedste praksis og C# bedste praksis.
Hvad ser vi? Ublid statistik til vores ulempe. I forhold til mængden af materiale er det det samme. I C# udvikling svømmer vi bare i materialer, vi har overlegen bedste praksis, der er bøger skrevet af eksperter samt bøger skrevet af andre eksperter, der kritiserer dem. En overflod af officiel dokumentation, artikler, uddannelseskurser, og nu også open source udvikling.
Hvad angår forespørgslen om IaC: her prøver du at samle information fra præsentationer fra højbelastede events eller HashiConf, fra den officielle dokumentation og utallige issues på GitHub. Hvordan placerer man overhovedet disse moduler, og hvad skal man gøre med dem? Det virker som et reelt problem… Der er et fællesskab, mine herrer, hvor du kan få 10 kommentarer på GitHub til ethvert spørgsmål. Men det er ikke sikkert.
Desværre er eksperterne kun lige begyndt at dukke op nu. Der er simpelthen for få af dem. Og selve fællesskabet er stadig i sin spæde begyndelse.
Hvor bevæger det hele sig hen, og hvad skal man gøre?
Man kan vælge at kaste alt væk og gå tilbage til C#, ind i riderens verden. Men nej. Hvorfor skulle man overhovedet beskæftige sig med det, hvis man ikke ønsker at finde en løsning? Nedenfor præsenterer jeg mine subjektive konklusioner. I er velkomne til at diskutere med mig i kommentarfeltet; det ville være interessant.
Personligt satser jeg på flere ting:
- Udviklingen inden for dette område sker utrolig hurtigt. Jeg viser grafen over forespørgsler relateret til DevOps.
Måske er emnet populært, men det faktum, at området vokser, giver en vis håb.Hvis noget vokser så hurtigt, vil der helt sikkert dukke kloge mennesker op, som kan fortælle, hvad man skal gøre, og hvad man ikke skal gøre. Den stigende popularitet betyder, at nogen måske får tid til endelig at færdiggøre en plugin til jsonnet for vscode, som gør det muligt at gå direkte til implementeringen af en funktion i stedet for at lede efter den via ctrl+shift+f. Når alt udvikler sig, bliver der mere materiale tilgængeligt. Udgivelsen af Googles bog om SRE er et glimrende eksempel på dette.
- Der er udviklet metoder og praksisser inden for normal udvikling, som vi med succes kan anvende her. Ja, der er nuancer med testning og heterogene miljøer og utilstrækkelig værktøjsudvikling, men der er samlet et enormt antal praksisser, som kan være nyttige og hjælpe.
Et banalt eksempel: samarbejde gennem pair programming. Det hjælper virkelig med at forstå. Når du har en nabo ved siden af dig, som også prøver at forstå noget, så vil I sammen forstå det bedre.
Forståelsen af, hvordan refactoring udføres, hjælper også i en sådan situation med at udføre det. Det vil sige, at du kan ændre ikke alt på én gang, men ændre navngivningen først, derefter ændre placeringen og måske fremhæve en del, åh, og her mangler der kommentarer.
Konklusion
Selvom mine overvejelser kan synes pessimistiske, ser jeg med håb mod fremtiden og håber oprigtigt, at vi (og I) vil få det til at lykkes.
Næste del af artiklen er på vej. I den vil jeg fortælle, hvordan vi har forsøgt at anvende praksisser inden for agil udvikling for at forbedre vores læringsproces og arbejde med infrastrukturer.
Kilde: habr.com
