Planteamendu bat IaC (Infrastructure as Code) biltegian gordetzen den kodeaz gain, kode hau inguratzen duten pertsonek eta prozesuek osatzen dute. Posible al da softwarearen garapenetik azpiegituren kudeaketa eta deskribapenerako planteamenduak berrerabiltzea? Artikulua irakurtzen duzun bitartean ideia hau gogoan edukitzea komeni da.
Hau nire transkripzioa da on .
Diapositibak eta bideoak
- Lehorra 2019-04-24
Azpiegitura bash historia gisa
Demagun proiektu berri batera etortzen zarela, eta esaten dizutela: “badaugu Azpiegitura Kode gisa". Errealitatean bihurtzen da Azpiegitura bash historia gisa edo adibidez Dokumentazioa bash historia gisa. Egoera oso erreala da, adibidez, antzeko kasu bat deskribatu zuen Denis Lysenkok hitzaldi batean , bash historiatik proiekturako azpiegitura koherente bat nola lortu zuten kontatu zuen.
Gogo pixka batekin, hori esan dezakegu Azpiegitura bash historia gisa hau kodea bezalakoa da:
- erreproduzigarritasuna: bash historia har dezakezu, komandoak hortik exekutatu eta, bide batez, laneko konfigurazio bat atera dezakezu irteera gisa.
- bertsioa egitea: badakizu nor sartu den eta zer egin duten, berriro ere, ez da kontua horrek irteerako lan-konfigurazio batera eramango zaitunik.
- historia: zer egin zuenaren istorioa. bakarrik ezin izango duzu erabili zerbitzaria galtzen baduzu.
Zer egin nahi duzu?
Azpiegitura Kode gisa
Halako kasu arraroa ere Azpiegitura bash historia gisa belarrietatik tira dezakezu Azpiegitura Kode gisa, baina LAMP zerbitzari zahar ona baino zerbait konplikatuagoa egin nahi dugunean, kode hau nolabait aldatu, aldatu, hobetu behar dela ondorioztatuko dugu. Jarraian, arteko paralelismoak aztertu nahi ditugu Azpiegitura Kode gisa eta software garapena.
LEHORRAK
Biltegiratze sistema garatzeko proiektu batean, azpizeregin bat zegoen : bertsio berri bat kaleratzen ari gara - proba gehiago egiteko zabaldu behar da. Zeregin oso erraza da:
- Hasi saioa hemen ssh bidez eta exekutatu komandoa.
- kopiatu fitxategia bertan.
- zuzendu konfigurazioa hemen.
- hor hasi zerbitzua
- ...
- IRABAZIA!
Deskribatutako logikarako, bash nahikoa da, batez ere proiektuaren hasierako faseetan, hasi besterik ez denean. Hau , baina denborarekin antzeko zerbait zabaltzeko eskaerak daude, baina apur bat desberdina. Burura datorkidan lehenengo gauza kopiatu-itsatsi da. Eta orain baditugu ia gauza bera egiten duten oso antzeko bi gidoi. Denborarekin, script kopurua hazi egin zen, eta script ezberdinen artean sinkronizatu behar den instalazio bat hedatzeko negozio logika jakin bat dagoela aurrean genuen, hau nahiko konplikatua da.
Ematen du DRY (Ez errepikatu zeure burua) bezalako praktika bat dagoela. Lehendik dagoen kodea berrerabiltzea da ideia. Erraza dirudi, baina ez ginen berehala heldu. Gure kasuan, ideia hutsala zen: konfigurazioak scriptetatik bereiztea. Horiek. instalazioa bereizita zabaltzen den negozio logika, konfigurazioak bereizita.
CFMrako SOLIDOA
Denborarekin proiektua hazi egin zen eta Ansibleren sorrera izan zen. Bere itxuraren arrazoi nagusia taldean aditua dagoela eta bash hori ez dago logika konplexurako diseinatuta. Ansible ere logika konplexua edukitzen hasi zen. Logika konplexua kaos bihur ez dadin, software garapenean kodea antolatzeko printzipioak daude SOLIDOA Era berean, adibidez, Grigory Petrovek "Zergatik behar du IT espezialista batek marka pertsonala" txostenean pertsona bat diseinatuta dagoela errazagoa den entitate sozial batzuekin funtzionatzea, softwarearen garapenean hauekin. objektuak dira. Bi ideia hauek uztartzen baditugu eta garatzen jarraitzen badugu, guk ere erabil ditzakegula ohartuko gara SOLIDOA etorkizunean logika hori mantentzea eta aldatzea errazteko.
Erantzukizun bakarraren printzipioa
Klase bakoitzak zeregin bakarra egiten du.
Ez dago kodea nahastu eta jainkozko espageti munstro monolitikoak egin beharrik. Azpiegiturak adreilu sinplez osatuta egon behar du. Ansible jolas-liburua zati txikitan zatitzen baduzu, Ansible rolak irakurtzen badituzu, errazago mantentzen dira.
Ireki Itxiaren Printzipioa
Ireki/itxi printzipioa.
- Hedapenerako irekita: entitate baten portaera heda daitekeela esan nahi du entitate mota berriak sortuz.
- Aldaketetarako itxita: entitate baten portaera hedatzearen ondorioz, ez da aldaketarik egin behar entitate horiek erabiltzen dituen kodean.
Hasieran, proba-azpiegitura makina birtualetan zabaldu genuen, baina hedapenaren negozio-logika inplementaziotik bereizita zegoenez, baremetall-era inplementatzea gehitu genuen arazorik gabe.
Liskoven ordezkapen printzipioa
Barbara Liskov-en ordezkapen-printzipioa. Programa bateko objektuak azpimoten instantziekin ordezkatu behar dira, programaren exekuzio zuzena aldatu gabe
Zabalago begiratuz gero, ez da bertan aplika daitekeen proiektu jakin baten ezaugarria SOLIDOA, orokorrean CFMri buruzkoa da, adibidez, beste proiektu batean Java aplikazio kutxadun bat zabaldu behar da hainbat Java, aplikazio zerbitzari, datu-base, OS, etab. Adibide hau erabiliz, printzipio gehiago aztertuko ditut SOLIDOA
Gure kasuan, azpiegitura taldearen barruan akordio bat dago imbjava edo oraclejava rola instalatu badugu, java bitar exekutagarri bat dugula. Hau beharrezkoa delako Upstream rolak portaera horren araberakoak dira; java espero dute. Aldi berean, honek java inplementazio/bertsio bat beste batekin ordezkatzeko aukera ematen digu aplikazioen hedapen-logika aldatu gabe.
Hemen arazoa Ansiblen hori ezartzea ezinezkoa izatean datza, eta horren ondorioz talde barruan hitzarmen batzuk agertzen dira.
Interfazearen Segregazioaren Printzipioa
Interfazea bereizteko printzipioa: "Bezeroentzako berariazko interfaze asko helburu orokorreko interfaze bat baino hobeak dira.
Hasieran, aplikazioen hedapenaren aldakortasun guztia Ansible liburu batean jartzen saiatu ginen, baina zaila zen onartzen, eta kanpoko interfaze bat zehaztu dugunean planteamendua (bezeroak 443 ataka espero du), orduan azpiegitura bat muntatu daiteke banakako batetik. adreiluak ezarpen zehatz baterako.
Mendekotasun Inbertsioaren Printzipioa
Mendekotasun-inbertsioaren printzipioa. Goi-mailako moduluek ez lukete behe-mailako moduluen menpe egon behar. Bi modulu motak abstrakzioen araberakoak izan behar dute. Abstrakzioak ez dira xehetasunen araberakoak izan behar. Xehetasunak abstrakzioen araberakoak izan behar dira.
Hemen adibidea antipatroi batean oinarrituko da.
- Bezeroetako batek hodei pribatu bat zuen.
- Hodei barruan makina birtualak eskatu genituen.
- Baina hodeiaren izaera dela eta, aplikazioen inplementazioa VM-a zein hipervisorearekin zegoen lotuta zegoen.
Horiek. Goi-mailako aplikazioak inplementatzeko logika menpekotasunekin jariatzen zen hipervisorearen beheko mailetara, eta horrek arazoak ekarri zituen logika hori berrerabiltzean. Ez egin horrela.
elkarrekintza
Azpiegitura kode gisa ez da soilik kodeari buruzkoa, baizik eta kodearen eta pertsonen arteko harremanari buruzkoa ere, azpiegitura garatzaileen arteko interakzioei buruzkoa.
Autobus faktorea
Demagun Vasya duzula zure proiektuan. Vasyak dena daki zure azpiegiturei buruz, zer gertatuko da Vasya bat-batean desagertzen bada? Egoera oso erreala da, autobus batek jo dezakeelako. Batzuetan gertatzen da. Hori gertatzen bada eta kodeari, bere egiturari, nola funtzionatzen duen, itxurak eta pasahitzei buruzko ezagutza taldean banatzen ez bada, hainbat egoera desatsegin topa ditzakezu. Arrisku horiek minimizatzeko eta ezagutza taldean banatzeko, hainbat ikuspegi erabil ditzakezu
Devopsing bikotea
Ez da bezalakoa , administratzaileek garagardoa edan zutela, pasahitzak aldatu eta bikoteen programazioaren analogo bat. Horiek. bi ingeniari ordenagailu batean, teklatu batean eseri eta elkarrekin zure azpiegitura konfiguratzen hasten dira: zerbitzari bat konfiguratu, Ansible rol bat idaztea, etab. Polita dirudi, baina ez zigun balio. Baina praktika honen kasu bereziek funtzionatu zuten. Langile berri bat dator, bere tutoreak benetako zeregin bat hartzen du berarekin batera, lan egiten du eta ezagutzak transferitzen ditu.
Beste kasu berezi bat gertakari dei bat da. Arazo batean, betebeharra dutenen eta parte hartzen dutenen talde bat biltzen da, buruzagi bat izendatzen da, bere pantaila partekatzen duena eta pentsamenduaren trenari ahotsa ematen diona. Beste parte-hartzaileek liderren pentsamenduak jarraitzen dituzte, kontsolaren trikimailuak zelatatzen dituzte, erregistroan lerrorik galdu ez dutela egiaztatu eta sistemari buruzko gauza berriak ikasten dituzte. Ikuspegi honek maizago funtzionatu zuen.
Kodearen berrikuspena
Subjektiboki, eraginkorragoa izan zen kodearen berrikuspena erabiliz azpiegiturari eta funtzionamenduari buruzko ezagutza zabaltzea:
- Azpiegitura kodearen bidez deskribatzen da biltegian.
- Aldaketak aparteko adar batean gertatzen dira.
- Batze-eskaera batean, azpiegituraren aldaketen delta ikus dezakezu.
Hemen azpimarragarria izan zen ebaluatzaileak banan-banan hautatzen zirela, egutegi baten arabera, hau da. nolabaiteko probabilitatearekin azpiegitura berri batera igoko zara.
kode estiloa
Denboraren poderioz, liskarrak agertzen hasi ziren berrikuspenetan, zeren... berrikusleek beren estiloa zuten eta berrikusleen txandaketak estilo ezberdinekin pilatu zituen: 2 espazio edo 4, camelCase edo snake_case. Ezin izan zen hori berehala ezartzea.
- Lehen ideia linter erabiltzea gomendatzea izan zen, azken finean, denak ingeniariak dira, denak adimentsuak. Baina editore desberdinak, OS, ez dira erosoak
- Hau konpromezu arazo bakoitzerako slack idazten zuen bot bihurtu zen eta linter irteera erantsi zuen. Baina kasu gehienetan gauza garrantzitsuagoak zeuden egiteko eta kodea konpondu gabe geratzen zen.
Eraikuntza Berdearen Maisua
Denbora pasatzen da, eta ondorioztatu dugu proba batzuk gainditzen ez dituzten konpromisoak ezin direla masterrean sartu. Voila! Green Build Master asmatu genuen, aspalditik software garapenean praktikatzen dena:
- Garapena adar bereizi batean abian da.
- Hari honetan probak egiten ari dira.
- Testek huts egiten badute, kodea ez da maisuan sartuko.
Erabaki hau hartzea oso mingarria izan zen, zeren... polemika handia sortu zuen, baina merezi izan zuen, zeren... Berrikuspenak estilo-desberdintasunik gabeko fusio-eskaerak jasotzen hasi ziren, eta denborarekin arazo-eremuen kopurua gutxitzen joan zen.
IaC probak
Estilo-egiaztapenaz gain, beste gauza batzuk erabil ditzakezu, adibidez, zure azpiegitura benetan zabaldu daitekeela egiaztatzeko. Edo egiaztatu azpiegituren aldaketek ez dutela diru galerarik ekarriko. Zergatik beharko litzateke hau? Galdera konplexua eta filosofikoa da, hobe da istorio batekin erantzutea, nolabait Powershell-en eskalatzaile automatiko bat zegoela, muga-baldintzak egiaztatzen ez zituen => behar baino VM gehiago sortu ziren => bezeroak aurreikusitakoa baino diru gehiago gastatu zuen. Hau ez da oso atsegina, baina nahiko posible izango litzateke akats hau lehen faseetan harrapatzea.
Galdetu liteke, zergatik are konplexuagoa den azpiegitura konplexua? Azpiegiturarako probak, kodearena bezala, ez dira sinplifikazioa, zure azpiegiturak nola funtzionatu behar duen jakitea baizik.
IaC probaren piramidea
IaC Testing: Analisi Estatikoa
Azpiegitura osoa aldi berean zabaltzen baduzu eta funtzionatzen duela egiaztatzen baduzu, baliteke denbora asko behar duela eta denbora asko eskatzen duela. Horregatik, oinarriak azkar funtzionatzen duen zerbait izan behar du, asko dago eta leku primitibo asko hartzen ditu.
Bash zaila da
Ikus dezagun adibide hutsal bat. hautatu uneko direktorioko fitxategi guztiak eta kopiatu beste leku batera. Burura datorkidan lehenengo gauza:
for i in * ; do
cp $i /some/path/$i.bak
doneZer gertatzen da fitxategiaren izenan zuriune bat badago? Beno, ados, argiak gara, badakigu komatxoak erabiltzen:
for i in * ; do cp "$i" "/some/path/$i.bak" ; doneOngi egina? Ez! Zer gertatzen da direktorioan ezer ez badago, hau da. globb-ak ez du funtzionatuko.
find . -type f -exec mv -v {} dst/{}.bak ;Ondo eginda orain? Ez... Fitxategiaren izenan egon daitekeena ahaztu zait n.
touch x
mv x "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dirAnalisi estatikoko tresnak
Aurreko urratseko arazoa komatxoak ahazten ditugunean har liteke, horretarako naturan erremedio asko daude , oro har, asko daude, eta ziurrenik zure pilarako linter bat aurki dezakezu zure IDEaren azpian.
Hizkuntza
Tool
golpear
Ruby
python
ansible
IaC Testing: Unitateko Probak
Aurreko adibidean ikusi genuenez, linterak ez dira ahalguztidunak eta ezin dituzte arazo-eremu guztiak adierazi. Gainera, softwarearen garapeneko proben analogia eginez, unitateko probak gogora ditzakegu. Berehala burura etortzen zaidana da , , , . Baina zer egin ansible, chef, saltstack eta antzeko beste batzuekin?
Hasieran bertan hitz egin genuen SOLIDOA eta gure azpiegiturak adreilu txikiz osatu behar direla. Iritsi da haien ordua.
- Azpiegitura adreilu txikitan banatzen da, adibidez, Ansible rolak.
- Ingurune mota bat zabaltzen da, docker edo VM bat izan.
- Gure Ansible rola proba-ingurune honetan aplikatzen dugu.
- Guztiak espero genuen bezala funtzionatu duela egiaztatzen dugu (probak egiten ditugu).
- Ondo erabakitzen dugu ala ez.
IaC Testing: Unit Testing tresnak
Galdera, zer dira CFMrako probak? Besterik gabe, scripta exekutatu dezakezu edo horretarako prest dauden irtenbideak erabil ditzakezu:
CFM
Tool
Ansible
Chef
Chef
gatz-pila
Testinfrarako adibidea, erabiltzaileak egiaztatzea test1, test2 existitzen dira eta talde batean daude sshusers:
def test_default_users(host):
users = ['test1', 'test2' ]
for login in users:
assert host.user(login).exists
assert 'sshusers' in host.user(login).groupsZer aukeratu? Galdera konplexua eta anbiguoa da, hona hemen github-en 2018-2019rako proiektuetan izandako aldaketen adibide bat:
IaC Testing esparruak
Galdera sortzen da: nola jarri dena eta martxan jarri? Ahal ingeniari kopuru nahikoa badago. Edo prest dauden irtenbideak har ditzakezu, asko ez diren arren:
CFM
Tool
Ansible
Chef
Terraform
Github-en 2018-2019rako proiektuetan izandako aldaketen adibidea:
Molekula vs. Proba sukaldea
Hasieran guk :
- Sortu VM bat paraleloan.
- Aplikatu Ansible rolak.
- Exekutatu ikuskapena.
25-35 roletarako 40-70 minututan aritu zen, hau da, luzea.
Hurrengo urratsa jenkins/docker/ansible/molecule-ra pasatzea izan zen. Idiologikoki dena berdina da
- Lint jolas liburuak.
- Rolak lerrokatu.
- Abiarazi edukiontzia
- Aplikatu Ansible rolak.
- Exekutatu testinfra.
- Idempotentzia egiaztatu.
40 roletarako linting eta dozena bat probak 15 minutu inguru hartzen hasi ziren.
Aukeratu zer faktore askoren araberakoa da, hala nola erabilitako pila, taldean esperientzia, etab. hemen bakoitzak bere kabuz erabakitzen du nola itxi Unitate-probaren galdera
IaC Testing: Integrazio probak
Azpiegituren probaren piramidearen hurrengo urratsa integrazio probak izango dira. Unitateko proben antzekoak dira:
- Azpiegitura adreilu txikitan banatzen da, adibidez Ansible roles.
- Ingurune mota bat zabaltzen da, docker edo VM bat izan.
- Proba-ingurune honetarako aplikatu set of Ansible rolak.
- Guztiak espero genuen bezala funtzionatu duela egiaztatzen dugu (probak egiten ditugu).
- Ondo erabakitzen dugu ala ez.
Gutxi gorabehera, ez dugu sistemaren elementu indibidual baten errendimendua egiaztatzen unitate-probetan bezala, zerbitzaria bere osotasunean nola konfiguratuta dagoen egiaztatzen dugu.
IaC Testing: End to End Tests
Piramidearen goialdean End to End probek agurtzen gaituzte. Horiek. Ez dugu zerbitzari bereizi baten, aparteko script baten edo gure azpiegituraren adreilu bereizi baten errendimendua egiaztatzen. Zerbitzari asko elkarrekin konektatuta daudela egiaztatzen dugu, gure azpiegiturak espero dugun moduan funtzionatzen duela. Zoritxarrez, ez dut inoiz prest egindako kutxako irtenbiderik ikusi, ziurrenik... Azpiegitura bakarra eta zaila da probak egiteko marko bat txantiloiatzea eta sortzea. Ondorioz, bakoitzak bere irtenbideak sortzen ditu. Eskaera bat dago, baina ez dago erantzunik. Hori dela eta, zer dagoen kontatuko dizut besteei pentsamenduak soinu egitera bultzatzeko edo sudurra igurtzitzeko, dena aspaldi asmatua zela gure aurretik.
Historia aberatsa duen proiektua. Erakunde handietan erabiltzen da eta ziurrenik zuetako bakoitza zeharka gurutzatu izan da berarekin. Aplikazioak datu-base, integrazio eta abar asko onartzen ditu. Azpiegitura nolakoa izan daitekeen jakitea docker-compose fitxategi asko da, eta zein probak exekutatu zein ingurunetan Jenkins den jakitea.
Eskema honek denbora luzez funtzionatu zuen, markoaren barruan arte ez gara saiatu hau Openshift-era transferitzen. Edukiontziek berdin jarraitzen dute, baina abiarazteko ingurunea aldatu egin da (kaixo DRY berriro).
Ikerketaren ideia urrunago joan zen, eta txanda irekian APB (Ansible Playbook Bundle) bezalako gauza bat aurkitu zuten, azpiegitura edukiontzi batean nola zabaldu jakiteko aukera ematen duena. Horiek. azpiegitura hedatzeko moduari buruzko ezagutza puntu errepikagarria eta probagarria dago.
Horrek guztiak ondo jotzen zuen azpiegitura heterogeneo batekin topo egin genuen arte: probak egiteko Windows behar genuen. Ondorioz, zer, non, nola zabaldu eta probaren ezagutza jenkins-en dago.
Ondorioa
Azpiegitura kodea den bezala
- Kodea biltegian.
- Giza elkarrekintza.
- Azpiegituren probak.
loturak
- Lehorra 2019-04-24
- &
Iturria: www.habr.com