1. zatia: Weba/Android
Kontuan izan: artikulu hau jatorrizko artikuluaren errusierara itzuli da Hala ere, ilustrazio, esteka, aipamen eta termino guztiak jatorrizko hizkuntzan gordetzen dira errusierara itzultzen direnean esanahiaren distortsioa ekiditeko. Zoriontsu ikasi nahi dizut!
Gaur egun, DevOps espezialitatea IT industrian gehien eskatzen denetako bat da. Lanak bilatzeko gune ezagunak ireki eta soldataren arabera iragazten badituzu, ikusiko duzu DevOps-ekin lotutako lanak zerrendaren goialdean daudela. Dena den, garrantzitsua da ulertzea, batez ere, 'Senior' postu bati egiten diola erreferentzia, eta horrek esan nahi du hautagaiak gaitasun, teknologia eta tresnen ezagutza maila altua dituela. Horrek, gainera, ekoizpenaren etenik gabeko funtzionamenduarekin lotutako erantzukizun maila altuarekin dator. Hala ere, DevOps zer den ahazten hasi ginen. Hasieran, ez zen pertsona edo sail zehatzik. Termino honen definizioak bilatzen baditugu, izen eder eta zuzen ugari aurkituko ditugu, hala nola, metodologia, praktikak, kultur filosofia, kontzeptu multzoa, etab.
Nire espezialitatea test automatizazio ingeniari bat da (QA automation engineering), baina uste dut ez dela lotu behar auto-testak idaztearekin edo proba-esparruaren arkitektura garatzearekin soilik. 2020an, automatizazio-azpiegituren ezagutza ere ezinbestekoa da. Horri esker, automatizazio prozesua zuk zeuk antola dezakezu, probak egiten hasi eta interesdun guztiei emaitzak eman arte zure helburuen arabera. Ondorioz, DevOps gaitasunak ezinbestekoak dira lana egiteko. Eta hori guztia ona da, baina, zoritxarrez, arazo bat dago (spoiler: artikulu hau arazo hau errazten saiatzen da). Kontua da DevOps gogorra dela. Eta hori agerikoa da, enpresek ez dutelako asko ordainduko erraza den zerbaitengatik... DevOps munduan, menperatu beharreko tresna, termino eta praktika ugari daude. Hau bereziki zaila da karrera baten hasieran eta pilatutako esperientzia teknikoaren araberakoa da.
Iturria:
Hemen ziurrenik sarrerako zatiarekin amaituko dugu eta artikulu honen helburuan zentratuko gara.
Zeri buruz da artikulu hau?
Artikulu honetan, probaren automatizazio azpiegitura bat eraikitzeko esperientzia partekatuko dut. Interneten informazio iturri ugari dago hainbat tresnari buruz eta nola erabili, baina automatizazioaren testuinguruan soilik aztertu nahiko nituzke. Uste dut automatizazio-ingeniari askok ezagutzen dutela zuk izan ezik inor garatutako probak exekutatzen edo mantentzeaz arduratzen direnean. Ondorioz, probak zaharkituta geratzen dira eta denbora eman behar duzu eguneratzen. Berriro ere, karrera baten hasieran, nahiko lan zaila izan daiteke: arazo jakin bat ezabatzen lagundu behar duten tresnak zentzuz erabakitzea, nola hautatu, konfiguratu eta mantendu. Probatzaile batzuek DevOps-era (gizakiak) jotzen dute laguntza eske eta, egia izan gaitezen, ikuspegi honek funtzionatzen du. Kasu askotan hau izan daiteke aukera bakarra, menpekotasun guztien ikusgarritasunik ez baitugu. Baina dakigunez, DevOps-ak oso lanpetuta daude, izan ere, enpresa osoaren azpiegitura, hedapena, monitorizazioa, mikrozerbitzuak eta antzeko beste zeregin batzuk pentsatu behar dituzte erakunde/taldearen arabera. Normalean gertatzen den bezala, automatizazioa ez da lehentasuna. Halako batean, gure aldetik ahal dugun guztia egiten saiatu behar dugu hasieratik amaierara. Horrek menpekotasunak murriztuko ditu, lan-fluxua bizkortuko du, gure gaitasunak hobetu eta gertatzen ari denaren irudi handiagoa ikusteko aukera emango digu.
Artikuluak tresna ezagunenak eta ezagunenak aurkezten ditu eta pausoz pauso automatizazio azpiegitura bat eraikitzeko nola erabili erakusten du. Talde bakoitza esperientzia pertsonalaren bidez probatu diren tresnek ordezkatzen dute. Baina horrek ez du esan nahi gauza bera erabili behar duzunik. Tresnak berez ez dira garrantzitsuak, agertzen dira eta zaharkituta geratzen dira. Gure ingeniaritza egitekoa oinarrizko printzipioak ulertzea da: zergatik behar dugun tresna talde hau eta zer lan arazo ebatzi ditzakegun haien laguntzarekin. Horregatik, atal bakoitzaren amaieran zure erakundean erabil daitezkeen antzeko tresnetarako estekak uzten ditut.
Artikulu honetan ez dagoena
Berriro errepikatzen dut artikulua ez dela tresna zehatzei buruzkoa, beraz, ez da komando zehatzen dokumentaziotik eta deskribapenetatik koderik sartuko. Baina atal bakoitzaren amaieran estekak uzten ditut azterketa zehatza egiteko.
Hau egiten da:
- material hau oso erraza da hainbat iturritan aurkitzea (dokumentazioa, liburuak, bideo-ikastaroak);
- sakontzen hasten bagara, artikulu honen 10, 20, 30 zati idatzi beharko ditugu (planak 2-3 diren bitartean);
- Ez dut zure denbora alferrik galdu nahi, baliteke beste tresna batzuk erabiltzea helburu berdinak lortzeko.
Praktika
Benetan gustatuko litzaidake material hau irakurle guztientzako baliagarria izatea, eta ez bakarrik irakurri eta ahaztuta. Edozein ikasketetan, praktika oso osagai garrantzitsua da. Horretarako prestatu dut. Etxeko lanak ere badaude zain exekutatzen ari zaren komandoen lerroak burugabe kopiatzen ez dituzula ziurtatzeko.
plan
Urratsera
Teknologia
tresnak
1
Tokiko exekuzioa (prestatu web / Android demo probak eta exekutatu lokalean)
Node.js, Selenium, Appium
2
Bertsioak kontrolatzeko sistemak
Git
3
Edukiontziratzea
Docker, Selenium grid, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Hodei plataformak
Google Cloud Platform
6
Orchestration
Kubernetes
7
Azpiegitura kode gisa (IaC)
Terraform, Ansible
Atal bakoitzaren egitura
Narrazioa argi edukitzeko, atal bakoitza eskema honen arabera deskribatzen da:
- teknologiaren deskribapen laburra,
- automatizazio azpiegiturentzako balioa,
- azpiegituren egungo egoeraren ilustrazioa,
- ikasteko estekak,
- antzeko tresnak.
1. Egin probak lokalean
Teknologiaren deskribapen laburra
Demo probak lokalean exekutatzeko eta gainditzen direla egiaztatzeko prestaketa-urrats bat besterik ez da. Parte praktikoan, Node.js erabiltzen da, baina programazio-lengoaia eta plataforma ere ez dira garrantzitsuak eta zure enpresan erabiltzen direnak erabil ditzakezu.
Hala ere, automatizazio tresna gisa, Selenium WebDriver web plataformetarako eta Appium Android plataformarako erabiltzea gomendatzen dut, hurrenez hurren, hurrengo urratsetan tresna hauekin bereziki lan egiteko egokitutako Docker irudiak erabiliko baititugu. Gainera, lan-eskakizunei erreferentzia eginez, tresna hauek dira merkatuan gehien eskatzen direnak.
Konturatuko zinen bezala, web eta Android probak soilik hartzen ditugu kontuan. Zoritxarrez, iOS guztiz bestelako istorio bat da (eskerrik asko Apple). Datozen zatietan IOSarekin lotutako soluzioak eta praktikak erakusteko asmoa dut.
Automatizazio azpiegiturentzako balioa
Azpiegituren ikuspegitik, lokalean ibiltzeak ez du baliorik ematen. Probak tokiko arakatzaile eta simulagailuetan tokiko makinan exekutatzen direla egiaztatzen duzu soilik. Baina, nolanahi ere, hori ezinbesteko abiapuntua da.
Azpiegituren egungo egoeraren ilustrazioa
Arakatzeko estekak
Antzeko tresnak
- Selenium/Appium probekin batera nahi duzun edozein programazio-lengoaia;
- edozein proba;
- edozein probako korrikalari.
2. Bertsioak kontrolatzeko sistemak (Git)
Teknologiaren deskribapen laburra
Ez da inorentzat errebelazio handia izango bertsioen kontrola garapenaren zati oso garrantzitsua dela esaten badut, bai taldean, bai bakarka. Hainbat iturritan oinarrituta, ziur esan daiteke Git ordezkaririk ezagunena dela. Bertsioak kontrolatzeko sistema batek abantaila ugari eskaintzen ditu, hala nola, kodea partekatzea, bertsioak gordetzea, aurreko adarretara leheneratzea, proiektuaren historia kontrolatzea eta babeskopiak. Ez dugu puntu bakoitza zehatz-mehatz eztabaidatuko, ziur nago oso ezagutzen duzula eta zure eguneroko lanean erabiltzen duzula. Baina bat-batean ez bada, artikulu hau irakurtzen pausatzea eta hutsune hori ahalik eta azkarren betetzea gomendatzen dut.
Automatizazio azpiegiturentzako balioa
Eta hemen arrazoizko galdera bat egin dezakezu: βZergatik ari da esaten Git-i buruz? Denek daki hori eta erabiltzen dute bai garapen-koderako eta baita auto-test-koderako ereβ. Arrazoi osoa izango duzu, baina artikulu honetan azpiegiturei buruz ari gara eta atal honek 7. atalaren aurrerapen gisa funtzionatzen du: βInfrastructure as Code (IaC)β. Guretzat, horrek esan nahi du azpiegitura osoa, probak barne, kode moduan deskribatuta dagoela, beraz, bertsio-sistemak ere aplika diezazkiokegu eta garapen eta automatizazio kodearen antzeko abantailak lor ditzakegu.
IaC-a xehetasun gehiagoz aztertuko dugu 7. urratsean, baina orain ere Git lokalean erabiltzen has zaitezke tokiko biltegi bat sortuz. Irudi handia zabalduko da azpiegitura urruneko biltegi bat gehitzen dugunean.
Azpiegituren egungo egoeraren ilustrazioa
Arakatzeko estekak
Antzeko tresnak
3. Edukiontziratzea (Docker)
Teknologiaren deskribapen laburra
Kontenedoreak joko-arauak nola aldatu dituen erakusteko, atzera egin dezagun hamarkada batzuk denboran. Orduan, jendeak zerbitzari makinak erosi eta erabiltzen zituen aplikazioak exekutatzeko. Baina kasu gehienetan, beharrezkoak ziren abioko baliabideak ez ziren aldez aurretik ezagutzen. Ondorioz, enpresek zerbitzari garesti eta indartsuak erosteko dirua gastatu zuten, baina gaitasun hori ez zen guztiz erabili.
Eboluzioaren hurrengo fasea makina birtualak (VM) izan ziren, erabili gabeko baliabideetan dirua xahutzearen arazoa konpondu zutenak. Teknologia horri esker, aplikazioak bata bestearengandik independentean exekutatu ahal izan dira zerbitzari berean, espazio guztiz isolatua esleituz. Baina, zoritxarrez, edozein teknologiak baditu bere eragozpenak. VM bat exekutatzeko sistema eragile osoa behar da, CPU, RAM, biltegiratzea kontsumitzen duena eta, sistema eragilearen arabera, lizentzia kostuak kontuan hartu behar dira. Faktore hauek kargatzeko abiadura eragiten dute eta eramangarritasuna zailtzen dute.
Eta orain edukiontzira gatoz. Berriro ere, teknologia honek aurreko arazoa konpontzen du, edukiontziek ez baitute OS osorik erabiltzen, eta horrek baliabide ugari askatzen ditu eta eramangarritasunerako irtenbide azkarra eta malgua eskaintzen du.
Jakina, edukiontzien teknologia ez da berria eta 70eko hamarkadaren amaieran sartu zen lehen aldiz. Garai haietan, ikerketa, garapen eta saiakera asko egin ziren. Baina Docker izan zen teknologia hori egokitu eta jendearentzat erraz eskura jarri zuena. Gaur egun, edukiontziei buruz hitz egiten dugunean, kasu gehienetan Docker esan nahi dugu. Docker edukiontziei buruz hitz egiten dugunean, Linux edukiontziak esan nahi dugu. Windows eta macOS sistemak erabil ditzakegu edukiontziak exekutatzeko, baina garrantzitsua da ulertzea kasu honetan geruza gehigarri bat agertzen dela. Adibidez, Docker-ek Mac-en isilean exekutatzen ditu edukiontziak Linux VM arin baten barruan. Gai horretara itzuliko gara Android emuladoreak edukiontzien barruan exekutatzen ari garenean, beraz, hemen zehatzago eztabaidatu beharreko Γ±abardura oso garrantzitsu bat dago.
Automatizazio azpiegiturentzako balioa
Kontenedoreak eta Docker politak direla jakin dugu. Ikus dezagun hau automatizazioaren testuinguruan, tresna edo teknologia bakoitzak arazo bat konpondu behar duelako. Azal ditzagun probaren automatizazioaren arazo nabariak UI proben testuinguruan:
- mendekotasun kopuru handia Selenium eta bereziki Appium instalatzerakoan;
- arakatzaileen, simulagailuen eta kontrolatzaileen bertsioen arteko bateragarritasun arazoak;
- nabigatzaile/simulatzaileentzako espazio isolatu falta, eta hori bereziki garrantzitsua da exekuzio paralelorako;
- zaila da kudeatzea eta mantentzea 10, 50, 100 edo are 1000 arakatzaile aldi berean exekutatu behar badituzu.
Baina Selenium automatizazio-tresna ezagunena denez eta Docker edukiontzi-tresna ezagunena denez, ez da harritzekoa izan behar norbait horiek konbinatzen saiatu izana goian aipatutako arazoak konpontzeko tresna indartsu bat sortzeko. Azter ditzagun horrelako irtenbideak xehetasun gehiagorekin.
Selenio sarea docker-en
Tresna hau Selenium munduko ezagunena da hainbat arakatzaile exekutatzeko hainbat makinatan eta horiek kudeatzeko zentro zentral batetik. Hasteko, gutxienez 2 zati erregistratu behar dituzu: Hub eta Nodo(k). Hub nodo zentral bat da, proben eskaera guztiak jasotzen dituena eta dagokion Nodoetara banatzen dituena. Nodo bakoitzeko konfigurazio zehatz bat konfiguratu dezakegu, adibidez, nahi den nabigatzailea eta bere bertsioa zehaztuz. Hala ere, oraindik ere arakatzaile bateragarriak diren kontrolatzaileak geuk zaindu behar ditugu eta nahi diren Nodoetan instalatu. Horregatik, Selenium grid ez da bere forma hutsean erabiltzen, Linux OSan instalatu ezin diren arakatzaileekin lan egin behar dugunean izan ezik. Beste kasu guztietan, soluzio nabarmen malgu eta zuzena izango litzateke Docker irudiak erabiltzea Selenium grid Hub eta Nodes exekutatzeko. Ikuspegi honek asko errazten du nodoen kudeaketa, behar dugun irudia hauta dezakegulako instalatuta dauden arakatzaileen eta kontrolatzaileen bertsio bateragarriekin.
Egonkortasunari buruzko iritzi negatiboak izan arren, batez ere Nodo kopuru handia paraleloan exekutatzen denean, Selenium grid Selenium probak paraleloan egiteko tresnarik ezagunena da oraindik. Garrantzitsua da erreminta honen hainbat hobekuntza eta aldaketa etengabe agertzen direla kode irekian, eta horrek hainbat botilen aurre egiten die.
Selenoid Weberako
Tresna hau aurrerapauso bat da selenioaren munduan, kaxatik aterata funtzionatzen baitu eta automatizazio ingeniari askoren bizitza askoz erraztu baitu. Lehenik eta behin, hau ez da selenio sarearen beste aldaketa bat. Horren ordez, garatzaileek Selenium Hub-en bertsio guztiz berria sortu zuten Golang-en, hainbat arakatzaileentzako Docker irudi arinekin konbinatuta, probaren automatizazioaren garapenari bultzada eman zion. Gainera, Selenium Grid-en kasuan, beharrezkoak diren arakatzaile guztiak eta haien bertsioak aldez aurretik zehaztu behar ditugu, eta hori ez da arazorik nabigatzaile bakarrarekin lan egiten denean. Baina onartzen diren arakatzaile anitzei dagokienez, Selenoid lehen irtenbidea da bere 'eskaeraren arabera nabigatzailea' funtzioari esker. Eskatzen zaiguna da aldez aurretik arakatzaileekin beharrezko irudiak deskargatzea eta Selenoid-ek elkarreragiten duen konfigurazio fitxategia eguneratzea. Selenoid-ek proben eskaera bat jaso ondoren, automatikoki nahi den edukiontzia abiaraziko du nahi den arakatzailearekin. Proba amaitzen denean, Selenoid-ek edukiontzia erretiratuko du, eta horrela baliabideak askatuko ditu etorkizuneko eskaeretarako. Ikuspegi honek Selenium sarean sarritan aurkitzen dugun "nodoen degradazioaren" arazo ezaguna guztiz ezabatzen du.
Baina, ai, Selenoid oraindik ez da zilarrezko bala bat. 'Nabigatzailea eskaeran' eginbidea lortu dugu, baina 'eskaeran dauden baliabideak' funtzioa oraindik ez dago erabilgarri. Selenoid erabiltzeko, hardware fisikoan edo VM batean zabaldu behar dugu, hau da, aldez aurretik jakin behar dugu zenbat baliabide esleitu behar diren. Uste dut hori ez dela arazo bat paraleloan 10, 20 edo 30 arakatzaile exekutatzen dituzten proiektu txikientzat. Baina zer gertatzen da 100, 500, 1000 edo gehiago behar baditugu? Ez du zentzurik hainbeste baliabide mantentzeak eta ordaintzeak denbora guztian. Artikulu honen 5. eta 6. ataletan, eskalatzeko aukera ematen duten soluzioei buruz hitz egingo dugu, horrela konpainiaren kostuak nabarmen murrizteko.
Selenoid Androiderako
Selenoid-ek web automatizazio tresna gisa arrakasta izan ondoren, jendeak antzeko zerbait nahi zuen Androiderako. Eta gertatu zen - Selenoid Android laguntzarekin kaleratu zen. Goi-mailako erabiltzaileen ikuspuntutik, funtzionamendu-printzipioa web automatizazioaren antzekoa da. Desberdintasun bakarra da arakatzailearen edukiontzien ordez, Selenoid-ek Android emulatzaile ontziak exekutatzen dituela. Nire ustez, hau da gaur egun Android probak paraleloan exekutatzeko doako tresnarik indartsuena.
Ez nuke gustatuko tresna honen alde negatiboei buruz hitz egitea, asko gustatzen zaidalako. Baina, hala ere, web automatizazioari aplikatzen zaizkion desabantaila berdinak daude eta eskalatzearekin lotuta daudenak. Honetaz gain, tresna lehen aldiz konfiguratzen badugu harrigarria izan daitekeen beste muga bati buruz hitz egin behar dugu. Android-eko irudiak exekutatzeko, makina fisiko edo VM bat behar dugu birtualizazio-laguntza habiaratua duena. Nola egin gidan, hau Linux VM batean nola gaitu erakusten dut. Hala ere, macOS erabiltzailea bazara eta Selenoid lokalean zabaldu nahi baduzu, ezin izango da Android probak exekutatu. Baina beti exekutatu dezakezu Linux VM bat lokalean "birtualizazio habiatua" konfiguratuta eta barruan Selenoid inplementatu.
Azpiegituren egungo egoeraren ilustrazioa
Artikulu honen testuinguruan, azpiegitura ilustratzeko 2 tresna gehituko ditugu. Hauek dira Selenium grid web probetarako eta Selenoid Android probetarako. GitHub tutorialean, Selenoid nola erabili web probak egiteko ere erakutsiko dizut.
Arakatzeko estekak
Antzeko tresnak
- Badira beste edukiontzi batzuk egiteko tresnak, baina Docker da ezagunena. Beste zerbait probatu nahi baduzu, kontuan izan Selenium probak paraleloan exekutatzeko landu ditugun tresnek ez dutela funtzionatuko.
- Esan bezala, selenio sarearen aldaketa asko daude, adibidez,.
4.CI/CD
Teknologiaren deskribapen laburra
Etengabeko integrazioaren praktika nahiko ezaguna da garapenean eta bertsioen kontrol sistemen parekoa da. Hala ere, terminologian nahasmena dagoela iruditzen zait. Paragrafo honetan teknologia honen 3 aldaketa deskribatu nahiko nituzke nire ikuspuntutik. Interneten hainbat artikulu aurkituko dituzu interpretazio ezberdinekin, eta guztiz normala da zure iritzia desberdina bada. Garrantzitsuena zure lankideekin orrialde berean egotea da.
Beraz, 3 termino daude: CI - Etengabeko integrazioa, CD - Etengabeko entrega eta berriro CD - Etengabeko hedapena. (Jarraian, termino hauek ingelesez erabiliko ditut). Aldaketa bakoitzak hainbat urrats gehitzen dizkio zure garapen-bideari. Baina hitza etengabeko (etengabea) da garrantzitsuena. Testuinguru honetan, hasieratik amaierara, etenik edo esku-hartzerik gabe, gertatzen den zerbait esan nahi dugu. Ikus ditzagun CI & CDa eta CDa testuinguru honetan.
- Etengabeko Integrazioa hau da eboluzioaren hasierako urratsa. Zerbitzariari kode berria bidali ondoren, gure aldaketak ondo daudela dioen iritzia azkar jasotzea espero dugu. Normalean, CIk kode estatikoa aztertzeko tresnak eta unitate/barneko API probak exekutatzen ditu. Horri esker, gure kodeari buruzko informazioa segundo/minutu gutxitan eskura dezakegu.
- Etengabeko erak urrats aurreratuagoa da, non integrazio/UI probak egiten ditugun. Hala ere, fase honetan ez ditugu CIrekin bezain azkar lortzen emaitzak. Lehenik eta behin, proba mota hauek denbora gehiago behar dute burutzeko. Bigarrenik, abiarazi baino lehen, gure aldaketak proba/eszenatze ingurunean zabaldu behar ditugu. Gainera, mugikorren garapenaz ari bagara, urrats gehigarri bat agertzen da gure aplikazioaren eraikuntza bat sortzeko.
- Etengabeko hedapena Gure aldaketak ekoizpenean automatikoki kaleratzen ditugula suposatzen du aurreko faseetan onarpen-proba guztiak gainditu badira. Honetaz gain, kaleratze fasearen ondoren, hainbat fase konfigura ditzakezu, hala nola ekoizpenean ke probak egitea eta interesgarri diren neurketak biltzea. Etengabeko hedapena proba automatikoen bidez estaldura onarekin soilik posible da. Eskuzko esku-hartzeak behar badira, probak barne, hau ez da gehiago Etengabeko (etengabea). Orduan esan dezakegu gure kanalizazioak Etengabeko Entregatzearen praktikarekin bakarrik betetzen duela.
Automatizazio azpiegiturentzako balioa
Atal honetan, argitu beharko nuke amaierako UI probei buruz hitz egiten dugunean esan nahi duela gure aldaketak eta lotutako zerbitzuak proba-inguruneetan zabaldu behar ditugula. Etengabeko integrazioa - prozesua ez da zeregin honetarako aplikagarria eta gutxienez Etengabeko Entrega praktikak ezartzeaz arduratu behar dugu. Etengabeko Inplementazioak ere zentzua du UI proben testuinguruan produkzioan exekutatzen baditugu.
Eta arkitektura aldaketaren ilustrazioari begiratu baino lehen, hitz batzuk esan nahi ditut GitLab CI-ri buruz. Beste CI/CD tresnak ez bezala, GitLab-ek urruneko biltegi bat eta beste funtzio gehigarri asko eskaintzen ditu. Horrela, GitLab CI baino gehiago da. Iturburu-kodeen kudeaketa, kudeaketa Agilea, CI/CD kanalizazioak, erregistro-tresnak eta kutxatik kanpoko neurgailuen bilketa barne hartzen ditu. GitLab arkitektura Gitlab CI/CD eta GitLab Runner-ek osatzen dute. Hona hemen webgune ofizialeko deskribapen labur bat:
Gitlab CI/CD bere egoera datu-base batean gordetzen duen API bat duen web aplikazio bat da, proiektuak/eraiketak kudeatzen ditu eta erabiltzaile-interfazea eskaintzen du. GitLab Runner eraikuntzak prozesatzen dituen aplikazio bat da. Bereiz inplementa daiteke eta GitLab CI/CD-rekin funtzionatzen du API baten bidez. Exekutatzen diren probetarako Gitlab instantzia eta Runner behar dituzu.
Azpiegituren egungo egoeraren ilustrazioa
Arakatzeko estekak
Antzeko tresnak
- Eta beste asko
5. Hodeiko plataformak
Teknologiaren deskribapen laburra
Atal honetan 'hodei publikoak' izeneko joera ezagun bati buruz hitz egingo dugu. Goian deskribatutako birtualizazio eta edukiontzien teknologiek ematen dituzten onura handiak izan arren, informatika baliabideak behar ditugu oraindik. Enpresek zerbitzari garestiak erosten dituzte edo datu zentroak alokatzen dituzte, baina kasu honetan beharrezkoa da kalkuluak egitea (batzuetan ez-errealistak) zenbat baliabide beharko ditugun, 24/7 erabiliko ditugun ala ez eta zertarako. Adibidez, ekoizpenak XNUMX/XNUMX exekutatzen duen zerbitzari bat behar du, baina antzeko baliabideak behar al ditugu lanorduetatik kanpo probak egiteko? Egiten den proba motaren araberakoa da ere. Adibide bat hurrengo egunean emaitzak lortzeko lanorduz kanpoko orduetan egiteko asmoa dugun karga/estres probak izango lirateke. Baina, zalantzarik gabe, XNUMX/XNUMX zerbitzariaren erabilgarritasuna ez da beharrezkoa amaierako proba automatikoetarako eta, batez ere, ez da eskuzko proba-inguruneetarako. Horrelako egoeretarako, ondo legoke behar adina baliabide eskuratzea eskatuz gero, erabiltzea eta gehiago behar ez direnean ordaintzeari uztea. Gainera, saguaren klik batzuk eginez edo script pare bat exekutatuta berehala jasotzea bikaina litzateke. Horretarako erabiltzen dira hodei publikoak. Ikus dezagun definizioa:
βHodei publikoa hirugarren hornitzaileek Internet publikoaren bidez eskaintzen dituzten zerbitzu informatiko gisa definitzen da, horiek erabili edo erosi nahi dituen edonorentzat eskuragarri jarriz. Doakoak izan daitezke edo eskaeraren arabera saldu daitezke, bezeroek kontsumitzen dituzten PUZaren zikloak, biltegiratzea edo banda zabalera erabiltzeagatik soilik ordaintzeko aukera emanez".
Hodei publikoak garestiak direla iritzia dago. Baina haien funtsezko ideia enpresaren kostuak murriztea da. Arestian esan bezala, hodei publikoek baliabideak eskariaren arabera eskura ditzakezu eta haiek erabiltzen dituzun denboragatik bakarrik ordaintzen dute. Gainera, batzuetan ahaztu egiten zaigu langileek soldatak jasotzen dituztela, eta espezialistak ere baliabide garestia direla. Kontuan izan behar da hodei publikoek azpiegituren euskarria askoz errazten dutela, eta horri esker ingeniariek zeregin garrantzitsuagoetara bideratu ahal izango dituzte.
Automatizazio azpiegiturentzako balioa
Zein baliabide zehatz behar ditugu amaierako UI probak egiteko? Funtsean, makina birtualak edo klusterrak dira (hurrengo atalean Kubernetes-i buruz hitz egingo dugu) arakatzaileak eta emuladoreak exekutatzeko. Zenbat eta arakatzaile eta emuladore gehiago aldi berean exekutatu nahi ditugun, orduan eta CPU eta memoria gehiago behar dira eta diru gehiago ordaindu beharko dugu. Horrela, hodei publikoek probaren automatizazioaren testuinguruan nabigatzaile/emuladore kopuru handi bat (100, 200, 1000...) exekutatzeko aukera ematen digute eskaeraren arabera, proben emaitzak ahalik eta azkarren lortzeko eta baliabide izugarri handienengatik ordaintzeari utzi. boterea.
Hodeiko hornitzaile ezagunenak Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP) dira. Gidak GCP erabiltzeko adibideak ematen ditu, baina, oro har, ez du axola zer erabiltzen duzun automatizazio-zereginetarako. Guztiek gutxi gorabehera funtzionalitate bera eskaintzen dute. Normalean, hornitzaile bat hautatzeko, kudeaketa konpainiaren azpiegitura orokorrean eta negozioen eskakizunetan zentratzen da, artikulu honen esparrutik kanpo geratzen dena. Automatizazio ingeniarientzat, interesgarriagoa izango da hodeiko hornitzaileen erabilera probak egiteko bereziki hodeiko plataformen erabilerarekin alderatzea, hala nola Sauce Labs, BrowserStack, BitBar, etab. Beraz, egin dezagun guk ere! Nire ustez, Sauce Labs hodeiko probak egiteko baserririk ospetsuena da, horregatik erabili nuen konparaziorako.
GCP vs Sauce Labs automatizazio helburuetarako:
Imajina dezagun 8 web proba eta 8 Android proba aldi berean egin behar ditugula. Horretarako GCP erabiliko dugu eta 2 makina birtual exekutatuko ditugu Selenoid-ekin. Lehenengoan nabigatzailedun 8 edukiontzi planteatuko ditugu. Bigarrenean 8 edukiontzi daude emuladoreekin. Ikus ditzagun prezioei:
Chrome-rekin edukiontzi bat exekutatzeko, behar dugu n1-estandar-1 autoa. Android-en kasuan izango da n1-estandar-4 emuladore baterako. Izan ere, modu malguagoa eta merkeagoa da PUZ/Memoriaren erabiltzaile-balio zehatzak ezartzea, baina momentuz ez da garrantzitsua Sauce Labs-ekin alderatzeko.
Eta hona hemen Sauce Labs erabiltzeko tarifak:
Uste dut dagoeneko nabaritu duzula aldea, baina oraindik taula bat emango dizut gure zereginerako kalkuluekin:
Beharrezko baliabideak
Hilero
Lanorduak(8:8-XNUMX:XNUMX)
Lanorduak+ Aurrez aurrekoa
Weberako GCP
n1-estandar-1 x 8 = n1-estandar-8
$194.18
23 egun * 12 h * 0.38 = 104.88 $
23 egun * 12 h * 0.08 = 22.08 $
Sauce Labs Weberako
Virtual Cloud8 proba paraleloak
$1.559
-
-
Android-erako GCP
n1-estandar-4 x 8: n1-estandar-16
$776.72
23 egun * 12 h * 1.52 = 419.52 $
23 egun * 12 h * 0.32 = 88.32 $
Sauce Labs Android-erako
Real Device Cloud 8 proba paraleloak
$1.999
-
-
Ikusten duzunez, kostuaren aldea handia da, batez ere probak hamabi orduko lanaldi batean bakarrik egiten badituzu. Baina kostuak are gehiago murriz ditzakezu prebentziozko makinak erabiltzen badituzu. Zer da hori?
Aurrez aurreko VM bat instantzia arruntak baino askoz prezio handiagoan sortu eta exekutatu dezakezun instantzia bat da. Dena den, Compute Engine-k instantzia horiek amaitu (aurreratu) ditzake baliabide horiek beste zereginetarako sarbidea behar badu. Prebentziozko instantziak Compute Engine-ren gehiegizko ahalmena dira; beraz, erabilgarritasuna aldatu egiten da erabileraren arabera.
Zure aplikazioek akatsak jasan ditzakete eta gerta daitezkeen instantzia-prebentzioei aurre egin badiezaieke, prebentziozko instantziek Compute Engine-ren kostuak nabarmen murriztu ditzakete. Esaterako, batch prozesatzeko lanak lehenespenezko instantzietan exekutatu daitezke. Instantzia horietako batzuk prozesatzen zehar amaitzen badira, lana moteldu egiten da baina ez da guztiz gelditzen. Prebentziozko instantziek batch prozesatzeko zereginak osatzen dituzte lehendik dauden instantziei lan-karga gehigarririk jarri gabe eta instantzia arrunt gehigarriengatik prezio osoa ordaintzera behartu gabe.
Eta oraindik ez da amaitu! Egia esan, ziur nago inork ez dituela probak egiten 12 orduz atsedenik gabe. Eta hala bada, orduan automatikoki abiarazi eta geldi ditzakezu makina birtualak behar ez direnean. Benetako erabilera-denbora eguneko 6 ordura murriztu daiteke. Orduan, gure zereginaren testuinguruan ordainketa hilean $ 11ra jaitsiko da 8 arakatzailetan. Ez al da zoragarria? Baina prebentziozko makinekin kontuz ibili eta prest egon behar dugu etenetarako eta ezegonkortasunetarako, egoera hauek softwarean eman eta kudeatu daitezkeen arren. Merezi du!
Baina inola ere ez dut esaten "inoiz ez erabili hodeiko proba-ustiategiak". Hainbat abantaila dituzte. Lehenik eta behin, hau ez da makina birtual bat bakarrik, probak automatizatzeko soluzio oso bat baizik eta funtzionaltasun multzo bat duen kutxatik kanpo: urruneko sarbidea, erregistroak, pantaila-argazkiak, bideo-grabaketa, hainbat arakatzaile eta gailu mugikor fisikoak. Egoera askotan, hau ezinbesteko alternatiba chic bat izan daiteke. Proba plataformak bereziki erabilgarriak dira IOS automatizaziorako, hodei publikoek Linux/Windows sistemak soilik eskain ditzaketenean. Baina iOS-i buruz hitz egingo dugu hurrengo artikuluetan. Egoerari begira beti eta zereginetatik hastea gomendatzen dut: kasu batzuetan merkeagoa eta eraginkorragoa da hodei publikoak erabiltzea, eta beste batzuetan proba-plataformek, zalantzarik gabe, merezi dute gastatutako dirua.
Azpiegituren egungo egoeraren ilustrazioa
Arakatzeko estekak
Antzeko tresnak:
6. Orkestrazioa
Teknologiaren deskribapen laburra
Berri onak ditut: ia artikuluaren amaieran gaude! Momentu honetan, gure automatizazio azpiegitura web eta Android probek osatzen dute, GitLab CI bidez paraleloki exekutatzen ditugunak, Docker-en gaitutako tresnak erabiliz: Selenium grid eta Selenoid. Gainera, GCP bidez sortutako makina birtualak erabiltzen ditugu nabigatzaile eta emuladoreekin edukiontziak ostatatzeko. Kostuak murrizteko, makina birtual hauek eskaeraren arabera abiarazten ditugu eta probak egiten ez direnean gelditzen ditugu. Ba al dago gure azpiegitura hobetu dezakeen beste zerbait? Erantzuna baiezkoa da! Ezagutu Kubernetes (K8s)!
Lehenik eta behin, ikus dezagun orkestrazio, cluster eta Kubernetes hitzak nola erlazionatzen diren elkarren artean. Maila altuan, orkestrazioa aplikazioak zabaldu eta kudeatzen dituen sistema da. Proba automatizatzeko, edukiontzidun aplikazio hauek Selenium grid eta Selenoid dira. Docker eta K8ak elkarren osagarri dira. Lehenengoa aplikazioak hedatzeko erabiltzen da, bigarrena orkestraziorako. Aldiz, K8s kluster bat da. Klusterren zeregina VM-ak Nodo gisa erabiltzea da, eta horrek hainbat funtzionalitate, programa eta zerbitzu zerbitzari baten barruan (kluster) instalatzeko aukera ematen du. Nodoren batek huts egiten badu, beste Nodo batzuk hartuko dira, eta horrek gure aplikazioaren etenik gabeko funtzionamendua bermatzen du. Honetaz gain, K8s-ek eskalatzearekin lotutako funtzionalitate garrantzitsuak ditu, eta horri esker automatikoki lortzen dugu baliabide kopuru optimoa kargaren eta ezarritako mugen arabera.
Egia esan, Kubernetes hutsetik eskuz zabaltzea ez da batere lan hutsala. "Kubernetes The Hard Way" gida ospetsuaren esteka bat utziko dizuet eta interesatzen bazaizu, praktikatu dezakezu. Baina, zorionez, badira metodo eta tresna alternatiboak. Modurik errazena Google Kubernetes Engine (GKE) GCPn erabiltzea da, eta horrek klik gutxitan prest egindako kluster bat lortzeko aukera emango dizu. Ikasten hasteko ikuspegi hau erabiltzea gomendatzen dizut, barne osagaiak elkarrekin nola integratu behar diren ikasi beharrean K8ak zure zereginetarako erabiltzen ikastera bideratuko duzulako.
Automatizazio azpiegiturentzako balioa
Ikus ditzagun K8ak eskaintzen dituen ezaugarri esanguratsu batzuk:
- aplikazioen hedapena: VM-en ordez nodo anitzeko kluster bat erabiltzea;
- eskalatze dinamikoa: eskaeraren arabera soilik erabiltzen diren baliabideen kostua murrizten du;
- autosendatzea: lekak automatikoki berreskuratzea (ondorioz, ontziak ere berreskuratzen dira);
- eguneratzeak eta aldaketak atzera botatzea geldialdirik gabe: tresnak, arakatzaileak eta emuladoreak eguneratzeak ez du eteten egungo erabiltzaileen lana.
Baina K8s oraindik ez da zilarrezko bala bat. Kontuan hartzen ari garen tresnen (selenio-sarekoa, selenoidea) testuinguruan dauden abantaila eta muga guztiak ulertzeko, K8en egitura labur-labur aztertuko dugu. Klusterrak bi nodo mota ditu: Nodo nagusiak eta Langileak. Nodo nagusiak kudeaketa, hedapen eta programazio erabakien arduradunak dira. Langileen nodoak dira aplikazioak abiarazten diren lekuetan. Nodoek edukiontzien exekuzio-ingurune bat ere badute. Gure kasuan, hau Docker da, edukiontziekin lotutako eragiketez arduratzen dena. Baina irtenbide alternatiboak ere badaude, adibidez. Garrantzitsua da ulertzea eskalatzea edo autosendatzea ez zaiela zuzenean ontziei aplikatzen. Hau ontzi kopurua gehituz/gutxituz gauzatzen da, hauek aldi berean edukiontziak dituztenak (normalean ontzi bakoitzeko edukiontzi bat, baina zereginaren arabera gehiago egon daitezke). Goi-mailako hierarkia langile-nodoek osatzen dute, eta horien barruan lekak daude, eta horien barruan edukiontziak altxatzen dira.
Eskalatze-eginbidea funtsezkoa da eta klusterreko nodo-bilduma bateko bi nodoetan eta nodo bateko podetan aplika daiteke. Bi eskalatze mota daude bai nodoei bai podei aplikatzen zaizkienak. Lehenengo mota horizontala da - eskalatzea nodo/pod kopurua handituz gertatzen da. Mota hau hobeagoa da. Bigarren mota, beraz, bertikala da. Eskalatzea nodo/pods tamaina handituz egiten da, eta ez haien kopurua.
Orain ikus ditzagun gure tresnak goiko terminoen testuinguruan.
Selenio sarea
Lehen esan bezala, Selenium grid tresna oso ezaguna da, eta ez da harritzekoa edukiontzietan eduki izana. Hori dela eta, ez da harritzekoa Selenium grid K8etan hedatzea. Hau egiteko adibide bat K8s biltegi ofizialean aurki daiteke. Ohi bezala, atalaren amaieran estekak eransten ditut. Horrez gain, nola egin behar den gidak Terraform-en nola egin erakusten du. Arakatzaileen edukiontziak dituzten ontzien kopurua nola eskalatzeko argibideak ere badaude. Baina K8s-en testuinguruan eskalatze funtzio automatikoa oraindik ez da guztiz agerikoa den zeregina. Ikasten hasi nintzenean, ez nuen gida edo gomendio praktikorik aurkitu. DevOps taldearen laguntzarekin hainbat azterketa eta esperimentu egin ondoren, langile-nodo baten barruan dagoen ontzi baten barruan beharrezko arakatzaileak dituzten edukiontziak biltzeko planteamendua aukeratu dugu. Metodo honek nodoen eskalatze horizontalaren estrategia aplikatzeko aukera ematen digu haien kopurua handituz. Etorkizunean hori aldatuko dela espero dut eta gero eta deskribapen gehiago ikusiko ditugu planteamendu hobeak eta prest egindako irtenbideak, batez ere Selenium grid 4 barne arkitektura aldatuta kaleratu ondoren.
Selenoidea:
K8s-en selenoideen hedapena da gaur egun etsipen handiena. Ez dira bateragarriak. Teorian, Selenoid edukiontzi bat ontzi baten barruan altxa dezakegu, baina Selenoid-ek nabigatzaileekin ontziak abiarazten hasten direnean, ontzi berean egongo dira oraindik. Horrek eskalatzea ezinezkoa egiten du eta, ondorioz, Selenoid-en lana kluster baten barruan ez da makina birtual baten barruan dagoen lanaren desberdina izango. Istorioaren amaiera.
Ilargia:
Selenoid-ekin lan egitean botila-lepo hori ezagututa, garatzaileek Moon izeneko tresna indartsuagoa kaleratu zuten. Tresna hau hasiera batean Kubernetesekin lan egiteko diseinatu zen eta, ondorioz, eskalatze automatikoaren funtzioa erabil daiteke eta erabili behar da. Gainera, momentuz hala dela esango nuke bakarra Selenium munduko tresna bat, jatorrizko K8s kluster euskarria duen kutxatik kanpo (jada ez dago erabilgarri, ikusi hurrengo tresna ). Laguntza hau ematen duten Ilargiaren ezaugarri nagusiak hauek dira:
Erabat estaturik gabea. Selenoid-ek memorian gordetzen du unean martxan dauden arakatzailearen saioei buruzko informazioa. Arrazoiren bategatik bere prozesua huts egiten bada, exekutatzen ari diren saio guztiak galtzen dira. Ilargiak, alderantziz, ez du barne-egoerarik eta datu-zentroetan errepika daiteke. Arakatzaile-saioek bizirik jarraitzen dute erreplika bat edo gehiago jaisten badira ere.
Beraz, Moon irtenbide bikaina da, baina arazo bat dago: ez da doakoa. Prezioa saio kopuruaren araberakoa da. 0-4 saio bakarrik exekutatu ditzakezu doan, eta hori ez da bereziki erabilgarria. Baina, bosgarren saiotik hasita, 5 dolar ordaindu beharko dituzu bakoitzeko. Egoera desberdina izan daiteke enpresa batetik bestera, baina gure kasuan, Ilargia erabiltzea alferrikakoa da. Goian deskribatu dudan moduan, Selenium Grid-ekin VM-ak exekutatu ditzakegu eskaeraren arabera edo klusterreko Nodo kopurua handitu. Gutxi gorabehera kanalizazio baterako, 500 arakatzaile abiarazten ditugu eta probak amaitu ondoren baliabide guztiak geldiarazten ditugu. Moon erabiliko bagenu, hilean 500 x 5 = 2500 $ gehiago ordaindu beharko genituzke, probak zenbat aldiz egiten ditugun ere. Berriz ere, ez dut esaten Ilargia erabili ez denik. Zure zereginetarako, ezinbesteko irtenbidea izan daiteke, adibidez, zure erakundean proiektu/talde asko badituzu eta guztientzako kluster komun handi bat behar baduzu. Beti bezala, amaieran esteka bat uzten dut eta zure zereginaren testuinguruan beharrezko kalkulu guztiak egitea gomendatzen dut.
Calisto: (Kontuz! Hau ez dago jatorrizko artikuluan eta errusierazko itzulpenean bakarrik dago)
Esan bezala, Selenium tresna oso ezaguna da, eta informatika arloa oso azkar garatzen ari da. Itzulpenean lanean ari nintzela, sarean Callisto izeneko tresna itxaropentsu bat agertu zen (kaixo Cypress eta beste selenio hiltzaileak). K8s-ekin natiboki funtzionatzen du eta Selenoid ontziak ontzietan exekutatzeko aukera ematen du, Nodoetan banatuta. Dena kaxatik aterata funtzionatzen du, eskalatze automatikoa barne. Zoragarria, baina probatu beharra dago. Dagoeneko lortu dut tresna hau zabaltzea eta hainbat esperimentu egitea. Baina goizegi da ondorioak ateratzeko, distantzia luzeko emaitzak jaso ondoren, agian hurrengo artikuluetan errepaso bat egingo dut. Oraingoz ikerketa independenteetarako estekak baino ez ditut uzten.
Azpiegituren egungo egoeraren ilustrazioa
Arakatzeko estekak
Antzeko tresnak
7. Azpiegitura Kode gisa (IaC)
Teknologiaren deskribapen laburra
Eta orain azken atalera gatoz. Normalean, teknologia hau eta lotutako zereginak ez dira automatizazio ingeniarien ardura. Eta horretarako arrazoiak daude. Lehenik eta behin, erakunde askotan, azpiegitura-arazoak DevOps sailaren kontrolpean daude eta garapen-taldeei ez zaie benetan axola zerk funtzionatzen duen kanalizazioa eta harekin lotutako guztia nola lagundu behar den. Bigarrenik, zintzoak izan gaitezen, Azpiegitura Kode gisa (IaC) praktika oraindik ez da onartu enpresa askotan. Baina, zalantzarik gabe, joera ezaguna bihurtu da eta garrantzitsua da harekin lotutako prozesu, planteamendu eta tresnetan parte hartzen saiatzea. Edo, behintzat, eguneratuta egon.
Has gaitezen planteamendu hau erabiltzeko motibazioarekin. Dagoeneko eztabaidatu dugu GitlabCI-n probak egiteko, Gitlab Runner exekutatzeko baliabideak beharko ditugula gutxienez. Eta nabigatzaile/emuladoreekin edukiontziak exekutatzeko, VM edo cluster bat erreserbatu behar dugu. Baliabideak probatzeaz gain, garapena, eszenaratzea, produkzio-inguruneak laguntzeko gaitasun handia behar dugu, datu-baseak, programazio automatikoak, sare-konfigurazioak, karga-orekatzaileak, erabiltzaile-eskubideak, etab. Funtsezko gaia dena laguntzeko behar den ahalegina da. Hainbat modu daude aldaketak egin eta eguneratzeak zabaltzeko. Adibidez, GCP-ren testuinguruan, arakatzailean UI kontsola erabil dezakegu eta ekintza guztiak egin ditzakegu botoiak sakatuz. Alternatiba bat hodeiko entitateekin elkarreragiteko API deiak erabiltzea edo gcloud komando-lerroko erabilgarritasuna erabiltzea litzateke nahi diren manipulazioak egiteko. Baina entitate eta azpiegitura elementu ezberdinen kopuru handiarekin, zaila edo ezinezkoa bihurtzen da eragiketa guztiak eskuz egitea. Gainera, eskuzko ekintza horiek guztiak kontrolaezinak dira. Ezin ditugu exekutatu aurretik berrikusteko bidali, bertsio-kontrol sistema bat erabili eta gertakaria eragin duten aldaketak azkar atzera egin. Arazo horiek konpontzeko, ingeniariek bash/shell script automatikoak sortu eta sortzen dituzte, aurreko metodoak baino askoz hobeak ez direnak, ez baitira hain erraz irakurtzen, ulertzen, mantentzen eta prozedurazko estiloan aldatzea.
Artikulu honetan eta nola egin gida honetan, IaC praktikarekin lotutako 2 tresna erabiltzen ditut. Hauek Terraform eta Ansible dira. Batzuek uste dute ez duela zentzurik horiek aldi berean erabiltzeak, haien funtzionaltasuna antzekoa baita eta trukagarriak baitira. Baina kontua da hasieran zeregin guztiz desberdinak ematen zaizkiela. Eta tresna hauek elkarren osagarri izan behar dutela baieztatu zuten HashiCorp eta RedHat ordezkatzen duten garatzaileek aurkezpen bateratu batean. Ezberdintasun kontzeptuala da Terraform zerbitzariak beraiek kudeatzeko hornikuntza tresna bat dela. Ansible, berriz, konfigurazioa kudeatzeko tresna bat da, zeinaren zeregina zerbitzari hauetan softwarea instalatzea, konfiguratzea eta kudeatzea.
Tresna horien bereizgarri nagusietako bat kodetze estiloa da. Bash eta Ansible ez bezala, Terraform-ek exekuzioaren ondorioz lortu nahi den amaiera-egoeraren deskribapenean oinarritutako estilo deklaratiboa erabiltzen du. Adibidez, 10 VM sortu eta aldaketak Terraform bidez aplikatuko baditugu, orduan 10 VM lortuko ditugu. Script-a berriro exekutatzen badugu, ez da ezer gertatuko dagoeneko 10 VM ditugunez, eta Terraform-ek badaki horren berri, azpiegituraren egungo egoera egoera fitxategi batean gordetzen duelako. Baina Ansiblek prozedurazko ikuspegia erabiltzen du eta, 10 VM sortzeko eskatzen badiozu, lehenengo abiaraztean 10 VM lortuko ditugu, Terraform-en antzekoa. Baina berrabiarazi ondoren dagoeneko 20 VM izango ditugu. Hau da diferentzia garrantzitsua. Prozedura-estiloan, ez dugu uneko egoera gordetzen eta egin beharreko urratsen sekuentzia bat besterik ez dugu deskribatzen. Jakina, hainbat egoera kudeatu ditzakegu, baliabideen existentziari eta egungo egoerari buruzko hainbat egiaztapen gehitu, baina ez du balio gure denbora alferrik galtzea eta logika hori kontrolatzeko ahaleginak egitea. Gainera, horrek akatsak egiteko arriskua areagotzen du.
Aurreko guztia laburbilduz, Terraform eta adierazpen deklaratiboa zerbitzariak hornitzeko tresna egokiagoak direla ondoriozta dezakegu. Baina hobe da konfigurazioaren kudeaketa lana Ansibleren esku uztea. Hori alde batera utzita, ikus ditzagun erabilera kasuak automatizazioaren testuinguruan.
Automatizazio azpiegiturentzako balioa
Hemen ulertu beharreko gauza garrantzitsu bakarra probaren automatizazio azpiegitura enpresaren azpiegitura osoaren parte gisa hartu behar dela da. Horrek esan nahi du IaC praktika guztiak globalki aplikatu behar direla erakunde osoaren baliabideetan. Honen arduraduna nor den zure prozesuen araberakoa da. DevOps taldeak esperientzia handiagoa du gai hauetan, gertatzen ari denaren argazki osoa ikusten dute. Hala ere, QA ingeniariek gehiago parte hartzen dute eraikinen automatizazio prozesuan eta kanalizazioaren egituran, eta horri esker, beharrezkoak diren aldaketa eta hobetzeko aukera guztiak hobeto ikusten dituzte. Aukerarik onena elkarrekin lan egitea da, ezagutzak eta ideiak trukatzea espero den emaitza lortzeko.
Hona hemen Terraform eta Ansible probaren automatizazioaren testuinguruan eta aurretik eztabaidatu ditugun tresnen erabileraren adibide batzuk:
1. Deskribatu Terraform erabiliz VM eta klusterren beharrezko ezaugarriak eta parametroak.
2. Ansible erabiliz, instalatu probak egiteko beharrezkoak diren tresnak: docker, Selenoid, Selenium Grid eta deskargatu arakatzaile/emuladoreen beharrezko bertsioak.
3. Terraform erabiliz, deskribatu GitLab Runner abiaraziko den VM-aren ezaugarriak.
4. Instalatu GitLab Runner eta beharrezko tresnak Ansible erabiliz, ezarri ezarpenak eta konfigurazioak.
Azpiegituren egungo egoeraren ilustrazioa
Arakatzeko estekak:
Antzeko tresnak
Laburtu dezagun!
Urratsera
Teknologia
tresnak
Automatizazio azpiegiturentzako balioa
1
Korrika lokala
Node.js, Selenium, Appium
- Weberako eta mugikorrerako tresna ezagunenak
- Hainbat hizkuntza eta plataforma onartzen ditu (Node.js barne)
2
Bertsioak kontrolatzeko sistemak
Git
- Garapen kodearekin antzeko abantailak
3
Edukiontziratzea
Docker, Selenium grid, Selenoid (Web, Android)
- Probak paraleloan egitea
- Ingurune isolatuak
- Bertsio berritze sinple eta malguak
- Erabiltzen ez diren baliabideak dinamikoki geldiaraztea
- Erraza konfiguratzeko
4
CI/CD
Gitlab CI
- Hodiaren zati bat probatzen du
- Iritzi azkarra
- Enpresa/talde osoaren ikusgarritasuna
5
Hodei plataformak
Google Cloud Platform
- Eskaerarako baliabideak (beharrezkoa denean bakarrik ordaintzen dugu)
- Kudeatzeko eta eguneratzeko erraza
- Baliabide guztien ikusgarritasuna eta kontrola
6
Orchestration
Kubernetes
Podetan nabigatzaile/emuladoreak dituzten edukiontzien testuinguruan:
- Eskalatzea/eskalatze automatikoa
- Autosendatzea
- Eguneratzeak eta atzera botatzea etenik gabe
7
Azpiegitura kode gisa (IaC)
Terraform, Ansible
- Garapen azpiegiturekin antzeko onurak
- Kode bertsioaren abantaila guztiak
- Aldaketak egiteko eta mantentzeko erraza
- Guztiz automatizatua
Mapa mentalaren diagramak: azpiegituren bilakaera
urratsa: tokikoa
2. urratsa: VCS
3. urratsa: edukiontziratzea
4. urratsa: CI/CD
5. urratsa: Hodeiko plataformak
urratsa:Orkestrazioa
urratsa: IaC
Zer da hurrengoa?
Beraz, hau da artikuluaren amaiera. Baina bukatzeko, hitzarmen batzuk ezarri nahiko nituzke zurekin.
Zure aldetik
Hasieran esan bezala, artikuluak erabilera praktikoa izatea eta lortutako ezagutzak benetako lanetan aplikatzen laguntzea gustatuko litzaidake. Berriro gehitzen dut.
Baina horren ondoren ere, ez gelditu, praktikatu, aztertu loturak eta liburu garrantzitsuak, ezagutu nola funtzionatzen duen zure enpresan, aurkitu hobetu daitezkeen tokiak eta parte hartu. Zorte on!
Nire aldetik
Izenburutik ikus daiteke hau lehen zatia baino ez zela. Nahiko handia izan arren, gai garrantzitsuak oraindik ez dira lantzen hemen. Bigarren zatian, automatizazio azpiegitura IOS-en testuinguruan aztertzeko asmoa dut. Applek iOS simulagailuak macOS sistemetan soilik exekutatzeko murrizketak direla eta, gure irtenbide sorta murriztu egiten da. Adibidez, ezin dugu Docker erabili simulagailua exekutatzeko edo hodei publikoak makina birtualak exekutatzeko. Baina horrek ez du esan nahi beste alternatibarik ez dagoenik. Soluzio aurreratuekin eta tresna modernoekin eguneratzen zaituzten saiatuko naiz!
Gainera, monitorizazioari lotutako gai handi samarrak ez ditut aipatu. 3. zatian, azpiegiturak monitorizatzeko tresna ezagunenak eta zer datu eta neurketa kontuan hartu behar diren aztertuko dut.
Eta azkenean. Etorkizunean, proba-azpiegitura eta tresna ezagunak eraikitzeko bideo-ikastaro bat kaleratzeko asmoa dut. Gaur egun, DevOps-i buruzko ikastaro eta hitzaldi dezente daude Interneten, baina material guztiak garapenaren testuinguruan aurkezten dira, ez probaren automatizazioan. Gai honi buruz, benetan iritzia behar dut horrelako ikastaro bat probatzaileen eta automatizazio ingeniarien komunitatearentzat interesgarria eta baliogarria izango den jakiteko. Eskerrikasko aldez aurretik!
Iturria: www.habr.com