Gure enpresa SRE talde bat sartzeko prozesuan dago. Istorio guzti honetan garapenaren aldetik sartu naiz. Prozesuan, beste garatzaile batzuekin partekatu nahi ditudan pentsamenduak eta ikuspegiak sortu zitzaizkidan. Hausnarketa artikulu honetan gertatzen ari denaz, nola gertatzen den eta denek bizitzen jarraitu dezaketenaz hitz egiten dut.
Gure barne ekitaldiko hitzaldietan oinarrituta idatzitako artikulu sortaren jarraipena :
2. Azpiegitura kode gisa. (Hemen zaude)
3. C# ereduak erabiliz Typescript kontratuak sortzea. (Abian...)
4. Raft adostasun algoritmoaren sarrera. (Abian...)
...
SRE talde bat sortzea erabaki genuen, ideiak gauzatuz . Beren garatzaileen artean programatzaileak kontratatu zituzten eta hainbat hilabetez trebatzera bidali zituzten.
Taldeak honako prestakuntza zeregin hauek izan zituen:
- Deskribatu gure azpiegitura, gehienbat Microsoft Azure-n dagoena kode moduan (Terraform eta inguruko guztia).
- Irakatsi garatzaileei azpiegiturarekin lan egiten.
- Prestatu garatzaileak betebeharretarako.
Azpiegitura kontzeptua kode gisa aurkezten dugu
Munduko ohiko ereduan (administrazio klasikoan), azpiegituren inguruko ezagutza bi lekutan kokatzen da:
- Edo jakintza moduan adituen buruetan.
- Edo informazio hori idazmakina batzuetan dago, horietako batzuk adituek ezagutzen dituztenak. Baina ez da kontua kanpoko batek (gure talde osoa bat-batean hiltzen bada) zer funtzionatzen duen eta nola funtzionatzen duen jakiteko gai izango denik. Makina batean informazio asko egon daiteke: osagarriak, cronjobs, beldurrak (ikus. ) diskoa eta gerta daitekeenaren zerrenda amaigabea besterik ez. Zaila da benetan gertatzen ari dena ulertzea.
Bi kasuetan, menpekotasunean harrapatuta aurkitzen gara:
- edo hilkorra den pertsona batengandik, gaixotasunaren mende dagoena, maitemintzea, aldarte aldaketak eta kaleratze hutsalak besterik ez;
- edo fisikoki lan egiten duen makina batetik, erortzen den, lapurtzen duten eta sorpresak eta eragozpenak sortzen dituena.
Esan gabe doa dena gizakiek irakur daitekeen, mantendu daitekeen eta ondo idatzitako kode batera itzuli behar dela.
Beraz, azpiegitura kode gisa (Incfastructure as Code - IaC) dagoen azpiegitura osoaren deskribapena da kode moduan, baita harekin lan egiteko eta bertatik benetako azpiegitura ezartzeko erlazionatutako tresnak ere.
Zergatik itzuli dena kodean?Pertsonak ez dira makinak. Ezin dute dena gogoratzen. Pertsona baten eta makina baten erreakzioa ezberdina da. Automatizatutako edozein gauza potentzialki azkarragoa da gizaki batek egiten duena baino. Garrantzitsuena egia iturri bakarra da.
Nondik datoz SRE ingeniari berriak?Beraz, SRE ingeniari berriak kontratatzea erabaki genuen, baina nondik atera? Erantzun zuzenekin liburua () esaten digu: garatzaileetatik. Azken finean, kodearekin lan egiten dute, eta egoera ideala lortzen duzu.
Asko bilatu genuen denbora luzez gure enpresatik kanpoko langileen merkatuan. Baina aitortu behar dugu ez dugula aurkitu gure eskaerei egokitzen zitzaigun inor. Nire jendearen artean bilatu behar izan nuen.
Arazoak Azpiegitura kode gisa
Orain ikus ditzagun azpiegitura kodean gogor kodetu daitekeen adibideak. Kodea ondo idatzita dago, kalitate handikoa, iruzkinekin eta koskarekin.
Terraformako kodearen adibidea.
Ansibleren kodearen adibidea.
Jaunak, hain sinplea balitz! Mundu errealean gaude, eta beti dago prest zu harritzeko, sorpresak eta arazoak aurkezteko. Hemen ere ezin da haiek gabe egin.
1. Lehenengo arazoa kasu gehienetan IaC dsl moduko bat dela da.
Eta DSL, berriz, egituraren deskribapena da. Zehazkiago, zer izan beharko zenuke: Json, Yaml, beren dsl propioa sortu zuten enpresa handi batzuen aldaketak (HCL erabiltzen da terraform-en).
Arazoa da erraz ez edukitzea horrelako gauza ezagunak:
- aldagaiak;
- baldintzak;
- nonbait ez dago iruzkinik, adibidez, Json-en, lehenespenez ez dira ematen;
- funtzioak;
- eta ez naiz ari maila altuko gauzetaz ere klaseak, herentzia eta guzti.
2. Kode horren bigarren arazoa da gehienetan ingurune heterogeneoa dela. Normalean C#rekin eseri eta lan egiten duzu, hau da. hizkuntza batekin, pila batekin, ekosistema batekin. Eta hemen teknologia ugari dituzu.
Oso egoera erreala da bash-ek python-ekin Json txertatzen den prozesuren bat abiarazten duenean. Aztertzen duzu, gero beste sorgailu batek beste 30 fitxategi ekoizten ditu. Horregatik guztiagatik, sarrera-aldagaiak Azure Key Vault-etik jasotzen dira, Go-n idatzitako drone.io-rako plugin batek biltzen dituena, eta aldagai horiek yaml-etik pasatzen dira, jsonnet txantiloi-motorretik sortutako sorreraren ondorioz. Nahiko zaila da zorrozki ondo deskribatutako kodea izatea ingurune anitza duzunean.
Zeregin baten esparruko garapen tradizionala hizkuntza batekin dator. Hemen hizkuntza ugarirekin lan egiten dugu.
3. Hirugarren arazoa afinazioa da. Gurekin dena egiten duten editoreak (Ms Visual Studio, Jetbrains Rider) hoztera ohituta gaude. Eta ergelak bagara ere oker gaudela esango dute. Normala eta naturala dirudi.
Baina nonbait gertu dago VSCode, eta bertan nolabait instalatuta, onartzen edo onartzen ez diren plugin batzuk daude. Bertsio berriak atera ziren eta ez ziren onartzen. Funtzio bat ezartzeko trantsizio hutsala (bada ere) arazo konplexu eta ez hutsala bihurtzen da. Aldagai baten izendapen sinplea dozena bat fitxategiko proiektu batean errepikatzea da. Zortea izango duzu behar duzuna jartzen badu. Noski, han eta hemen atzeko argia dago, auto-osaketa dago, nonbait formatua dago (nahiz eta Windows-en terraform-en ez zidan funtzionatu).
Hau idazteko momentuan oraindik ez dira kaleratu 0.12 bertsioa onartzen duten arren, 3 hilabetez kaleratu den.
ahazteko garaia da...
- Arazketa.
- Birfaktorizazio tresna.
- Osaketa automatikoa.
- Konpilazioan akatsak hautematea.
Dibertigarria da, baina horrek garapen-denbora areagotzen du eta ezinbestean gertatzen diren akatsen kopurua areagotzen du.
Okerrena da behartuta gaudela ez pentsatzera nola diseinatu, fitxategiak karpetetan antolatu, deskonposatu, kodea mantentzen, irakurgarri egin eta abar, baizik eta komando hau zuzen nola idatzi dezakedan, nolabait gaizki idatzi dudalako. .
Hasiberria zaren aldetik, terraformak ikasten saiatzen ari zara, eta IDEak ez dizu batere laguntzen. Dokumentazioa dagoenean, sartu eta begiratu. Baina programazio-lengoaia berri bat sartuko bazenu, IDEak esango lizuke halako mota bat dagoela, baina ez dago horrelakorik. Gutxienez int edo kate mailan. Hau askotan erabilgarria da.
Zer gertatzen da probei buruz?
Galdetzen duzu: "Eta probak, jaun programatzaileak?" Mutil serioek dena probatzen dute ekoizpenean, eta gogorra da. Hona hemen webguneko terraform modulu baterako proba unitate baten adibidea .
Dokumentazio ona dute. Microsoft beti gustatu izan zait dokumentazioaren eta prestakuntzaren ikuspegiagatik. Baina ez duzu osaba Bob izan behar hau kode perfektua ez dela ulertzeko. Kontuan izan eskuineko balioztatzea.
Unitate-proba baten arazoa da zuk eta biok Json irteeraren zuzentasuna egiazta dezakegula. 5 parametro bota nituen eta 2000 lerro dituen Json oinetako bat eman zidaten. Hemen gertatzen dena azter dezaket, probaren emaitza balioztatu...
Zaila da Go-n Json analizatzea. Eta Go-n idatzi behar duzu, Go-n terraform praktika ona delako idazten duzun hizkuntzan probak egiteko. Kodearen antolaketa bera oso ahula da. Aldi berean, hau da probak egiteko liburutegirik onena.
Microsoftek berak idazten ditu bere moduluak, era honetan probatuz. Noski Open Source da. Hizketan ari naizen guztia etor zaitezke konpontzera. Astebetean eseri eta dena konpondu dezaket, kode irekiko VS kodearen pluginak, terraforms, txirrindulariarentzat plugin bat egin. Agian analizatzaile pare bat idatzi, linters gehitu, probak egiteko liburutegi bat lagundu. Denetarik egin dezaket. Baina hori ez da nik egin behar nuena.
Praktika onak Azpiegitura kode gisa
Goazen aurrera. IaC-n probarik ez badago, IDEa eta sintonizazioa txarrak dira, gutxienez praktika onak egon beharko lirateke. Google Analytics-era joan eta bi bilaketa-kontsulta alderatu ditut: Terraform praktika onak eta c# praktika onak.
Zer ikusten dugu? Estatistika errukigabeak ez daude gure alde. Material kantitatea berdina da. C# garapenean, materialez beteta gaude, praktika onak ditugu, adituek idatzitako liburuak daude eta liburu horiek kritikatzen dituzten beste aditu batzuek liburuetan idatzitakoak ere badaude. Dokumentazio ofizial, artikulu, prestakuntza-ikastaroak eta orain kode irekiko garapena ere.
IaC eskaerari dagokionez: hemen pixkanaka informazioa biltzen saiatzen ari zara highload edo HashiConf txostenetatik, dokumentazio ofizialetatik eta Github-eko arazo ugarietatik. Nola banatu modulu hauek orokorrean, zer egin haiekin? Badirudi hau benetako arazoa dela... Komunitate bat dago, jaunak, non edozein galdera egiteko Github-en 10 iruzkin emango dizkizuten. Baina ez da zehazki.
Zoritxarrez, une honetan, adituak sortzen hasi besterik ez dira. Gutxiegi daude orain arte. Eta komunitatea bera maila arruntean ibiltzen da.
Nora doa hau guztia eta zer egin
Dena utzi eta C#ra itzul dezakezu, txirrindulariaren mundura. Baina ez. Zergatik trabatuko zinateke hori egiten, irtenbiderik aurkitzen ez baduzu. Jarraian nire ondorio subjektiboak aurkezten ditut. Nirekin eztabaidatu dezakezu iruzkinetan, interesgarria izango da.
Pertsonalki, gauza batzuen aldeko apustua egiten dut:
- Arlo honetan garapena oso azkar gertatzen ari da. Hona hemen DevOps-en eskaeren egutegia.
Gaia hypea izan daiteke, baina esfera hazten ari denak berak itxaropen bat ematen du.Zerbait hain azkar hazten bada, behin betiko pertsona adimentsuak agertuko dira, zer egin eta zer ez esango dizutenak. Ospea handitzeak ekartzen du agian norbaitek denbora izango duela azkenean jsonnet-en vscode-rako plugin bat gehitzeko, eta horrek funtzioa inplementatzera pasatzeko aukera emango dizu, ctrl+shift+f bidez bilatu beharrean. Gauzak eboluzionatu ahala, material gehiago agertzen dira. SREri buruzko Google-ren liburu bat kaleratzea horren adibide bikaina da.
- Garapen konbentzionalean garatutako teknikak eta praktikak daude hemen arrakastaz aplika ditzakegunak. Bai, ñabardurak daude probarekin eta ingurune heterogeneoarekin, tresna nahikorik ez, baina praktika ugari pilatu dira erabilgarriak eta lagungarriak izan daitezkeenak.
Adibide hutsal bat: bikotekako programazioaren bidez elkarlana. Asko laguntzen du asmatzen. Inguruko auzokide bat ere zerbait ulertzen saiatzen ari zarenean, elkarrekin hobeto ulertuko duzu.
Refactoring nola egiten den ulertzeak laguntzen du horrelako egoera batean ere gauzatzen. Hau da, ezin duzu dena aldi berean aldatu, baina izena aldatu, gero kokapena aldatu, gero zatiren bat nabarmendu dezakezu, oh, baina hemen ez dago nahikoa iruzkin.
Ondorioa
Nire arrazoiketak ezkorra dirudien arren, etorkizunari itxaropentsu begiratzen diot eta zintzoki espero dut dena guretzat (eta zuentzat) aterako den.
Artikuluaren bigarren zatia prestatzen ari dira jarraian. Bertan, gure ikaskuntza-prozesua hobetzeko eta azpiegiturekin lan egiteko garapen-praktika bizkorrak nola erabiltzen saiatu ginen buruz hitz egingo dut.
Iturria: www.habr.com