Nálgunin IaC (Infrastructure as Code) samanstendur ekki aðeins af kóðanum sem er geymdur í geymslunni, heldur einnig af fólki og ferlum sem umlykja þennan kóða. Er hægt að endurnýta aðferðir frá hugbúnaðarþróun til innviðastjórnunar og lýsingar? Það væri gott að hafa þessa hugmynd í huga á meðan þú lest greinina.

Þetta er afrit af mínum sýningar á DevopsConf 2019-05-28.

Glærur og myndbönd

ensk útgáfa
Rússnesk útgáfa
Þurrhlaup 2019-04-24 SpbLUG
Myndband (RU) frá DevopsConf 2019-05-28
Myndband(RU) frá DINS DevOps KVÖLD 2019-06-20
Glærur

Innviðir sem bash saga

Segjum sem svo að þú komir að nýju verkefni og þeir segja þér: „Við höfum Innviðir sem kóða". Í raun og veru kemur í ljós Innviðir sem bash saga eða til dæmis Skjöl sem bash saga. Þetta er mjög raunveruleg staða, til dæmis lýsti Denis Lysenko svipuðu máli í ræðu Hvernig á að skipta um allan innviði og byrja að sofa rólegur, sagði hann hvernig þeir fengu samhangandi innviði fyrir verkefnið úr bash sögu.

Með nokkurri löngun getum við sagt það Innviðir sem bash saga þetta er eins og kóði:

endurgerðanleika: Þú getur tekið bash sögu, keyrt skipanirnar þaðan, og þú gætir, við the vegur, fengið vinnustillingar sem úttak.
útgáfugerð: þú veist hver kom inn og hvað þeir gerðu, aftur, það er ekki staðreynd að þetta muni leiða þig í virka uppsetningu við útganginn.
Saga: sagan um hver gerði hvað. aðeins þú munt ekki geta notað það ef þú tapar þjóninum.

Hvað á að gera?

Innviðir sem kóða

Jafnvel svo undarlegt mál sem Innviðir sem bash saga þú getur dregið það í eyrun Innviðir sem kóða, en þegar við viljum gera eitthvað flóknara en gamla góða LAMP þjóninn þá komumst við að þeirri niðurstöðu að einhvern veginn þurfi að breyta, breyta, bæta þennan kóða. Næst viljum við líta á hliðstæðurnar þar á milli Innviðir sem kóða og hugbúnaðarþróun.

ÞURR

Í þróunarverkefni geymslukerfis var undirverkefni stilla SDS reglulega: við erum að gefa út nýja útgáfu - það þarf að setja hana út til frekari prófunar. Verkefnið er mjög einfalt:

skráðu þig inn hér í gegnum ssh og keyrðu skipunina.
afritaðu skrána þangað.
leiðréttu stillinguna hér.
hefja þjónustuna þar
...
HAGNAÐUR!

Fyrir lýst rökfræði er bash meira en nóg, sérstaklega á fyrstu stigum verkefnisins, þegar það er rétt að byrja. Þetta það er ekki slæmt að þú notir bash, en með tímanum eru beiðnir um að senda eitthvað svipað, en aðeins öðruvísi. Það fyrsta sem kemur upp í hugann er copy-paste. Og nú erum við nú þegar með tvö mjög svipuð handrit sem gera næstum það sama. Með tímanum jókst fjöldi skrifta og við stóðum frammi fyrir því að það er ákveðin viðskiptarökfræði fyrir því að setja upp uppsetningu sem þarf að samstilla á milli mismunandi skrifta, þetta er frekar flókið.

Það kemur í ljós að það er til æfing eins og DRY (Do not Repeat Yourself). Hugmyndin er að endurnýta núverandi kóða. Það hljómar einfalt, en við komumst ekki að þessu strax. Í okkar tilviki var það banal hugmynd: að aðskilja stillingar frá skriftum. Þeir. viðskiptarökfræði um hvernig uppsetningin er notuð sérstaklega, stillir sérstaklega.

SOLID fyrir CFM

Með tímanum stækkaði verkefnið og eðlilegt framhald var tilkoma Ansible. Aðalástæðan fyrir útliti þess er sú að það er sérfræðiþekking á liðinu og að bash er ekki hannað fyrir flókna rökfræði. Ansible byrjaði líka að innihalda flókna rökfræði. Til að koma í veg fyrir að flókin rökfræði breytist í glundroða eru til reglur um skipulag kóða í hugbúnaðarþróun FAST Einnig, til dæmis, vakti Grigory Petrov í skýrslunni „Af hverju þarf upplýsingatæknisérfræðingur persónulegt vörumerki“ þá spurningu að einstaklingur sé hannaður á þann hátt að það sé auðveldara fyrir hann að starfa með einhverjum félagslegum aðilum, í hugbúnaðarþróun, þ. eru hlutir. Ef við sameinum þessar tvær hugmyndir og höldum áfram að þróa þær, munum við taka eftir því að við getum líka notað FAST til að auðvelda að viðhalda og breyta þessari rökfræði í framtíðinni.

Eina ábyrgðarreglan

Hver bekkur vinnur aðeins eitt verkefni.

Engin þörf á að blanda kóða og búa til einhæf guðdómleg spaghettí skrímsli. Innviðir ættu að samanstanda af einföldum múrsteinum. Það kemur í ljós að ef þú skiptir Ansible leikbókinni í litla bita, lestu Ansible hlutverkin, þá er auðveldara að viðhalda þeim.

Opna lokaða meginreglan

Opin/lokuð regla.

Opið fyrir framlengingu: þýðir að hægt er að útvíkka hegðun einingar með því að búa til nýjar einingargerðir.
Lokað fyrir breytingu: Sem afleiðing af útvíkkun á hegðun aðila ætti ekki að gera breytingar á kóðanum sem notar þessar einingar.

Upphaflega settum við upp prófunarinnviðina á sýndarvélar, en vegna þess að viðskiptarökfræði dreifingarinnar var aðskilin frá innleiðingunni, bættum við útrásinni í baremetall án vandræða.

Liskov staðgöngureglan

Staðgönguregla Barböru Liskov. hlutir í forriti verða að vera hægt að skipta út fyrir tilvik af undirtegundum þeirra án þess að breyta réttri framkvæmd forritsins

Ef þú skoðar það víðar, þá er það ekki eiginleiki í neinu sérstöku verkefni sem hægt er að beita þar FAST, það snýst almennt um CFM, til dæmis í öðru verkefni er nauðsynlegt að setja Java forrit í kassa ofan á ýmsa Java, forritaþjóna, gagnagrunna, stýrikerfi osfrv. Með því að nota þetta dæmi mun ég íhuga frekari meginreglur FAST

Í okkar tilviki er samkomulag innan innviða teymisins að ef við höfum sett upp imbjava eða oraclejava hlutverkið, þá erum við með java tvíundar keyrslu. Þetta er nauðsynlegt vegna þess Uppstreymishlutverk eru háð þessari hegðun sem þeir búast við java. Á sama tíma gerir þetta okkur kleift að skipta út einni Java útfærslu/útgáfu fyrir aðra án þess að breyta rökfræði dreifingar forrita.

Vandamálið hér liggur í því að það er ómögulegt að innleiða þetta í Ansible, þar af leiðandi birtast einhverjir samningar innan teymisins.

Reglan um aðskilnað viðmóta

Viðmótsaðskilnaðarreglan: „Mörg viðskiptavinasértæk viðmót eru betri en eitt almennt viðmót.

Upphaflega reyndum við að setja allan breytileika dreifingar forrita í eina Ansible leikbók, en það var erfitt að styðja, og nálgunin þegar við erum með ytra viðmót tilgreint (viðskiptavinurinn býst við höfn 443), þá er hægt að setja saman innviði úr einstökum múrsteinar fyrir ákveðna útfærslu.

The Dependency Inversion Principle

Meginreglan um ósjálfstæði. Einingar á hærri stigum ættu ekki að vera háðar einingum á lægri stigum. Báðar tegundir eininga verða að vera háðar útdrætti. Útdráttur ætti ekki að vera háður smáatriðum. Upplýsingar verða að ráðast af útdrætti.

Hér verður dæmið byggt á andmynstri.

Einn viðskiptavinanna var með einkaský.
Við pöntuðum sýndarvélar inni í skýinu.
En vegna eðlis skýsins var uppsetning forrita bundin við hvaða hypervisor sem VM var á.

Þeir. Dreifingarrökfræði forrita á háu stigi flæddi með ósjálfstæði til lægri stiga yfirsýnarans og þetta þýddi vandamál þegar þessi rökfræði var endurnotuð. Ekki gera þetta á þennan hátt.

Samskipti

Innviðir sem kóða snýst ekki aðeins um kóða, heldur einnig um tengsl milli kóða og fólks, um samskipti milli innviðaframleiðenda.

Strætó þáttur

Gerum ráð fyrir að þú sért með Vasya í verkefninu þínu. Vasya veit allt um innviði þína, hvað mun gerast ef Vasya hverfur skyndilega? Þetta er mjög raunverulegt ástand, því hann gæti orðið fyrir rútu. Stundum gerist það. Ef þetta gerist og þekkingu um kóðann, uppbyggingu hans, hvernig hann virkar, útlit og lykilorð er ekki dreift á hópinn, þá gætir þú lent í ýmsum óþægilegum aðstæðum. Til að lágmarka þessa áhættu og dreifa þekkingu innan teymisins er hægt að nota ýmsar aðferðir

Pair Devopsing

Það er ekki eins og sem brandari, að stjórnendur hafi drukkið bjór, skipt um lykilorð og hliðstæða paraforritun. Þeir. tveir verkfræðingar setjast við eina tölvu, eitt lyklaborð og byrja að setja upp innviði ykkar saman: setja upp netþjón, skrifa Ansible hlutverk o.s.frv. Það hljómar vel, en það virkaði ekki fyrir okkur. En sérstök tilvik um þessa framkvæmd virkuðu. Nýr starfsmaður kemur, leiðbeinandi hans tekur að sér alvöru verkefni með honum, vinnur og miðlar þekkingu.

Annað sértilvik er atvikskall. Á meðan á vandamáli stendur safnast saman hópur þeirra sem standa vaktina og þeirra sem taka þátt, einn leiðtogi er skipaður sem deilir skjánum sínum og kveður hugsunarháttinn. Aðrir þátttakendur fylgjast með hugsunum leiðtogans, njósna um brellur frá stjórnborðinu, athuga hvort þeir hafi ekki misst af línu í skránni og læra nýja hluti um kerfið. Þessi aðferð virkaði oftar en ekki.

Endurskoðun kóða

Huglægt var það skilvirkara að miðla þekkingu um innviðina og hvernig það virkar með því að nota kóða endurskoðun:

Innviðum er lýst með kóða í geymslunni.
Breytingar eiga sér stað í sérstakri grein.
Meðan á sameiningarbeiðni stendur geturðu séð þátt breytinga á innviðum.

Hápunkturinn hér var að gagnrýnendur voru valdir einn af öðrum, samkvæmt dagskrá, þ.e. með einhverjum líkum á að þú klifrar inn í nýjan innviði.

Kóðastíll

Með tímanum fóru að koma upp deilur við dóma, vegna þess að... gagnrýnendur höfðu sinn eigin stíl og skipting gagnrýnenda staflað þeim með mismunandi stílum: 2 bilum eða 4, camelCase eða snake_case. Það var ekki hægt að koma þessu í framkvæmd strax.

Fyrsta hugmyndin var að mæla með því að nota linter, þegar allt kemur til alls eru allir verkfræðingar, allir klárir. En mismunandi ritstjórar, OS, eru ekki þægilegir
Þetta þróaðist í vélmenni sem skrifaði til að slaka á fyrir hverja erfiða skuldbindingu og festi linter úttakið. En í flestum tilfellum voru mikilvægari hlutir að gera og kóðinn var ólagaður.

Grænn smíðameistari

Tíminn líður og við höfum komist að þeirri niðurstöðu að skuldbindingum sem standast ekki ákveðin próf megi ekki hleypa inn í meistarann. Voila! Við fundum upp Green Build Master, sem hefur verið stundaður í hugbúnaðarþróun í langan tíma:

Unnið er að þróun í sérstakri grein.
Próf eru í gangi á þessum þræði.
Ef prófin mistakast mun kóðinn ekki komast inn í masterinn.

Að taka þessa ákvörðun var mjög sársaukafullt, vegna þess að... olli miklum deilum, en það var þess virði, því... Umsagnir fóru að berast beiðnir um sameiningu án stílsmuna og með tímanum fór vandamálasvæðum að fækka.

IaC prófun

Til viðbótar við stílaskoðun geturðu notað aðra hluti, til dæmis til að athuga hvort innviðir þínir geti raunverulega sett upp. Eða athugaðu að breytingar á innviðum leiði ekki til peningataps. Hvers vegna gæti verið þörf á þessu? Spurningin er flókin og heimspekileg, það er betra að svara með sögu að einhvern veginn hafi verið sjálfvirkur mælikvarði á Powershell sem athugaði ekki mörkin => fleiri VM voru búnar til en nauðsynlegt er => viðskiptavinurinn eyddi meiri peningum en áætlað var. Þetta er ekki mjög skemmtilegt, en það væri alveg hægt að ná þessari villu á fyrri stigum.

Spyrja má, hvers vegna gera flókna innviði enn flóknari? Próf fyrir innviði, rétt eins og fyrir kóða, snúast ekki um einföldun, heldur um að vita hvernig innviðir þínir ættu að virka.

IaC prófunarpýramída

IaC prófun: Static Analysis

Ef þú setur allt innviðina í notkun í einu og athugar hvort það virki gætirðu fundið að það tekur mikinn tíma og krefst mikils tíma. Þess vegna verður grunnurinn að vera eitthvað sem virkar hratt, það er mikið af því og spannar marga frumstæða staði.

Bash er erfiður

Lítum á léttvæg dæmi. veldu allar skrár í núverandi möppu og afritaðu á annan stað. Það fyrsta sem kemur upp í hugann:

for i in * ; do 
    cp $i /some/path/$i.bak
done

Hvað ef það er bil í skráarnafninu? Jæja, allt í lagi, við erum klár, við vitum hvernig á að nota tilvitnanir:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

Vel gert? Nei! Hvað ef það er ekkert í möppunni, þ.e. globbing virkar ekki.

find . -type f -exec mv -v {} dst/{}.bak ;

Vel gert núna? Nei... Gleymdi hvað getur verið í skráarnafninu n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

Stöðug greiningartæki

Vandamálið frá fyrra skrefi gæti gripist þegar við gleymdum tilvitnunum, fyrir þetta eru mörg úrræði í náttúrunni Shellcheck, Almennt er mikið af þeim, og líklegast geturðu fundið linter fyrir stafla þinn undir IDE þinni.

Tungumál
Tól

bash
Shellcheck

Ruby
RuboCop

python
pylint

ansible
Ansible Lint

IaC próf: Einingapróf

Eins og við sáum frá fyrra dæminu eru linters ekki almáttugur og geta ekki bent á öll vandamálasvæðin. Ennfremur, á hliðstæðan hátt við prófun í hugbúnaðarþróun, getum við rifjað upp einingapróf. Það sem kemur strax upp í hugann er shunit, vegamót, rspec, pytest. En hvað á að gera við ansible, kokkur, saltstakka og aðra slíka?

Strax í upphafi ræddum við um FAST og að innviðir okkar ættu að samanstanda af litlum múrsteinum. Þeirra tími er kominn.

Innviðum er skipt í litla múrsteina, til dæmis Ansible hlutverk.
Einhvers konar umhverfi er notað, hvort sem það er docker eða VM.
Við notum Ansible hlutverki okkar í þessu prófunarumhverfi.
Við athugum hvort allt hafi virkað eins og við bjuggumst við (við keyrum próf).
Við ákveðum allt í lagi eða ekki í lagi.

IaC prófun: Einingaprófunartæki

Spurning, hvað eru próf fyrir CFM? Þú getur einfaldlega keyrt skriftuna, eða þú getur notað tilbúnar lausnir fyrir þetta:

CFM
Tól

Ansible
Testinfra

Chef
Skoðaðu

Chef
Serverspec

saltstafla
Goss

Dæmi um testinfra, athuga að notendur test1, test2 eru til og eru í hóp sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

Hvað á að velja? Spurningin er flókin og óljós, hér er dæmi um breytingar á verkefnum á github fyrir 2018-2019:

IaC prófunarramma

Spurningin vaknar: hvernig á að setja þetta allt saman og ræsa það? Dós taktu það og gerðu það sjálfur ef nægilegur fjöldi verkfræðinga er. Eða þú getur tekið tilbúnar lausnir, þó þær séu ekki mjög margar:

CFM
Tól

Ansible
Molecule

Chef
Prófað eldhús

Terraform
Terratest

Dæmi um breytingar á verkefnum á github fyrir 2018-2019:

Sameind vs. Prófeldhús

Upphaflega við prófaði að nota testkitchen:

Búðu til VM samhliða.
Notaðu Ansible hlutverk.
Keyra skoðun.

Fyrir 25-35 hlutverk virkaði það 40-70 mínútur, sem var langt.

Næsta skref var umskipti yfir í jenkins/docker/ansible/sameind. Hugmyndafræðilega er allt við það sama

Lint leikrit.
Raðaðu hlutverkunum upp.
Ræstu ílát
Notaðu Ansible hlutverk.
Keyra testinfra.
Athugaðu getuleysi.

Fóðrun fyrir 40 hlutverk og próf fyrir tugi tók að taka um 15 mínútur.

Hvað á að velja fer eftir mörgum þáttum, svo sem staflanum sem notaðir eru, sérfræðiþekkingu í teyminu o.s.frv. hér ákveður hver sjálfur hvernig á að loka Einingaprófunarspurningunni

IaC próf: Samþættingarpróf

Næsta skref í innviðaprófunarpýramídanum verður samþættingarpróf. Þau eru svipuð einingaprófum:

Innviðum er skipt í litla múrsteina, til dæmis Ansible hlutverk.
Einhvers konar umhverfi er notað, hvort sem það er docker eða VM.
Fyrir þetta prófunarumhverfi gilda margir Ansible hlutverk.
Við athugum hvort allt hafi virkað eins og við bjuggumst við (við keyrum próf).
Við ákveðum allt í lagi eða ekki í lagi.

Í grófum dráttum könnum við ekki frammistöðu einstaks þáttar kerfisins eins og í einingaprófum, við athugum hvernig þjónninn er stilltur í heild sinni.

IaC prófun: Próf frá enda til enda

Efst í pýramídanum taka á móti okkur End to End próf. Þeir. Við athugum ekki frammistöðu sérstaks netþjóns, sérstakts handrits eða sérstakrar múrsteins innviða okkar. Við athugum hvort margir netþjónar séu tengdir saman, innviðir okkar virka eins og við búumst við. Því miður hef ég aldrei séð tilbúnar kassalausnir, líklega vegna þess að... Innviðirnir eru oft einstakir og erfitt að búa til ramma fyrir prófun. Fyrir vikið búa allir til sínar eigin lausnir. Það er eftirspurn, en það er ekkert svar. Þess vegna skal ég segja þér hvað það er til að ýta öðrum til að hugsa eða nudda nefinu á mér í því að allt var fundið upp fyrir löngu á undan okkur.

Verkefni með ríka sögu. Það er notað í stórum stofnunum og sennilega hefur hvert ykkar farið óbeint yfir það. Forritið styður marga gagnagrunna, samþættingu osfrv. Að vita hvernig innviðirnir gætu litið út er mikið af docker-compose skrám og að vita hvaða próf á að keyra í hvaða umhverfi er Jenkins.

Þetta fyrirkomulag virkaði í nokkuð langan tíma, þar til innan rammans rannsóknir við höfum ekki reynt að flytja þetta yfir á Openshift. Gámarnir eru óbreyttir, en sjósetningarumhverfið hefur breyst (halló DRY aftur).

Rannsóknarhugmyndin gekk lengra og í openshift fundu þeir eitthvað eins og APB (Ansible Playbook Bundle), sem gerir þér kleift að pakka þekkingu um hvernig á að dreifa innviðum í gám. Þeir. það er endurtekinn, prófanlegur þekkingarpunktur um hvernig eigi að dreifa innviðunum.

Allt þetta hljómaði vel þar til við lentum í ólíkum innviðum: við þurftum Windows til að prófa. Þar af leiðandi er vitneskjan um hvað, hvar, hvernig á að dreifa og prófa í jenkins.

Niðurstaða

Innviði eins og kóða er

Kóði í geymslunni.
Mannleg samskipti.
Innviðaprófun.

tenglar

Heimild: www.habr.com

Það sem ég lærði af því að prófa 200 línur af innviðakóða