Vores virksomhed er i gang med at onboarde et SRE-team. Jeg kom ind i hele denne historie fra udviklingssiden. I processen kom jeg med tanker og indsigter, som jeg gerne vil dele med andre udviklere. I denne refleksionsartikel fortæller jeg om, hvad der sker, hvordan det sker, og hvordan alle kan blive ved med at leve med det.
Fortsættelse af en række artikler skrevet på baggrund af taler ved vores interne arrangement :
2. Infrastruktur som kode. (Du er her)
3. Generering af Typescript-kontrakter ved hjælp af C#-modeller. (I gang...)
4. Introduktion til Raft-konsensusalgoritmen. (I gang...)
...
Vi besluttede at oprette et SRE-team, der implementerede ideerne . De rekrutterede programmører blandt deres egne udviklere og sendte dem for at træne i flere måneder.
Holdet havde følgende træningsopgaver:
- Beskriv vores infrastruktur, som mest er i Microsoft Azure i form af kode (Terraform og alt omkring).
- Lær udviklere at arbejde med infrastruktur.
- Forbered udviklere til pligt.
Vi introducerer begrebet Infrastruktur som kode
I den sædvanlige model af verden (klassisk administration) er viden om infrastruktur placeret to steder:
- Eller i form af viden i hovedet på eksperter.
- Eller disse oplysninger er på nogle skrivemaskiner, hvoraf nogle er kendt af eksperter. Men det er ikke et faktum, at en outsider (i tilfælde af at hele vores team pludselig dør) vil være i stand til at finde ud af, hvad der virker, og hvordan det fungerer. Der kan være en masse information på en maskine: tilbehør, cronjobs, intimideret (se. ) disk og bare en endeløs liste over, hvad der kan ske. Det er svært at forstå, hvad der virkelig sker.
I begge tilfælde er vi fanget i at blive afhængige:
- eller fra en person, der er dødelig, underlagt sygdom, forelskelse, humørsvingninger og simpelthen banale afskedigelser;
- eller fra en fysisk fungerende maskine, som også falder, bliver stjålet og giver overraskelser og gener.
Det siger sig selv, at ideelt set bør alt oversættes til menneskelig læsbar, vedligeholdelig, velskrevet kode.
Infrastruktur som kode (Incfastructure as Code - IaC) er således en beskrivelse af hele den eksisterende infrastruktur i form af kode, samt relaterede værktøjer til at arbejde med den og implementere rigtig infrastruktur ud fra den.
Hvorfor oversætte alt til kode?Mennesker er ikke maskiner. De kan ikke huske alt. Reaktionen af en person og en maskine er anderledes. Alt automatiseret er potentielt hurtigere end noget, der udføres af et menneske. Det vigtigste er en enkelt kilde til sandhed.
Hvor kommer nye SRE-ingeniører fra?Så vi besluttede at ansætte nye SRE-ingeniører, men hvor får vi dem fra? Bog med rigtige svar () fortæller os: fra udviklerne. De arbejder jo med koden, og du opnår den ideelle tilstand.
Dem ledte vi meget efter i lang tid på personalemarkedet uden for vores virksomhed. Men vi må indrømme, at vi ikke fandt en, der matchede vores anmodninger. Jeg måtte søge blandt mit eget folk.
Problemer Infrastruktur som kode
Lad os nu se på eksempler på, hvordan infrastruktur kan hårdkodes til kode. Koden er velskrevet, høj kvalitet, med kommentarer og indrykninger.
Eksempelkode fra Terraforma.
Eksempelkode fra Ansible.
Mine herrer, hvis det bare var så enkelt! Vi er i den virkelige verden, og den er altid klar til at overraske dig, præsentere dig for overraskelser og problemer. Kan heller ikke undvære dem her.
1. Det første problem er, at IaC i de fleste tilfælde er en slags dsl.
Og DSL er til gengæld en beskrivelse af strukturen. Mere præcist, hvad du skal have: Json, Yaml, modifikationer fra nogle store virksomheder, der kom med deres egen dsl (HCL bruges i terraform).
Problemet er, at det nemt ikke kan indeholde sådanne velkendte ting som:
- variabler;
- betingelser;
- et eller andet sted er der ingen kommentarer, for eksempel i Json, som standard leveres de ikke;
- funktioner;
- og jeg taler ikke engang om sådanne ting på højt niveau som klasser, arv og alt det der.
2. Det andet problem med en sådan kode er, at det oftest er et heterogent miljø. Normalt sidder man og arbejder med C#, dvs. med ét sprog, én stak, ét økosystem. Og her har du et stort udvalg af teknologier.
Det er en meget reel situation, når bash med python starter en eller anden proces, som Json indsættes i. Du analyserer det, så producerer en anden generator yderligere 30 filer. Til alt dette modtages inputvariabler fra Azure Key Vault, som trækkes sammen af et plugin til drone.io skrevet i Go, og disse variabler passerer gennem yaml, som blev genereret som et resultat af generering fra jsonnet-skabelonmotoren. Det er ret svært at have nøje beskrevet kode, når du har et så forskelligartet miljø.
Traditionel udvikling inden for rammerne af én opgave kommer med ét sprog. Her arbejder vi med en lang række sprog.
3. Det tredje problem er tuning. Vi er vant til at seje redaktører (Ms Visual Studio, Jetbrains Rider), der gør alt for os. Og selvom vi er dumme, vil de sige, at vi tager fejl. Det virker normalt og naturligt.
Men et sted i nærheden er der VSCode, hvor der er nogle plugins, der på en eller anden måde er installeret, understøttet eller ikke understøttet. Nye versioner kom ud og blev ikke understøttet. En banal overgang til implementering af en funktion (selvom den eksisterer) bliver et komplekst og ikke-trivielt problem. Et simpelt omdøbning af en variabel er en genafspilning i et projekt af et dusin filer. Du vil være heldig, hvis han placerer det, du har brug for. Selvfølgelig er der baggrundsbelysning hist og her, der er autofuldførelse, et eller andet sted er der formatering (selvom det ikke fungerede for mig i terraform på Windows).
I skrivende stund er endnu ikke blevet frigivet til at understøtte version 0.12, selvom den har været udgivet i 3 måneder.
Det er tid til at glemme...
- Fejlretning.
- Refaktoreringsværktøj.
- Autofuldførelse.
- Registrering af fejl under kompilering.
Det er sjovt, men det øger også udviklingstiden og øger antallet af fejl, der uundgåeligt opstår.
Det værste er, at vi er tvunget til ikke at tænke på, hvordan man designer, organiserer filer i mapper, dekomponerer, gør koden vedligeholdbar, læsbar og så videre, men på hvordan jeg kan skrive denne kommando korrekt, fordi jeg på en eller anden måde skrev den forkert. .
Som nybegynder forsøger du at lære terraformer, og IDE'en hjælper dig overhovedet ikke. Når der er dokumentation, så gå ind og kig. Men hvis du skulle indtaste et nyt programmeringssprog, ville IDE fortælle dig, at der er sådan en type, men der er ikke sådan noget. I hvert fald på int- eller strengniveau. Dette er ofte nyttigt.
Hvad med testene?
Du spørger: "Hvad med testene, mine herrer programmører?" Seriøse fyre tester alt i produktionen, og det er svært. Her er et eksempel på en enhedstest til et terraform-modul fra hjemmesiden .
De har god dokumentation. Jeg har altid godt kunne lide Microsoft for dets tilgang til dokumentation og træning. Men du behøver ikke at være onkel Bob for at forstå, at dette ikke er perfekt kode. Bemærk valideringen til højre.
Problemet med en enhedstest er, at du og jeg kan kontrollere rigtigheden af Json-outputtet. Jeg smed 5 parametre ind og fik en Json-fodklud med 2000 linjer. Jeg kan analysere, hvad der foregår her, validere testresultatet...
Det er svært at parse Json i Go. Og du skal skrive i Go, for terraform i Go er en god praksis til at teste på det sprog, du skriver på. Organiseringen af selve koden er meget svag. Samtidig er dette det bedste bibliotek til test.
Microsoft skriver selv sine moduler og tester dem på denne måde. Det er selvfølgelig Open Source. Alt, hvad jeg taler om, kan du komme og ordne. Jeg kan sætte mig ned og ordne alt på en uge, open source VS kode plugins, terraforms, lave et plugin til rytteren. Måske skrive et par analysatorer, tilføje linters, bidrage med et bibliotek til test. Jeg kan alt. Men det er ikke det, jeg burde gøre.
Bedste praksis Infrastruktur som kode
Lad os gå videre. Hvis der ikke er nogen test i IaC, er IDE og tuning dårlige, så burde der i det mindste være bedste praksis. Jeg gik lige til Google Analytics og sammenlignede to søgeforespørgsler: Terraform best practices og c# best practices.
Hvad ser vi? Nådesløse statistikker er ikke til vores fordel. Mængden af materiale er den samme. I C#-udvikling er vi simpelthen oversvømmet af materialer, vi har super-best practices, der er bøger skrevet af eksperter og også bøger skrevet på bøger af andre eksperter, der kritiserer disse bøger. Et hav af officiel dokumentation, artikler, kurser og nu også open source-udvikling.
Med hensyn til IaC-anmodningen: her forsøger du at indsamle information bit for bit fra highload- eller HashiConf-rapporter, fra officiel dokumentation og adskillige problemer på Github. Hvordan distribuerer man disse moduler generelt, hvad skal man gøre med dem? Det ser ud til, at dette er et reelt problem... Der er et fællesskab, mine herrer, hvor du for ethvert spørgsmål vil få 10 kommentarer på Github. Men det er det ikke ligefrem.
Desværre er eksperter lige begyndt at dukke op på dette tidspunkt. Der er for få af dem indtil videre. Og selve samfundet hænger ud på det rudimentære niveau.
Hvor går alt dette hen, og hvad skal man gøre
Du kan droppe alt og gå tilbage til C#, til rytterens verden. Men nej. Hvorfor ville du overhovedet gider at gøre dette, hvis du ikke kan finde en løsning. Nedenfor præsenterer jeg mine subjektive konklusioner. Du kan argumentere med mig i kommentarerne, det bliver interessant.
Personligt satser jeg på et par ting:
- Udviklingen på dette område sker meget hurtigt. Her er en tidsplan for anmodninger om DevOps.
Emnet kan være hype, men selve det, at sfæren vokser, giver håb.Hvis noget vokser så hurtigt, så vil der helt sikkert dukke smarte mennesker op, som vil fortælle dig, hvad du skal gøre, og hvad du ikke skal gøre. Stigningen i popularitet fører til, at nogen måske vil have tid til endelig at tilføje et plugin til jsonnet til vscode, som vil give dig mulighed for at gå videre til at implementere funktionen, i stedet for at søge efter den via ctrl+shift+f. Efterhånden som tingene udvikler sig, dukker flere materialer op. Udgivelsen af en bog fra Google om SRE er et glimrende eksempel på dette.
- Der er udviklede teknikker og praksisser inden for konventionel udvikling, som vi med succes kan anvende her. Ja, der er nuancer med test og et heterogent miljø, utilstrækkeligt værktøj, men et stort antal praksisser er blevet akkumuleret, som kan være nyttige og nyttige.
Et trivielt eksempel: samarbejde gennem parprogrammering. Det hjælper meget at finde ud af det. Når man har en nabo i nærheden, som også forsøger at forstå noget, vil man sammen forstå bedre.
At forstå, hvordan refactoring udføres, hjælper med at udføre det selv i en sådan situation. Det vil sige, du kan ikke ændre alt på én gang, men ændre navngivningen, så ændre placeringen, så kan du fremhæve en del, åh, men der er ikke nok kommentarer her.
Konklusion
På trods af at mit ræsonnement kan virke pessimistisk, ser jeg på fremtiden med håb og håber inderligt, at alt ordner sig for os (og dig).
Anden del af artiklen er under udarbejdelse. I den vil jeg fortælle om, hvordan vi forsøgte at bruge agil udviklingspraksis til at forbedre vores læreproces og arbejde med infrastruktur.
Kilde: www.habr.com