Fyrirtækið okkar er að vinna í SRE teymi. Ég kom inn í alla þessa sögu frá þróunarhliðinni. Í því ferli kom ég með hugsanir og innsýn sem ég vil deila með öðrum forriturum. Í þessari hugleiðingargrein fjalla ég um það sem er að gerast, hvernig það er að gerast og hvernig allir geta lifað áfram með það.
Framhald á röð greina sem skrifuð voru á grundvelli ræðum á innri viðburði okkar :
2. Innviðir sem kóða. (Þú ert hér)
3. Gerð vélritunarsamninga með C# módelum. (Í vinnslu...)
4. Kynning á Raft consensus algrím. (Í vinnslu...)
...
Við ákváðum að stofna SRE teymi til að hrinda hugmyndunum í framkvæmd . Þeir réðu til sín forritara úr hópi eigin þróunaraðila og sendu þá til að þjálfa í nokkra mánuði.
Liðið hafði eftirfarandi þjálfunarverkefni:
- Lýstu innviðum okkar, sem eru að mestu í Microsoft Azure í formi kóða (Terraform og allt í kring).
- Kenndu forriturum hvernig á að vinna með innviði.
- Undirbúðu verktaki fyrir skyldustörf.
Við kynnum hugtakið innviði sem kóða
Í venjulegu líkani heimsins (klassískri stjórnsýslu) er þekking um innviði staðsett á tveimur stöðum:
- Eða í formi þekkingar í höfði sérfræðinga.
- Eða þessar upplýsingar eru á sumum ritvélum, sumar þeirra eru þekktar af sérfræðingum. En það er ekki staðreynd að utanaðkomandi (ef allt liðið okkar deyr skyndilega) muni geta fundið út hvað virkar og hvernig það virkar. Það getur verið mikið af upplýsingum um vél: aukahlutir, cronjobs, hræða (sjá. ) diskur og bara endalaus listi yfir það sem getur gerst. Það er erfitt að skilja hvað er í raun og veru að gerast.
Í báðum tilfellum finnum við okkur föst í því að verða háð:
- eða frá manneskju sem er dauðleg, háð veikindum, ástfangi, skapsveiflum og einfaldlega banalum uppsögnum;
- eða frá líkamlega vinnandi vél, sem líka dettur, verður stolið og kemur á óvart og óþægindum.
Það segir sig sjálft að helst ætti allt að vera þýtt yfir á mannlæsilegan, viðhaldanlegan, vel skrifaðan kóða.
Þannig er innviði sem kóða (Incfastructure as Code - IaC) lýsing á öllu núverandi innviði í formi kóða, auk tengdra verkfæra til að vinna með hann og útfæra raunverulegan innviði út frá honum.
Af hverju að þýða allt í kóða?Fólk er ekki vélar. Þeir geta ekki munað allt. Viðbrögð manns og vélar eru mismunandi. Allt sem er sjálfvirkt er hugsanlega hraðar en nokkuð sem maður gerir. Það mikilvægasta er ein uppspretta sannleikans.
Hvaðan koma nýir SRE verkfræðingar?Þannig að við ákváðum að ráða nýja SRE verkfræðinga, en hvaðan á að fá þá? Bók með réttum svörum () segir okkur: frá hönnuðum. Þegar öllu er á botninn hvolft vinna þeir með kóðann og þú nærð kjörstöðu.
Við leituðum lengi að þeim á starfsmannamarkaði utan fyrirtækisins okkar. En við verðum að viðurkenna að við fundum engan sem hentaði beiðnum okkar. Ég varð að leita meðal míns eigin fólks.
Vandamál Innviði sem kóða
Nú skulum við skoða dæmi um hvernig hægt er að harðkóða innviði í kóða. Kóðinn er vel skrifaður, hágæða, með athugasemdum og inndráttum.
Dæmi um kóða frá Terraforma.
Dæmi um kóða frá Ansible.
Herrar mínir, ef þetta væri bara svona einfalt! Við erum í hinum raunverulega heimi og hann er alltaf tilbúinn að koma þér á óvart, koma þér á óvart og vandamál. Get ekki verið án þeirra hér heldur.
1. Fyrsta vandamálið er að í flestum tilfellum er IaC einhvers konar dsl.
Og DSL er aftur á móti lýsing á uppbyggingunni. Nánar tiltekið, það sem þú ættir að hafa: Json, Yaml, breytingar frá nokkrum stórum fyrirtækjum sem komu með eigin dsl (HCL er notað í terraform).
Vandamálið er að það gæti auðveldlega innihaldið svo kunnuglega hluti eins og:
- breytur;
- skilyrði;
- einhvers staðar eru engar athugasemdir, til dæmis í Json, sjálfgefið eru þær ekki veittar;
- aðgerðir;
- og ég er ekki einu sinni að tala um svona háttsetta hluti eins og flokka, arfleifð og allt það.
2. Annað vandamálið við slíkan kóða er að oftast er það misleitt umhverfi. Yfirleitt situr maður og vinnur með C#, þ.e. með einu tungumáli, einum stafla, einu vistkerfi. Og hér hefur þú mikið úrval af tækni.
Það er mjög raunverulegt ástand þegar bash með python ræsir eitthvað ferli sem Json er sett inn í. Þú greinir það, þá framleiðir einhver annar rafall 30 skrár í viðbót. Fyrir allt þetta eru inntaksbreytur mótteknar frá Azure Key Vault, sem eru dregnar saman með viðbót fyrir drone.io sem er skrifað í Go, og þessar breytur fara í gegnum yaml, sem var myndað vegna kynslóðar frá jsonnet sniðmát vélinni. Það er frekar erfitt að hafa nákvæmlega vel lýst kóða þegar þú ert með svona fjölbreytt umhverfi.
Hefðbundin þróun innan ramma eins verkefnis fylgir einu tungumáli. Hér er unnið með fjölda tungumála.
3. Þriðja vandamálið er stilling. Við erum vön flottum ritstjórum (Ms Visual Studio, Jetbrains Rider) sem gera allt fyrir okkur. Og jafnvel þótt við séum heimsk, munu þeir segja að við höfum rangt fyrir okkur. Það virðist eðlilegt og eðlilegt.
En einhvers staðar í nágrenninu er VSCode, þar sem eru nokkrar viðbætur sem eru einhvern veginn uppsettar, studdar eða ekki studdar. Nýjar útgáfur komu út og voru ekki studdar. Banal umskipti yfir í að innleiða aðgerð (jafnvel þótt hún sé til) verða flókið og ekki léttvægt vandamál. Einfalt endurnefna breytu er endurspilun í verkefni sem inniheldur tugi skráa. Þú verður heppinn ef hann setur það sem þú þarft. Auðvitað er baklýsing hér og þar, það er sjálfvirk útfylling, einhvers staðar er formatting (þó það virkaði ekki fyrir mig í terraform á Windows).
Þegar þetta er skrifað hafa ekki enn verið gefin út til að styðja útgáfu 0.12, þó hún hafi verið gefin út í 3 mánuði.
Það er kominn tími til að gleyma...
- Kembiforrit.
- Refactoring tól.
- Sjálfvirk útfylling.
- Að greina villur við söfnun.
Það er fyndið, en þetta eykur líka þróunartíma og eykur fjölda villna sem óumflýjanlega eiga sér stað.
Það versta er að við neyðumst til að hugsa ekki um hvernig eigi að hanna, skipuleggja skrár í möppur, sundurliða, gera kóðann viðhaldanlegan, læsilegan og svo framvegis, heldur hvernig ég get skrifað þessa skipun rétt, því ég skrifaði hana einhvern veginn vitlaust. .
Sem byrjandi ertu að reyna að læra terraforms og IDE hjálpar þér alls ekki. Þegar skjöl eru til, farðu inn og skoðaðu. En ef þú værir að slá inn nýtt forritunarmál myndi IDE segja þér að það sé til slík tegund, en það er ekkert slíkt. Að minnsta kosti á int eða strengjastigi. Þetta er oft gagnlegt.
Hvað með prófin?
Þú spyrð: "Hvað með prófin, herrar forritarar?" Alvarlegir krakkar prófa allt í framleiðslu og það er erfitt. Hér er dæmi um einingapróf fyrir terraform mát af vefsíðunni .
Þeir hafa góð skjöl. Mér hefur alltaf líkað við Microsoft fyrir nálgun þess á skjölum og þjálfun. En þú þarft ekki að vera Bob frændi til að skilja að þetta er ekki fullkominn kóða. Athugaðu staðfestinguna til hægri.
Vandamálið við einingapróf er að þú og ég getum athugað réttmæti Json úttaksins. Ég henti inn 5 breytum og fékk Json fótklút með 2000 línum. Ég get greint hvað er að gerast hér, sannreynt niðurstöður prófs...
Það er erfitt að flokka Json í Go. Og þú þarft að skrifa í Go, því terraform í Go er góð æfing til að prófa á tungumálinu sem þú skrifar á. Skipulag kóðans sjálfs er mjög veikt. Á sama tíma er þetta besta bókasafnið til að prófa.
Microsoft skrifar sjálft einingar sínar og prófar þær á þennan hátt. Auðvitað er það Open Source. Allt sem ég er að tala um geturðu komið og lagað. Ég get sest niður og lagað allt á einni viku, opið uppruna VS kóða viðbætur, terraforms, búið til viðbót fyrir knapann. Kannski skrifa nokkra greiningartæki, bæta við linters, leggja til bókasafn til að prófa. Ég get allt. En það er ekki það sem ég ætti að gera.
Bestu starfsvenjur Innviði sem kóða
Höldum áfram. Ef það eru engin próf í IaC, IDE og tuning eru slæm, þá ættu að minnsta kosti að vera bestu starfsvenjur. Ég fór bara á Google Analytics og bar saman tvær leitarfyrirspurnir: Bestu starfsvenjur Terraform og bestu starfsvenjur í c#.
Hvað sjáum við? Miskunnarlaus tölfræði er okkur ekki í hag. Efnismagnið er það sama. Í C# þróun erum við einfaldlega yfirfull af efni, við höfum frábærar bestu starfsvenjur, það eru bækur skrifaðar af sérfræðingum og líka bækur skrifaðar á bækur eftir aðra sérfræðinga sem gagnrýna þessar bækur. Sjó af opinberum skjölum, greinum, þjálfunarnámskeiðum og nú einnig opnum uppspretta þróun.
Hvað IaC beiðnina varðar: hér ertu að reyna að safna upplýsingum smátt og smátt úr háhleðslu eða HashiConf skýrslum, frá opinberum skjölum og fjölmörgum málum á Github. Hvernig á að dreifa þessum einingum almennt, hvað á að gera við þær? Það virðist sem þetta sé raunverulegt vandamál... Það er samfélag, herrar mínir, þar sem þú færð 10 athugasemdir á Github fyrir hvaða spurningu sem er. En það er ekki nákvæmlega.
Því miður, á þessum tímapunkti, eru sérfræðingar rétt að byrja að koma fram. Þeir eru of fáir enn sem komið er. Og samfélagið sjálft hangir á frumstigi.
Hvert er þetta allt að fara og hvað á að gera
Þú getur sleppt öllu og farið aftur í C#, í heim knapans. En nei. Af hverju myndirðu jafnvel nenna að gera þetta ef þú finnur ekki lausn. Hér að neðan set ég fram huglægar niðurstöður mínar. Þú getur rökrætt við mig í athugasemdunum, það verður áhugavert.
Persónulega veðja ég á nokkra hluti:
- Þróun á þessu sviði er mjög hröð. Hér er áætlun um beiðnir um DevOps.
Umræðuefnið gæti verið efla, en sú staðreynd að kúlan er að stækka gefur nokkra von.Ef eitthvað vex svona hratt þá mun klárt fólk örugglega birtast sem segir þér hvað þú átt að gera og hvað ekki. Auknar vinsældir leiða til þess að kannski mun einhver hafa tíma til að bæta loksins viðbót við jsonnet fyrir vscode, sem gerir þér kleift að halda áfram að innleiða aðgerðina, frekar en að leita að henni með ctrl+shift+f. Eftir því sem hlutirnir þróast birtast fleiri efni. Útgáfa bókar frá Google um SRE er frábært dæmi um þetta.
- Það eru þróaðar aðferðir og venjur í hefðbundinni þróun sem við getum beitt með góðum árangri hér. Já, það eru blæbrigði með prófunum og ólíku umhverfi, ófullnægjandi verkfæri, en gríðarlegur fjöldi starfsvenja hefur safnast fyrir sem geta verið gagnlegar og gagnlegar.
Lítið dæmi: samstarf í gegnum paraforritun. Það hjálpar mikið að finna út úr því. Þegar þú ert með nágranna í nágrenninu sem er líka að reyna að skilja eitthvað, þá muntu skilja betur.
Skilningur á því hvernig endurþáttun er gerð hjálpar til við að framkvæma hana jafnvel í slíkum aðstæðum. Það er, þú getur ekki breytt öllu í einu, heldur breytt nafninu, breyttu síðan staðsetningunni, þá geturðu auðkennt einhvern hluta, ó, en það eru ekki nægar athugasemdir hér.
Ályktun
Þrátt fyrir að rökstuðningur minn kunni að virðast svartsýnn horfi ég til framtíðar með von og vona innilega að allt gangi upp hjá okkur (og þér).
Seinni hluti greinarinnar er í undirbúningi næst. Þar mun ég segja frá því hvernig við reyndum að nota lipra þróunaraðferðir til að bæta námsferlið okkar og vinna með innviði.
Heimild: www.habr.com