Infrastruktur som kode: en første introduksjon

I selskapet vårt er det en onboarding-prosess for SRE-teamet. Jeg har tatt del i hele denne prosessen fra utviklersiden. Underveis har jeg fått tanker og innsikter som jeg ønsker å dele med andre utviklere. I denne refleksjonsartikkelen snakker jeg om hva som skjer, hvordan det skjer, og hvordan alle skal leve med dette videre.

Fortsettelse av en serie artikler skrevet med inspirasjon fra presentasjoner på vårt interne arrangement DevForum:

1. Schrödingers katt uten eske: konsensusproblemet i distribuerte systemer.
2. Infrastruktur som kode. (Du er her)
3. Generering av Typescript-kontrakter basert på C#-modeller. (Pågår…)
4. Introduksjon til Raft-konsensusalgoritmen. (Pågår…)
…

Vi har besluttet å opprette et SRE-team, basert på ideene google sre. Vi har valgt programmerere fra våre egne utviklere og sendt dem på kurs i flere måneder.

Teamet hadde følgende læringsoppgaver:

• Å beskrive infrastrukturen vår, som stort sett er i Microsoft Azure, som kode (Terraform og alt relatert).
• Å lære utviklerne å arbeide med infrastrukturen.
• Å forberede utviklerne på vaktarbeid.

Vi innfører begrepet Infrastruktur som kode

I den vanlige verdensmodellen (klassisk administrasjon) er kunnskap om infrastrukturen i to steder:

1. Enten i hodene på eksperter.
2. Eller disse opplysningene finnes på maskiner, hvor eksperter kjenner til noen av dem. Men det er ikke sikkert at en utenforstående (hvis hele teamet vårt skulle dø plutselig) kan forstå hva som fungerer og hvordan. På maskinen kan det være mange opplysninger: tilgangsrettigheter, cron-jobber, tilknyttede (se diskmontering) disker og bare en endeløs liste over hva som kan skje. Det er vanskelig å forstå hva som faktisk skjer.

I begge tilfeller havner vi i en felle, hvor vi blir avhengige:

• enten av en person, som er dødelig, utsatt for sykdommer, forelskelser, humørforandringer og bare helt vanlig oppsigelser;
• eller av en fysisk fungerende maskin, som også kan krasje, bli stjålet, gi overraskelser og ulemper.

Det er åpenbart at løsningen er å oversette alt til lesbar, vedlikeholdbar, kvalitetskodet.

Dermed er infrastruktur som kode (Infrastructure as Code – IaC) en beskrivelse av all eksisterende infrastruktur i form av kode, samt tilhørende verktøy for å arbeide med det og realisere faktisk infrastruktur fra det.

Hvorfor oversette alt til kodeMennesker er ikke maskiner. De kan ikke huske alt. Reaksjonen til et menneske og en maskin er forskjellig. Alt som er automatisert, fungerer potensielt raskere enn det som gjøres av mennesker. Det viktigste er én sannhet (single source of truth).

Hvor kommer nye SRE-ingeniører fraSå vi har bestemt oss for å ansette nye SRE-ingeniører, men hvor finner vi dem? Boken med de riktige svarene (Google SRE Book) forteller oss: fra utviklere. De jobber med kode, og du oppnår den ideelle tilstanden.

Vi har lett mye og lenge etter dem på arbeidsmarkedet utenfor vårt selskap. Men vi må innse at vi ikke fant en eneste som passet våre ønsker. Vi måtte sjekke blant våre egne.

Problemer med infrastruktur som kode

La oss nå se på eksempler på hvordan infrastruktur kan være integrert i kode. Koden er godt skrevet, av høy kvalitet, med kommentarer og innrykk.

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 alltid klar til å overraske deg, gi deg overraskelser og problemer. Det er ikke uten problemer her heller.

1. Det første problemet er at IaC i de fleste tilfeller er en slags DSL.

Og en DSL, på sin side, er en beskrivelse av strukturen. Nærmere bestemt hva du bør ha: Json, Yaml, modifikasjoner fra noen store selskaper som har utviklet sin egen DSL (i Terraform brukes HCL).

Problemet er at det lett kan mangle slike vanlige ting som:

• variabler;
• betingelser;
• noen steder mangler kommentarer, for eksempel er de ikke forhåndsdefinert i Json;
• funksjoner;
• og jeg har ennå ikke nevnt slike høyere nivåer, som klasser, arv og alt det der.

2. Det andre problemet med slik kode er at det oftest er et heterogent miljø. Vanligvis sitter du og arbeider med C#, altså med ett språk, én stakk, én økosystem. Men her har du et enormt mangfold av teknologier.

Det er en helt reell situasjon der en bash med Python kjører en eller annen prosess, hvor Json settes inn. Du analyserer det, og deretter gir en annen generator ytterligere 30 filer. For alt dette kommer det inn variable fra Azure Key Vault, som hentes av et plugin til drone.io, skrevet i Go, og disse variable passerer gjennom yaml, som ble generert fra templater i jsonnet. Det er ganske vanskelig å ha strengt godt beskrevet kode når du har et så variert miljø.

Tradisjonell utvikling innenfor en oppgave skjer med ett og samme språk. Her jobber vi med et stort antall språk.

3. Det tredje problemet – er verktøyene.. Vi er vant til kule redaktører (Ms Visual Studio, Jetbrains Rider), som gjør alt for oss. Og selv om vi skulle gjøre en feil, vil de si at vi ikke er riktige. Det føles som normalt og naturlig.

Men et sted i nærheten er VSCode, som har noen plugins som på en eller annen måte installeres, støttes eller ikke støttes. Nye versjoner kommer ut, men de blir ikke støttet. Et banalt skifte til implementeringen av en funksjon (selv om den finnes) blir et vanskelig og ikke-banalt problem. En enkel omdøpning av en variabel - det er en erstatning i prosjektet fra dusinvis av filer. Heldigvis, hvis den erstatte det som trengs. Det er selvfølgelig noen steder med syntaksutheving, autocompletion og noen steder er det formatering (men jeg klarte ikke å få det til å fungere med terraform på Windows).

Ved tidspunktene artiklen ble skrevet vscode-terraform plugin har enda ikke blitt utgitt for å støtte versjon 0.12, selv om den allerede har vært ute i 3 måneder.

Det er på tide å glemme…

1. Debugging.
2. Refactoring-verktøy.
3. Auto fullføring.
4. Oppdagelse av feil under kompilering.

Det er morsomt, men dette øker tiden for utvikling og øker antall feil som uunngåelig skjer.

Det mest skremmende er at vi må tenke ikke på hvordan vi skal designe, organisere filene i mapper, dekomponere, gjøre koden vedlikeholdbar, lesbar og så videre, men på hvordan jeg kan skrive denne kommandoen korrekt, fordi jeg på en eller annen måte skrev den feil.

Som nybegynner prøver du å forstå terraform, men IDE-en hjelper deg ikke i det hele tatt. Når det finnes dokumentasjon – går du inn og ser. Men hvis du begynte med et nytt programmeringsspråk, ville IDE-en ha foreslått at det finnes en slik type, og en slik type finnes ikke. I hvert fall på nivået int eller string. Dette er ofte nyttig.

Men hvordan med testene?

Dere spør: «Hvordan er det med testene, kjære programmerere?» Seriøse folk tester alt i produksjon, og det er strengt. Her er et eksempel på en enhetstest for et Terraform-modul fra nettstedet. Microsoft.

De har god dokumentasjon. Microsoft har alltid imponert meg med sin tilnærming til dokumentasjon og opplæring. Men man trenger ikke å være onkel Bob for å forstå at koden her ikke er perfekt. Legg merke til valideringen som er plassert til høyre.

Problemet med enhetstesten er at vi kan sjekke om JSON-en er korrekt på utgangen. Jeg ga fem parametere, og jeg fikk en JSON som er 2000 linjer lang. Jeg kan analysere hva som skjer her, validere testresultatet…

Det er vanskelig å analysere JSON i Go. Men man bør skrive i Go, fordi Terraform på Go er god praksis, å teste i språket man skriver i. Kodeutformingen er også veldig svak. Likevel er dette det beste biblioteket for testing.

Selv Microsoft skriver sine moduler og tester dem på denne måten. Selvfølgelig er dette Open Source. Alt jeg snakker om kan du komme og reparere. Jeg kan sette meg ned og fikse alt på en uke, open-sourc'e VS Code-plugger, Terraform, lage en plugin for Rider. Kanskje skrive et par analyseverktøy, legge til lintrere, bidra til testbiblioteket. Jeg kan gjøre alt dette. Men det er ikke det jeg skal bruke tiden min på.

Beste praksiser for Infrastructure as Code

La oss gå videre. Hvis det ikke finnes tester i IaC, hvis IDE og verktøyene er dårlige, så må det i det minste finnes noen beste praksiser. Jeg søkte bare i Google Analytics og sammenlignet to søk: Terraform beste praksiser og C# beste praksiser.

Hva ser vi? Uutholdelig statistikk som ikke er til vår fordel. Når det gjelder mengden materiale, er det det samme. Innen C# utvikling er vi faktisk overfylt av materiale, vi har supergode praksiser, det er bøker skrevet av eksperter, og også bøker skrevet av andre eksperter som kritiserer de bøkene. Mye offisiell dokumentasjon, artikler, opplæringskurs, og nå også open source utvikling.

Når det gjelder søket om IaC: her må du i det minste prøve å samle informasjon fra foredrag og HashiConf, fra den offisielle dokumentasjonen og utallige problemer på GitHub. Hvordan skal man egentlig dele opp disse modulene, hva skal man gjøre med dem? Det virker som et reelt problem… Det finnes et fellesskap, folkens, hvor du kan få ti kommentarer på GitHub for hvert spørsmål du har. Men det er ikke sikkert.

Dessverre begynner ekspertene først nå å dukke opp. Det er fortsatt for få. Og fellesskapet er fortsatt på et tidlig stadium.

Hvor er alt dette på vei, og hva skal vi gjøre?

Man kan bare gi opp og gå tilbake til C#, til verden av Rider. Men nei. Hvorfor skulle man i det hele tatt gjøre det, hvis man ikke prøver å finne en løsning? Her er mine subjektive konklusjoner. Du kan gjerne argumentere med meg i kommentarfeltet, det vil være interessant.

Personlig satser jeg på flere faktorer:

1. Utviklingen innen dette området skjer veldig raskt. Jeg viser grafen over søkene relatert til DevOps.

   
   
   Kanskje dette er et hypet tema, men selve faktum at feltet vokser, gir en viss håp.

   Hvis noe vokser så raskt, vil det nødvendigvis dukke opp kloke mennesker som sier hva man skal gjøre og hva man ikke skal gjøre. Økt popularitet kan føre til at noen endelig får tid til å skrive et plugin til jsonnet for vscode, som lar deg hoppe til implementeringen av funksjonen, i stedet for å lete etter den med ctrl+shift+f. Når alt utvikler seg, kommer det flere ressurser. Utgivelsen av Google-boken om SRE er et glimrende eksempel på dette.

2. Det finnes utviklede metoder og praksiser i vanlig utvikling som vi kan bruke med suksess her. Ja, det er noen nyanser med testing og heterogene miljøer, samt utilstrekkelig verktøy, men det er opparbeidet en enorm mengde praksiser som kan være nyttige og hjelpe.

   Et banalt eksempel: samarbeid gjennom pair programming. Det hjelper mye med å forstå. Når du har en nabo ved siden av deg som også prøver å forstå noe, vil dere sammen forstå bedre.

   Forståelsen av hvordan refaktorering gjøres, hjelper selv i en slik situasjon. Det betyr at du kan endre ikke alt på en gang, men først navngivningen, så plasseringen, og kanskje dele ut en del, åh, men her mangler det kommentarer.

Konklusjon

Selv om mine resonnementer kan virke pessimistiske, ser jeg med håp mot fremtiden og håper oppriktig at vi (og dere) vil lykkes.

Den andre delen av artikkelen er på vei. Der vil jeg fortelle om hvordan vi prøvde å bruke praksiser fra smidig utvikling for å forbedre vår opplæringsprosess og arbeid med infrastrukturen.

Kilde: habr.com