Ez pêşniyar dikim ku ji hêla Inventos ve ji hêla Alexander Sigachev ve ji "Pêvajoya Pêşveçûn û ceribandinê bi Docker + Gitlab CI" ve hatî nivîsandin bixwînin.
Yên ku nû dest bi pêkanîna pêvajoya pêşkeftin û ceribandinê li ser bingeha Docker + Gitlab CI dikin, pir caran pirsên bingehîn dipirsin. Li ku derê dest pê bikin? Meriv çawa organîze dike? Çawa ceribandinê?
Ev rapor baş e ji ber ku ew bi rengek rêkûpêk li ser pêvajoya pêşkeftin û ceribandinê bi karanîna Docker û Gitlab CI diaxive. Rapor bi xwe ji sala 2017’an e. Ez difikirim ku ji vê raporê hûn dikarin bingeh, rêbaz, raman, ezmûna karanîna fêr bibin.
Kî xem dike, kerem bike binê pisîkê.
Navê min Alexander Sigaçev e. Ez ji bo Inventos kar dikim. Ez ê ji we re qala ezmûna xwe ya karanîna Docker bikim û em çawa hêdî hêdî li ser projeyên di pargîdaniyê de bicîh dikin.
Mijara pêşkêşkirinê: Pêvajoya pêşkeftinê bi karanîna Docker û Gitlab CI.
Ev axaftina min a duyemîn e li ser Docker. Di dema rapora yekem de, me tenê Docker di Pêşkeftinê de li ser makîneyên pêşdebir bikar anî. Hejmara xebatkarên ku Docker bikar anîn nêzî 2-3 kes bû. Gav bi gav azmûn peyda bû û em hinekî pêş de çûn. Girêdana me .
Di vê raporê de dê çi hebe? Em ê serpêhatiya xwe li ser çi rage berhev kirine, me çi pirsgirêk çareser kirine parve bikin. Ne li her derê xweş bû, lê destûr dida ku bi pêş ve biçe.
Motoya me ev e: her tiştê ku em dikarin bigihîjin destên me bixin dorê.
Em çi pirsgirêkan çareser dikin?
Dema ku di pargîdaniyek de çend tîm hebin, bernamesaz çavkaniyek hevpar e. Qonax hene ku bernamesazek ji projeyekê tê derxistin û ji bo demekî dide projeyek din.
Ji bo ku bernamesaz zû fêm bike, pêdivî ye ku ew koda çavkaniyê ya projeyê dakêşîne û di zûtirîn dem de jîngehê bide destpêkirin, ku dê bihêle ku ew di çareserkirina pirsgirêkên vê projeyê de bêtir tevbigere.
Bi gelemperî, heke hûn ji sifirê dest pê bikin, wê hingê di projeyê de belgeyek hindik heye. Agahdariya li ser awayê sazkirinê tenê ji bo kevneperestan heye. Karmend di nava rojek-du rojan de cihê karê xwe bi tena serê xwe ava dikin. Ji bo lezkirina vê yekê, me Docker bikar anî.
Sedema din standardîzekirina mîhengan di Pêşkeftinê de ye. Di ezmûna min de, pêşdebir her gav pêşengiyê dikin. Di her rewşa pêncemîn de, domainek xwerû tê navnîş kirin, mînakî vasya.dev. Li kêleka wî cîranê wî Petya rûniştiye, domana wî petya.dev e. Ew malperek an hin pêkhateyek pergalê bi karanîna vê navê domainê pêşdixin.
Dema ku pergal mezin dibe û van navên domainê dest bi konfigurasyonan dikin, nakokîyek hawîrdora Pêşveçûnê çêdibe û riya malperê ji nû ve tê nivîsandin.
Heman tişt bi mîhengên databasê re dibe. Kesek ji ewlehiyê aciz nabe û bi şîfreyek root ya vala dixebite. Di qonaxa sazkirinê de, MySQL ji kesekî şîfreyek xwest û şîfre derket 123. Gelek caran diqewime ku konfigurasyona databasê li gorî peywira pêşdebiran bi berdewamî diguhere. Kesek rast kir, yekî konfigurasyon rast nekir. Gava ku me cûreyek konfigurasyona testê derxist holê, hîle hebûn .gitignore û her pêşdebir neçar bû ku databasê saz bike. Vê yekê dest pê kir dijwar bû. Di nav tiştên din de, pêdivî ye ku meriv li ser databasê bîr bîne. Divê databas were destpêkirin, şîfreyek were nivîsandin, bikarhênerek were qeyd kirin, tabloyek were çêkirin û hwd.
Pirsgirêkek din guhertoyên cûda yên pirtûkxaneyan e. Pir caran diqewime ku pêşdebirek bi projeyên cûda re dixebite. Projeyek Legacy heye ku pênc sal berê dest pê kir (ji 2017 - ed. note). Di dema destpêkirinê de, me bi MySQL 5.5 dest pê kir. Di heman demê de projeyên nûjen jî hene ku em hewl didin ku guhertoyên nûjentir ên MySQL bicîh bikin, mînakî, 5.7 an kevntir (di 2017 de - ed. note)
Her kesê ku bi MySQL-ê re dixebite dizane ku ev pirtûkxane bi wan re girêdayîne. Rêvekirina 2 baregehan bi hev re pir pirsgirêk e. Bi kêmanî, xerîdarên kevn ji bo girêdana bi databasa nû re pirsgirêk in. Ev jî di encamê de gelek pirsgirêkan derdixe holê.
Pirsgirêka din ev e ku gava pêşdebirek li ser makîneyek herêmî dixebite, ew çavkaniyên herêmî, pelên herêmî, RAM-a herêmî bikar tîne. Hemî danûstendina di dema pêşdebirina çareseriya pirsgirêkan de di çarçoveya rastiya ku ew li ser yek makîneyê dixebite pêk tê. Mînakek ev e ku di Hilberîna 3-ê de serverên me yên paşdemayî hene, û pêşdebir pelan li pelrêça root hildide û ji wir nginx pelan digire da ku bersivê bide daxwazê. Dema ku kodek wusa dikeve Hilberînê, derdikeve holê ku pel li ser yek ji 3 pêşkêşkeran heye.
Arasteya mîkroxizmet niha pêş dikeve. Dema ku em serîlêdanên xwe yên mezin li hin beşên piçûk ên ku bi hevûdu re têkilî dikin dabeş dikin. Ev dihêle hûn teknolojiyên ji bo komek taybetî ya peywiran hilbijêrin. Ew jî dihêle hûn di navbera pêşdebiran de kar û berpirsiyariyan parve bikin.
Frondend-developer, ku li ser JS pêşve diçe, hema hema ti bandorek li ser Backend-ê tune. Pêşdebirê paşîn, di dorê de, di doza me de, Ruby on Rails pêş dixe û bi Frondend re destwerdanê nake. Têkilî bi karanîna API-ê tête kirin.
Wekî bonus, bi alîkariya Docker, me karî çavkaniyên li ser Staging ji nû ve vegerînin. Her proje, ji ber taybetmendiyên xwe, hewceyê hin mîhengan bû. Ji hêla fizîkî ve, pêdivî bû ku an serverek virtual were veqetandin û wan ji hev veqetînin, an jî celebek hawîrdorek guhêrbar parve bikin û proje, li gorî guhertoya pirtûkxaneyan, dikarin li ser hev bandor bikin.
Amûrên. Em çi bikar tînin?
- Docker bixwe. Dockerfile girêdayîbûna serîlêdanek yekane diyar dike.
- Docker-compose pêlekek e ku çend serîlêdanên me yên Docker tîne cem hev.
- Em GitLab bikar tînin ku koda çavkaniyê hilînin.
- Em ji bo yekbûna pergalê GitLab-CI bikar tînin.
Rapor ji du beşan pêk tê.
Beşa yekem dê li ser ka çawa Docker li ser makîneyên pêşdebiran hate xebitandin biaxive.
Di beşa duyemîn de dê biaxive ka meriv çawa bi GitLab re têkilî daynin, em çawa ceribandinan dimeşînin û em çawa digihîjin Staging.
Docker teknolojiyek e ku destûrê dide (bikaranîna nêzîkatiyek daxuyandî) ku hêmanên pêwîst diyar bike. Ev mînakek Dockerfile ye. Li vir em eşkere dikin ku em ji wêneya fermî Ruby: 2.3.0 Docker mîras digirin. Ew guhertoya Ruby 2.3 sazkirî ye. Em pirtûkxaneyên avakirina pêwîst û NodeJS saz dikin. Em diyar dikin ku em pelrêçek çêbikin /app. Peldanka sepanê wekî pelrêça xebatê saz bikin. Di vê pelrêçê de em Gemfile û Gemfile.lock hindiktirîn hewcedar cîh dikin. Dûv re em projeyên ku vê wêneya girêdayîbûnê saz dikin ava dikin. Em destnîşan dikin ku konteynir dê amade be ku li porta derveyî 3000 guhdarî bike. Fermana paşîn fermana ku rasterast serlêdana me dide destpêkirin. Ger em fermana destpêkirina projeyê bicîh bînin, serîlêdan dê hewl bide ku emrê diyarkirî bimeşîne û bixebite.
Ev mînakek hindiktirîn a pelê docker-compose ye. Di vê rewşê de, em destnîşan dikin ku di navbera du konteyneran de têkiliyek heye. Ev rasterast di nav karûbarê databasê û karûbarê malperê de ye. Serlêdanên meya webê di pir rewşan de ji bo hilanîna daneyan wekî paşverûyek databasê hewce dike. Ji ber ku em MySQL bikar tînin, mînakek bi MySQL re ye - lê tiştek me nahêle ku em databasek din bikar bînin (PostgreSQL, Redis).
Em ji çavkaniya fermî ya ji hub Docker wêneya MySQL 5.7.14 bêyî guhertin digirin. Em wêneya ku ji serîlêdana meya webê berpirsiyar e ji pelrêça heyî berhev dikin. Ew di dema destpêkirina yekem de ji me re wêneyek berhev dike. Dûv re ew fermana ku em li vir bicîh dikin dimeşîne. Ger em vegerin, em ê bibînin ku fermana destpêkirinê bi rêya Puma ve hatî destnîşan kirin. Puma karûbarek e ku bi Ruby hatî nivîsandin. Di rewşa duyemîn de, em bi ser dikevin. Ev ferman li gorî hewcedarî an peywirên me dikare kêfî be.
Em her weha diyar dikin ku pêdivî ye ku em portek li ser makîneya xweya mêvandar a pêşdebiran ji 3000 heya 3000 li ser porta konteynerê bişînin. Ev bixweber bi karanîna iptables û mekanîzmaya wê, ku rasterast di Docker-ê de tête bicîh kirin, tête kirin.
Pêşvebir her weha dikare, wekî berê, bigihîje her navnîşana IP-ya berdest, mînakî, 127.0.0.1 navnîşana IP-ya herêmî an derveyî ya makîneyê ye.
Rêza paşîn dibêje ku konteynera tevneyê bi konteynera db ve girêdayî ye. Dema ku em banga destpêkirina konteynera malperê dikin, docker-compose dê pêşî ji me re databasê dest pê bike. Jixwe di destpêka databasê de (bi rastî, piştî destpêkirina konteynerê! Ev amadebûna databasê garantî nake) dê serîlêdanê, paşiya me dest pê bike.
Dema ku databas neyê hilanîn ev ji xeletiyan dûr dikeve û dema ku em konteynera databasê rawestînin çavkaniyan hilîne, bi vî rengî çavkaniyên ji bo projeyên din azad dike.
Ya ku li ser projeyê karanîna dokerkirina databasê dide me. Em guhertoya MySQL ji bo hemî pêşdebiran rast dikin. Ev yek ji hin xeletiyên ku dibe ku dema ku guhertoyên ji hev cihê dibin, dema ku hevoksazî, veavakirin, mîhengên xwerû diguhezin, çêdibin. Ev dihêle hûn ji bo databas, têketin, şîfreyê navek mêvandarek hevpar diyar bikin. Em ji zozana nav û nakokiyên pelên mîhengê yên ku me berê hebûn dûr dikevin.
Derfeta me heye ku em ji bo hawîrdora Pêşveçûnê konfigurasyonek çêtirîn bikar bînin, ku dê ji xwerû cûda bibe. MySQL ji hêla xwerû ve ji bo makîneyên qels ve hatî mîheng kirin û performansa wê ya derveyî pir qels e.
Docker dihêle hûn Python, Ruby, NodeJS, PHP wergêrê guhertoya xwestinê bikar bînin. Em ji hewcedariya karanîna celebek rêveberê guhertoyê xilas dibin. Berê, Ruby pakêtek rpm bikar anî ku destûrê dide we ku hûn guhertoya li gorî projeyê biguhezînin. Di heman demê de ew dihêle, bi saya konteynera Docker, ku kodê bi rêkûpêk veguhezîne û bi pêwendiyan re biguherîne. Pirsgirêka me ji famkirina guhertoya hem wergêr û hem jî kodê tune. Ji bo nûvekirina guhertoyê, konteynera kevn kêm bikin û konteynera nû bilind bikin. Ger tiştek xelet bû, em dikarin konteynera nû dakêşin, konteynera kevin rakin.
Piştî avakirina wêneyê, konteynir hem di Pêşkeftin û hem jî Hilberîn dê yek bin. Ev bi taybetî ji bo sazkirinên mezin rast e.
Li ser Frontend em JavaScipt û NodeJS bikar tînin.
Naha me projeya paşîn li ser ReacJS heye. Pêşdebir her tiştî di konteynerê de rijand û bi karanîna nûvekirina germ pêşxist.
Dûv re, peywira meclîsa JavaScipt tê dest pê kirin û koda ku di statîkan de hatî berhev kirin bi çavkaniyên hilanînê nginx ve tê dayîn.
Li vir min nexşeya projeya xwe ya dawîn da.
Çi kar hatin çareserkirin? Pêwîstiya me hebû ku em pergalek ku amûrên mobîl pê re têkiliyek çêbikin ava bikin. Ew daneyan distînin. Yek îmkan ev e ku ji vê cîhazê re agahdariya push bişînin.
Me ji bo vê çi kiriye?
Me di serîlêdanê de hêmanên weha dabeş kir: beşa rêveberê li ser JS, paşverû, ku bi navgîniya REST-ê di binê Ruby on Rails de dixebite. Piştgir bi databasê re têkilî dike. Encama ku tê çêkirin ji xerîdar re tê dayîn. Panela rêveberiyê bi navgîniya REST-ê bi paşverû û databasê re têkilî dike.
Pêdiviya me bi şandina notifications jî hebû. Beriya wê, projeyek me hebû ku mekanîzmayek ku berpirsiyar e gihandina ragihandinan ji platformên mobîl re bicîh kir.
Me pilana jêrîn pêşxistiye: operatorek ji gerokê bi panela rêveberê re têkildar dibe, panela rêveberiyê bi paşverû re têkildar dibe, peywir şandina agahdariya Push e.
Daxuyanên Push bi pêkhateyek din a ku di NodeJS-ê de hatî bicîh kirin re têkilî daynin.
Doz têne çêkirin û piştre li gorî mekanîzmaya wan agahdarî têne şandin.
Li vir du databas têne kişandin. Heya nuha, bi alîkariya Docker, em 2 databasên serbixwe ku bi ti awayî bi hev re ne têkildar bikar tînin. Wekî din, wan xwedan torgilokek virtual ya hevpar in, û daneyên laşî di pelrêçên cihêreng de li ser makîneya pêşdebiran têne hilanîn.
Heman tişt lê bi hejmaran. Li vir ji nû ve karanîna kodê girîng e.
Ger berê me qala ji nû ve karanîna kodê di forma pirtûkxaneyan de kir, wê hingê di vê nimûneyê de karûbarê me ya ku bersivê dide agahdariya Push wekî serverek bêkêmasî ji nû ve tê bikar anîn. Ew API-ê peyda dike. Û pêşkeftina meya nû jixwe pê re têkildar e.
Wê demê, me guhertoya 4 ya NodeJS bikar anî. Naha (di 2017 de - ed. note) di pêşkeftinên dawî de em guhertoya 7 ya NodeJS bikar tînin. Di pêkhateyên nû de pirsgirêk tune ku guhertoyên nû yên pirtûkxaneyan tevlê bibin.
Ger hewce be, hûn dikarin guhertoya NodeJS ji karûbarê ragihandina Push-ê ji nû ve saz bikin û bilind bikin.
Û heger em dikarin lihevhatina API-ê biparêzin, wê hingê dê gengaz be ku wê bi projeyên din ên ku berê hatine bikar anîn veguhezînin.
Ma hûn çi hewce dikin ku Docker lê zêde bikin? Em Dockerfile li depoya xwe zêde dikin, ku pêwendiyên pêwîst diyar dike. Di vê nimûneyê de, pêkhate bi awayekî mentiqî têne parçe kirin. Ev komek herî kêm a pêşdebirek paşverû ye.
Dema ku projeyek nû diafirînin, em Dockerfile diafirînin, ekosîstema xwestinê vedibêjin (Python, Ruby, NodeJS). Di docker-compose de, ew pêwendiya pêwîst - databasê diyar dike. Em diyar dikin ku ji me re databasek guhertoyek wusa û wusa hewce ye, daneyan li wir û li wir hilînin.
Em bi nginx konteynirek sêyemîn a cihêreng bikar tînin da ku statîk xizmet bikin. Barkirina wêneyan gengaz e. Backend wan dixe nav cildek pêş-amadekirî, ku di heman demê de di konteynirek bi nginx de hatî danîn, ku statîkê dide.
Ji bo hilanîna nginx, veavakirina mysql, me peldankek Docker lê zêde kir ku tê de em konfigurasyonên pêwîst hilînin. Dema ku pêşdebirek git klonek depoyek li ser makîneya xwe dike, ew jixwe projeyek ji bo pêşkeftina herêmî amade ye. Pirs tune ku kîjan port an kîjan mîhengan bicîh bikin.
Dûv re, çend hêmanên me hene: rêveber, agahdar-API, notifications push.
Ji bo ku em van hemî dest pê bikin, me depoyek din çêkir, ku me jê re digotin dockerized-app. Vê gavê em berî her pêkhateyê çend depoyan bikar tînin. Ew tenê bi mantiqî cûda ne - di GitLab de ew mîna peldankek xuya dike, lê li ser makîneya pêşdebiran, peldankek ji bo projeyek taybetî ye. Yek astek jêrîn pêkhateyên ku dê bêne hev kirin hene.
Ev mînakek tenê naveroka dockerized-app e. Di heman demê de em pelrêça Docker jî tînin vir, ku tê de em mîhengên ku ji bo danûstendinên hemî pêkhateyan hewce ne tije dikin. README.md heye ku bi kurtî diyar dike ka meriv çawa projeyê dimeşîne.
Li vir me du pelên docker-compose sepandine. Ev yek ji bo ku bikaribe bi gavan bimeşe tê kirin. Dema ku pêşdebirek bi bingehîn re dixebite, ew ne hewce ye ku agahdariya push-ê, ew tenê pelek docker-compose dide destpêkirin û, li gorî vê yekê, çavkanî tê hilanîn.
Ger hewceyê yekbûna bi notifications push hebe, wê hingê docker-compose.yaml û docker-compose-push.yaml têne destpêkirin.
Ji ber ku docker-compose.yaml û docker-compose-push.yaml di peldankekê de ne, torgilokek virtual bixweber tê afirandin.
Danasîna pêkhateyan. Ev pelek pêşkeftî ye ku ji berhevkirina pêkhateyan berpirsiyar e. Li vir çi balkêş e? Li vir em pêkhateya balanserê destnîşan dikin.
Ev wêneyek Docker-a amade ye ku nginx dimeşîne û serîlêdanek ku li soketa Docker guhdarî dike. Dînamîk, ji ber ku konteynir têne zivirandin û girtin, ew veavakirina nginx ji nû ve çêdike. Em hilgirtina pêkhateyan bi navên domaina asta sêyemîn belav dikin.
Ji bo hawîrdora Pêşveçûnê, em domaina .dev - api.informer.dev bikar tînin. Serlêdanên bi domainek .dev li ser makîneya herêmî ya pêşdebiran hene.
Zêdetir, mîheng li her projeyê têne veguheztin û hemî proje di heman demê de bi hev re têne destpêkirin.
Ji hêla grafîkî ve, derdikeve holê ku xerîdar geroka me ye an hin amûrek e ku em pê re daxwazan ji balanserê dikin.
Balansa navê domainê diyar dike ku bi kîjan konteynerê re têkilî daynin.
Ew dikare nginx be, ku rêveberê JS dide. Ev dikare bibe nginx, ku API-ê dide, an pelên statîk, ku di forma barkirina wêneyan de ji nginx re têne dayîn.
Diagram destnîşan dike ku konteynir bi torgilokek virtual ve girêdayî ne û li pişt proxy veşartiye.
Li ser makîneya pêşdebirker, hûn dikarin bi IP-yê dizanin xwe bigihînin konteynerê, lê di prensîbê de em vê yekê bikar naynin. Di pratîkê de hewcedariya gihîştina rasterast tune.
Kîjan nimûne ku meriv lê binêre da ku serîlêdana xwe doker bike? Bi dîtina min, mînakek baş ji bo MySQL wêneya dokera fermî ye.
Ew pir dijwar e. Gelek versiyonên hene. Lê fonksiyona wê dihêle hûn gelek hewcedariyên ku dibe ku di pêvajoya pêşkeftina bêtir de çêbibin veşêrin. Ger hûn wextê xwe derbas bikin û fêm bikin ka ew hemî çawa tevdigere, wê hingê ez difikirim ku hûn ê di xwe-pêkanînê de pirsgirêk tune bin.
Hub.docker.com bi gelemperî girêdanên github.com-ê vedihewîne, ku rasterast daneyên xav vedihewîne ku hûn dikarin bi xwe wêneyê jê ava bikin.
Zêdetir di vê depoyê de skrîptek docker-endpoint.sh heye, ku ji destpêkirina destpêkê û ji bo pêvajoyek din a destpêkirina serîlêdanê berpirsiyar e.
Di vê nimûneyê de jî, şiyana mîhengkirina bi karanîna guhêrbarên jîngehê heye. Bi danasîna guhêrbarek jîngehê dema ku konteynirek yekane dimeşîne an bi navgîniya docker-compose ve, em dikarin bibêjin ku pêdivî ye ku em şîfreyek vala saz bikin ku docker li ser MySQL an tiştê ku em dixwazin root bikin.
Vebijarkek ji bo afirandina şîfreyek rasthatî heye. Em dibêjin ku ji me re bikarhênerek pêdivî ye, pêdivî ye ku em ji bikarhêner re şîfreyek saz bikin, û pêdivî ye ku em databasek çêbikin.
Di projeyên xwe de, me hinekî Dockerfile, ku berpirsiyarê destpêkirinê ye, yek kir. Li wir me ew li gorî hewcedariyên xwe rast kir da ku ew tenê dirêjkirina mafên bikarhêner ên ku serîlêdan bikar tîne bikin. Vê yekê hişt ku em paşê paşê ji konsolê serîlêdanê databasek biafirînin. Serîlêdanên Ruby fermanek ji bo afirandina, guheztin û jêbirina databasan heye.
Ev mînakek e ku guhertoyek taybetî ya MySQL li ser github.com çawa xuya dike. Hûn dikarin Dockerfile vekin û bibînin ka sazkirinê li wir çawa diçe.
docker-endpoint.sh skrîpta ku ji xala têketinê berpirsiyar e. Di dema destpêkirina destpêkê de, hin gavên amadekariyê hewce ne, û van hemî kiryaran tenê di skrîpta destpêkê de têne derxistin.
Ka em derbasî beşa duyemîn bibin.
Ji bo hilanîna kodên çavkaniyê, me veguherî gitlab. Ev pergalek pir hêzdar e ku têkiliyek dîtbar heye.
Yek ji pêkhateyên Gitlab Gitlab CI ye. Ew dihêle hûn rêzek fermanan diyar bikin ku dê paşê were bikar anîn da ku pergalek radestkirina kodê organîze bike an ceribandina otomatîkî bimeşîne.
Gitlab CI 2 axaftin - Rapora ji klûba Ruby Russia - pir berfireh û dibe ku ew ê we eleqedar bike.
Naha em ê li tiştên ku ji bo çalakkirina Gitlab CI hewce ne binihêrin. Ji bo ku em Gitlab CI-ê dest pê bikin, tenê hewce ye ku em pelê .gitlab-ci.yml têxin nav koka projeyê.
Li vir em rave dikin ku em dixwazin rêzek dewletan wekî ceribandinek, bicîh bikin.
Em skrîptên ku rasterast gazî docker-compose dikin da ku serlêdana xwe ava bikin. Ev tenê mînakek paşde ye.
Dûv re, em dibêjin ku ji bo guhertina databasê û meşandina ceribandinan pêdivî ye ku koçberan bimeşînin.
Ger skrîpt rast werin darve kirin û kodek xeletiyek venegere, wê hingê pergal berbi qonaxa duyemîn a bicîhkirinê ve diçe.
Qonaxa şandinê niha ji bo qonaxkirinê tê pêkanîn. Me ji nû ve destpêkirina dema sifirê organîze nekir.
Em hemî konteyneran bi zorê ditemirînin, û dûv re em hemî konteyneran, ku di qonaxa yekem de di dema ceribandinê de hatine berhev kirin, dîsa bilind dikin.
Em ji bo guhêrbara jîngehê ya heyî koçên databasê yên ku ji hêla pêşdebiran ve hatine nivîsandin dimeşînin.
Têbînî heye ku ev tenê ji bo şaxa masterê derbas dibe.
Dema guhertina şaxên din nayên darvekirin.
Mimkûn e ku ji hêla şaxan ve veqetandî were organîzekirin.
Ji bo organîzekirina vê bêtir, divê em Gitlab Runner saz bikin.
Ev karûbar bi Golang hatiye nivîsandin. Ew pelek yekane ye, wekî ku di cîhana Golang de hevpar e, ku pêwendiyek hewce nake.
Di destpêkê de, em Gitlab Runner qeyd dikin.
Em mifteyê di navgîniya tevna Gitlab de digirin.
Dûv re em gazî fermana destpêkêkirinê li ser rêza fermanê dikin.
Gitlab Runner bi înteraktîf saz bikin (Shell, Docker, VirtualBox, SSH)
Koda li ser Gitlab Runner dê li ser her commit-ê, li gorî mîhengê .gitlab-ci.yml were bicîh kirin.
Çawa ew di navgîniya malperê de li Gitlab bi dîtbarî xuya dike. Piştî ku me GItlab CI ve girêda, me alayek heye ku rewşa avahîsaziyê ya niha nîşan dide.
Em dibînin ku berî 4 hûrdeman peymanek hate çêkirin, ku hemî ceribandinan derbas kir û tu pirsgirêk derneket.
Em dikarin ji nêz ve li avahiyan binêrin. Li vir em dibînin ku du dewlet berê derbas bûne. Rewşa ceribandinê û statûya bicîhkirinê li ser qonaxê.
Ger em li ser avahiyek taybetî bikirtînin, wê hingê dê encamek konsolê ya fermanên ku di pêvajoyê de li gorî .gitlab-ci.yml hatine xebitandin hebe.
Dîroka hilberê me bi vî rengî xuya dike. Em dibînin ku hewldanên serkeftî hene. Dema ku ceribandin têne şandin, ew berbi qonaxa paşîn naçe û koda qonaxê nayê nûve kirin.
Dema ku me docker bicîh anî me çi peywir li ser sehneyê çareser kir? Pergala me ji pêkhateyan pêk tê û hewcedariya me hebû ku em ji nû ve bidin destpêkirin, tenê beşek ji pêkhateyên ku di depoyê de hatine nûve kirin, û ne tevahiya pergalê.
Ji bo vê yekê, me neçar ma ku her tiştî di peldankên cihêreng de bihejînin.
Piştî ku me ev kir, me pirsgirêkek bi vê yekê re hebû ku Docker-compose ji bo her bavekî cîhê torê xwe diafirîne û pêkhateyên cîran nabîne.
Ji bo ku em li dora xwe bigerin, me tora li Docker bi destan çêkir. Di Docker-compose de hate nivîsandin ku hûn ji bo vê projeyê torgilokek wusa bikar tînin.
Ji ber vê yekê, her pêkhateya ku bi vê tevnvîsê dest pê dike, pêkhateyên di beşên din ên pergalê de dibîne.
Pirsgirêka din dabeşkirina qonaxa li ser pir projeyan e.
Ji ber ku ji bo ku ev hemî xweşik xuya bike û bi qasî ku gengaz nêzî hilberînê bibe, baş e ku meriv porta 80 an 443-ê bikar bîne, ku li her derê WEB-ê tê bikar anîn.
Me çawa çareser kir? Me yek Gitlab Runner ji hemî projeyên mezin re destnîşan kiriye.
Gitlab dihêle hûn çend Runnerên Gitlab-ê yên belavkirî bimeşînin, ku dê bi hêsanî hemî peywiran bi rengek kaotîk bigire û wan bimeşîne.
Ji ber ku xaniyek me tune, me koma projeyên xwe bi yek Gitlab Runner ve sînordar kir, ku bêyî pirsgirêk bi cildên me re mijûl dibe.
Me nginx-proxy veguhezand nav skrîptek destpêkek cihêreng û ji bo hemî projeyên tê de torên lê zêde kirin.
Projeya me yek şebek heye, û balanser jî bi navên projeyê çend şebek hene. Ew dikare bi navên domainê bêtir proxy bike.
Daxwazên me di nav domaina li porta 80-ê de têne û di nav komek konteynerê de ku ji vê domainê re xizmet dike têne çareser kirin.
Çi pirsgirêkên din hebûn? Ya ku hemî konteynir ji hêla xwerû ve wekî root dimeşin ev e. Ev root ji hosteya root ya pergalê re newekhev e.
Lêbelê, heke hûn têkevin konteynerê, ew ê root be û pelê ku em di vê konteynerê de çêdikin mafên root digire.
Ger pêşdebir bikeve konteynerê û li wir hin fermanên ku pelan çêdikin kir, dûv re ji konteynerê derket, wê hingê di pelrêça wî ya xebatê de pelek heye ku gihîştina wî tune.
Çawa dikare çareser bibe? Hûn dikarin bikarhênerên ku dê di konteynerê de bin lê zêde bikin.
Dema ku me bikarhêner lê zêde kir çi pirsgirêk derketin?
Dema ku bikarhênerek diafirîne, em bi gelemperî nasnameya komê (UID) û nasnameya bikarhêner (GID) tune.
Ji bo çareserkirina vê pirsgirêkê di konteynerê de, em bikarhênerên bi ID 1000 bikar tînin.
Di doza me de, ev yek bi rastiya ku hema hema hemî pêşdebiran Ubuntu OS-ê bikar tînin re hevaheng bû. Û li ser Ubuntu, bikarhênerê yekem nasnameya 1000 heye.
Ma planên me hene?
Belgeya Docker bixwînin. Proje bi rengek çalak pêş dikeve, belge diguhere. Daneyên ku du sê meh berê hatine wergirtin hêdî hêdî kevnar dibin.
Hin pirsgirêkên ku me çareser kirin, dibe ku jixwe bi rêyên standard çareser bibin.
Ji ber vê yekê ez dixwazim pêştir biçim û rasterast biçim orkestrasyonê.
Mînakek mekanîzmaya çêkirî ya Docker-ê ya bi navê Docker Swarm e, ku ji qutikê derdikeve. Ez dixwazim di hilberînê de li ser bingeha teknolojiya Docker Swarm tiştek bimeşînim.
Kêlkirina konteyniran nerehetiyê dike ku bi têketin re bixebite. Niha têketin hatine îzolekirin. Ew li konteyneran belav dibin. Yek ji peywiran ev e ku meriv bi navgîniya tevnvîsê re gihîştina têketinê hêsan bike.
Source: www.habr.com