Nia firmao estas en procezo de aliĝo al SRE-teamo. Mi venis en ĉi tiun tutan historion de la evolua flanko. En la procezo, mi elpensis pensojn kaj komprenojn, kiujn mi volas dividi kun aliaj programistoj. En ĉi tiu pripensa artikolo mi parolas pri tio, kio okazas, kiel ĝi okazas, kaj kiel ĉiuj povas daŭre vivi kun ĝi.
Daŭrigo de serio de artikoloj verkitaj surbaze de paroladoj ĉe nia interna aranĝo :
2. Infrastrukturo kiel kodo. (Vi estas ĉi tie)
3. Generacio de Typescript-kontraktoj uzante C# modelojn. (En progreso...)
4. Enkonduko al la Raft-konsenta algoritmo. (En progreso...)
...
Ni decidis krei SRE-teamon, efektivigante la ideojn . Ili varbis programistojn el inter siaj propraj programistoj kaj sendis ilin trejni dum pluraj monatoj.
La teamo havis la sekvajn trejnajn taskojn:
- Priskribu nian infrastrukturon, kiu estas plejparte en Microsoft Azure en formo de kodo (Terraform kaj ĉio ĉirkaŭe).
- Instruu programistojn kiel labori kun infrastrukturo.
- Preparu programistojn por devo.
Ni enkondukas la koncepton de Infrastrukturo kiel kodon
En la kutima modelo de la mondo (klasika administrado), scio pri infrastrukturo situas en du lokoj:
- Aŭ en formo de scio en la kapoj de spertuloj.
- Aŭ ĉi tiuj informoj estas pri iuj skribmaŝinoj, iuj el kiuj estas konataj de spertuloj. Sed ne estas fakto, ke eksterulo (kaze nia tuta teamo subite mortos) povos eltrovi kio funkcias kaj kiel ĝi funkcias. Povas esti multe da informoj pri maŝino: akcesoraĵoj, kronlaboroj, timigitaj (vidu. ) disko kaj nur senfina listo de kio povas okazi. Estas malfacile kompreni, kio vere okazas.
En ambaŭ kazoj, ni trovas nin kaptitaj en iĝi dependaj:
- aŭ de homo, kiu estas mortema, submetata al malsano, enamiĝo, humoroŝanĝoj kaj simple banalaj maldungoj;
- aŭ de fizike laboranta maŝino, kiu ankaŭ falas, estas ŝtelita kaj prezentas surprizojn kaj ĝenojn.
Nepras, ke ideale ĉio estu tradukita en homlegeblan, konserveblan, bone verkitan kodon.
Tiel, infrastrukturo kiel kodo (Incfastructure as Code - IaC) estas priskribo de la tuta ekzistanta infrastrukturo en la formo de kodo, same kiel rilataj iloj por labori kun ĝi kaj efektivigi realan infrastrukturon de ĝi.
Kial traduki ĉion en kodon?Homoj ne estas maŝinoj. Ili ne povas memori ĉion. La reago de homo kaj maŝino estas malsama. Io ajn aŭtomatigita estas eble pli rapida ol ĉio farita de homo. La plej grava afero estas ununura fonto de vero.
De kie venas novaj SRE-inĝenieroj?Do, ni decidis dungi novajn SRE-inĝenierojn, sed de kie akiri ilin? Libro kun ĝustaj respondoj () diras al ni: de la programistoj. Post ĉio, ili funkcias kun la kodo, kaj vi atingas la idealan staton.
Ni multe serĉis ilin dum longa tempo sur la dungita merkato ekster nia kompanio. Sed ni devas konfesi, ke ni trovis neniun, kiu konvenis al niaj petoj. Mi devis serĉi inter miaj propraj homoj.
Problemoj Infrastrukturo kiel kodo
Nun ni rigardu ekzemplojn de kiel infrastrukturo povas esti malmola kodita en kodon. La kodo estas bone skribita, altkvalita, kun komentoj kaj indentaĵoj.
Ekzempla kodo de Terraforma.
Ekzempla kodo de Ansible.
Sinjoroj, se estus tiel simple! Ni estas en la reala mondo, kaj ĝi ĉiam pretas surprizi vin, prezenti al vi surprizojn kaj problemojn. Ankaŭ ĉi tie ne povas malhavi ilin.
1. La unua problemo estas, ke plejofte IaC estas ia dsl.
Kaj DSL, siavice, estas priskribo de la strukturo. Pli precize, kion vi devus havi: Json, Yaml, modifojn de iuj grandaj kompanioj, kiuj elpensis sian propran dsl (HCL estas uzata en terraform).
La problemo estas, ke ĝi povas facile ne enhavi tiajn konatajn aferojn kiel:
- variabloj;
- kondiĉoj;
- ie ne estas komentoj, ekzemple en Json, defaŭlte ili ne estas provizitaj;
- funkcioj;
- kaj mi eĉ ne parolas pri tiaj altnivelaj aferoj kiel klasoj, heredo kaj ĉio tio.
2. La dua problemo kun tia kodo estas, ke plej ofte ĝi estas heterogena medio. Kutime oni sidas kaj laboras kun C#, t.e. kun unu lingvo, unu stako, unu ekosistemo. Kaj ĉi tie vi havas grandegan varion de teknologioj.
Estas tre reala situacio kiam bash kun python lanĉas iun procezon en kiun Json estas enigita. Vi analizas ĝin, tiam iu alia generatoro produktas aliajn 30 dosierojn. Por ĉio ĉi, enigaj variabloj ricevas de Azure Key Vault, kiuj estas kunigitaj per kromaĵo por drone.io skribita en Go, kaj ĉi tiuj variabloj pasas tra yaml, kiu estis generita kiel rezulto de generacio de la jsonnet-ŝablona motoro. Estas sufiĉe malfacile havi strikte bone priskribitan kodon kiam oni havas tiom diversan medion.
Tradicia evoluo kadre de unu tasko venas kun unu lingvo. Ĉi tie ni laboras kun granda nombro da lingvoj.
3. La tria problemo estas agordado. Ni kutimas malvarmigi redaktistojn (Ms Visual Studio, Jetbrains Rider) kiuj faras ĉion por ni. Kaj eĉ se ni estas stultaj, ili diros, ke ni eraras. Ĝi ŝajnas normala kaj natura.
Sed ie proksime estas VSCode, en kiu estas iuj kromprogramoj, kiuj estas iel instalitaj, subtenataj aŭ ne subtenataj. Novaj versioj aperis kaj ne estis subtenataj. Banala transiro al efektivigo de funkcio (eĉ se ĝi ekzistas) fariĝas kompleksa kaj ne bagatela problemo. Simpla renomo de variablo estas ripeto en projekto de deko da dosieroj. Vi havos bonŝancon, se li metas tion, kion vi bezonas. Kompreneble, estas kontraŭlumo jen kaj jen, estas aŭtomata kompletigo, ie estas formatado (kvankam ĝi ne funkciis por mi en terraform en Vindozo).
En la momento de ĉi tiu skribado ankoraŭ ne estis liberigitaj por subteni version 0.12, kvankam ĝi estis liberigita dum 3 monatoj.
Estas tempo forgesi pri...
- Sencimigado.
- Refaktoriga ilo.
- Aŭtomata kompletigo.
- Detektante erarojn dum kompilo.
Estas amuza, sed ĉi tio ankaŭ pliigas la disvolvan tempon kaj pliigas la nombron da eraroj, kiuj neeviteble okazas.
La plej malbona afero estas, ke ni estas devigitaj pensi ne pri kiel desegni, organizi dosierojn en dosierujojn, malkomponi, igi la kodon konservebla, legebla, ktp, sed pri kiel mi povas skribi ĉi tiun komandon ĝuste, ĉar mi iel skribis ĝin malĝuste. .
Kiel komencanto, vi provas lerni teraformojn, kaj la IDE tute ne helpas vin. Kiam estas dokumentado, eniru kaj rigardu. Sed se vi enirus novan programlingvon, la IDE dirus al vi, ke ekzistas tia tipo, sed tia ne ekzistas. Almenaŭ ĉe la int aŭ ĉennivelo. Ĉi tio ofte estas utila.
Kio pri la provoj?
Vi demandas: "Kion pri la testoj, sinjoroj programistoj?" Seriozaj uloj testas ĉion pri produktado, kaj ĝi estas malfacila. Jen ekzemplo de unutesto por teraforma modulo de la retejo .
Ili havas bonan dokumentadon. Mi ĉiam ŝatis Microsoft pro ĝia aliro al dokumentado kaj trejnado. Sed vi ne bezonas esti onklo Bob por kompreni, ke tio ne estas perfekta kodo. Notu la validigon dekstre.
La problemo kun unutesto estas ke vi kaj mi povas kontroli la ĝustecon de la eligo Json. Mi enĵetis 5 parametrojn kaj ricevis Json-piedtukon kun 2000 linioj. Mi povas analizi kio okazas ĉi tie, validigi testrezulton...
Estas malfacile analizi Json en Go. Kaj vi devas skribi en Go, ĉar terraform en Go estas bona praktiko por testi en la lingvo en kiu vi skribas. La organizo de la kodo mem estas tre malforta. Samtempe, ĉi tiu estas la plej bona biblioteko por testado.
Microsoft mem skribas siajn modulojn, provante ilin tiamaniere. Kompreneble ĝi estas Malferma Fonto. Ĉio, pri kio mi parolas, vi povas veni kaj ripari. Mi povas sidiĝi kaj ripari ĉion en semajno, malfermfontaj VS-kodaj kromaĵoj, terformoj, fari kromprogramon por la rajdanto. Eble verku kelkajn analizilojn, aldonu linters, kontribuu bibliotekon por testado. Mi povas fari ĉion. Sed ne tion mi devus fari.
Plej bonaj Praktikoj Infrastrukturo kiel kodo
Ni pluiru. Se ne ekzistas testoj en IaC, la IDE kaj agordado estas malbonaj, tiam devus almenaŭ ekzisti plej bonaj praktikoj. Mi ĵus iris al Google Analytics kaj komparis du serĉdemandojn: Terraform plej bonaj praktikoj kaj c# plej bonaj praktikoj.
Kion ni vidas? Senkompataj statistikoj ne estas en nia favoro. La kvanto de materialo estas la sama. En C#-disvolviĝo, ni simple estas superfluaj de materialoj, ni havas super-bonajn praktikojn, ekzistas libroj skribitaj de fakuloj, kaj ankaŭ libroj skribitaj pri libroj de aliaj fakuloj kiuj kritikas tiujn librojn. Maro da oficiala dokumentaro, artikoloj, trejnaj kursoj, kaj nun ankaŭ malfermkoda disvolviĝo.
Koncerne la IaC-peton: ĉi tie vi provas kolekti informojn iom post iom el highload aŭ HashiConf-raportoj, el oficiala dokumentaro kaj multaj aferoj pri Github. Kiel distribui ĉi tiujn modulojn ĝenerale, kion fari kun ili? Ŝajnas, ke ĉi tio estas vera problemo... Estas komunumo, sinjoroj, kie por ajna demando vi ricevos 10 komentojn pri Github. Sed ĝi ne estas ĝuste.
Bedaŭrinde, en ĉi tiu momento, spertuloj ĵus komencas aperi. Estas tro malmultaj el ili ĝis nun. Kaj la komunumo mem pendas ĉe la rudimenta nivelo.
Kien ĉio ĉi iras kaj kion fari
Vi povas faligi ĉion kaj reiri al C#, al la mondo de la rajdanto. Sed ne. Kial vi eĉ ĝenus fari ĉi tion, se vi ne povas trovi solvon. Ĉi-sube mi prezentas miajn subjektivajn konkludojn. Vi povas diskuti kun mi en la komentoj, ĝi estos interese.
Persone, mi vetas pri kelkaj aferoj:
- Evoluo en ĉi tiu areo okazas tre rapide. Jen horaro de petoj por DevOps.
La temo povas esti hype, sed la fakto mem, ke la sfero kreskas, donas iom da espero.Se io kreskas tiel rapide, tiam certe aperos inteligentaj homoj, kiuj diros al vi kion fari kaj kion ne fari. La pliiĝo de populareco kondukas al tio, ke eble iu havos tempon por finfine aldoni kromprogramon al jsonnet por vscode, kio permesos al vi pluiri al efektivigo de la funkcio, anstataŭ serĉi ĝin per ctrl+shift+f. Dum aferoj evoluas, pli da materialoj aperas. La eldono de libro de Guglo pri SRE estas bonega ekzemplo de tio.
- Estas evoluintaj teknikoj kaj praktikoj en konvencia evoluo, kiujn ni povas sukcese apliki ĉi tie. Jes, estas nuancoj kun testado kaj heterogena medio, nesufiĉa ilaro, sed amasiĝis grandega nombro da praktikoj, kiuj povas esti utilaj kaj helpemaj.
Triviala ekzemplo: kunlaboro per parprogramado. Ĝi multe helpas eltrovi ĝin. Kiam vi havas apude najbaron, kiu ankaŭ klopodas kompreni ion, kune vi komprenos pli bone.
Kompreni kiel refactoring estas farita helpas efektivigi ĝin eĉ en tia situacio. Tio estas, vi ne povas ŝanĝi ĉion samtempe, sed ŝanĝi la nomadon, poste ŝanĝi la lokon, tiam vi povas reliefigi iun parton, ho, sed ne estas sufiĉe da komentoj ĉi tie.
konkludo
Malgraŭ tio, ke mia rezonado povas ŝajni pesimisma, mi esperas al la estonteco kaj sincere esperas, ke ĉio funkcios por ni (kaj por vi).
La dua parto de la artikolo estas preparita poste. En ĝi, mi parolos pri kiel ni provis uzi lertajn evoluajn praktikojn por plibonigi nian lernprocezon kaj labori kun infrastrukturo.
fonto: www.habr.com