Pranimi IaC (Infrastructure as Code) nuk përbëhet vetëm nga kodi që ruhet në depo, por edhe nga njerëzit dhe proceset që e rrethojnë këtë kod. A mund të ripërdoren qasjet nga zhvillimi i softuerit në menaxhimin dhe përshkrimin e infrastrukturës? Nuk do të ishte keq ta mbani në mend këtë ide teksa po lexoni artikullin.

Kjo është një shkrim për the presentation në DevopsConf 2019-05-28.

Shtojcat dhe videot

Versioni në anglisht
Versioni në rusisht
Tryezë e thatë 2019-04-24 SpbLUG
Video (RU) nga DevopsConf 2019-05-28
Video (RU) nga DINS DevOps EVENING 2019-06-20
Shtojcat

Infrastruktura si historia e bash-it

Supozoni se po vini në një projekt të ri, dhe ju thonë: "kemi Infrastrukturë si Kod". Në realitet duket se, Infrastruktura si historia e bash-it ose për shembull Dokumentimi si historia e bash-it. Kjo është një situatë mjaft reale, për shembull, një rast të tillë e ka përshkruar Denis Lysenko në një paraqitje Si të zëvendësojmë të gjithë infrastrukturën dhe të fillojmë të flijmë qetë, ai tregoi se si nga historia e bash-it ata morën një infrastrukturë të strukturuar në projekt.

Me një dëshirë të caktuar, mund të thuhet se Infrastruktura si historia e bash-it është si kodi:

riprodhueshmëria: ju mund të merrni historinë e bash-it, të ekzekutoni komandat atje, ndoshta, për ironi, do të merrni një konfigurim funksional në dalje.
versionimi: ju dini kush hyri dhe çfarë bëri, përsëri nuk është e sigurt se kjo do t'ju çojë në një konfigurim funksional në dalje.
historie: historia e kujt dhe çfarë bëri. vetëm se nuk do të mund ta përdorni, nëse humbisni serverin.

Çfarë të bëjmë?

Infrastrukturë si Kod

Madje një rast kaq i çuditshëm si Infrastruktura si historia e bash-it mund të të zhvendoset me vështirësi në Infrastrukturë si Kod, por kur dëshirojmë të bëjmë diçka më të komplikuar se serveri tradicional LAMP, do të arrijmë në përfundimin se ky kod duhet ndonjëherë të modifikohet, ndryshohet dhe plotësohet. Më tej do të shqyrtojmë paralelizmat midis Infrastrukturë si Kod dhe zhvillimit të softuerit.

D.R.Y.

Në një projekt për zhvillimin e SAS, kishte një nën detyrë në mënyrë të rregullt të konfigurojë SDS: po nxjerrim një version të ri — duhen shpërndarë për testim të mëtejshëm. Detyra ishte jashtëzakonisht e thjeshtë:

shkoni këtu përmes ssh dhe ekzekutoni komandën.
kopjoni skedarin atje.
ndryshoni konfigurimin këtu.
nisni shërbimin atje.
…
PROFIT!

Për logjikën e përshkruar, është më se e mjaftueshme bash-i, veçanërisht në fazat e hershme të projektit, kur ai sapo ka filluar. Kjo nuk është keq që po përdorni bash., por kalim të paraqiten kërkesa për të zhvilluar diçka të ngjashme, por pak më ndryshe. E para që vjen në mend është: kopjo-ngjit. Dhe tani kemi dy skenare shumë të ngjashme që bëjnë pothuajse të njëjtën gjë. Me kalimin e kohës, numri i skenarëve është rritur, dhe ne u përballëm me faktin që kishte një logjikë biznesi për zhvillimin e instalimit, e cila duhet të sinkronizohet mes skenarëve të ndryshëm, kjo është mjaft e komplikuar.

Kështu që, ekziston një praktikë e tillë D.R.Y. (Mos e Përsërit Vetën). Ideja është të rishfrytëzohet kodi ekzistues. Dëgjohesh e thjeshtë, por nuk arritëm aty menjëherë. Në rastin tonë, kjo ishte një ide banale: të ndajmë konfigurimet nga skenarët. Pra, logjika e biznesit si zhvillohet instaluar veçmas, konfigurimet veçmas.

S.O.L.I.D. për CFM

Me kalimin e kohës, projekti u rrit dhe një vazhdim natyror ishte shfaqja e Ansible. Arsyetimi kryesor i shfaqjes së tij është se ekziston ekspertiza në ekip dhe se bash nuk është i destinuar për logjikë të komplikuar. Ansible gjithashtu filloi të përmbajë logjikë të komplikuar. Për të siguruar që logjika e komplikuar mos të kthehet në kaos, në zhvillimin e softuerit ekzistojnë parimet e organizimit të kodit. S.O.L.I.D. Po ashtu, për shembull, Grigori Petrov në leksionin e tij "Pse i duhen një IT-isti një markë personale" përmendi se njeriu, është i strukturuar në mënyrë që t'i jetë më e lehtë të operojë me entitete shoqërore, në zhvillimin e softuerit këto janë objekte. Nëse i bashkojmë këto dy ide dhe vazhdojmë t'i zhvillohemi, atëherë mund të vërehet se në përshkrimin e infrastrukturës mund të përdoren S.O.L.I.D. që më pas të jetë më e lehtë të mbahen dhe modifikohen këto logjika.

Parimi i Përgjegjësisë Individuale

Çdo klasë kryen vetëm një detyrë.

Nuk duhet të përzihen kodet dhe të krijohen monstra të mëdha dhe të pamundshme. Infrastrukturë duhet të përbëhet nga gure të thjeshtë. Duket se nëse e ndan Ansible playbook në copë të vogla, lexoni Ansible roles, është më e lehtë t'i mbani.

Parimi i Hapor dhe të Mbyllur

Parimi i hapjes/mbylljes.

I hapur për zgjerim: do të thotë se sjellja e një entiteti mund të zgjeron përmes krijimit të llojeve të reja të entiteteve.
Mbyllur për ndryshime: si rezultat i zgjerimit të sjelljes së entitetit, nuk duhet të bëhen ndryshime në kodin që përdor këto entitete.

Fill them initially we deployed a test infrastructure on virtual machines, but because the business logic of deployment was separate from the implementation, we easily added deployment on bare metal.

Principi i Zëvendësimit të Liskovit

Principi i zëvendësimit të Barabara Liskov. Objektet në program duhet të jenë të zëvendësueshme me instancat e nën-tipeve të tyre pa ndryshuar saktësinë e ekzekutimit të programit.

Nëse shohim më gjerë, nuk është një veçori e ndonjë projekti të veçantë që aty mund të aplikohet. S.O.L.I.D., ai në përgjithësi është për CFM, për shembull, në një projekt tjetër është e nevojshme të zhvillohet një aplikacion Java kutie mbi serverë të ndryshëm Java, aplikacioneve, bazën e të dhënave, OS, etj. Në këtë shembull do të shqyrtoj parimet e mëtejshme. S.O.L.I.D.

Në rastin tonë, brenda ekipit të infrastrukturës ka një marrëveshje që nëse ne instalojmë rolin imbjava ose oraclejava, atëherë ne kemi një skedar ekzekutiv binar java. Kjo është e nevojshme, pasi rollet e larta varen nga kjo sjellje, ato presin praninë e java. Njëkohësisht, kjo na lejon të zëvendësojmë një realizim/version java me një tjetër pa ndryshuar logjikën e zhvillimit të aplikacionit.

Problemi këtu qëndron në atë se në Ansible nuk është e mundur të realizohet një gjë, si pasojë brenda ekipit paraqiten disa marrëveshje.

Principi i Ndara e Interface-it

Principi i ndarjes së interface-it: "shumë interface-e, të posaçme për klientët, janë më të mira se një interface i zakonshëm."

Fillimisht ne provuam të grumbullojmë të gjithë variacionin e zhvillimit të aplikacionit në një Ansible playbook, por kjo ishte e vështirë për t'u mbështetur, dhe qasja, kur kemi një interface të specifikuar nga jashtë (klienti pret portin 443), atëherë për realizimin specifik mund të kompozojmë infrastrukturën nga blloqe të veçanta.

Principi i Inverzimit të Varësive

Principi i inverzimit të varësive. Modulët e niveleve të larta nuk duhet të varen nga modulët e niveleve të ulëta. Të dy tipet e modulëve duhet të varen nga abstraksionet. Abstraksionet nuk duhet të varen nga detajet. Detajet duhet të varen nga abstraksionet.

Këtu shembulli do të bazohet në një antipater.

Një nga klientët tanë kishte një re private.
Brenda re-së ne porositeme makina virtuale.
Por për shkak të veçorive të re-së, zhvillimi i aplikacionit ishte lidhur me atë se në cilin hipervizor kishte përfunduar VM.

Pra ndodhur një logjikë e lartë të shpërndarjes së aplikacionit, varësitë i kaluan në nivelet më të ulëta të hipervizorit, dhe kjo do të thoshte probleme kur rishfrytëzohej kjo logjikë. Mos e bëni kështu.

Interaksioni

Infrastruktura si kod nuk i referohet vetëm kodit, por gjithashtu marrëdhënieve midis kodit dhe njeriut, dhe ndërveprimeve midis zhvilluesve të infrastrukturës.

Bus factor

Supozoni se në projektin tuaj është Vasja. Vasja di gjithçka rreth infrastrukturës tuaj, çfarë do të ndodhte nëse Vasja papritur humbet? Kjo është një situatë shumë reale, sepse mund të goditet nga një autobus. Disa herë ndodhin gjëra të tilla. Nëse ndodh dhe njohuritë mbi kodin, strukturën e tij, si funksionon, si dhe informacionet e aksesit, nuk ndahen në ekip, atëherë mund të përballeni me një sërë situatash të pakëndshme. Për të minimizuar këto rreziqe dhe për të ndarë njohuritë brenda ekipit, mund të përdoren qasje të ndryshme.

Pair Devopsing

Nuk është si në shaka, që administratorët pinë birrë, ndërronin fjalëkalimet, dhe është analogu i programimit të çiftëve. Pra, dy inxhinierë ulen përpara një kompiuteri, një tastiere dhe fillojnë së bashku të konfigurojnë infrastrukturën tuaj: të konfigurojnë serverin, të shkruajnë rolin e Ansible, etj. Kjo tingëllon bukur, por tek ne nuk funksionoi. Megjithatë, disa raste të veçanta të kësaj praktike kanë funksionuar. Një punonjës i ri, mentori i tij me të merr një detyrë të vërtetë, punojnë — transferojnë njohuri.

Një rast tjetër i veçantë është thirrja e incidentit. Gjatë një problemi, grumbullohet një grup punonjësish dhe të angazhuarish, caktohet një udhëheqës, i cili ndan ekranin e tij dhe shpreh trenin e mendimit. Pjesëmarrësit e tjerë ndjekin mendimin e udhëheqësit, shikojnë truket nga konsola, kontrollojnë se çfarë nuk e kanë humbur në log, mësojnë gjëra të reja për sistemin. Kjo qasje ka funksionuar më shumë se sa jo.

Code Review

Sipas mendimit tim, përhapja e njohurive mbi infrastrukturën dhe mënyrën se si ajo është e ndërtuar kaloi më efektivisht përmes shqyrtimit të kodit:

Infrastruktura është e përshkruar si kod në repositor.
Ndryshimet ndodhin në një degë të veçantë.
Gjatë kërkesës për bashkimin, mund të shihni diferencën në ndryshimet e infrastrukturës.

Thelbi këtu ishte se rishikuesit zgjidheshin me radhë, sipas një grafiku, pra me një probabilitet të caktuar do të çohesh te një sektor të ri të infrastrukturës.

Stili i Kodit

Me kaluam, filluan të shfaqen shqetësime gjatë rishikimeve, pasi rishikuesit kishin stilin e tyre dhe rotacioni i rishikuesve i vuri përballë stileve të ndryshme: 2 hapësira ose 4, camelCase ose snake_case. Zbatimi i kësaj nuk ndodhi menjëherë.

Ideja fillestare ishte të rekomandohej përdorimi i linter-it, sepse inxhinierët janë të mençur. Por redaktorët e ndryshëm, sistemet operative, ishte e papërshtatshme.
Kjo evoluoi në një bot që për çdo commit problematik shkruante në slack dhe i përcillte daljen e linter-it. Por në shumë raste, kishte punë më të rëndësishme dhe kodi mbetej i papërmirësuar.

Green Build Master

Koha kalon, dhe arritëm në përfundimin se nuk duhej të lejonim në master commit-e që nuk kalonin disa teste. Vula! Ne shpikëm Green Build Master, i cili tashmë praktikohet prej kohësh në zhvillimin e softuerit:

Zhvillimi ndodh në një degë të veçantë.
Testet kryhen në këtë degë.
Nëse testet nuk kalojnë, kodi nuk do të kalojë në master.

Pranimi i këtij vendimi ishte shumë i dhimbshëm, sepse shkaktoi shumë debate, por ia vlejti, sepse kërkesat për bashkimin vinin pa mosmarrëveshje për stilin dhe me kalimin e kohës numri i problemeve filloi të zvogëlohej.

IaC Testing

Përveç kontrollit të stilit, mund të përdoren edhe gjëra të tjera, për shembull, të kontrolloni nëse infrastruktura juaj në të vërtetë mund të implementohet. Ose të kontrolloni nëse ndryshimet në infrastrukturë nuk do të shkaktojnë humbje të parave. Pse mund të nevojitet kjo? Pyetje e komplikuar dhe filozofike, më mirë do t'i përgjigjem me një tregim, se një herë kishte një auto-scaler në Powershell që, pa kontrolluar kushtet kritike => krijoi më shumë VM sesa duhej => klienti shpenzoi më shumë para sesa e kishte planifikuar. Nuk është e këndshme, por ky gabim mund të ishte kapur në faza më të hershme.

Dikush mund të pyesë, pse ta bësh infrastrukturën e komplikuar edhe më të komplikuar? Testet për infrastrukturën, ashtu si për kodin, nuk janë për thjeshtim, por për mirëkuptim se si duhet të funksionojë infrastruktura juaj.

IaC Testing Pyramid

IaC Testing: Static Analysis

Nëse menjëherë implementoni gjithë infrastrukturën dhe kontrolloni nëse ajo funksionon, mund të rezultojë se këtë proces e zë shumë kohë dhe kërkon shumë burime. Prandaj, në thelb duhet të ketë diçka që funksionon shpejt, është e përhapur, dhe mbulon shumë vende primitive.

Bash është i komplikuar

Le të shqyrtojmë një shembull banal. Të zgjedhim të gjitha skedaret në drejtorinë aktuale dhe t'i kopjojmë në një tjetër vend. E para që na vjen në mendje:

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

Po çfarë ndodh nëse emri i skedarit ka hapësira? Mirë, ne jemi të zgjuar, dimë të përdorim thonjëzat:

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

Jemi të mençur? Jo! Çfarë nëse nuk ka asnjë gjë në directory, dmth. globimi nuk funksionon.

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

Tani jemi të mençur? Jo... Haruam se emri i skedarit mund të ketë n.

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

Veglat e analizës statike

Problemi nga hapi i mëparshëm mund të kapet kur harrojmë thonjëzat, për këtë ka shumë mjete në natyrë Shellcheck, në të vërtetë janë shumë, dhe për më shumë mund të gjeni një lintrues për IDE tuaj dhe për stivën tuaj.

Gjuha
Mjeti

bash
Shellcheck

Ruby
RuboCop

python
Pylint

ansible
Ansible Lint

Testimi i IaC: Testet Njësì

Siç e pamë nga shembulli i mëparshëm, lintruesit nuk janë gjithëfuqishëm dhe nuk mund të tregojnë për çdo vend problematik. Më tutje, sipas analogjisë me testimin në zhvillimin e softuerit, mund të kujtojmë testet njësie. Këtu na vijnë menjëherë në mendje shunit, junit, rspec, pytest. Por çfarë të bëjmë me ansible, chef, saltstack dhe të tjerët?

Në fillim folëm për S.O.L.I.D. dhe se infrastruktura jonë duhet të përbëhet nga blloqe të vogla. Ka ardhur koha për ta.

Infrastruktura ndahen në blloqe të vogla, për shembull, rollet Ansible.
Krijohet një ambient i caktuar, qoftë docker apo VM.
Në këtë ambient testues aplikojmë rolin tonë Ansible.
Kontrollojmë që gjithçka ka shkuar si e prisnim (kemi kaluar testet).
Vendosim nëse është mirë apo jo.

Testimi i IaC: Mjetet e Testimit të Njësive

Përgjigjja, çfarë janë testet për CFM? Mund të ekzekutojmë thjesht një skenar, por gjithashtu mund të përdorim zgjidhje të gatshme për këtë:

CFM
Mjeti

Ansible
Testinfra

Chef
Inspec

Chef
Serverspec

saltstack
Goss

Shembulli për testinfra, kontrollojmë se përdoruesit test1, test2 ekzistojnë dhe janë në grupin 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

Çfarë të zgjidhni? Pyetje e ndërlikuar dhe e papërcaktuar, ja një shembull i ndryshimeve në projektet në github gjatë viteve 2018-2019:

Korniza e Testimit IaC

Shfaqet si të gjitha këto t'i mbledhim së bashku dhe t'i lançojmë? Mund të merrni dhe të bëni gjithçka vetë nëse keni një numër të mjaftueshëm inxhinierësh. Ose mund të merrni zgjidhje të gatshme, megjithatë ato nuk janë shumë:

CFM
Mjeti

Ansible
Molecule

Chef
Test Kitchen

Terraform
Terratest

Shembujt e ndryshimeve në projektet në github gjatë viteve 2018-2019:

Molecule vs. Testkitchen

Fillimisht ne provonim të përdornim testkitchen:

Krijoni VM në paralel.
Aplikoni rolet e Ansible.
Ekzekutoni inspec.

Për 25-35 role, kjo zgjati 40-70 minuta, që ishte shumë gjatë.

Hapi tjetër ishte kalimi në jenkins / docker / ansible / molecule. Ideologjikisht gjithçka është e njëjtë.

Lintoni playbook-et.
Lintoni rolet.
Nisni konteinerin.
Aplikoni rolet e Ansible.
Ekzekutoni testinfra.
Kontrolloni idempotentësinë.

Lintimi për 40 role dhe testet për dhjetë u morën rreth 15 minuta.

Çfarë të zgjidhni varet nga shumë faktorë, siç janë staku që përdoret, ekspertiza në skuadër, etj. Çdo kush vendos vetë se si t’i zgjidhë çështjet e testimit të njësive.

Testimi i IaC: Teste Integruese

Në shkallën tjetër të piramidës së testimit të infrastrukturës, paraqiten testet integruese. Ato janë të ngjashme me testet e njësive:

Infrastruktura ndahet në blloqe të vegjël, për shembull rolet e Ansible.
Krijohet një ambient i caktuar, qoftë docker apo VM.
Kjo mjedis testi zbatohet ka shumë rolet e Ansible.
Kontrollojmë që gjithçka ka funksionuar siç e presim (ekzekutojmë testet).
Vendosim nëse është mirë apo jo.

Pra, ne nuk kontrollojmë funksionalitetin e një elementi të vetëm të sistemit si në testet e njësive, por kontrollojmë si është konfiguruar serveri si një tërësi.

Testimi i IaC: Teste nga Fillimi në Fund

Në majë të piramidës na presin testet nga Fillimi në Fund. Pra, nuk kontrollojmë funksionalitetin e një serveri të vetëm, një script-i të vetëm, një bllok të vetëm të infrastrukturës sonë. Kontrollojmë që shumë serverë, të bashkuar së bashku, infrastruktura jonë funksionon siç e presim. Fatkeqësisht, nuk kam parë zgjidhje të gatshme, ndoshta për shkak se infrastruktura shpesh është unike dhe është e vështirë ta templatezosh dhe të krijosh një kornizë për testimin e saj. Në fund, çdo kush krijon zgjidhje të veta. Ka kërkesë, por përgjigje nuk ka. Prandaj, do të tregoj çfarë ka, për t’i sugjeruar të tjerëve mendime të shëndosha ose për të më drejtuar se gjithçka është shpikur para nesh.

Një projekt me histori të pasur. Përdoret në organizata të mëdha dhe ndoshta secili prej jush është takuar drejtpërdrejt me të. Aplikacioni mbështet shumë baza të dhënash, integrime etj. Dija se si mund të duket infrastruktura janë shumë skeda docker-compose, dhe dija se cilat teste të ekzekutohen në cilin mjedis — është jenkins.

Kjo skemë ka funksionuar mjaft gjatë, derisa në kuadër të studime ne provuam ta transferojmë atë në Openshift. Konteinerët mbetën të njëjtë, por ambienti i ekzekutimit u ndryshua (përshëndetje D.R.Y. përsëri).

Hulumtimi u zhvillua më tej dhe në openshift u gjet një gjë e tillë APB (Ansible Playbook Bundle), e cila lejon të paketosh njohuritë për si të zhvendosësh infrastrukturën brenda një kontejneri. Kështu, ekziston një pikë njohurie e riprodhueshme dhe e testueshme, se si të zhvendosësh infrastrukturën.

E gjithë kjo dukej mirë derisa u përballëm me një infrastrukturë heterogjene: na duhej Windows për testime. Si rezultat, njohuria për atë që, ku dhe si të zhvendosim dhe të testojmë është ruajtur në jenkins.