Infrastruktūra kā kods: pirmā iepazīŔanās

MÅ«su uzņēmumā notiek SRE komandas izveides process. Es ienācu visā Å”ajā stāstā no attÄ«stÄ«bas puses. Å ajā procesā man radās domas un atziņas, ar kurām vēlos dalÄ«ties ar citiem izstrādātājiem. Å ajā pārdomu rakstā es runāju par to, kas notiek, kā tas notiek un kā ikviens var turpināt ar to sadzÄ«vot.

Infrastruktūra kā kods: pirmā iepazīŔanās

Turpinājums rakstu sērijai, kas tapusi, balstoties uz runām mÅ«su iekŔējā pasākumā DevForum:

1. Šrēdingera kaķis bez kastes: vienprātības problēma sadalītajās sistēmās.
2. Infrastruktūra kā kods. (Tu esi Ŕeit)
3. Typescript lÄ«gumu Ä£enerÄ“Å”ana, izmantojot C# modeļus. (Notiek darbs...)
4. Ievads Raft konsensa algoritmā. (Notiek darbs...)
...

Nolēmām izveidot SRE komandu, realizējot idejas google sre. Viņi pieņēma darbā programmētājus no savu izstrādātāju vidus un nosÅ«tÄ«ja tos apmācÄ«t vairākus mēneÅ”us.

Komandai bija Ŕādi treniņu uzdevumi:

  • Aprakstiet mÅ«su infrastruktÅ«ru, kas galvenokārt ir Microsoft Azure koda veidā (Terraform un viss apkārt).
  • Māciet izstrādātājiem strādāt ar infrastruktÅ«ru.
  • Sagatavojiet izstrādātājus darbam.

Mēs ievieÅ”am jēdzienu InfrastruktÅ«ra kā kods

Parastajā pasaules modelī (klasiskā administrācija) zināŔanas par infrastruktūru atrodas divās vietās:

  1. Vai zināŔanu veidā ekspertu galvās.Infrastruktūra kā kods: pirmā iepazīŔanās
  2. Vai arÄ« Ŕī informācija ir uz dažām rakstāmmaŔīnām, no kurām dažas ir zināmas ekspertiem. Bet tas nav fakts, ka cilvēks no malas (ja visa mÅ«su komanda pēkŔņi nomirst) varēs saprast, kas darbojas un kā tas darbojas. Par maŔīnu var bÅ«t daudz informācijas: piederumi, cronjobs, iebiedēti (sk. diska montāža) disku un tikai bezgalÄ«gs saraksts ar to, kas var notikt. GrÅ«ti saprast, kas Ä«sti notiek.InfrastruktÅ«ra kā kods: pirmā iepazÄ«Å”anās

Abos gadījumos mēs esam iesprostoti, kļūstot atkarīgi:

  • vai no cilvēka, kurÅ” ir mirstÄ«gs, pakļauts slimÄ«bām, iemÄ«lÄ“Å”anās, garastāvokļa svārstÄ«bām un vienkārÅ”i banālām atlaiÅ”anām;
  • vai no fiziski strādājoÅ”as maŔīnas, kura arÄ« krÄ«t, tiek nozagta un sagādā pārsteigumus un neērtÄ«bas.

Pats par sevi saprotams, ka ideālā gadījumā viss būtu jāpārtulko cilvēkam lasāmā, apkopējamā, labi uzrakstītā kodā.

Tādējādi infrastruktÅ«ra kā kods (Incfastructure as Code - IaC) ir visas esoŔās infrastruktÅ«ras apraksts koda formā, kā arÄ« ar to saistÄ«tie rÄ«ki darbam ar to un reālas infrastruktÅ«ras ievieÅ”anai no tās.

Kāpēc visu tulkot kodā?Cilvēki nav maŔīnas. Viņi nevar atcerēties visu. Cilvēka un maŔīnas reakcija ir atŔķirÄ«ga. Jebkas automatizēts ir potenciāli ātrāks nekā jebkas, ko dara cilvēks. VissvarÄ«gākais ir viens patiesÄ«bas avots.

No kurienes nāk jauni SRE inženieri?Tātad, mēs nolēmām nolīgt jaunus SRE inženierus, bet no kurienes tos iegūt? Grāmata ar pareizām atbildēm (Google SRE grāmata) stāsta: no izstrādātājiem. Galu galā viņi strādā ar kodu, un jūs sasniedzat ideālo stāvokli.

Mēs ilgu laiku viņus daudz meklējām personāla tirgū ārpus mūsu uzņēmuma. Bet mums jāatzīst, ka mēs neatradām nevienu, kas atbilstu mūsu prasībām. Man vajadzēja meklēt starp savējiem.

Problēmas Infrastruktūra kā kods

Tagad apskatīsim piemērus, kā infrastruktūru var kodēt kodā. Kods ir labi uzrakstīts, kvalitatīvs, ar komentāriem un atkāpēm.

Koda piemērs no Terraforma.

Infrastruktūra kā kods: pirmā iepazīŔanās

Koda piemērs no Ansible.

Infrastruktūra kā kods: pirmā iepazīŔanās

Kungi, ja tas bÅ«tu tik vienkārÅ”i! Mēs atrodamies reālajā pasaulē, un tā vienmēr ir gatava jÅ«s pārsteigt, sagādāt pārsteigumus un problēmas. ArÄ« Å”eit bez tiem neiztikt.

1. Pirmā problēma ir tāda, ka vairumā gadījumu IaC ir kaut kāds dsl veids.

Un DSL, savukārt, ir struktūras apraksts. Precīzāk, kam jums vajadzētu būt: Json, Yaml, dažu lielu uzņēmumu modifikācijas, kas nāca klajā ar savu dsl (HCL tiek izmantots terraformā).

Problēma ir tā, ka tajā var viegli nebūt tādas pazīstamas lietas kā:

  • mainÄ«gie;
  • nosacÄ«jumi;
  • kaut kur nav komentāru, piemēram, Json, pēc noklusējuma tie netiek sniegti;
  • funkcijas;
  • un es pat nerunāju par tādām augsta lÄ«meņa lietām kā klases, mantojums un tas viss.

2. Otra problēma ar Ŕādu kodu ir tā, ka visbiežāk tā ir neviendabÄ«ga vide. Parasti tu sēdi un strādā ar C#, t.i. ar vienu valodu, vienu kaudzi, vienu ekosistēmu. Un Å”eit jums ir ļoti daudz dažādu tehnoloÄ£iju.

Tā ir ļoti reāla situācija, kad bash ar python palaiž kādu procesu, kurā tiek ievietots Json. JÅ«s to analizējat, tad kāds cits Ä£enerators ražo vēl 30 failus. Å im visam no Azure Key Vault tiek saņemti ievades mainÄ«gie, kas tiek savesti kopā ar spraudni drone.io, kas rakstÄ«ts Go, un Å”ie mainÄ«gie iziet cauri yaml, kas tika Ä£enerēts jsonnet veidņu dzinēja Ä£enerÄ“Å”anas rezultātā. Ir diezgan grÅ«ti iegÅ«t stingri precÄ«zi aprakstÄ«tu kodu, ja jums ir tik daudzveidÄ«ga vide.

Tradicionālā attīstība viena uzdevuma ietvaros nāk ar vienu valodu. Šeit mēs strādājam ar lielu skaitu valodu.

3. TreŔā problēma ir tÅ«nings. Mēs esam pieraduÅ”i pie forÅ”iem redaktoriem (Ms Visual Studio, Jetbrains Rider), kas visu dara mÅ«su vietā. Un pat ja mēs esam stulbi, viņi teiks, ka mēs kļūdāmies. Tas Ŕķiet normāli un dabiski.

Bet kaut kur tuvumā ir VSCode, kurā ir daži spraudņi, kas kaut kā ir instalēti, atbalstÄ«ti vai neatbalstÄ«ti. Iznāca jaunas versijas, kuras netika atbalstÄ«tas. Banāla pāreja uz funkcijas ievieÅ”anu (pat ja tā pastāv) kļūst par sarežģītu un nenozÄ«mÄ«gu problēmu. VienkārÅ”s mainÄ«gā lieluma pārdēvÄ“Å”ana ir duci failu projekta atkārtoÅ”ana. Jums veiksies, ja viņŔ novietos to, kas jums nepiecieÅ”ams. Protams, Å”ur un tur ir fona apgaismojums, ir automātiskā pabeigÅ”ana, kaut kur ir formatējums (lai gan tas man nedarbojās terraformā operētājsistēmā Windows).

Å Ä«s rakstÄ«Å”anas laikā vscode-terraform spraudnis vēl nav izlaistas, lai atbalstÄ«tu versiju 0.12, lai gan tā ir izlaista 3 mēneÅ”us.

Ir pienācis laiks aizmirst par...

  1. AtkļūdoŔana.
  2. Refaktoringa rīks.
  3. Automātiskā pabeigŔana.
  4. Kļūdu noteikŔana kompilācijas laikā.

Tas ir smieklīgi, bet tas arī palielina izstrādes laiku un palielina kļūdu skaitu, kas neizbēgami rodas.

Sliktākais ir tas, ka esam spiesti domāt nevis par to, kā noformēt, kārtot failus mapēs, sadalÄ«t, padarÄ«t kodu uzturējamu, lasāmu un tā tālāk, bet gan par to, kā es varu pareizi uzrakstÄ«t Å”o komandu, jo es kaut kā nepareizi uzrakstÄ«ju .

Kā iesācējs jÅ«s mēģināt apgÅ«t terraformas, un IDE jums nepalÄ«dz. Kad ir dokumentācija, ieejiet un paskatieties. Bet, ja jÅ«s ievadÄ«tu jaunu programmÄ“Å”anas valodu, IDE jums pateiktu, ka Ŕāds veids ir, bet tāda nav. Vismaz int vai stÄ«gu lÄ«menÄ«. Tas bieži vien ir noderÄ«gi.

Kā ar testiem?

JÅ«s jautājat: "Kā ir ar testiem, programmētāju kungi?" Nopietni puiÅ”i visu pārbauda ražoÅ”anā, un tas ir grÅ«ti. Å eit ir vietnes terraform moduļa vienÄ«bas pārbaudes piemērs microsoft.

Infrastruktūra kā kods: pirmā iepazīŔanās

Viņiem ir laba dokumentācija. Man vienmēr ir paticis Microsoft ar savu pieeju dokumentācijai un apmācÄ«bai. Taču nav jābÅ«t tēvocim Bobam, lai saprastu, ka Å”is nav ideāls kods. Ievērojiet apstiprinājumu pa labi.

VienÄ«bas pārbaudes problēma ir tāda, ka jÅ«s un es varam pārbaudÄ«t Json izvades pareizÄ«bu. Es iemetu 5 parametrus un man iedeva Json kāju lupatiņu ar 2000 lÄ«nijām. Es varu analizēt, kas Å”eit notiek, apstiprināt testa rezultātu...

Programmā Go ir grÅ«ti parsēt Json. Un jums ir jāraksta Go, jo terraform in Go ir laba prakse testÄ“Å”anai valodā, kurā rakstāt. Pati koda organizācija ir ļoti vāja. Tajā paŔā laikā Ŕī ir labākā bibliotēka testÄ“Å”anai.

Microsoft pati raksta savus moduļus, pārbaudot tos Ŕādā veidā. Protams, tas ir atvērtais avots. Visu, par ko es runāju, jÅ«s varat nākt un salabot. Varu pasēdēt un nedēļas laikā visu salabot, atvērtā koda VS koda spraudņus, terraformus, uztaisÄ«t braucējam spraudni. VarbÅ«t uzrakstÄ«t pāris analizatorus, pievienot lÄ«kumus, pievienot bibliotēku testÄ“Å”anai. Es varu visu. Bet tas nav tas, ko man vajadzētu darÄ«t.

Paraugprakse Infrastruktūra kā kods

Ejam tālāk. Ja IaC nav testu, IDE un regulÄ“Å”ana ir slikta, tad vismaz vajadzētu bÅ«t paraugpraksei. Es tikko apmeklēju Google Analytics un salÄ«dzināju divus meklÄ“Å”anas vaicājumus: Terraform labākās prakses un c# labākās prakses.

Infrastruktūra kā kods: pirmā iepazīŔanās

Ko mēs redzam? NežēlÄ«gā statistika mums nav par labu. Materiāla daudzums ir vienāds. C# izstrādē mēs esam vienkārÅ”i pārpildÄ«ti ar materiāliem, mums ir super-labākās prakses, ir grāmatas, kuras rakstÄ«juÅ”i eksperti, kā arÄ« grāmatas, ko rakstÄ«juÅ”i citi eksperti, kuri kritizē Ŕīs grāmatas. Oficiālās dokumentācijas, rakstu, apmācÄ«bu kursu jÅ«ra un tagad arÄ« atvērtā koda izstrāde.

Kas attiecas uz IaC pieprasÄ«jumu: Å”eit jÅ«s mēģināt pamazām apkopot informāciju no Highload vai HashiConf ziņojumiem, no oficiālās dokumentācijas un daudzām problēmām Github. Kā Å”os moduļus vispār izplatÄ«t, ko ar tiem darÄ«t? Å Ä·iet, ka tā ir reāla problēma... Ir tāda kopiena, kungi, kur par jebkuru jautājumu jums tiks doti 10 komentāri Githubā. Bet tā gluži nav.

Diemžēl Å”ajā brÄ«dÄ« eksperti tikai sāk parādÄ«ties. Pagaidām to ir pārāk maz. Un pati kopiena čakarējas elementārā lÄ«menÄ«.

Kur tas viss notiek un ko darīt

Jūs varat atmest visu un atgriezties pie C#, braucēja pasaulē. Bet nē. Kāpēc jūs to darītu, ja nevarat atrast risinājumu. Tālāk es sniedzu savus subjektīvos secinājumus. Ar mani varat strīdēties komentāros, būs interesanti.

Personīgi es lieku uz dažām lietām:

  1. Attīstība Ŕajā jomā notiek ļoti ātri. Šeit ir DevOps pieprasījumu grafiks.

    Infrastruktūra kā kods: pirmā iepazīŔanās

    Tēma var būt ažiotāža, bet pats fakts, ka sfēra aug, dod zināmu cerību.

    Ja kaut kas tik ātri izaugs, tad noteikti uzradÄ«sies gudri cilvēki, kas pateiks, ko darÄ«t un ko nedarÄ«t. Popularitātes pieaugums noved pie tā, ka varbÅ«t kādam bÅ«s laiks beidzot pievienot jsonnet priekÅ” vscode spraudni, kas ļaus pāriet uz funkcijas ievieÅ”anu, nevis meklēt to ar ctrl+shift+f. AttÄ«stoties lietām, parādās vairāk materiālu. Google izdota grāmata par SRE ir lielisks piemērs tam.

  2. Ir izstrādātas metodes un prakses tradicionālajā attÄ«stÄ«bā, ko mēs varam veiksmÄ«gi pielietot Å”eit. Jā, ir nianses ar testÄ“Å”anu un neviendabÄ«gu vidi, nepietiekamu instrumentu komplektāciju, taču ir uzkrāts milzÄ«gs daudzums prakÅ”u, kas var bÅ«t noderÄ«gas un noderÄ«gas.

    Triviāls piemērs: sadarbÄ«ba, izmantojot pāru programmÄ“Å”anu. Tas ļoti palÄ«dz to izdomāt. Kad blakus ir kaimiņŔ, kurÅ” arÄ« cenÅ”as kaut ko saprast, kopā jÅ«s sapratÄ«sit labāk.

    Izpratne par to, kā notiek refaktorings, palīdz to veikt pat Ŕādā situācijā. Tas ir, var nemainīt visu uzreiz, bet mainīt nosaukumu, tad mainīt vietu, tad var izcelt kādu daļu, ak, bet Ŕeit ir par maz komentāru.

Secinājums

Neskatoties uz to, ka mana argumentācija var Ŕķist pesimistiska, es raugos nākotnē ar cerÄ«bu un patiesi ceru, ka mums (un jums) viss izdosies.

Nākamā tiek gatavota raksta otrā daļa. Tajā es pastāstÄ«Å”u par to, kā mēs centāmies izmantot veiklās izstrādes prakses, lai uzlabotu mācÄ«bu procesu un darbu ar infrastruktÅ«ru.

Avots: www.habr.com

Pievieno komentāru