Vårt firma er i ferd med å inngå et SRE-team. Jeg kom inn i hele denne historien fra utviklingssiden. I prosessen kom jeg med 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 kan fortsette å leve med det.
Fortsettelse av en serie artikler skrevet med utgangspunkt i taler på vårt interne arrangement :
2. Infrastruktur som kode. (Du er her)
3. Generering av Typescript-kontrakter ved bruk av C#-modeller. (I prosess...)
4. Introduksjon til Raft-konsensusalgoritmen. (I prosess...)
...
Vi bestemte oss for å opprette et SRE-team som implementerte ideene . De rekrutterte programmerere blant sine egne utviklere og sendte dem for å trene i flere måneder.
Laget hadde følgende treningsoppgaver:
- Beskriv vår infrastruktur, som for det meste er i Microsoft Azure i form av kode (Terraform og alt rundt).
- Lær utviklere hvordan de jobber med infrastruktur.
- Forbered utviklere til tjeneste.
Vi introduserer konseptet Infrastruktur som kode
I den vanlige verdensmodellen (klassisk administrasjon) er kunnskap om infrastruktur lokalisert to steder:
- Eller i form av kunnskap i hodet på eksperter.
- Eller denne informasjonen er på noen skrivemaskiner, hvorav noen er kjent for eksperter. Men det er ikke et faktum at en utenforstående (i tilfelle hele teamet vårt plutselig dør) vil være i stand til å finne ut hva som fungerer og hvordan det fungerer. Det kan være mye informasjon på en maskin: tilbehør, cronjobs, skremt (se. ) disk og bare en endeløs liste over hva som kan skje. Det er vanskelig å forstå hva som egentlig skjer.
I begge tilfeller finner vi oss selv fanget i å bli avhengige:
- eller fra en person som er dødelig, utsatt for sykdom, forelskelse, humørsvingninger og rett og slett banale permitteringer;
- eller fra en fysisk fungerende maskin, som også faller, blir stjålet og byr på overraskelser og ulemper.
Det sier seg selv at ideelt sett bør alt oversettes til menneskelig lesbar, vedlikeholdbar, velskrevet kode.
Dermed er infrastruktur som kode (Incfastructure as Code - IaC) en beskrivelse av hele den eksisterende infrastrukturen i form av kode, samt tilhørende verktøy for å jobbe med den og implementere reell infrastruktur fra den.
Hvorfor oversette alt til kode?Mennesker er ikke maskiner. De kan ikke huske alt. Reaksjonen til en person og en maskin er annerledes. Alt automatisert er potensielt raskere enn noe som gjøres av et menneske. Det viktigste er en enkelt kilde til sannhet.
Hvor kommer nye SRE-ingeniører fra?Så vi bestemte oss for å ansette nye SRE-ingeniører, men hvor skal vi få dem fra? Bok med riktige svar () forteller oss: fra utviklerne. De jobber tross alt med koden, og du oppnår den ideelle tilstanden.
Vi søkte lenge etter dem på personalmarkedet utenfor selskapet vårt. Men vi må innrømme at vi ikke fant noen som passet våre forespørsler. Jeg måtte søke blant mitt eget folk.
Problemer Infrastruktur som kode
La oss nå se på eksempler på hvordan infrastruktur kan hardkodes til kode. Koden er velskrevet, høy kvalitet, med kommentarer og innrykk.
Eksempelkode fra Terraforma.
Eksempelkode fra Ansible.
Mine herrer, hvis det bare var så enkelt! Vi er i den virkelige verden, og den er alltid klar til å overraske deg, presentere deg for overraskelser og problemer. Klarer meg ikke uten dem her heller.
1. Det første problemet er at IaC i de fleste tilfeller er en slags dsl.
Og DSL er på sin side en beskrivelse av strukturen. Mer presist, hva du bør ha: Json, Yaml, modifikasjoner fra noen store selskaper som kom opp med sin egen dsl (HCL brukes i terraform).
Problemet er at det lett ikke inneholder slike kjente ting som:
- variabler;
- forhold;
- et sted er det ingen kommentarer, for eksempel i Json, som standard er de ikke gitt;
- funksjoner;
- og jeg snakker ikke engang om ting på høyt nivå som klasser, arv og alt det der.
2. Det andre problemet med slik kode er at det oftest er et heterogent miljø. Vanligvis sitter man og jobber med C#, dvs. med ett språk, en stabel, ett økosystem. Og her har du et stort utvalg av teknologier.
Det er en veldig reell situasjon når bash med python starter en prosess som Json settes inn i. Du analyserer det, så produserer en annen generator ytterligere 30 filer. For alt dette mottas inngangsvariabler fra Azure Key Vault, som trekkes sammen av en plugin for drone.io skrevet i Go, og disse variablene går gjennom yaml, som ble generert som et resultat av generering fra jsonnet-malmotoren. Det er ganske vanskelig å ha strengt godt beskrevet kode når du har et så mangfoldig miljø.
Tradisjonell utvikling innenfor rammen av én oppgave kommer med ett språk. Her jobber vi med en lang rekke språk.
3. Det tredje problemet er tuning. Vi er vant til kule redaktører (Ms Visual Studio, Jetbrains Rider) som gjør alt for oss. Og selv om vi er dumme, vil de si at vi tar feil. Det virker normalt og naturlig.
Men et sted i nærheten er det VSCode, der det er noen plugins som på en eller annen måte er installert, støttet eller ikke støttet. Nye versjoner kom ut og ble ikke støttet. En banal overgang til å implementere en funksjon (selv om den eksisterer) blir et komplekst og ikke-trivielt problem. Et enkelt nytt navn på en variabel er en replay i et prosjekt med et dusin filer. Du vil være heldig hvis han plasserer det du trenger. Selvfølgelig er det bakgrunnsbelysning her og der, det er autofullføring, et sted er det formatering (selv om det ikke fungerte for meg i terraform på Windows).
I skrivende stund har ennå ikke blitt utgitt for å støtte versjon 0.12, selv om den har vært utgitt i 3 måneder.
Det er på tide å glemme...
- Feilsøking.
- Refaktoreringsverktøy.
- Autofullføring.
- Oppdager feil under kompilering.
Det er morsomt, men dette øker også utviklingstiden og øker antallet feil som uunngåelig oppstår.
Det verste er at vi ikke blir tvunget til å tenke på hvordan vi skal designe, organisere filer i mapper, dekomponere, gjøre koden vedlikeholdbar, lesbar og så videre, men på hvordan jeg kan skrive denne kommandoen riktig, fordi jeg på en eller annen måte skrev den feil .
Som nybegynner prøver du å lære terraformer, og IDE hjelper deg ikke i det hele tatt. Når det er dokumentasjon, gå inn og se. Men hvis du gikk inn i et nytt programmeringsspråk, ville IDE fortelle deg at det finnes en slik type, men det er ikke noe slikt. I det minste på int- eller strengnivå. Dette er ofte nyttig.
Hva med testene?
Du spør: "Hva med testene, mine herrer programmerere?" Seriøse gutter tester alt på produksjon, og det er tøft. Her er et eksempel på en enhetstest for en terraform-modul fra nettsiden .
De har god dokumentasjon. Jeg har alltid likt Microsoft for sin tilnærming til dokumentasjon og opplæring. Men du trenger ikke være onkel Bob for å forstå at dette ikke er perfekt kode. Legg merke til valideringen til høyre.
Problemet med en enhetstest er at du og jeg kan sjekke riktigheten til Json-utgangen. Jeg kastet inn 5 parametere og fikk en Json fotklut med 2000 linjer. Jeg kan analysere hva som skjer her, validere testresultat...
Det er vanskelig å analysere Json i Go. Og du må skrive i Go, fordi terraform i Go er en god praksis for å teste på språket du skriver. Organiseringen av selve koden er veldig svak. Samtidig er dette det beste biblioteket for testing.
Microsoft skriver selv modulene sine, og tester dem på denne måten. Selvfølgelig er det åpen kildekode. Alt jeg snakker om kan du komme og fikse. Jeg kan sette meg ned og fikse alt på en uke, åpne kildekode VS-kodeplugins, terraforms, lage en plugin for rytteren. Kanskje skrive et par analysatorer, legge til linters, bidra med et bibliotek for testing. Jeg kan gjøre alt. Men det er ikke det jeg burde gjøre.
Beste praksis Infrastruktur som kode
La oss gå videre. Hvis det ikke er tester i IaC, er IDE og tuning dårlig, så burde det i det minste være beste praksis. Jeg gikk nettopp til Google Analytics og sammenlignet to søk: Terraforms beste fremgangsmåter og beste fremgangsmåter for c#.
Hva ser vi? Nådeløs statistikk er ikke i vår favør. Mengden materiale er den samme. I C#-utvikling er vi rett og slett oversvømmet av materialer, vi har super-beste praksis, det er bøker skrevet av eksperter, og også bøker skrevet på bøker av andre eksperter som kritiserer disse bøkene. Et hav av offisiell dokumentasjon, artikler, kurs, og nå også åpen kildekode-utvikling.
Når det gjelder IaC-forespørselen: her prøver du å samle informasjon bit for bit fra highload- eller HashiConf-rapporter, fra offisiell dokumentasjon og en rekke problemer på Github. Hvordan distribuere disse modulene generelt, hva skal jeg gjøre med dem? Det ser ut til at dette er et reelt problem... Det er et fellesskap, mine herrer, der du vil få 10 kommentarer på Github for alle spørsmål. Men det er det ikke akkurat.
Dessverre, på dette tidspunktet, begynner eksperter bare å dukke opp. Det er for få av dem så langt. Og samfunnet selv henger på det rudimentære nivået.
Hvor går alt dette og hva skal man gjøre
Du kan slippe alt og gå tilbake til C#, til rytterens verden. Men nei. Hvorfor skulle du i det hele tatt gidder å gjøre dette hvis du ikke finner en løsning. Nedenfor presenterer jeg mine subjektive konklusjoner. Du kan argumentere med meg i kommentarene, det blir interessant.
Personlig satser jeg på et par ting:
- Utviklingen på dette området skjer veldig raskt. Her er en tidsplan med forespørsler for DevOps.
Temaet er kanskje hype, men nettopp det at sfæren vokser gir litt håp.Hvis noe vokser så raskt, vil det definitivt dukke opp smarte mennesker som vil fortelle deg hva du skal gjøre og ikke gjøre. Økningen i popularitet fører til at kanskje noen vil ha tid til å endelig legge til en plugin til jsonnet for vscode, som lar deg gå videre til å implementere funksjonen, i stedet for å søke etter den via ctrl+shift+f. Etter hvert som ting utvikler seg, dukker det opp flere materialer. Utgivelsen av en bok fra Google om SRE er et utmerket eksempel på dette.
- Det er utviklet teknikker og praksis innen konvensjonell utvikling som vi med hell kan bruke her. Ja, det er nyanser med testing og et heterogent miljø, utilstrekkelig verktøy, men det er samlet et stort antall praksiser som kan være nyttige og nyttige.
Et trivielt eksempel: samarbeid gjennom parprogrammering. Det hjelper mye å finne ut av det. Når du har en nabo i nærheten som også prøver å forstå noe, vil dere sammen forstå bedre.
Å forstå hvordan refactoring gjøres hjelper å gjennomføre det selv i en slik situasjon. Det vil si at du ikke kan endre alt på en gang, men endre navn, så endre plassering, så kan du markere en del, åh, men det er ikke nok kommentarer her.
Konklusjon
Til tross for at resonnementet mitt kan virke pessimistisk, ser jeg på fremtiden med håp og håper inderlig at alt ordner seg for oss (og deg).
Den andre delen av artikkelen er under utarbeidelse. I den skal jeg snakke om hvordan vi prøvde å bruke smidig utviklingspraksis for å forbedre læringsprosessen vår og jobbe med infrastruktur.
Kilde: www.habr.com