Meie ettevõttes on käimas SRE meeskonna ühendamine. Tulin kogu sellesse loosse arengu poolelt. Selle käigus tekkisid mul mõtted ja arusaamad, mida tahan teiste arendajatega jagada. Selles mõtisklusartiklis räägin sellest, mis toimub, kuidas see toimub ja kuidas igaüks saab sellega edasi elada.
Meie siseüritusel peetud kõnede põhjal kirjutatud artiklite sarja jätk :
2. Infrastruktuur kui kood. (Sa oled siin)
3. Typescripti lepingute genereerimine C# mudelite abil. (Käimas...)
4. Parve konsensusalgoritmi tutvustus. (Käimas...)
...
Otsustasime ideid ellu viia SRE meeskonna . Nad värbasid programmeerijaid enda arendajate hulgast ja saatsid nad mitmeks kuuks koolitama.
Meeskonnal olid järgmised treeningülesanded:
- Kirjeldage meie infrastruktuuri, mis on enamasti Microsoft Azure'is koodi kujul (Terraform ja kõik selle ümber).
- Õpetage arendajatele infrastruktuuriga töötamist.
- Valmistage arendajad tööks ette.
Tutvustame infrastruktuuri kui koodi mõistet
Tavapärases maailmamudelis (klassikaline haldus) asuvad teadmised infrastruktuurist kahes kohas:
- Või teadmiste näol asjatundjate peas.
- Või on see teave mõnel kirjutusmasinal, millest mõned on ekspertidele teada. Kuid see ei ole tõsiasi, et kõrvalseisja (juhul kui kogu meie meeskond ootamatult sureb) saab aru, mis töötab ja kuidas see töötab. Masina kohta võib olla palju teavet: tarvikud, töökohad, hirmutatud (vt. ) ketas ja lihtsalt lõputu nimekiri sellest, mis võib juhtuda. Raske on mõista, mis tegelikult toimub.
Mõlemal juhul leiame end sõltuvuses:
- või inimeselt, kes on surelik, kannatab haiguste, armumise, meeleolumuutuste ja lihtsalt banaalsete koondamiste all;
- või füüsiliselt töötavast masinast, mis samuti kukub, varastatakse ning toob üllatusi ja ebameeldivusi.
On ütlematagi selge, et ideaalis tuleks kõik tõlkida inimloetavaks, hooldatavaks ja hästi kirjutatud koodiks.
Seega on infrastruktuur koodina (Incfastructure as Code - IaC) kogu olemasoleva taristu kirjeldus koodi kujul, aga ka sellega seotud tööriistad sellega töötamiseks ja sellest reaalse infrastruktuuri juurutamiseks.
Miks tõlkida kõik koodiks?Inimesed ei ole masinad. Nad ei mäleta kõike. Inimese ja masina reaktsioon on erinev. Kõik automatiseeritud on potentsiaalselt kiirem kui kõik, mida inimene teeb. Kõige tähtsam on üksainus tõeallikas.
Kust tulevad uued SRE insenerid?Niisiis otsustasime palgata uued SRE insenerid, kuid kust neid saada? Õigete vastustega raamat () ütleb meile: arendajatelt. Lõppude lõpuks töötavad nad koodiga ja te saavutate ideaalse oleku.
Otsisime neid pikka aega personaliturult väljaspool meie ettevõtet. Kuid peame tunnistama, et me ei leidnud kedagi, kes meie soovidele vastaks. Pidin otsima omade seast.
Probleemid Infrastruktuur kui kood
Vaatame nüüd näiteid selle kohta, kuidas infrastruktuuri saab koodiks kõvasti kodeerida. Kood on hästi kirjutatud, kvaliteetne, kommentaaride ja taandega.
Näidiskood Terraformast.
Näidiskood Ansible'ist.
Härrased, kui see vaid nii lihtne oleks! Oleme reaalses maailmas ja see on alati valmis teid üllatama, üllatusi ja probleeme esitama. Ilma nendeta ei saa ka siin.
1. Esimene probleem seisneb selles, et enamikul juhtudel on IaC mingi dsl.
Ja DSL on omakorda struktuuri kirjeldus. Täpsemalt, mis teil peaks olema: Json, Yaml, mõne suure ettevõtte modifikatsioonid, mis tulid välja oma dsl-iga (terraformis kasutatakse HCL-i).
Probleem on selles, et see ei pruugi sisaldada selliseid tuttavaid asju nagu:
- muutujad;
- tingimused;
- kuskil puuduvad kommentaarid, näiteks Jsonis, vaikimisi neid ei pakuta;
- funktsioonid;
- ja ma isegi ei räägi sellistest kõrgetasemelistest asjadest nagu klassid, pärimine ja kõik muu.
2. Teiseks sellise koodi probleemiks on see, et enamasti on tegemist heterogeense keskkonnaga. Tavaliselt istud ja töötad C#-ga, st. ühe keele, ühe virna, ühe ökosüsteemiga. Ja siin on teil tohutult erinevaid tehnoloogiaid.
See on väga reaalne olukord, kui bash koos pythoniga käivitab protsessi, millesse Json sisestatakse. Analüüsid seda, siis mõni teine generaator toodab veel 30 faili. Kõige selle jaoks võetakse Azure Key Vaultilt vastu sisendmuutujad, mis tõmmatakse kokku Go-s kirjutatud drone.io pluginaga ja need muutujad läbivad yamli, mis genereeriti jsonneti mallimootorist genereerimise tulemusena. Nii mitmekesise keskkonna korral on üsna raske omada rangelt hästi kirjeldatud koodi.
Traditsiooniline areng ühe ülesande raames tuleb ühe keelega. Siin töötame paljude keeltega.
3. Kolmas probleem on häälestamine. Oleme harjunud lahedate toimetajatega (Ms Visual Studio, Jetbrains Rider), kes teevad kõik meie eest ära. Ja isegi kui me oleme rumalad, öeldakse, et me eksime. Tundub normaalne ja loomulik.
Kuid kuskil lähedal on VSCode, milles on mõned pluginad, mis on kuidagi installitud, toetatud või mitte. Uued versioonid ilmusid ja neid ei toetatud. Banaalne üleminek funktsiooni rakendamisele (isegi kui see on olemas) muutub keeruliseks ja mittetriviaalseks probleemiks. Muutuja lihtne ümbernimetamine on tosinast failist koosneva projekti taasesitus. Teil veab, kui ta paneb teile vajaliku. Muidugi on siin-seal taustvalgustus, on automaatne lõpetamine, kuskil on vormindamine (kuigi terraformaadis see Windowsis minu jaoks ei töötanud).
Selle kirjutamise ajal pole veel versiooni 0.12 toetamiseks välja antud, kuigi see on välja antud 3 kuud.
On aeg unustada...
- Silumine.
- Refaktori tööriist.
- Automaatne lõpetamine.
- Vigade tuvastamine kompileerimise ajal.
See on naljakas, kuid see pikendab ka arendusaega ja suurendab paratamatult tekkivate vigade arvu.
Kõige hullem on see, et me oleme sunnitud mõtlema mitte sellele, kuidas kujundada, faile kaustadesse korraldada, lagundada, muuta kood hooldatavaks, loetavaks ja nii edasi, vaid sellele, kuidas ma saan selle käsu õigesti kirjutada, sest ma kirjutasin selle kuidagi valesti. .
Algajana proovite õppida terravorme ja IDE ei aita teid üldse. Kui dokumentatsioon käes, minge sisse ja vaadake. Kui aga sisestaksite uude programmeerimiskeelt, teataks IDE teile, et selline tüüp on olemas, kuid sellist asja pole. Vähemalt int või stringi tasemel. See on sageli kasulik.
Aga testid?
Te küsite: "Aga testidega, härrased programmeerijad?" Tõsised mehed katsetavad kõike tootmises ja see on raske. Siin on näide terraformi mooduli ühikutestist veebisaidilt .
Neil on korralik dokumentatsioon. Microsoft on mulle alati meeldinud selle lähenemise tõttu dokumenteerimisele ja koolitusele. Kuid te ei pea olema onu Bob, et mõista, et see pole täiuslik kood. Pange tähele paremal olevat kinnitust.
Ühikutesti probleem seisneb selles, et teie ja mina saame kontrollida Jsoni väljundi õigsust. Viskasin 5 parameetrit ja mulle anti 2000 joonega Json jalalapp. Saan siin toimuvat analüüsida, testitulemust kinnitada...
Jsoni on Go-s raske sõeluda. Ja peate kirjutama Go keeles, sest terraform in Go on hea tava testimiseks selles keeles, milles kirjutate. Koodi enda korraldus on väga nõrk. Samal ajal on see testimiseks parim raamatukogu.
Microsoft kirjutab ise oma moodulid, testides neid sel viisil. Loomulikult on see avatud lähtekoodiga. Kõik, millest ma räägin, võite tulla ja parandada. Saan maha istuda ja nädalaga kõik korda teha, avada lähtekoodiga VS koodi pluginad, terraformid, teha sõitjale plugina. Võib-olla kirjutage paar analüsaatorit, lisage lintereid, panustage testimiseks raamatukogu. Ma saan kõike teha. Aga ma ei peaks seda tegema.
Parimad tavad Infrastruktuur koodina
Liigume edasi. Kui IaC-s pole teste, IDE ja häälestus on halvad, siis peaksid olema vähemalt parimad tavad. Käisin just Google Analyticsis ja võrdlesin kahte otsingupäringut: Terraformi parimad tavad ja c# parimad tavad.
Mida me näeme? Halastamatu statistika ei ole meie kasuks. Materjali kogus on sama. C# arenduses oleme lihtsalt materjalidest tulvil, meil on super-parimad tavad, on raamatuid, mille on kirjutanud eksperdid, ja ka raamatuid, mis on kirjutatud teiste ekspertide raamatutele, kes neid raamatuid kritiseerivad. Meri ametlikku dokumentatsiooni, artikleid, koolitusi ja nüüd ka avatud lähtekoodiga arendust.
Mis puudutab IaC päringut: siin proovite koguda teavet osade kaupa highloadi või HashiConfi aruannetest, ametlikust dokumentatsioonist ja paljudest Githubi probleemidest. Kuidas neid mooduleid üldiselt levitada, mida nendega teha? Tundub, et see on tõeline probleem... Härrased, on kogukond, kus iga küsimuse kohta antakse teile Githubis 10 kommentaari. Kuid see pole täpselt nii.
Kahjuks on praegusel hetkel eksperdid alles hakanud tekkima. Neid on seni liiga vähe. Ja kogukond ise poeb algelisel tasemel.
Kuhu see kõik läheb ja mida teha
Võite kõik maha jätta ja minna tagasi C#-sse, sõitjate maailma. Kuid mitte. Miks te üldse vaevaksite seda teha, kui te ei leia lahendust. Allpool esitan oma subjektiivsed järeldused. Võite minuga kommentaarides vaielda, see saab olema huvitav.
Isiklikult panustan mõne asja peale:
- Areng selles valdkonnas toimub väga kiiresti. Siin on DevOpsi taotluste ajakava.
Teema võib olla hype, aga juba see, et sfäär kasvab, annab lootust.Kui miski nii kiiresti kasvab, siis ilmuvad kindlasti targad inimesed, kes ütlevad, mida teha ja mida mitte. Populaarsuse kasv toob kaasa asjaolu, et ehk on kellelgi aega jsonnetisse vscode jaoks lõpuks plugin lisada, mis võimaldab edasi liikuda funktsiooni juurutamise juurde, mitte seda ctrl+shift+f abil otsida. Asjade arenedes ilmub rohkem materjale. Google'i SRE-teemalise raamatu väljaandmine on selle suurepärane näide.
- Tavaarenduses on välja töötatud tehnikad ja praktikad, mida saame siin edukalt rakendada. Jah, testimisel on nüansse ja heterogeenset keskkonda, ebapiisav tööriist, kuid kogunenud on tohutult palju praktikaid, millest võib kasu ja abi olla.
Triviaalne näide: koostöö paarisprogrammeerimise kaudu. Selle väljaselgitamine aitab palju. Kui läheduses on naaber, kes samuti üritab millestki aru saada, saate koos paremini aru.
Refaktori tegemise mõistmine aitab seda ka sellises olukorras läbi viia. See tähendab, et te ei saa kõike korraga muuta, vaid muuta nimetust, seejärel asukohta, siis saate mõne osa esile tõsta, oh, aga siin pole piisavalt kommentaare.
Järeldus
Vaatamata sellele, et mu arutluskäik võib tunduda pessimistlik, vaatan tulevikku lootusrikkalt ja loodan siiralt, et meil (ja teil) kõik läheb korda.
Järgmisena valmistatakse ette artikli teist osa. Selles räägin sellest, kuidas püüdsime kasutada agiilseid arenduspraktikaid oma õppeprotsessi täiustamiseks ja infrastruktuuriga töötamiseks.
Allikas: www.habr.com