Etengabeko bidalketa-praktikak Docker-ekin (iritzia eta bideoa)

Gure bloga gure zuzendari teknikoaren azken hitzaldietan oinarritutako argitalpenekin hasiko dugu distol (Dmitri Stolyarov). Horiek guztiak 2016an hainbat ekitaldi profesionaletan egin ziren eta DevOps eta Docker gaiari eskaini ziren. Badooko bulegoan Docker Moskuko bilerako bideo bat, badaukagu ​​jada argitaratua Sarean. Berriak txostenen funtsa helarazten duten artikuluekin batera joango dira. Beraz…

Maiatzak 31 hitzaldian RootConf 2016, "Russian Internet Technologies" (RIT++ 2016) jaialdiaren baitan ospatu zen, "Continuous Deployment and Deployment" atala ireki zen "Best Practices of Continuous Delivery with Docker" txostenarekin. Docker eta kode irekiko beste produktu batzuk erabiliz Etengabeko entrega (CD) prozesu bat eraikitzeko jardunbide onenak laburtu eta sistematizatu zituen. Soluzio hauekin lan egiten dugu produkzioan, eta horri esker, esperientzia praktikoan oinarritzen gara.

Ordubete pasatzeko aukera baduzu erreportajearen bideoa, osorik ikustea gomendatzen dugu. Bestela, behean laburpen nagusia testu moduan dago.

Etengabeko entrega Docker-ekin

azpian Etengabeko erak Gertaeren katea ulertzen dugu, eta horren ondorioz Git biltegiko aplikazio-kodea lehenik produkziora etortzen da, eta gero artxiboan amaitzen da. Honela dirudi: Git → Eraiki → Probatu → Askatu → Funtzionatu.

Txostenaren zatirik handiena eraikitze faseari dago (aplikazioen muntaia), eta askatzea eta funtzionatzea gaiak laburki ukitzen dira. Horiek konpontzeko aukera ematen duten arazo eta ereduei buruz hitz egingo dugu, eta eredu horien ezarpen zehatzak desberdinak izan daitezke.

Zergatik behar da Docker hemen? Ez da ezertarako Etengabeko Entregako praktikei buruz hitz egitea Kode Irekiko tresna honen testuinguruan. Txosten osoa erabilerari eskainita dagoen arren, arrazoi asko azaltzen dira aplikazio-kodeen zabaltze eredu nagusia kontuan hartuta.

Zabaltze eredu nagusia

Beraz, aplikazioaren bertsio berriak zabaltzen ditugunean, zalantzarik gabe, aurrean gaude geldialdiaren arazoa, ekoizpen-zerbitzaria aldatzean sortutakoa. Aplikazioaren bertsio zaharretik berrira trafikoa ezin da berehala aldatu: lehenik eta behin, ziurtatu behar dugu bertsio berria behar bezala deskargatu ez ezik, "berotuta" dagoela (hau da, eskaerak betetzeko guztiz prest dagoela).

Horrela, denbora batean aplikazioaren bi bertsioak (zaharra eta berria) aldi berean funtzionatuko dute. Horrek automatikoki eramaten du partekatutako baliabideen gatazka: sarea, fitxategi-sistema, IPC, etab. Docker-ekin, arazo hau erraz konpontzen da aplikazioaren bertsio desberdinak edukiontzi bereizietan exekutatuta, eta horretarako baliabideen isolamendua bermatuta dago ostalari berean (zerbitzaria/makina birtuala). Noski, isolamendurik gabeko trikimailu batzuekin atera zaitezke, baina tresna prest eta erosoa badago, kontrako arrazoia dago: ez ahaztu.

Edukiontziak beste abantaila asko eskaintzen ditu zabaltzen denean. Edozein aplikazioren araberakoa da bertsio zehatza (edo bertsio sorta) interprete, moduluen/luzapenen eta abarren erabilgarritasuna, baita haien bertsioak ere. Eta hori ez da berehalako ingurune exekutagarriari bakarrik aplikatzen, baita ingurune osoari ere, barne sistemaren softwarea eta bere bertsioa (erabiltzen den Linux banaketaraino). Izan ere, edukiontziak aplikazio-kodea ez ezik, aurrez instalatutako sistema eta beharrezko bertsioen aplikazio-softwarea ere badutenez, mendekotasunen arazoak ahaztu ditzakezu.

Laburtu dezagun zabaltze-eredu nagusia bertsio berriak faktore hauek kontuan hartuta:

1. Hasieran, aplikazioaren bertsio zaharra lehen edukiontzian exekutatzen da.
2. Ondoren, bertsio berria zabaldu eta "berotzen" da bigarren edukiontzi batean. Azpimarratzekoa da bertsio berri honek berak aplikazio-kode eguneratua ez ezik, bere menpekotasunen bat ere eraman dezakeela, baita sistemaren osagaiak ere (adibidez, OpenSSLren bertsio berri bat edo banaketa osoa).
3. Bertsio berria eskaerak betetzeko guztiz prest dagoenean, trafikoa lehen edukiontzitik bigarrenera aldatzen da.
4. Orain bertsio zaharra geldi daiteke.

Aplikazioaren bertsio desberdinak edukiontzi bereizietan zabaltzeko ikuspegi honek beste erosotasun bat eskaintzen du - itzulera azkarra bertsio zaharrera (finean, nahikoa da trafikoa nahi den edukiontzira aldatzea).

Azken lehen gomendioak kapitainak ere akatsik aurkitu ezin izan duen zerbait dirudi: "[Docker-ekin Etengabeko Bidalketa antolatzen denean] Erabili Docker [eta ulertu zer ematen duen]" Gogoratu, hau ez da arazo guztiak konponduko dituen zilarrezko bala bat, oinarri zoragarria eskaintzen duen tresna baizik.

Erreproduzigarritasuna

"Erreproduzigarritasuna" esan nahi dugu aplikazioak ustiatzean aurkitzen diren arazoen multzo orokor bat. Horrelako kasuei buruz ari gara:

• Eszenaratzeko kalitate sailak egiaztatutako gidoiak zehaztasunez erreproduzitu behar dira ekoizpenean.
• Aplikazioak biltegiaren ispilu ezberdinetatik paketeak jaso ditzaketen zerbitzarietan argitaratzen dira (denborarekin eguneratzen dira, eta horiekin batera instalatutako aplikazioen bertsioak).
• "Dena funtzionatzen dit lokalean!" (...eta garatzaileei ezin zaie produkzioan sartzen.)
• Zerbait egiaztatu behar duzu bertsio zaharrean (artxibatuta).
• ...

Haien esentzia orokorra erabiltzen diren inguruneak (baita giza faktorearen eza) betetzea beharrezkoa dela adierazten du. Nola berma dezakegu erreproduzigarritasuna? Egin Docker irudiak Git-eko kodean oinarrituta, eta gero edozein zereginetarako erabili: proba guneetan, ekoizpenean, programatzaileen tokiko makinetan... Aldi berean, egiten diren ekintzak gutxitzea garrantzitsua da. ondoren irudia muntatzea: zenbat eta sinpleagoa izan, orduan eta aukera gutxiago egongo dira akatsak.

Azpiegitura kodea da

Azpiegitura-eskakizunak (zerbitzariaren softwarearen erabilgarritasuna, bere bertsioa, etab.) formalizatu eta "programatzen" ez badira, edozein aplikazio eguneratzeak ondorio negargarriak ekar ditzake. Esaterako, eszenaratzean PHP 7.0ra aldatu eta horren arabera kodea berridatzi duzu; orduan PHP zahar batzuekin (5.5) ekoizpenean agertzeak norbait harrituko du zalantzarik gabe. Baliteke interpretearen bertsioan aldaketa handi bat ahaztu gabe, baina “deabrua xehetasunetan dago”: sorpresa edozein mendekotasunen eguneratze txiki batean egon daiteke.

Arazo hau konpontzeko planteamendu bat bezala ezagutzen da IaC (Infrastructure as Code, "azpiegitura gisa kodea") eta aplikazioaren kodearekin batera azpiegitura-eskakizunak gordetzea dakar. Hori erabiliz, garatzaileek eta DevOps-eko espezialistek Git aplikazioen biltegi berdinarekin lan egin dezakete, baina zati ezberdinetan. Kode horretatik abiatuta, Docker irudi bat sortzen da Git-en, eta bertan aplikazioa hedatzen da azpiegituraren berezitasun guztiak kontuan hartuta. Besterik gabe, irudiak biltzeko gidoiak (arauak) iturburu-kodearen biltegi berean egon behar dira eta elkarrekin batu.

Geruza anitzeko aplikazioen arkitektura baten kasuan -adibidez, nginx dago, Docker edukiontzi batean dagoeneko martxan dagoen aplikazio baten aurrean dagoena- Docker irudiak Git-en kodetik sortu behar dira geruza bakoitzeko. Ondoren, lehenengo irudiak interprete bat eta beste menpekotasun "hurbil" dituen aplikazio bat izango du, eta bigarren irudiak gorako nginx edukiko du.

Docker irudiak, Git-ekin komunikazioa

Git-etik bildutako Docker irudi guztiak bi kategoriatan banatzen ditugu: aldi baterakoak eta kaleratzeak. Behin-behineko irudiak Git-en adarraren izenaz etiketatuta, hurrengo konpromezuarekin gainidatzi daiteke eta aurrebistarako soilik zabaltzen dira (ez ekoizpenerako). Hau da kaleratzeekin duten aldea: inoiz ez dakizu zein konpromiso zehatz dagoen haietan.

Zentzuzkoa da behin-behineko irudietan biltzea: adar nagusia (automatikoki zabaldu dezakezu aparteko gune batera, maisuaren uneko bertsioa etengabe ikusteko), oharra dituzten adarrak, berrikuntza zehatzen adarrak.

Behin-behineko irudien aurrebista ekoizpenera itzultzeko beharra ikusi ondoren, garatzaileek etiketa jakin bat jartzen dute. Etiketa bidez automatikoki biltzen da askatu irudia (bere etiketa Git-eko etiketari dagokio) eta eszenaratzera zabaltzen da. Kalitate sailak ongi egiaztatzen badu, ekoizpenera joaten da.

dapp

Deskribatutako guztia (inplementazioa, irudien muntaketa, ondorengo mantentze-lanak) modu independentean inplementa daiteke Bash script-ak eta beste tresna "inprobisatuak" erabiliz. Baina hau egiten baduzu, uneren batean ezarpenak konplexutasun handia eta kontrolagarritasun eskasa ekarriko du. Hori ulertuta, gure lan-fluxuaren erabilgarritasun espezializatua sortzera iritsi ginen CI/CDa eraikitzeko - dapp.

Bere iturburu-kodea Ruby-n idatzita dago, kode irekian eta argitaratzen da GitHub. Tamalez, dokumentazioa da gaur egun tresnaren puntu ahulena, baina horretan ari gara. Eta behin baino gehiagotan idatzi eta hitz egingo dugu dapp-ari buruz, zeren... Benetan ezin dugu itxaron bere gaitasunak komunitate osoarekin partekatzeko, baina bitartean, bidali zure arazoak eta eskaerak eta/edo jarraitu proiektuaren garapena GitHub-en.

13ko abuztuaren 2019an eguneratua: gaur egun proiektu bat dapp izena aldatu werf, bere kodea guztiz berridatzi da Go-n, eta bere dokumentazioa nabarmen hobetu da.

Kubernetes

Lanbide-ingurunean dagoeneko aintzatespen handia jaso duen Kode Irekiko prest egindako beste tresna bat da Kubernetes,Docker kudeaketa-kluster bat. Docker-en eraikitako proiektuen funtzionamenduan erabiltzearen gaia txostenaren esparrutik kanpo dago, beraz, aurkezpena ezaugarri interesgarri batzuen ikuspegi orokor batera mugatzen da.

Inplementatzeko, Kubernetes-ek honako hauek eskaintzen ditu:

• Readiness probe — aplikazioaren bertsio berri baten prest dagoen egiaztatzea (trafikoa bertara aldatzeko);
• rolling update - irudi sekuentziala eguneratzea edukiontzi multzo batean (itzaltzea, eguneratzea, abiarazteko prestatzea, trafikoa aldatzea);
• eguneraketa sinkronikoa - kluster batean irudi bat eguneratzea beste ikuspegi batekin: lehenengo edukiontzien erdian, gero gainerakoetan;
• canary releases - ontzi-kopuru (txiki) mugatu batean irudi berri bat abian jartzea anomaliak kontrolatzeko.

Etengabeko Bidalketa bertsio berri bat kaleratzea soilik ez denez, Kubernetesek hainbat aukera ditu ondorengo azpiegituren mantentze-lanetarako: edukiontzi guztien jarraipena eta erregistroa integratua, eskalatze automatikoa, etab. Hori guztia dagoeneko funtzionatzen ari da eta behar bezala zain dago. inplementazioa zure prozesuetan.

Azken gomendioak

1. Erabili Docker.
2. Sortu aplikazioen Docker irudiak zure behar guztietarako.
3. Jarraitu "Azpiegitura kodea da" printzipioa.
4. Lotu Git Docker-era.
5. Inplementatzeko ordena arautu.
6. Erabili prest egindako plataforma bat (Kubernetes edo beste).

Bideoak eta diapositibak

Emanaldiko bideoa (ordubete inguru) YouTuben argitaratua (erreportajea bera 5. minututik hasten da - jarraitu esteka une honetatik jolasteko).

Txostenaren aurkezpena:

PS

Gure blogean gaiari buruzko beste erreportaje batzuk:

• «werf - Kubernetes-en CI / CDrako gure tresna (ikuspegi orokorra eta bideo-txostena)» (Dmitry Stolyarov; 27ko maiatzaren 2019a DevOpsConf-en);
• «Datu-baseak eta Kubernetes» (Dmitry Stolyarov; 8ko azaroaren 2018a HighLoad++-n);
• «CI/CD praktika onak Kubernetes eta GitLab-ekin» (Dmitry Stolyarov; 7ko azaroaren 2017a HighLoad++-n);
• «Gure esperientzia Kubernetesekin proiektu txikietan» (Dmitry Stolyarov; 6ko ekainaren 2017an RootConf-en).

Iturria: www.habr.com