Qashtu IaC (Infrastruktura si Kod) përfshin jo vetëm kodin që ruhet në depo, por edhe njerëzit dhe proceset që rrethojnë atë kod. A është e mundur të ripërdoren qasjet nga zhvillimi i softuerit në menaxhimin dhe përshkrimin e infrastrukturës? Nuk do të ishte e tepërt ta mbani këtë ide në mendje, ndërsa po lexoni artikullin.

Ky është shpjegimi im për i fjalës në DevopsConf 2019-05-28.

Slidet dhe videot

Versioni në anglisht
Versioni në rusisht
Dry run 2019-04-24 SpbLUG
Video(RU) nga DevopsConf 2019-05-28
Video(RU) nga DINS DevOps EVENING 2019-06-20
Prezantimet

Infrastruktura si historiku i bash

Le të supozojmë se vini në një projekt të ri, dhe ju thonë: «kemi Infrastruktura si Kod«. Në të vërtetë del të jetë, Infrastruktura si historiku i bash ose për shembull Dokumentacioni si historiku i bash. Kjo është një situatë krejt reale, për shembull, një rast të ngjashëm e përshkruante Denis Lysenko në fjalimin e tij Si të zëvendësohet e gjithë infrastruktura dhe të filloni të flini qetë, ai tregoi se si nga historiku i bash ata morën një infrastrukturë të strukturuar në projekt.

Me pak dëshirë, mund të thuash se Infrastruktura si historiku i bash është si kodi:

riprodhueshmëria: ju mund të merrni historikun e bash, të ekzekutoni komandat nga aty, ndoshta, nga ana tjetër, do të merrni një konfigurim të punës në dalje.
versionimi: e dini kush kishte hyrë dhe çfarë kishte bërë, përsëri nuk është e sigurt që kjo do t'ju çojë në një konfigurim funksional në fund.
historia: historia e këtyre që bënë dhe çfarë bënë. por nuk do të jeni në gjendje ta përdorni atë nëse humbni serverin.

Çfarë duhet të bëjmë?

Infrastruktura si Kod

Madje një rast kaq i çuditshëm si Infrastruktura si historiku i bash mund të tërhiqet për hi Infrastruktura si Kod, por kur do të duam të bëjmë diçka më të komplikuar se serveri i vjetër i njohur LAMP, do të arrijmë në përfundimin se ky kod duhet të modifikohet, të ndryshohet, të përmirësohet. Më pas, do të shqyrtojmë paralellet midis Infrastruktura si Kod dhe zhvillimit të softuerit.

D.R.Y.

Në projektin për zhvillimin e HDD, kishte një nënpërgjegjësi për të konfiguroni SDS rregullisht: po lëshojmë një version të ri — duhet ta instalojmë atë për testim të mëtejshëm. Detyra është shumë e thjeshtë:

hyni këtu përmes ssh dhe ekzekutoni komandën.
kopyoni dosjen atje.
ndryshoni konfigurimin këtu.
nisni shërbimin atje
…
PROFIT!

Për logjikën e përshkruar, është më se e mjaftueshme bash, sidomos në fazat e hershme të projektit, kur ai sapo fillon. Kjo nuk është keq që përdorni bash, por ko njëkohësisht dalin kërkesa për të zhvilluar diçka të ngjashme, por pak ndryshe. E para që më vjen në mendje: kopjimi dhe ngjitja. Dhe ja, tashmë kemi dy skripta shumë të ngjashme që bëjnë gati të njëjtën gjë. Me kalimin e kohës, numri i skripteve u rrit, dhe u përballëm me faktin që ekziston një logjikë biznesi për vendosjen e instalimeve, që duhet të sinkronizohet mes skripteve të ndryshme, dhe kjo është mjaft e komplikuar.

Doli të ketë një praktikë të tillë D.R.Y. (Mos e Përsëris vetën). Ideja është që të ripërdorim kodin ekzistues. Dëgjohet e thjeshtë, por nuk arritëm tek kjo menjëherë. Në rastin tonë, ishte një ide banale: ndarja e konfigurimeve nga skriptet. D.m.th., logjika e biznesit si instalohet ndaras, konfigurimet ndaras.

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

Me kalimin e kohës, projekti u rrit dhe si një vazhdim natural u shfaq Ansible. Arsyeja kryesore për shfaqjen e tij është prania e ekspertizës në ekip dhe që bash është i papërshtatshëm për logjikë të komplikuar. Ansible gjithashtu filloi të përmbajë logjikë të komplikuar. Për të siguruar që logjika e komplikuar të mos shndërrohet në kaos, në zhvillimin e softuerit ekzistojnë parime për organizimin e kodit. S.O.L.I.D. Po shembull, Grigori Petrov në raportin 'Pse një IT-isti ka nevojë për markë personale' përmendi se njerëzit janë të prirur të operojnë me disa entitete sociale, dhe në zhvillimin e softuerit, këto janë objekte. Nëse e bashkojmë këto dy ide dhe vazhdojmë t'i zhvillojmë ato, mund të vërejmë se në përshkrimin e infrastrukturës mund të përdoren gjithashtu. S.O.L.I.D. kishte për qëllim që në të ardhmen të ishte më e lehtë të mbaheshin dhe të modifikoheshin këto logjika.

Principi i Përgjegjësisë së Vetme

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

Nuk duhet të përzihen kodet dhe të bëhen monsterë të mëdhenj monolitë. Infrastrukturë duhet të përbëhet nga blloqe të thjeshta. Zbulohet se nëse e copëzojmë Ansible playbook në copa të vogla, pra Ansible roles, është më e lehtë t'i mbash.

Principi i Hapjes dhe Mbylljes

Principi i hapjes/mbylljes.

Të hapur për zgjerim: do të thotë se sjellja e entitetit mund të zgjerohet duke krijuar lloje të reja entitetesh.
Të mbyllur për ndryshim: si rezultat i zgjerimit të sjelljes së entitetit, nuk duhet të bëhen ndryshime në kodin që përdor këto entitete.

Fillimisht, ne kishim ndërtuar infrastrukturën testuese në makina virtuale, por për shkak se logjika e biznesit të implementimit ishte ndarë nga realizimi, ne e shtuam pa probleme implementimin në bare metal.

Parimi i Zëvendësimit të Liskov

Parimi i zëvendësimit të Barbare Liskov. Objektet në program duhet të jenë të zëvendësueshme me instanca të nën-tipave të tyre pa ndryshuar saktësinë e ekzekutimit të programit.

Nëse e shikoni më gjerë, nuk është veçori e ndonjë projekti të veçantë se atje mund të aplikohet. S.O.L.I.D., ajo në përgjithësi ka të bëjë me CFM, për shembull, në një projekt tjetër është e nevojshme të implementohet një aplikacion Java në kutatë mbi serverë të ndryshëm Java, bazat 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 kemi instaluar rolin imbjava ose oraclejava, atëherë ne kemi një skedar ekzekutiv binar java. Kjo është e nevojshme, sepse rolet e sipërme varen nga ky sjellje, ato presin praninë e java. Njëkohësisht, kjo na lejon të zëvendësojmë një implementim/version të java me një tjetër pa ndryshuar logjikën e implementimit të aplikacionit.

Problemi këtu është se në Ansible nuk është e mundur të realizohet diçka, si rezultat, në ekip shfaqen disa marrëveshje.

Parimi i Ndashjes së Interfaces

Parimi i ndarjes së interfaces 'shumë interface, të dizajnuara veçmas për klientët, është më mirë se një interface i përgjithshëm.

Fillimisht, ne provuam të mbledhim të gjithë variabilitetin e vendosjes së aplikacionit në një Ansible playbook, por kjo ishte e vështirë për t'u mbajtur, dhe qasja, kur ne kemi një interface të specifikuar nga jashtë (klienti pret portin 443), është që për realizimin konkret mund të ndërtojmë infrastrukturën nga blloqe të veçanta.

Parimi i Inversimit të Varësisë

Parimi i inversimit të varësisë. Modulet e niveleve të larta nuk duhet të varen nga modulet e niveleve të ulëta. Të dyja llojet e modulit 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ë antipattern.

Një nga klientët tanë kishte një re private.
Brenda re, ne porositëm makina virtuale.
Por për shkak të veçorive të re, vendosja e aplikacionit ishte e lidhur me atë se në cilin hypervisor përfundoi VM.

Kështu, logjika e nivelit të lartë për shpërndarjen e aplikacionit, me varësi, kalonte në nivelet e poshtme të hipervizorit, dhe kjo do të thoshte probleme gjatë ripërdorimit të kësaj logjike. Nuk duhen bërë kështu.

Interaksioni

Infrastruktura si kod — nuk është vetëm për kod, por gjithashtu për marrëdhëniet midis kodit dhe njeriut, për interaksionet mes zhvilluesve të infrastrukturës.

Faktori i autobusit

Supozoni se keni një person të quajtur Vasilij në projektin tuaj. Vasilij di gjithçka për infrastrukturën tuaj, çfarë do të ndodhte nëse Vasilij ndonjëherë zhduket? Kjo është një situatë mjaft reale, sepse mund të goditet nga një autobus. Ndonjëherë, kjo ndodh. Nëse ndodh dhe njohuritë për kodin, strukturën e tij, si funksionon, emrat dhe fjalëkalimet, nuk janë shpërndarë brenda ekipit, atëherë mund të përballeni me disa situata të pakëndshme. Për të minimalizuar këto rreziqe dhe për të shpërndarë njohuritë brenda ekipit, mund të përdoren qasje të ndryshme.

Devopsing në çift

Nuk është si në një shaka, që administratorët pinin birrë, ndryshonin fjalëkalimet, dhe një analogji e programimit në çift. dmth. dy inxhinierë ulen përpara një kompjuteri, një tastierë dhe fillojnë së bashku të konfigurojnë infrastrukturën tuaj: të konfigurojnë serverin, të shkruajnë rolin Ansible, etj. Dëgjohet bukur, por për ne nuk funksionoi. Megjithatë, disa raste private të kësaj praktike funksionuan. Një punonjës i ri erdhi, mentor i tij merr një detyrë reale, punon — kalon njohuritë.

Një rast tjetër privat është incident call. Gjatë një problemi, mblidhet një grup i turneve dhe të përfshirëve, emërohet një udhëheqës, i cili ndan ekranin e tij dhe shpreh mendimet. pjesëmarrësit e tjerë ndjekin mendimin e udhëheqësit, shikojnë truket nga konsola, kontrollojnë çfarë nuk ka humbur një rresht në log, mësojnë diçka të re për sistemin. Ky qasje funksionoi më shumë se sa jo.

Shqyrtimi i Kodit

Subjektivisht, shpërndarja më efikase e njohurive mbi infrastrukturën dhe se si është e organizuar ndodhi përmes shqyrtimit të kodit:

Infrastruktura përshkruhet me kod në repository.
Ndryshimet ndodhin në një degë të veçantë.
Me kërkesën e bashkimit mund të shihni diferencën e ndryshimeve në infrastrukturë.

E veçantja këtu ishte që rishikuesit zgjidheshin me turne, sipas një grafiku, dmth me një nivel të caktuar probabiliteti do të përfshihesh në një pjesë të re të infrastrukturës.

Stili i Kodit

Me kalimin e kohës, filluan të shfaqen tensione gjatë rishikimeve, pasi rishikuesit kishin stilin e tyre dhe rotacioni i rishikuesve i kombinonte ata me stile të ndryshme: 2 hapësira ose 4, camelCase ose snake_case. Implementimi i kësaj nuk arriti të bëhet menjëherë.

Ideja e parë ishte të rekomandohej përdorimi i linter-it, sepse gjithsesi inxhinierët janë të gjithë të mençur. Por redaktorët e ndryshëm, OS, ishin të pah便利.
Kjo evoluoi në një bot, i cili për çdo komit problematik shkruante në slack dhe bashkëngjiste daljen nga linter-i. Por në shumicën e rasteve, ndiheshin punë më të rëndësishme dhe kodi mbetej i pa korrigjuar.

Green Build Master

Koha kalon dhe arritëm në atë që nuk mund të lejojmë në master komite që nuk kalojnë disa teste. Voilà! ne shpikëm Green Build Master, i cili është përdorur prej një kohë të gjatë në zhvillimin e softuerit:

Zhvillimi bëhet në një degë të veçantë.
Testet kryhen mbi këtë degë.
Nëse testet nuk kalojnë, kodi nuk do të shkojë në master.

Pranimi i këtij vendimi ishte shumë i dhimbshëm, sepse shkaktoi shumë polemika, por ia vlejti, pasi kërkesat për bashkimin filluan të mbërrinin pa mos ndodhur mosmarrëveshje mbi stilin dhe me kalimin e kohës numri i vendeve problematike filloi të zvogëlohej.

Testimi i IaC

Përveç kontrollit të stilit, mund të përdoren edhe gjëra të tjera, për shembull, të kontrolloni që infrastruktura juaj në të vërtetë mund të zbatohet. ose të kontrolloni që ndryshimet në infrastrukturë nuk do të shkaktojnë humbje financiare. Pse mund të nevojitet kjo? Pyetja është e komplikuar dhe filozofike, mund të përgjigjemi më mirë me një tregim që njëherë kishte një auto-scaler në Powershell që nuk kontrollonte kushtet kufitare => krijoheshin më shumë VM se sa duhej => klienti shpenzoi më shumë para se sa kishte planifikuar. Nuk është e këndshme, por ky gabim mund të ishte kapur në faza më të hershme.

Mund të pyesni, përse ta bëni një infrastrukturë të komplikuar edhe më të komplikuar? Testet për infrastrukturën, ashtu si për kodin, nuk janë për thjeshtësim, por për të ditur se si duhet të funksionojë infrastruktura juaj.

Piramida e Testimit të IaC

Testimi i IaC: Analiza Statike

Nëse zgjidhni të filloni me të gjitha infrastrukturat dhe të kontrolloni nëse ato funksionojnë, mund të zhytni shumë kohë dhe të jeni të zënë me punë. Prandaj, duhet të ketë diçka që punon shpejt, është në sasi të madhe dhe mbulon shumë vende primitive.

Bash është i komplikuar

Le të shqyrtojmë një shembull të thjeshtë. Zgjidhni të gjitha skedarët në direktorinë aktuale dhe kopjoni ato diku tjetër. E para që na vjen në mend:

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

Por çfarë do të ndodhte nëse emri i skedarit përmban një hapësirë? Mirë, ne jemi të zgjuar dhe dimë të përdorim thonjëza:

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

A jemi të mençur tani? Jo! Çfarë do të ndodhte nëse në direktori nuk ka asgjë, dmth globimi nuk do të funksiononte.

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

Tani jemi të mençur? Jo… Haruam që në emrin e 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 së statikës

Problemi nga hapi i kaluar mund të kapet në momentin që harrojmë thonjëzat; për këtë, ekzistojnë shumë mjete Shellcheck, në të vërtetë ka shumë, dhe me siguri do të jeni në gjendje të gjeni një linters për IDE-në tuaj për stack-un tuaj.

Gjuha
Mjeti

bash
Shellcheck

Ruby
RuboCop

python
Pylint

ansible
Ansible Lint

Testimi i IaC: Testet Njësit

Siç e kemi parë nga shembulli i mëparshëm, linters nuk janë të gjithfuqishëm dhe nuk mund të tregojnë për të gjitha vendet problematike. Në vijim, duke u bazuar në analogjinë me testimin në zhvillimin e softuerit, mund të kujtojmë testet unike. Menjëherë në mendje vjen shunit, junit, rspec, pytest. Por çfarë duhet të bëjmë me ansible, chef, saltstack dhe të ngjashme?

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 to.

Infrastruktura ndahet në blloqe të vogla, siç janë rolet Ansible.
Vendosim një ambient të caktuar, qofshin këto docker ose VM.
Në këtë ambient testues aplikojmë rolin tonë Ansible.
Kontrollojmë se gjithçka ka funksionuar siç e prisnim (kemi kaluar testet).
Për gjithçka që është në rregull ose jo.

Testimi i IaC: Veglat për Testimin e Njësisë

Pyetja është, çfarë janë testet për CFM? Mund të thjeshtë takohet script-in, ose të përdoren zgjidhje të gatshme për këtë:

CFM
Mjeti

Ansible
Testinfra

Chef
Inspec

Chef
Serverspec

saltstack
Goss

Shembulli për testinfra, kontrollojmë që përdoruesit test1, test2 ekzistojnë dhe janë pjesë e grupit 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ë zgjedhësh? Pyetja është e komplikuar dhe jo e qartë. Ja një shembull i ndryshimeve në projektet në GitHub për vitet 2018-2019:

Kornizat e Testimit IaC

Si të mbledhim së bashku dhe ta nisim këtë? 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

Shembulli i ndryshimeve në projektet në GitHub për vitet 2018-2019:

Molecule vs. Testkitchen

Fillimisht ne provonim të përdornim testkitchen:

Krijo VM në paralel.
Aplikoni rolet e Ansible.
Kryeni inspec.

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

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

Për të kontrolluar playbooks.
Për të kontrolluar rolet.
Nisa kontejnerin.
Aplikoni rolet e Ansible.
Kryeni testinfra.
Kontrolloni idempotencën.

Kontrolli për 40 role dhe testet për dhjetë u bënë rreth 15 minuta.

Çfarë të zgjedhim varet nga shumë faktorë, siç janë stack-u i përdorur, ekspertiza në ekip etj. këtu secili vendos vetë si të mbulojë çështjen e testimit të njësive.

IaC Testing: Testet e Integrimit

Në nivelin e ardhshëm të piramidës së testimit të infrastrukturës, do të shfaqen testet e integrimit. Ato janë të ngjashme me testin e njësive:

Infrastrukturen ndahet në blloqe të vogla, siç janë rolet Ansible.
Vendosim një ambient të caktuar, qofshin këto docker ose VM.
Kjo mjedis testi aplikohet numer të madh rolleve Ansible.
Kontrollojmë që gjithçka ka funksionuar siç e presim (kaluam testet).
Për gjithçka që është në rregull ose jo.

Me fjalë të thjeshta, ne nuk kontrollojmë funksionimin e një elementi të vetëm të sistemit si në testet e njësive, por kontrollojmë si është konfiguruar serveri si një e tërë.

Testimi IaC: Testet End to End

Në majën e piramidës na presin testet End to End. Që do të thotë, ne nuk kontrollojmë funksionimin e një serveri të vetëm, një skripti të vetëm, një ndihmesë të vetme të infrastrukturës sonë. Ne kontrollojmë se si disa serverë, të bashkuar së bashku, infrastrukturen tonë punon ashtu siç e presim. Fatkeqësisht, nuk kam parë ndonjëherë zgjidhje të gatshme, ndoshta sepse infrastruktura është shpesh unike dhe është e vështirë të krijohet një model për testimin e saj. Si pasojë, çdo kush krijon zgjidhje të veta. Ka kërkesë, por përgjigje nuk ka. Prandaj, do të flas se çfarë ekziston, për të nxitur të tjerët në mendime të shëndosha ose për të më treguar se gjithçka është shpikur tashmë para nesh.

Një projekt me një histori të pasur. Përdoret në organizata të mëdha dhe ndoshta secili prej jush ka pasur ndonjëherë lidhje me të. Aplikacioni mbështet shumë baza të dhënash, integrime etj. Dija se si mund të duket infrastruktura janë një mori skedarësh docker-compose, ndërsa dija se cilat teste duhet të ekzekutohen në cila mjedis është jenkins.

Ky skemë ka funksionuar mjaft gjatë, derisa brenda hulumtimit nuk e provuam të transferojmë këtë në Openshift. Konteinerit mbetën të njëjta, por ambienti i lançimit u ndërrua (përshëndetje D.R.Y. përsëri).

Mendimi i hulumtimit shkoi më tej, dhe në openshift u gjet një gjë e tillë APB (Ansible Playbook Bundle), e cila lejon paketimin e njohurive se si të shtrihen infrastrukturat në konteiner. Pra, ka një pikë njohurie të riprodhueshme, të testueshme, se si të shtrihen infrastrukturat.

E gjithë kjo tingëllonte mirë, derisa u përballëm me një infrastrukturë heterogjene: na duhej Windows për testet. Në fund, njohuria se çfarë, ku dhe si të shtrijmë dhe testojmë qëndronte në jenkins.