Inventos-eko Alexander Sigachev-ek egindako txostenaren transkripzioa irakurtzea proposatzen dut "Docker + Gitlab CIrekin garatzeko eta probatzeko prozesua"
Docker + Gitlab CI-n oinarritutako garapen- eta proba-prozesua ezartzen hasi berri direnek oinarrizko galderak egiten dituzte maiz. Nondik hasi? Nola antolatu? Nola probatu?
Txosten hau ona da, Docker eta Gitlab CI erabiliz garapen eta proba prozesuari buruz modu egituratuan hitz egiten duelako. Txostena bera 2017koa da. Uste dut txosten honetatik oinarriak, metodologia, ideia, erabileraren esperientzia ikas daitezkeela.
Nori axola zaio, mesedez, katuaren azpian.
Nire izena Alexander Sigachev da. Inventos enpresan egiten dut lan. Docker erabiltzen dudan esperientzia kontatuko dizuet eta pixkanaka enpresan proiektuetan nola ezartzen ari garen.
Aurkezpen gaia: Docker eta Gitlab CI erabiliz garatzeko prozesua.
Hau Dockerri buruzko nire bigarren hitzaldia da. Lehen txostena egin zenean, Docker garapenean garatzaileen makinetan bakarrik erabiltzen genuen. Docker erabili zuten langileen kopurua 2-3 pertsona ingurukoa zen. Pixkanaka-pixkanaka, esperientzia hartu eta pixka bat harago joan ginen. Gure esteka .
Zer izango da txosten honetan? Gure esperientzia partekatuko dugu zer bildu dugun, zein arazo konpondu ditugun. Leku guztietan ez zen ederra, baina aurrera jarraitzeko aukera ematen zuen.
Gure leloa hauxe da: eskuan eskura dezakegun guztia atrakatu.
Zein arazo konpontzen ari gara?
Enpresa batean hainbat talde daudenean, programatzailea baliabide partekatua da. Programatzaile bat proiektu batetik atera eta denbora baterako beste proiektu bati ematen zaion etapak daude.
Programatzaileak azkar uler dezan, proiektuaren iturburu-kodea deskargatu behar du eta ahalik eta azkarren ingurunea abiarazi behar du, eta horrek proiektu honen arazoak konpontzen gehiago mugitzeko aukera emango dio.
Normalean, hutsetik hasten bazara, orduan dokumentazio gutxi dago proiektuan. Konfiguratzeko moduari buruzko informazioa denbora zaharrentzako bakarrik dago eskuragarri. Langileek euren lantokia ezartzen dute egun batean edo bitan. Hau bizkortzeko, Docker erabili dugu.
Hurrengo arrazoia garapenean ezarpenen estandarizazioa da. Nire esperientziaren arabera, garatzaileek beti hartzen dute ekimena. Bosgarren kasu guztietan, domeinu pertsonalizatu bat sartzen da, adibidez, vasya.dev. Haren ondoan eserita dago bere bizilaguna Petya, zeinaren domeinua petya.dev da. Webgune bat edo sistemaren osagairen bat garatzen dute domeinu-izen hau erabiliz.
Sistema hazten denean eta domeinu-izen hauek konfigurazioetan sartzen hasten direnean, Garapen-ingurunearen gatazka sortzen da eta gunearen bidea berridazten da.
Gauza bera gertatzen da datu-basearen ezarpenekin. Norbaitek ez du segurtasunarekin traba egiten eta root pasahitz hutsarekin lan egiten du. Instalazio fasean, MySQL-k norbaiti pasahitza eskatu zion eta pasahitza 123koa izan zen. Sarritan gertatzen da datu-basearen konfigurazioa etengabe aldatzen ari dela garatzailearen konpromisoaren arabera. Norbaitek zuzendu du, norbaitek ez du konfigurazioa zuzendu. Trikimailuak zeuden probaren konfigurazio moduko bat atera genuenean .gitignore eta garatzaile bakoitzak datu-basea instalatu behar zuen. Horrek zaildu egin zuen hastea. Beharrezkoa da, besteak beste, datu-baseari buruz gogoratzea. Datu-basea hasieratu behar da, pasahitza sartu, erabiltzaile bat erregistratu, taula bat sortu, etab.
Beste arazo bat liburutegien bertsio desberdinak dira. Askotan gertatzen da garatzaile batek proiektu ezberdinekin lan egitea. Duela bost urte hasitako Legacy proiektu bat dago (2017tik aurrera - oharra). Abiarazteko unean, MySQL 5.5-ekin hasi ginen. Proiektu modernoak ere badaude non MySQL-ren bertsio modernoagoak inplementatzen saiatzen garen, adibidez, 5.7 edo zaharragoak (2017an - ed. oharra)
MySQL-rekin lan egiten duen edonork badaki liburutegi hauek mendekotasunak ekartzen dituztela. Nahiko problematikoa da 2 oinarri elkarrekin exekutatzeko. Gutxienez, bezero zaharrak arazotsuak dira datu-base berrira konektatzeko. Horrek hainbat arazo sortzen ditu.
Hurrengo arazoa garatzaile batek tokiko makina batean lan egiten duenean, tokiko baliabideak, tokiko fitxategiak, tokiko RAM erabiltzen ditu. Arazoen konponbidea garatzeko unean elkarrekintza guztiak makina batean funtzionatzen duen esparruan egiten dira. Adibide bat da Produkzio 3-n backend zerbitzariak ditugunean, eta garatzaileak fitxategiak erroko direktorioan gordetzen ditu eta hortik nginx-ek fitxategiak hartzen ditu eskaerari erantzuteko. Kode hori Produkzioan sartzen denean, fitxategia 3 zerbitzarietako batean dagoela ematen du.
Mikrozerbitzuen norabidea garatzen ari da orain. Gure aplikazio handiak elkarri eragiten dioten osagai txiki batzuetan banatzen ditugunean. Honi esker, zeregin pila zehatz baterako teknologiak hauta ditzakezu. Garatzaileen artean lana eta ardurak partekatzeko aukera ere ematen du.
Frondend-garatzaileak, JS-n garatzen dituenak, ez du ia eraginik Backend-en. Backend garatzaileak, gure kasuan, Ruby on Rails garatzen du eta ez du Frondend-ekin oztopatzen. Interakzioa APIa erabiliz egiten da.
Hobari gisa, Dockerren laguntzaz, Staging-en baliabideak birziklatu ahal izan ditugu. Proiektu bakoitzak, bere berezitasunak direla eta, ezarpen batzuk behar zituen. Fisikoki, beharrezkoa zen zerbitzari birtual bat esleitu eta bereizita konfiguratzea, edo ingurune aldakorren bat partekatzea eta proiektuek, liburutegien bertsioaren arabera, elkarrengan eragina izan dezakete.
Tresnak. Zer erabiltzen dugu?
- Docker bera. Dockerfile-k aplikazio bakar baten menpekotasunak deskribatzen ditu.
- Docker-compose gure Docker aplikazio batzuk batzen dituen sorta bat da.
- GitLab erabiltzen dugu iturburu-kodea gordetzeko.
- GitLab-CI erabiltzen dugu sistema integratzeko.
Txostenak bi zati ditu.
Lehenengo zatian Docker garatzaileen makinetan nola exekutatu zen hitz egingo da.
Bigarren zatian GitLab-ekin elkarreragin nola egin, probak nola egiten ditugun eta Staging-era nola zabaltzen garen hitz egingo da.
Docker beharrezko osagaiak deskribatzeko aukera ematen duen teknologia da (ikuspegi deklaratiboa erabiliz). Hau Dockerfile adibide bat da. Hemen Ruby:2.3.0 Docker irudi ofizialetik heredatzen ari garela adierazten dugu. Ruby 2.3 bertsioa dauka instalatuta. Beharrezko eraikuntza liburutegiak eta NodeJS instalatzen ditugu. Direktorio bat sortzen dugula deskribatzen dugu /app. Ezarri aplikazioaren direktorioa laneko direktorio gisa. Direktorio honetan beharrezkoak diren Gemfile eta Gemfile.lock minimoak jartzen ditugu. Ondoren, mendekotasun-irudi hori instalatzen duten proiektuak eraikitzen ditugu. Edukiontzia kanpoko 3000 atakan entzuteko prest egongo dela adierazten dugu. Azken komandoa gure aplikazioa zuzenean abiarazten duen komandoa da. Proiektua hasteko komandoa exekutatzen badugu, aplikazioa zehaztutako komandoa exekutatzen eta exekutatzen saiatuko da.
Hau docker-compose fitxategi baten adibide minimo bat da. Kasu honetan, bi edukiontzien artean lotura bat dagoela erakusten dugu. Hau zuzenean datu-base zerbitzuan eta web zerbitzura sartzen da. Gure web-aplikazioek kasu gehienetan datu-base bat behar dute datuak gordetzeko backend gisa. MySQL erabiltzen ari garenez, adibidea MySQLrekin dago, baina ezerk ez digu eragozten beste datu-baseren bat erabiltzea (PostgreSQL, Redis).
Docker hub-eko iturri ofizialetik hartzen dugu MySQL 5.7.14-ren irudia aldaketarik gabe. Gure web aplikazioaren arduraduna den irudia uneko direktoriotik biltzen dugu. Irudi bat biltzen digu lehenengo abiaraztean. Ondoren, hemen exekutatzen ari garen komandoa exekutatzen du. Atzera egiten badugu, Puma bidez abiarazteko komandoa definitu dela ikusiko dugu. Puma Rubyz idatzitako zerbitzua da. Bigarren kasuan, gainidatzi egiten dugu. Komando hau arbitrarioa izan daiteke gure beharren edo zereginen arabera.
Era berean, deskribatzen dugu gure garatzaileen ostalari-makinan ataka bat 3000-tik 3000-ra birbidali behar dugula edukiontzi-atatuan. Hau automatikoki egiten da iptables eta bere mekanismoa erabiliz, Docker-en zuzenean txertatuta dagoena.
Garatzaileak, lehen bezala, erabilgarri dagoen edozein IP helbide atzi dezake, adibidez, 127.0.0.1 makinaren tokiko edo kanpoko IP helbidea da.
Azken lerroak dio web edukiontzia db edukiontziaren araberakoa dela. Web edukiontziaren hasiera deitzen dugunean, docker-compose-k lehenik datu-basea abiaraziko digu. Dagoeneko datu-basearen hasieran (hain zuzen ere, edukiontzia abiarazi ondoren! Horrek ez du datu-basearen prest egotea bermatzen) aplikazioa abiaraziko du, gure backend-a.
Honek akatsak saihesten ditu datu-basea ateratzen ez denean eta baliabideak aurrezten ditu datu-basearen edukiontzia gelditzen dugunean, horrela beste proiektu batzuetarako baliabideak askatuz.
Zerk ematen digu datu-baseen dockerizazioa proiektuan erabiltzeko. MySQL-ren bertsioa garatzaile guztientzat konpontzen dugu. Honek bertsioak desberdintzen direnean, sintaxia, konfigurazioa eta ezarpen lehenetsiak aldatzen direnean gerta daitezkeen errore batzuk saihesten dira. Honek datu-baserako, saioa hasteko, pasahitzerako ostalari-izen komun bat zehazteko aukera ematen du. Lehen genituen konfigurazio fitxategietan izenen eta gatazken zootik urruntzen ari gara.
Garapen-ingurunerako konfigurazio optimoagoa erabiltzeko aukera dugu, lehenetsitakoa desberdina izango dena. MySQL makina ahuletarako konfiguratuta dago lehenespenez eta bere errendimendua oso eskasa da.
Docker-ek nahi duzun bertsioaren Python, Ruby, NodeJS, PHP interpretea erabiltzeko aukera ematen du. Bertsio-kudeatzaile moduko bat erabili beharra kentzen dugu. Aurretik, Ruby-k rpm pakete bat erabiltzen zuen, proiektuaren arabera bertsioa aldatzeko aukera ematen zuena. Gainera, Docker edukiontziari esker, kodea arin migratzeko eta mendekotasunekin batera bertsioa egiteko aukera ematen du. Ez dugu arazorik interpretearen zein kodearen bertsioa ulertzeko. Bertsioa eguneratzeko, jaitsi edukiontzi zaharra eta igo edukiontzi berria. Zerbait gaizki joan bada, edukiontzi berria jaitsi dezakegu, edukiontzi zaharra igo.
Irudia eraiki ondoren, bai Garapenean bai Ekoizpenean edukiontziak berdinak izango dira. Hau bereziki egia da instalazio handietarako.
Frontend-en JavaScipt eta NodeJS erabiltzen ditugu.
Orain ReacJS-en azken proiektua dugu. Garatzaileak edukiontzian dagoen guztia exekutatu eta beroa birkargatuz garatu zuen.
Ondoren, JavaScipt muntaketa-zeregina abiarazten da eta estatikoetan konpilatutako kodea nginx gordetzeko baliabideen bidez ematen da.
Hemen eman dut gure azken proiektuaren eskema.
Zein zeregin konpondu ziren? Gailu mugikorrekin elkarreragiten duen sistema bat eraikitzeko beharra genuen. Datuak jasotzen dituzte. Aukera bat gailu honetara push jakinarazpenak bidaltzea da.
Zer egin dugu horretarako?
Aplikazioan osagai hauek banatu ditugu: JS-en admin zatia, backend-a, Ruby on Rails-en REST interfazearen bidez lan egiten duena. Backend-ak datu-basearekin elkarreragiten du. Sortzen den emaitza bezeroari ematen zaio. Admin panelak backendarekin eta datu-basearekin elkarreragiten du REST interfazearen bidez.
Push jakinarazpenak bidaltzeko beharra ere izan genuen. Horren aurretik, plataforma mugikorretara jakinarazpenak bidaltzeaz arduratzen den mekanismo bat ezarri zuen proiektu bat genuen.
Honako eskema hau garatu dugu: nabigatzaileko operadore batek administrazio panelarekin elkarreragiten du, administrazio panelak backendarekin elkarreragiten du, zeregina Push jakinarazpenak bidaltzea da.
Push jakinarazpenak NodeJS-en inplementatutako beste osagai batekin elkarreragiten dute.
Ilarak eraikitzen dira eta gero jakinarazpenak bidaltzen dira haien mekanismoaren arabera.
Hemen bi datu-base marraztuta daude. Momentuz, Dockerren laguntzaz, inolaz ere elkarren artean erlazionatuta ez dauden 2 datu-base independente erabiltzen ditugu. Horrez gain, sare birtual komun bat dute, eta datu fisikoak garatzailearen makinan direktorio ezberdinetan gordetzen dira.
Berdin baina zenbakitan. Hor garrantzitsua da kodea berrerabiltzea.
Lehenago liburutegi moduan kodea berrerabiltzeari buruz hitz egin badugu, adibide honetan Push jakinarazpenei erantzuten dien gure zerbitzua zerbitzari oso gisa berrerabiltzen da. API bat eskaintzen du. Eta gure garapen berriak harekin elkarreragiten du jada.
Garai hartan, NodeJS-ren 4. bertsioa erabiltzen ari ginen. Orain (2017an - ed. oharra) azken garapenetan NodeJS-en 7. bertsioa erabiltzen dugu. Osagai berrietan ez dago arazorik liburutegien bertsio berriak inplikatzeko.
Beharrezkoa izanez gero, Push jakinarazpen zerbitzutik NodeJS bertsioa birfaktorizatu eta igo dezakezu.
Eta API bateragarritasuna mantentzen badugu, posible izango da aurretik erabiltzen ziren beste proiektu batzuekin ordezkatzea.
Zer behar duzu Docker gehitzeko? Dockerfile bat gehitzen dugu gure biltegian, beharrezko mendekotasunak deskribatzen dituena. Adibide honetan, osagaiak logikoki banatzen dira. Hau da backend garatzaile baten gutxieneko multzoa.
Proiektu berri bat sortzean, Dockerfile bat sortzen dugu, nahi den ekosistema deskribatzen dugu (Python, Ruby, NodeJS). Docker-compose-n, beharrezko mendekotasuna deskribatzen du - datu-basea. Halako bertsioaren datu-base bat behar dugula deskribatzen dugu, datuak han eta hemen gorde.
Nginx-ekin hirugarren edukiontzi bat erabiltzen dugu estatikoa zerbitzatzeko. Argazkiak igotzeko aukera dago. Backend-ek aurrez prestatutako bolumen batean jartzen ditu, hau ere nginx duen edukiontzi batean muntatuta dagoena, estatikoa ematen duena.
Nginx, mysql konfigurazioa gordetzeko, Docker karpeta bat gehitu dugu eta bertan beharrezko konfigurazioak gordetzen ditugu. Garatzaile batek biltegi baten git klona egiten duenean bere makinan, dagoeneko prest dauka tokiko garapenerako proiektu bat. Ez dago zalantzarik zer ataka edo zer ezarpen aplikatu.
Ondoren, hainbat osagai ditugu: admin, inform-API, push jakinarazpenak.
Hau guztia hasteko, beste biltegi bat sortu genuen, dockerized-app deitu geniona. Momentuz osagai bakoitzaren aurretik hainbat biltegi erabiltzen ditugu. Logikoki desberdinak dira - GitLab-en karpeta bat dirudi, baina garatzailearen makinan, proiektu zehatz baterako karpeta bat. Maila bat beherago dira konbinatuko diren osagaiak.
Hau dockerized-app-en edukiaren adibidea da. Docker direktorioa ere ekartzen dugu hona, eta bertan osagai guztien interakzioetarako beharrezkoak diren konfigurazioak betetzen ditugu. Badago README.md bat proiektua nola exekutatu den laburki deskribatzen duena.
Hemen bi docker-compose fitxategi aplikatu ditugu. Hau urratsetan exekutatu ahal izateko egiten da. Garatzaile batek corearekin lan egiten duenean, ez du push jakinarazpenik behar, docker-compose fitxategi bat abiarazten du eta, horren arabera, baliabidea gordetzen da.
Push jakinarazpenekin integratzeko beharra badago, docker-compose.yaml eta docker-compose-push.yaml abiarazten dira.
Docker-compose.yaml eta docker-compose-push.yaml karpeta batean daudenez, sare birtual bakarra sortzen da automatikoki.
Osagaien deskribapena. Fitxategi aurreratuagoa da, osagaien bilketaz arduratzen dena. Zer da aipagarria hemen? Hemen orekatzeko osagaia aurkezten dugu.
Hau nginx exekutatzen duen Docker irudia eta Docker socketean entzuten duen aplikazio bat da. Dinamikoa, edukiontziak piztu eta itzaltzen diren heinean, nginx konfigurazioa birsortzen du. Osagaien maneiua hirugarren mailako domeinu izenen arabera banatzen dugu.
Garapen ingurunerako, .dev domeinua erabiltzen dugu - api.informer.dev. .dev domeinua duten aplikazioak garatzailearen tokiko makinan daude eskuragarri.
Gainera, konfigurazioak proiektu bakoitzean transferitzen dira eta proiektu guztiak batera abiarazten dira aldi berean.
Grafikoki, bezeroa gure nabigatzailea da edo orekatzaileari eskaerak egiten dizkiogun tresna bat dela.
Domeinu-izenen balantzaileak zehazten du zein edukiontzirekin harremanetan jarri.
Nginx izan daiteke, administratzaileari JS ematen duena. Hau nginx izan daiteke, APIa ematen duena, edo fitxategi estatikoak, zeinak nginx-i ematen zaizkion irudiak igotzeko moduan.
Diagramak erakusten du edukiontziak sare birtual baten bidez konektatuta daudela eta proxy baten atzean ezkutatuta daudela.
Garatzailearen makinan, edukiontzira sar zaitezke IPa ezagututa, baina printzipioz ez dugu hau erabiltzen. Ia ez dago zuzeneko sarbiderik behar.
Zein adibide begiratu zure aplikazioa dockerizatzeko? Nire ustez, adibide ona MySQL-ren docker irudi ofiziala da.
Nahiko erronka da. Bertsio asko daude. Baina bere funtzionaltasunak garapen-prozesuan sor daitezkeen behar asko estaltzeko aukera ematen du. Denbora pasatzen baduzu eta dena nola elkarreragiten ikusten baduzu, uste dut ez duzula arazorik izango auto-inplementazioan.
Hub.docker.com-ek normalean github.com-erako estekak ditu, eta datu gordinak ditu zuzenean, zeinetatik irudia zuk zeuk eraiki dezakezu.
Biltegi honetan, docker-endpoint.sh script bat dago, hasierako hasieraz eta aplikazioaren abiarazte gehiago prozesatzeaz arduratzen dena.
Adibide honetan ere, ingurune-aldagaiak erabiliz konfiguratzeko aukera dago. Edukiontzi bakar bat exekutatzen denean ingurune-aldagai bat definituz edo docker-compose bidez, esan dezakegu docker-ek MySQL-n edo nahi dugun edozertan errotzeko pasahitz huts bat ezarri behar dugula.
Aukera bat dago ausazko pasahitza sortzeko. Erabiltzaile bat behar dugula esaten dugu, erabiltzaileari pasahitza ezarri behar diogula eta datu-base bat sortu behar dugula.
Gure proiektuetan, apur bat bateratu dugu Dockerfile, hasieratzeaz arduratzen dena. Bertan gure beharretara zuzendu genuen aplikazioak erabiltzen dituen erabiltzaile-eskubideen luzapen bat besterik ez izateko. Horri esker, geroago aplikazioen kontsolatik datu-base bat sortzea ahalbidetu genuen. Ruby aplikazioek komando bat dute datu-baseak sortzeko, aldatzeko eta ezabatzeko.
Hau github.com-en MySQL-ren bertsio zehatz baten itxuraren adibide bat da. Dockerfile ireki dezakezu eta bertan instalazioa nola gertatzen den ikus dezakezu.
docker-endpoint.sh sarrera-puntuaren arduraduna den script-a da. Hasierako abiaraztean, prestatzeko urrats batzuk behar dira, eta ekintza horiek guztiak hasierako scriptean bakarrik ateratzen dira.
Goazen bigarren zatira.
Iturburu-kodeak gordetzeko, gitlab-era aldatu gara. Hau sistema nahiko indartsua da, bisual interfazea duena.
Gitlab-en osagaietako bat Gitlab CI da. Geroago kodea emateko sistema bat antolatzeko edo proba automatikoak egiteko erabiliko den komando-sekuentzia bat deskribatzeko aukera ematen du.
Gitlab CI 2 hitzaldia - Ruby Russia klubaren txostena - nahiko zehatza eta agian interesatuko zaizu.
Orain Gitlab CI aktibatzeko behar dena aztertuko dugu. Gitlab CI abiarazteko, .gitlab-ci.yml fitxategia proiektuaren erroan jarri besterik ez dugu behar.
Hemen deskribatzen dugu egoera-sekuentzia bat exekutatu nahi dugula proba bat bezala, zabaldu.
Docker-compose zuzenean deitzen duten scriptak exekutatzen ditugu gure aplikazioa eraikitzeko. Hau backend adibide bat besterik ez da.
Jarraian, datu-basea aldatzeko eta probak egiteko migrazioak exekutatu behar direla esaten dugu.
Scriptak behar bezala exekutatzen badira eta errore-koderik itzultzen ez badute, sistema inplementazioaren bigarren fasera igarotzen da.
Inplementazio-fasea eszenaratzeko ezarrita dago. Ez dugu zero geldialdi-denbora berrabiaraztea antolatu.
Edukiontzi guztiak indarrez itzaltzen ditugu, eta, ondoren, berriro altxatzen ditugu ontzi guztiak, saiakuntzan lehen fasean jasotakoak.
Gaur egungo ingurune-aldagairako garatzaileek idatzitako datu-baseen migrazioak exekutatzen ari gara.
Oharra dago hau maisu-adarrari bakarrik aplikatzen zaiola.
Beste adar batzuk aldatzean ez da exekutatzen.
Adarka antolatzea posible da.
Hau gehiago antolatzeko, Gitlab Runner instalatu behar dugu.
Erabilgarritasun hau Golang-en idatzita dago. Fitxategi bakarra da, Golang munduan ohikoa den bezala, eta horrek ez du inolako menpekotasunik behar.
Abiatzean, Gitlab Runner erregistratzen dugu.
Gakoa Gitlab web interfazean jasoko dugu.
Ondoren, hasierako komandoari komando lerroan deitzen diogu.
Konfiguratu Gitlab Runner modu interaktiboan (Shell, Docker, VirtualBox, SSH)
Gitlab Runner-en kodea konpromiso guztietan exekutatu egingo da, .gitlab-ci.yml ezarpenaren arabera.
Nola ikusten den Gitlab-en web interfazean. GItlab CI konektatu ondoren, momentuko eraikuntzaren egoera erakusten duen bandera dugu.
Duela 4 minutu konpromezu bat egin zela ikusten dugu, proba guztiak gainditu zituena eta ez zuen arazorik sortu.
Eraikuntzak hurbilagotik begiratu ditzakegu. Hemen ikusten dugu dagoeneko bi estatu pasatu direla. Proba-egoera eta inplementazio-egoera eszenaratzean.
Eraikitze zehatz batean klik egiten badugu, orduan prozesuan exekutatu ziren komandoen kontsolaren irteera egongo da .gitlab-ci.yml-ren arabera.
Hau da gure produktuen historiaren itxura. Saiakera arrakastatsuak izan zirela ikusten dugu. Probak bidaltzen direnean, ez da hurrengo urratsera jarraitzen eta eszenatze-kodea ez da eguneratzen.
Zer zeregin ebatzi genituen eszenaratzean docker ezarri genuenean? Gure sistema osagaiez osatuta dago eta berrabiarazi beharra izan genuen, biltegian eguneratuta zeuden osagaien zati bat bakarrik, eta ez sistema osoa.
Horretarako, dena karpeta bereizietan apurtu behar izan dugu.
Hau egin ondoren, arazo bat izan dugu Docker-compose-k bere sare-espazio propioa sortzen duela aita bakoitzarentzat eta ez ditu bizilagunaren osagaiak ikusten.
Mugitzeko, eskuz sortu dugu sarea Docker-en. Docker-compose-n idatzi zen proiektu honetarako halako sare bat erabiltzen duzula.
Horrela, sare honekin hasten den osagai bakoitzak sistemaren beste ataletako osagaiak ikusten ditu.
Hurrengo alea eszenaratzea hainbat proiektutan banatzea da.
Hau guztia polita eta ekoizpenetik ahalik eta gertuen izan dadin, ondo dago WEB-an nonahi erabiltzen den 80 edo 443 ataka erabiltzea.
Nola konpondu dugu? Gitlab Runner bat esleitu diegu proiektu nagusi guztiei.
Gitlab-ek banatutako hainbat Gitlab Runner exekutatzeko aukera ematen du, zeregin guztiak txandaka era kaotikoan hartu eta exekutatuko dituztenak.
Etxerik ez izateko, gure proiektuen taldea Gitlab Runner batera mugatu genuen, gure bolumenei arazorik gabe aurre egiten diona.
Nginx-proxy abioko script bereizi batera eraman genuen eta bertan dauden proiektu guztien saretak gehitu genituen.
Gure proiektuak sareta bat du, eta balantzaileak hainbat sareta ditu proiektuen izenen arabera. Domeinu-izenen bidez proxy gehiago egin dezake.
Gure eskaerak 80 atakako domeinutik datoz eta domeinu hau zerbitzatzen duen edukiontzi talde batean ebazten dira.
Zein beste arazo zeuden? Hau da edukiontzi guztiek root gisa exekutatzen dutena lehenespenez. Hau root sistemaren erro ostalariaren berdina da.
Hala ere, edukiontzian sartzen bazara, root izango da eta edukiontzi honetan sortzen dugun fitxategiak root eskubideak lortuko ditu.
Garatzaileak edukiontzian sartu eta fitxategiak sortzen dituzten komando batzuk egiten baditu, gero edukiontzia utzi badu, orduan fitxategi bat dauka bere laneko direktorioan sarbiderik ez duena.
Nola konpondu daiteke? Edukiontzian egongo diren erabiltzaileak gehi ditzakezu.
Zein arazo sortu ziren erabiltzailea gehitzean?
Erabiltzaile bat sortzean, askotan ez ditugu talde ID (UID) eta erabiltzaile ID (GID) berdinak.
Edukiontzian arazo hau konpontzeko, 1000 ID-a duten erabiltzaileak erabiltzen ditugu.
Gure kasuan, ia garatzaile guztiek Ubuntu OS erabiltzen dutenarekin bat etorri da. Eta Ubuntun, lehen erabiltzaileak 1000 ID bat du.
Ba al dugu planik?
Irakurri Docker-en dokumentazioa. Proiektua aktiboki garatzen ari da, dokumentazioa aldatzen ari da. Duela bizpahiru hilabete jaso ziren datuak jada zaharkitzen ari dira pixkanaka.
Ebatzi ditugun arazoetako batzuk, seguru asko, jada bide estandarren bidez konponduta daude.
Beraz, urrunago joan nahi dut jada orkestraziora zuzenean joateko.
Adibide bat Dockerren Docker Swarm izeneko mekanismo integratua da, kutxatik ateratzen dena. Docker Swarm teknologian oinarritutako ekoizpenean zerbait exekutatu nahi dut.
Erregistratzeko edukiontziak deserosoa egiten du erregistroekin lan egitea. Orain erregistroak isolatuta daude. Edukiontzietan zehar sakabanatuta daude. Zereginetako bat web interfazearen bidez erregistroetara sarbide egokia izatea da.
Iturria: www.habr.com