Ons maatskappy is besig om 'n SRE-span aan te sluit. Ek het in hierdie hele storie van die ontwikkelingskant af gekom. In die proses het ek met gedagtes en insigte vorendag gekom wat ek met ander ontwikkelaars wil deel. In hierdie refleksie-artikel praat ek oor wat aan die gebeur is, hoe dit gebeur, en hoe almal daarmee kan voortleef.
Voortsetting van 'n reeks artikels wat geskryf is op grond van toesprake by ons interne geleentheid :
2. Infrastruktuur as kode. (Jy is hier)
3. Generering van Typescript-kontrakte deur C#-modelle te gebruik. (Besig om...)
4. Inleiding tot die Raft-konsensusalgoritme. (Besig om...)
...
Ons het besluit om 'n SRE-span te skep en die idees te implementeer . Hulle het programmeerders uit hul eie ontwikkelaars gewerf en hulle vir etlike maande gestuur om op te lei.
Die span het die volgende opleidingstake gehad:
- Beskryf ons infrastruktuur, wat meestal in Microsoft Azure is in die vorm van kode (Terraform en alles rondom).
- Leer ontwikkelaars hoe om met infrastruktuur te werk.
- Berei ontwikkelaars voor vir diens.
Ons stel die konsep van Infrastruktuur as kode bekend
In die gewone model van die wêreld (klassieke administrasie) is kennis oor infrastruktuur op twee plekke geleë:
- Of in die vorm van kennis in die koppe van kundiges.
- Of hierdie inligting is op sommige tikmasjiene, waarvan sommige aan kenners bekend is. Maar dit is nie 'n feit dat 'n buitestander (indien ons hele span skielik sterf) sal kan uitvind wat werk en hoe dit werk nie. Daar kan baie inligting op 'n masjien wees: bykomstighede, cronjobs, geïntimideer (sien. ) skyf en net 'n eindelose lys van wat kan gebeur. Dit is moeilik om te verstaan wat werklik aan die gebeur is.
In beide gevalle vind ons onsself vasgevang om afhanklik te word:
- of van 'n persoon wat sterflik is, onderhewig is aan siekte, verliefdheid, buierigheid en bloot banale afdankings;
- of van 'n fisies werkende masjien, wat ook val, gesteel word en verrassings en ongerief bied.
Dit spreek vanself dat ideaal gesproke alles in mensleesbare, handhaafbare, goedgeskrewe kode vertaal moet word.
Dus, infrastruktuur as kode (Incfastructure as Code - IaC) is 'n beskrywing van die hele bestaande infrastruktuur in die vorm van kode, sowel as verwante hulpmiddels om daarmee te werk en werklike infrastruktuur daaruit te implementeer.
Hoekom alles in kode vertaal?Mense is nie masjiene nie. Hulle kan nie alles onthou nie. Die reaksie van 'n persoon en 'n masjien is anders. Enigiets outomaties is potensieel vinniger as enigiets wat deur 'n mens gedoen word. Die belangrikste ding is 'n enkele bron van waarheid.
Waar kom nuwe SRE-ingenieurs vandaan?So, ons het besluit om nuwe SRE-ingenieurs aan te stel, maar waar om hulle vandaan te kry? Boek met korrekte antwoorde () vertel ons: van die ontwikkelaars. Hulle werk immers met die kode, en jy bereik die ideale toestand.
Ons het baie lank na hulle op die personeelmark buite ons maatskappy gesoek. Maar ons moet erken dat ons niemand gevind het wat by ons versoeke pas nie. Ek moes tussen my eie mense soek.
Probleme Infrastruktuur as kode
Kom ons kyk nou na voorbeelde van hoe infrastruktuur hardkodeer kan word in kode. Die kode is goed geskryf, van hoë gehalte, met opmerkings en inkepings.
Voorbeeld kode van Terraforma.
Voorbeeldkode van Ansible.
Menere, as dit net so eenvoudig was! Ons is in die regte wêreld, en dit is altyd gereed om jou te verras, verrassings en probleme aan jou te bied. Kan ook nie hier sonder hulle klaarkom nie.
1. Die eerste probleem is dat IaC in die meeste gevalle 'n soort dsl is.
En DSL is op sy beurt 'n beskrywing van die struktuur. Meer presies, wat jy moet hê: Json, Yaml, wysigings van sommige groot maatskappye wat met hul eie dsl vorendag gekom het (HCL word in terraform gebruik).
Die probleem is dat dit maklik nie sulke bekende dinge bevat soos:
- veranderlikes;
- toestande;
- iewers is daar geen opmerkings nie, byvoorbeeld in Json, by verstek word dit nie verskaf nie;
- funksies;
- en ek praat nie eers van sulke hoëvlak goed soos klasse, erfenis en al die dinge nie.
2. Die tweede probleem met so 'n kode is dat dit meestal 'n heterogene omgewing is. Gewoonlik sit jy en werk met C#, m.a.w. met een taal, een stapel, een ekosisteem. En hier het jy 'n groot verskeidenheid tegnologieë.
Dit is 'n baie werklike situasie wanneer bash met python een of ander proses begin waarin Json ingevoeg word. Jy ontleed dit, dan produseer 'n ander kragopwekker nog 30 lêers. Vir dit alles word invoerveranderlikes van Azure Key Vault ontvang, wat saamgetrek word deur 'n inprop vir drone.io wat in Go geskryf is, en hierdie veranderlikes gaan deur yaml, wat gegenereer is as gevolg van generering vanaf die jsonnet-sjabloonenjin. Dit is nogal moeilik om 'n streng goed beskryfde kode te hê as jy so 'n diverse omgewing het.
Tradisionele ontwikkeling binne die raamwerk van een taak kom met een taal. Hier werk ons met 'n groot aantal tale.
3. Die derde probleem is tuning. Ons is gewoond aan koel redakteurs (Me Visual Studio, Jetbrains Rider) wat alles vir ons doen. En al is ons dom, sal hulle sê dat ons verkeerd is. Dit lyk normaal en natuurlik.
Maar iewers naby is daar VSCode, waarin daar 'n paar plugins is wat op een of ander manier geïnstalleer, ondersteun of nie ondersteun word nie. Nuwe weergawes het uitgekom en is nie ondersteun nie. 'n Banale oorgang na die implementering van 'n funksie (selfs al bestaan dit) word 'n komplekse en nie-triviale probleem. 'n Eenvoudige hernaam van 'n veranderlike is 'n herhaling in 'n projek van 'n dosyn lêers. Jy sal gelukkig wees as hy plaas wat jy nodig het. Natuurlik is daar hier en daar agtergrondbeligting, daar is outo-voltooiing, iewers is daar formatering (alhoewel dit nie vir my in terraform op Windows gewerk het nie).
Ten tyde van hierdie skrywe is nog nie vrygestel om weergawe 0.12 te ondersteun nie, alhoewel dit vir 3 maande vrygestel is.
Dis tyd om te vergeet van...
- Ontfouting.
- Refactoring gereedskap.
- Outo-voltooiing.
- Bespeur foute tydens samestelling.
Dit is snaaks, maar dit verhoog ook die ontwikkelingstyd en verhoog die aantal foute wat onvermydelik voorkom.
Die ergste is dat ons gedwing word om nie te dink oor hoe om te ontwerp, lêers in vouers te organiseer, te ontbind, die kode onderhoubaar, leesbaar te maak, ensovoorts nie, maar oor hoe ek hierdie opdrag korrek kan skryf, want ek het dit op een of ander manier verkeerd geskryf .
As 'n beginner probeer jy terraforms aanleer, en die IDE help jou glad nie. Wanneer daar dokumentasie is, gaan in en kyk. Maar as jy 'n nuwe programmeertaal betree, sal die IDE vir jou sê dat daar so 'n tipe is, maar daar is nie so iets nie. Ten minste op die int- of stringvlak. Dit is dikwels nuttig.
Wat van die toetse?
Jy vra: "Wat van die toetse, menere programmeerders?" Ernstige ouens toets alles op produksie, en dit is moeilik. Hier is 'n voorbeeld van 'n eenheidstoets vir 'n terraform-module vanaf die webwerf .
Hulle het goeie dokumentasie. Ek het nog altyd van Microsoft gehou vir sy benadering tot dokumentasie en opleiding. Maar jy hoef nie oom Bob te wees om te verstaan dat dit nie perfekte kode is nie. Let op die bekragtiging aan die regterkant.
Die probleem met 'n eenheidstoets is dat ek en jy die korrektheid van die Json-uitset kan kontroleer. Ek het 5 parameters ingegooi en 'n Json-voetlap met 2000 lyne gekry. Ek kan ontleed wat hier aangaan, toetsuitslag bevestig ...
Dit is moeilik om Json in Go te ontleed. En jy moet in Go skryf, want terraform in Go is 'n goeie praktyk om te toets in die taal waarin jy skryf. Die organisasie van die kode self is baie swak. Terselfdertyd is dit die beste biblioteek om te toets.
Microsoft skryf self sy modules en toets dit op hierdie manier. Natuurlik is dit oopbron. Alles waarvan ek praat kan jy kom regmaak. Ek kan sit en alles regmaak in 'n week, open source VS-kode plugins, terraforms, maak 'n plugin vir die ruiter. Skryf dalk 'n paar ontleders, voeg linters by, dra 'n biblioteek by om te toets. Ek kan alles doen. Maar dit is nie wat ek moet doen nie.
Beste praktyke Infrastruktuur as kode
Kom ons gaan aan. As daar geen toetse in IaC is nie, is die IDE en tuning sleg, dan behoort daar ten minste beste praktyke te wees. Ek het net na Google Analytics gegaan en twee soeknavrae vergelyk: Terraform beste praktyke en c# beste praktyke.
Wat sien ons? Meedoënlose statistieke is nie in ons guns nie. Die hoeveelheid materiaal is dieselfde. In C#-ontwikkeling is ons eenvoudig oorspoel met materiaal, ons het super-beste praktyke, daar is boeke geskryf deur kundiges, en ook boeke geskryf oor boeke deur ander kundiges wat daardie boeke kritiseer. 'n See van amptelike dokumentasie, artikels, opleidingskursusse en nou ook oopbronontwikkeling.
Wat die IaC-versoek betref: hier probeer jy bietjie vir bietjie inligting insamel uit highload- of HashiConf-verslae, uit amptelike dokumentasie en talle kwessies op Github. Hoe om hierdie modules in die algemeen te versprei, wat om daarmee te doen? Dit blyk dat dit 'n werklike probleem is ... Daar is 'n gemeenskap, menere, waar vir enige vraag aan u 10 kommentaar op Github gegee sal word. Maar dit is nie presies nie.
Ongelukkig begin kenners op hierdie tydstip net na vore kom. Daar is tot dusver te min van hulle. En die gemeenskap self kuier op die rudimentêre vlak.
Waar gaan dit alles en wat om te doen
Jy kan alles laat val en teruggaan na C#, na die wêreld van die ruiter. Maar nee. Hoekom sal jy selfs die moeite doen om dit te doen as jy nie 'n oplossing kan vind nie. Hieronder gee ek my subjektiewe gevolgtrekkings. Jy kan met my stry in die kommentaar, dit sal interessant wees.
Persoonlik wed ek op 'n paar dinge:
- Ontwikkeling op hierdie gebied vind baie vinnig plaas. Hier is 'n skedule van versoeke vir DevOps.
Die onderwerp is dalk hype, maar die feit dat die sfeer groei, gee 'n bietjie hoop.As iets so vinnig groei, dan sal daar beslis slim mense verskyn wat vir jou sal sê wat om te doen en wat om nie te doen nie. Die toename in gewildheid lei daartoe dat iemand dalk tyd sal hê om uiteindelik 'n inprop by jsonnet vir vscode te voeg, wat jou sal toelaat om voort te gaan met die implementering van die funksie, eerder as om daarna te soek via ctrl+shift+f. Soos dinge ontwikkel, verskyn meer materiale. Die vrystelling van 'n boek van Google oor SRE is 'n uitstekende voorbeeld hiervan.
- Daar is ontwikkelde tegnieke en praktyke in konvensionele ontwikkeling wat ons suksesvol hier kan toepas. Ja, daar is nuanses met toetsing en 'n heterogene omgewing, onvoldoende gereedskap, maar 'n groot aantal praktyke is opgehoop wat nuttig en nuttig kan wees.
'n Triviale voorbeeld: samewerking deur paarprogrammering. Dit help baie om dit uit te vind. Wanneer jy ’n buurman naby het wat ook iets probeer verstaan, sal julle saam beter verstaan.
Om te verstaan hoe herfaktorering gedoen word, help om dit selfs in so 'n situasie uit te voer. Dit wil sê, jy kan nie alles gelyktydig verander nie, maar die naam verander, dan die ligging verander, dan kan jy 'n deel uitlig, o, maar hier is nie genoeg opmerkings nie.
Gevolgtrekking
Ten spyte van die feit dat my redenasie dalk pessimisties lyk, kyk ek met hoop na die toekoms en hoop van harte dat alles vir ons (en jou) sal uitwerk.
Die tweede deel van die artikel word volgende voorberei. Hierin sal ek praat oor hoe ons probeer het om ratse ontwikkelingspraktyke te gebruik om ons leerproses te verbeter en met infrastruktuur te werk.
Bron: will.com