Vårt företag håller på att ta in ett SRE-team. Jag kom in i hela den här historien från utvecklingssidan. I processen kom jag på tankar och insikter som jag vill dela med andra utvecklare. I den här reflektionsartikeln pratar jag om vad som händer, hur det händer, och hur alla kan fortsätta leva med det.
Fortsättning på en serie artiklar skrivna utifrån tal på vårt interna event :
2. Infrastruktur som kod. (Du är här)
3. Generering av Typescript-kontrakt med C#-modeller. (Pågående...)
4. Introduktion till flottens konsensusalgoritm. (Pågående...)
.
Vi bestämde oss för att skapa ett SRE-team som implementerade idéerna . De rekryterade programmerare bland sina egna utvecklare och skickade dem att utbilda sig i flera månader.
Teamet hade följande träningsuppgifter:
- Beskriv vår infrastruktur, som mestadels finns i Microsoft Azure i form av kod (Terraform och allt runt omkring).
- Lär utvecklare hur man arbetar med infrastruktur.
- Förbered utvecklare för tjänst.
Vi introducerar konceptet Infrastruktur som kod
I den vanliga modellen av världen (klassisk administration) finns kunskap om infrastruktur på två ställen:
- Eller i form av kunskap i experternas huvuden.
- Eller så finns den här informationen på vissa skrivmaskiner, av vilka några är kända för experter. Men det är inte ett faktum att en utomstående (ifall hela vårt team plötsligt dör) kommer att kunna ta reda på vad som fungerar och hur det fungerar. Det kan finnas mycket information på en maskin: tillbehör, cronjobs, skrämd (se. ) disk och bara en oändlig lista över vad som kan hända. Det är svårt att förstå vad som verkligen händer.
I båda fallen är vi fångade i att bli beroende:
- eller från en person som är dödlig, utsatt för sjukdom, förälskelse, humörsvängningar och helt enkelt banala uppsägningar;
- eller från en fysiskt fungerande maskin, som också faller, blir stulen och ger överraskningar och olägenheter.
Det säger sig självt att helst bör allt översättas till mänskligt läsbar, underhållbar, välskriven kod.
Infrastruktur som kod (Incfastructure as Code - IaC) är alltså en beskrivning av hela den befintliga infrastrukturen i form av kod, samt relaterade verktyg för att arbeta med den och implementera verklig infrastruktur från den.
Varför översätta allt till kod?Människor är inte maskiner. De kan inte komma ihåg allt. En persons och en maskins reaktion är annorlunda. Allt automatiserat är potentiellt snabbare än något som görs av en människa. Det viktigaste är en enda källa till sanning.
Var kommer nya SRE-ingenjörer ifrån?Så vi bestämde oss för att anställa nya SRE-ingenjörer, men var ska vi få dem ifrån? Boka med rätt svar () berättar: från utvecklarna. När allt kommer omkring arbetar de med koden, och du uppnår det ideala tillståndet.
Vi letade länge efter dem på personalmarknaden utanför vårt företag. Men vi måste erkänna att vi inte hittade någon som passade våra önskemål. Jag var tvungen att söka bland mitt eget folk.
Problem Infrastruktur som kod
Låt oss nu titta på exempel på hur infrastruktur kan hårdkodas till kod. Koden är välskriven, hög kvalitet, med kommentarer och indrag.
Exempelkod från Terraforma.
Exempelkod från Ansible.
Mina herrar, om det bara vore så enkelt! Vi är i den verkliga världen, och den är alltid redo att överraska dig, ge dig överraskningar och problem. Kan inte vara utan dem här heller.
1. Det första problemet är att IaC i de flesta fall är någon form av dsl.
Och DSL är i sin tur en beskrivning av strukturen. Mer exakt, vad du bör ha: Json, Yaml, modifieringar från några stora företag som kom med sin egen dsl (HCL används i terraform).
Problemet är att det lätt kanske inte innehåller sådana bekanta saker som:
- variabler;
- betingelser;
- någonstans finns det inga kommentarer, till exempel i Json, som standard tillhandahålls de inte;
- funktioner;
- och jag pratar inte ens om sådana saker på hög nivå som klasser, arv och allt det där.
2. Det andra problemet med sådan kod är att det oftast är en heterogen miljö. Oftast sitter man och jobbar med C#, d.v.s. med ett språk, en stack, ett ekosystem. Och här har du ett stort utbud av tekniker.
Det är en mycket verklig situation när bash med python startar någon process där Json infogas. Du analyserar det, sedan producerar någon annan generator ytterligare 30 filer. För allt detta tas indatavariabler emot från Azure Key Vault, som dras ihop av en plugin för drone.io skriven i Go, och dessa variabler passerar genom yaml, som genererades som ett resultat av generering från jsonnet-mallmotorn. Det är ganska svårt att ha strikt väl beskriven kod när man har en så varierad miljö.
Traditionell utveckling inom ramen för en uppgift kommer med ett språk. Här arbetar vi med ett stort antal språk.
3. Det tredje problemet är tuning. Vi är vana vid coola redaktörer (Ms Visual Studio, Jetbrains Rider) som gör allt för oss. Och även om vi är dumma kommer de att säga att vi har fel. Det verkar normalt och naturligt.
Men någonstans i närheten finns VSCode, där det finns några plugins som på något sätt är installerade, stöds eller inte stöds. Nya versioner kom ut och stöddes inte. En banal övergång till att implementera en funktion (även om den existerar) blir ett komplext och icke-trivialt problem. Ett enkelt byte av en variabel är en repris i ett projekt med ett dussin filer. Du kommer att ha tur om han placerar det du behöver. Naturligtvis finns det bakgrundsbelysning här och där, det finns autokomplettering, någonstans finns det formatering (även om det inte fungerade för mig i terraform på Windows).
När detta skrivs har ännu inte släppts för att stödja version 0.12, även om den har släppts i 3 månader.
Det är dags att glömma...
- Felsökning.
- Refaktoreringsverktyg.
- Automatisk komplettering.
- Upptäcker fel under kompilering.
Det är roligt, men detta ökar också utvecklingstiden och ökar antalet fel som oundvikligen uppstår.
Det värsta är att vi tvingas att inte tänka på hur man designar, organiserar filer i mappar, dekomponerar, gör koden underhållbar, läsbar och så vidare, utan på hur jag kan skriva det här kommandot korrekt, eftersom jag på något sätt skrev det fel .
Som nybörjare försöker du lära dig terraformer, och IDE hjälper dig inte alls. När det finns dokumentation, gå in och titta. Men om du skulle skriva in ett nytt programmeringsspråk, skulle IDE berätta för dig att det finns en sådan typ, men det finns inget sådant. Åtminstone på int- eller strängnivå. Detta är ofta användbart.
Hur är det med testerna?
Du frågar: "Hur är det med testerna, mina herrar programmerare?" Seriösa killar testar allt på produktion, och det är tufft. Här är ett exempel på ett enhetstest för en terraform-modul från webbplatsen .
De har bra dokumentation. Jag har alltid gillat Microsoft för dess inställning till dokumentation och utbildning. Men du behöver inte vara farbror Bob för att förstå att detta inte är perfekt kod. Notera valideringen till höger.
Problemet med ett enhetstest är att du och jag kan kontrollera att Json-utgången är korrekt. Jag kastade in 5 parametrar och fick en Json-fotduk med 2000 linjer. Jag kan analysera vad som händer här, validera testresultat...
Det är svårt att analysera Json i Go. Och du måste skriva i Go, eftersom terraform i Go är en bra praxis för att testa på det språk du skriver på. Organisationen av själva koden är mycket svag. Samtidigt är detta det bästa biblioteket för att testa.
Microsoft skriver själva sina moduler och testar dem på detta sätt. Självklart är det öppen källkod. Allt jag pratar om kan du komma och fixa. Jag kan sätta mig ner och fixa allt på en vecka, open source VS-kodplugins, terraforms, göra ett plugin för ryttaren. Kanske skriva ett par analysatorer, lägga till linters, bidra med ett bibliotek för testning. Jag kan göra allt. Men det är inte vad jag borde göra.
Bästa metoder Infrastruktur som kod
Låt oss gå vidare. Om det inte finns några tester i IaC, IDE och tuning är dåliga, så borde det åtminstone finnas bästa praxis. Jag gick precis till Google Analytics och jämförde två sökfrågor: Terraforms bästa praxis och c# bästa praxis.
Vad ser vi? Hänsynslös statistik är inte till vår fördel. Mängden material är densamma. I C#-utveckling är vi helt enkelt översvämmade av material, vi har superbästa metoder, det finns böcker skrivna av experter och även böcker skrivna om böcker av andra experter som kritiserar dessa böcker. Ett hav av officiell dokumentation, artiklar, utbildningar och nu även utveckling av öppen källkod.
När det gäller IaC-förfrågan: här försöker du samla in information bit för bit från highload- eller HashiConf-rapporter, från officiell dokumentation och många problem på Github. Hur distribuerar man dessa moduler i allmänhet, vad ska man göra med dem? Det verkar som att detta är ett verkligt problem... Det finns en gemenskap, mina herrar, där ni kommer att få 10 kommentarer på Github för alla frågor. Men det är det inte precis.
Tyvärr, vid denna tidpunkt, har experter bara börjat dyka upp. Det är för få av dem än så länge. Och själva samhället hänger på den rudimentära nivån.
Vart är allt detta på väg och vad man ska göra
Du kan släppa allt och gå tillbaka till C#, till ryttarens värld. Men nej. Varför skulle du ens bry dig om att göra det här om du inte kan hitta en lösning. Nedan presenterar jag mina subjektiva slutsatser. Du kan argumentera med mig i kommentarerna, det kommer att bli intressant.
Personligen satsar jag på några saker:
- Utvecklingen inom detta område går mycket snabbt. Här är ett schema över förfrågningar för DevOps.
Ämnet kan vara hype, men själva det faktum att sfären växer ger lite hopp.Om något växer så snabbt, kommer definitivt smarta människor att dyka upp som kommer att berätta för dig vad du ska göra och vad du inte ska göra. Ökningen i popularitet leder till att någon kanske hinner äntligen lägga till ett plugin till jsonnet för vscode, vilket gör att du kan gå vidare till att implementera funktionen, snarare än att söka efter den via ctrl+shift+f. När saker och ting utvecklas dyker det upp fler material. Utgivningen av en bok från Google om SRE är ett utmärkt exempel på detta.
- Det finns utvecklade tekniker och metoder inom konventionell utveckling som vi framgångsrikt kan tillämpa här. Ja, det finns nyanser med testning och en heterogen miljö, otillräckliga verktyg, men ett stort antal metoder har samlats som kan vara användbara och användbara.
Ett trivialt exempel: samarbete genom parprogrammering. Det hjälper mycket att ta reda på det. När du har en granne i närheten som också försöker förstå något så kommer ni tillsammans att förstå bättre.
Att förstå hur refactoring görs hjälper till att genomföra det även i en sådan situation. Det vill säga, du kan inte ändra allt på en gång, utan ändra namnet, sedan ändra platsen, sedan kan du markera någon del, oj, men det finns inte tillräckligt med kommentarer här.
Slutsats
Trots att mitt resonemang kan verka pessimistiskt ser jag på framtiden med hopp och hoppas innerligt att allt ska lösa sig för oss (och dig).
Den andra delen av artikeln förbereds härnäst. I den kommer jag att prata om hur vi försökte använda agila utvecklingsmetoder för att förbättra vår inlärningsprocess och arbeta med infrastruktur.
Källa: will.com