Ju ftoj të shqyrtoni interpretimin e paraqitjes së Aleksandër Sigachev nga Inventos "Procesi i zhvillimit dhe testimit me Docker + Gitlab CI"
Ata që sapo kanë filluar të zbatojnë procesin e zhvillimit dhe testimit mbi bazën e Docker + Gitlab CI shpesh bëjnë pyetje themelore. Nga të fillosh? Si të organizosh? Si të testohet?
Ky raport është i mirë sepse tregon në mënyrë të strukturuar procesin e zhvillimit dhe testimit duke përdorur Docker dhe Gitlab CI. Raporti vetë është nga viti 2017. Mendoj se nga ky raport mund të nxirren baza, metodologji, ide dhe përvojë përdorimi.
Kush është interesuar, lutem shihni më poshtë.
Më quaj Aleksandër Sigachev. Punoj në kompaninë Inventos. Do flas për përvojën time të përdorimit të Docker dhe se si e implementojmë ngadalë në projektet e kompanisë.
Tema e raportit: Procesi i zhvillimit duke përdorur Docker dhe Gitlab CI.
Ky është raporti im i dytë për Docker. Në momentin e raportit të parë, ne e përdornim Docker vetëm në Zhvillim në makinat e zhvilluesve. Numri i punonjësve që e përdornin Docker ishte rreth 2-3 persona. Gradualisht u grumbullua përvojë dhe ne shkuam pak më përpara. Linku në .
Çfarë do të përmbajë ky raport? Ne do të ndajmë përvojën tonë mbi pengesat që hasëm dhe si i zgjodhëm ato. Nuk ishte gjithmonë e këndshme, por na ndihmoi të shkojmë përpara.
Sllogani ynë: dockerizo gjithçka që arrin në duar tona.
Cilat probleme adresojmë?
Kur ka disa ekipe në kompani, programuesi bëhet një burim i ndarë. Ka etapa kur programuesi merret nga një projekt dhe i jepet për një kohë në një projekt tjetër.
Për të kuptuar shpejt, programuesi duhet të shkarkojë kodin burimor të projektit dhe ta nisë sa më shpejt ambientin që do t’i lejojë të avancojë në zgjidhjen e detyrave të këtij projekti.
Në përgjithësi, kur starton nga zero, dokumentacioni në projekt është i kufizuar. Informacioni mbi konfigurimin është i disponueshëm vetëm te të vjetrit. Punonjësit zakonisht rregullojnë vendin e tyre të punës brenda një ose dy ditësh. Për ta përshpejtuar këtë, ne përdorëm Docker.
Arsyeja tjetër është standardizimi i konfigurimeve në Development. Sipas përvojës time, zhvilluesit gjithmonë tregojnë iniciativë. Në çdo rast të pestë, një domain i personalizuar, si p.sh. vasya.dev, përfshihet. I uluri afër është fqinji Petja, që ka domenin petya.dev. Ata po zhvillojnë një faqe ose ndonjë komponent të sistemit duke përdorur këtë emër domeni.
Kur sistemi zgjeron dhe këto emra domeni fillojnë të përfshihen në konfigurime, atëherë ndodhin konflikte të ambientit Development dhe rruga e faqes rikriptohet.
E njëjta gjë ndodh edhe me konfigurimet e bazës së të dhënave. Disa nuk shqetësohen për sigurinë dhe punojnë me një fjalëkalim të zbrazët root. Disa të tjerë, gjatë instalimit, MySQL ka kërkuar një fjalëkalim dhe fjalëkalimi ka qenë një 123. Ndodhin shpesh raste kur konfigurimi i bazës së të dhënave ndryshonte vazhdimisht në varësi të commit-it të zhvilluesit. Disa e korrigjuan, disa nuk e korrigjuan konfigurimin. Kishin pasur shkollime kur e nxirrnim ndonjë konfigurim provues në .gitignore çdo zhvillues duhet të vendosë bazën e të dhënave. Kjo e komplikon procesin e fillimit. Përveç të gjitha, duhet të mbani mend për bazën e të dhënave. Duhet të inicializoni bazën e të dhënave, të shkruani fjalëkalimin, të krijoni përdoruesin, të krijoni tabelat dhe kështu me radhë.
Një tjetër problem është versionet e ndryshme të librarive. Shpesh ndodhi që zhvilluesi punon me projekte të ndryshme. Ka projekte Legacy, që filluan pesë vjet më parë (nga viti 2017 — shënim redaktor). Në momentin e fillimit, filluam me MySQL 5.5. Ka dhe projekte moderne ku përpiqemi të implementojmë versionet më të reja të MySQL, për shembull 5.7 ose më të reja (në vitin 2017 — shënim redaktor).
Ajo që punon me MySQL e di se këto biblioteka sjellin varësi. Është mjaft problematike të nisim 2 baza njëkohësisht. Së paku, është problematike të lidhen klientët e vjetër me bazën e të dhënave të re. Kjo shpërndan njëkohësisht disa probleme.
Problemi i ardhshëm është kur zhvilluesi punon në makinën lokale, ai përdor burime lokale, skedarë lokalë, RAM lokal. Të gjitha ndërveprimet në momentin e zhvillimit të zgjidhjeve bëhen brenda kuptimit se kjo funksionon në një makinë. Një shembull mund të jetë kur kemi 3 serverë backend në Production, dhe zhvilluesi ruan skedarët në katalogun rrënjësor dhe nga aty nginx merr skedarët për t'u përgjigjur kërkesave. Kur ky kod arrin në Production, rezulton se skedari është prezent në njërin nga 3 serverët.
Aktualisht, po zhvillohet drejtimi i mikroshërbimeve. Kur i ndajmë aplikacionet tona të mëdha në disa komponentë të vegjël që ndërveprojnë me njëri-tjetrin. Kjo lejon që për çdo grup specifik detyrash të zgjidhen teknologjitë e duhura. Gjithashtu, kjo ndihmon në ndarjen e punës dhe zonës së përgjegjësisë midis zhvilluesve.
Zhvilluesi Frondend, duke zhvilluar me JS, praktikisht nuk ndikon në Backend. Zhvilluesi Backend, nga ana tjetër, zhvillon, në rastin tonë, me Ruby on Rails dhe nuk e pengon Frondend-in. Ndërveprimi bëhet nëpërmjet API-së.
Si bonus, me ndihmën e Docker arritëm të shfrytëzojmë burimet në Staging. Çdo projekt, për shkak të specifikës së tij, kërkonte konfigurime të caktuara. Fizikisht, duhej të ndaheshim ose me nga një server virtual dhe t'i konfiguroni ato veç e veç, ose të ndanim ndonjë ambient variabli dhe projektet mund të ndikonin njëra-tjetrën në varësi të versioneve të bibliotekave.
Mjetet. Çfarë përdorim?
- Pikërisht vetë Docker. Në Dockerfile përshkruhen varësitë e një aplikacioni.
- Docker-compose është lidhja që bashkon disa nga aplikacionet tona Docker.
- Përdorim GitLab për ruajtjen e kodit burimor.
- Përdorim GitLab-CI për integrimin sistemor.
Raporti përbëhet nga dy pjesë.
Pjesa e parë do t'i tregojë sesi e kemi nisur Docker në makinat e zhvilluesve.
Pjesa e dytë do të tregojë sesi bashkëpunojmë me GitLab, si i aktivizojmë testet dhe si i deploy-ojmë në Staging.
Docker është një teknologji që lejon (duke përdorur një qasje deklarative) përshkrimin e komponentëve të nevojshëm. Ky është një shembull i Dockerfile. Këtu shpallim se trashëgojmë nga imazhi zyrtar Docker i Ruby:2.3.0. Ai përmban Ruby versioni 2.3. Ne instalojmë bibliotekat e nevojshme për ndërtim dhe NodeJS. Përcaktojmë se po krijojmë një katalog /app. Caktojmë katalogun app si direktorinë e punës. Në këtë katalog vendosim Gemfile minimale dhe Gemfile.lock të nevojshme. Pastaj kryejmë ndërtimin e projekteve që instalojnë këtë imazh varësitë. Tregon se kontejneri do të jetë gati të dëgjojë në portin e jashtëm 3000. Komanda e fundit është komanda që drejtpërdrejt nis aplikacionin tonë. Nëse ekzekutojmë komandanë për nisjen e projektit, aplikacioni do të përpiqet të ekzekutojë dhe do të nisë komandën e caktuar.
Ky është një shembull minimal i një skedari docker-compose. Këtu tregojmë se si ndodhet lidhja mes dy kontejnerëve, konkretisht shërbimi i bazës së të dhënave dhe shërbimi web. Aplikacionet tona web, në shumicën e rasteve, kërkojnë një bazë të dhënash për të ruajtur të dhënat si backend. Duke marrë parasysh se po përdorim MySQL, shembulli i MySQL është i tillë — por asgjë nuk na pengon të përdorim një bazë të dhënash tjetër (PostgreSQL, Redis).
Ne marrim imazhin e MySQL 5.7.14 nga burimi zyrtar në Docker Hub pa modifikime. Imazhi që përfaqëson aplikacionin tonë web e ndërtuam nga direktorja aktuale. Në momentin e parë të nisjes, ai ndërtuan imazhin për ne. Pas kësaj, ekzekuton komandën që kemi këtu. Nëse kthehemi mbrapa, do të shohim se ishte caktuar një komandë fillestare përmes Puma. Puma është një shërbim i shkruar në Ruby. Në rastin e dytë, ne e ridefinojmë. Kjo komandë mund të jetë arbitrare, në varësi të nevojave ose detyrave tona.
Gjithashtu, ne përcaktojmë se duhet të kalojmë portin në makinën tonë zhvilluesi nga 3000 në portin 3000 të kontejnerit. Kjo zbatohet automatikisht përmes iptables dhe mekanizmit të vetë, që është inkorporuar direkt në Docker.
Zhvilluesi mund të drejtohet si më parë në çdo adresë IP të disponueshme, për shembull, 127.0.0.1, IP lokal ose IP të jashtëm të makinës.
Rreshti i fundit thotë se kontejneri web varet nga kontejneri db. Kur aktivizojmë lancimin e kontejnerit web, docker-compose do të aktivizojë bazën e të dhënave. Pas fillimit të bazës së të dhënave (realmente — pas aktivizimit të kontejnerit! Gatishmëria e BDs nuk është e garantuar) do të aktivizohet aplikacioni ynë, backend-i ynë.
Kjo shmang gabimet kur baza e të dhënave nuk është ngritur dhe ndihmon në ruajtjen e burimeve kur ndalim kontejnerin e bazës së të dhënave, duke liruar kështu burimet për projekte të tjera.
Çfarë na ofron përdorimi i dockerizimit të bazës së të dhënave në projekt. Ne dokumentojmë versionin e MySQL për të gjithë zhvilluesit. Kjo ndihmon në shmangien e disa gabimeve që mund të ndodhin kur ndodhin diferenca versionesh, kur ndryshon sintaksa, konfigurimi, cilësimet e përpamta. Kjo lejon të shkruhen hostname të zakonshëm për bazën e të dhënave, emrin e përdoruesit, fjalëkalimin. Shkëputemi nga ai kaos emrash dhe konflikteve në skedarët config që ishin më parë.
Ne kemi mundësinë të përdorim një konfigurim më optimal për mjedisin e Zhvillimit, i cili do të ndryshojë nga ai default. MySQL, në mënyrë të parazgjedhur, është i optimizuar për makina të dobëta dhe performanca e tij është shumë e ulët nga kutia.
Docker lejon përdorimin e interpreterëve Python, Ruby, NodeJS, PHP në versionin e nevojshëm. Kështu shmangim nevojën për të përdorur një menaxher versioni. Më parë, për Ruby përdornim një paketë rpm që lejonte ndërrimin e versioneve në varësi të projektit. Gjithashtu, kjo lejon migrimin e qetë të kodit dhe versionimin e tij së bashku me varësitë përmes kontejnerit Docker. Nuk kemi asnjë problem për të kuptuar versionin e interpreterit dhe të kodit. Për të përditësuar versionin, është e nevojshme të ulet kontejneri i vjetër dhe të ngrihet një kontejner i ri. Nëse diçka shkon keq, mund të ulim kontejnerin e ri dhe të ngremë kontejnerin e vjetër.
Pas ndërtimit të imazhit, kontejnerët si në Zhvillim ashtu edhe në Prodhim do të jenë identikë. Kjo është veçanërisht relevante për instalimet e mëdha.
Në Frontend përdorim JavaScript dhe NodeJS.
Projektin e fundit e kemi në ReactJS. Zhvilluesi nisi të gjitha kontejnerët dhe punoi duke përdorur hot-reload.
Më pas niset detyra për ndërtimin e JavaScript dhe kodi, i ndërtuar në statikë, dorëzohet përmes nginx për të kursyer burimet.
Këtu kam sjellë skemën e projektit tonë më të fundit.
Çfarë detyrash zgjidhëm? Kemi pasur nevojë të ndërtojmë një sistem që bashkëvepron me pajisjet mobile. Ato marrin të dhëna. Një nga mundësitë është dërgimi i njoftimeve push në këtë pajisje.
Çfarë bëmë për këtë?
Ne e ndamë aplikacionin në komponentë si: pjesa administrative në JS, backend-i, i cili funksionon përmes një ndërfaqe REST nën Ruby on Rails. Backend-i bashkëvepron me bazën e të dhënave. Rezultati, që gjenerohet, dorëzohet te klienti. Pjesa administrative bashkëvepron me backend-in dhe bazën e të dhënave përmes ndërfaqes REST.
Në të njëjtën kohë, kishim nevojë të dërgonim njoftime Push. Para kësaj, kishim një projekt në të cilin ishte realizuar mekanizmi që merrej me dorëzimin e njoftimeve në platformat mobile.
Ne zhvilluam këtë skemë: operatori nga shfletuesi bashkëvepron me pjesën administrative, pjesa administrative bashkëvepron me backend-in, vendoset detyra për të dërguar njoftime Push.
Njoftimet Push bashkëveprojnë me një komponent tjetër, i cili është realizuar në NodeJS.
Krijohen radhë dhe më pas vazhdon mekanizmi i dërgimit të njoftimeve.
Këtu janë ilustruar dy baza të dhënash. Aktualisht, ne po përdorim 2 baza të dhënash të pavarura me ndihmën e Docker, të cilat nuk janë aspak të lidhura me njëra-tjetrën. Përveç faktit që ato ndajnë një rrjet virtual të përbashkët, të dhënat fisnike ruhen në kataloge të ndryshme në makinën e zhvilluesit.
E njëjta gjë por në numra. Këtu është e rëndësishme ripërdorimi i kodit.
Nëse më parë kemi folur për ripërdorimin e kodit në formën e bibliotekave, në këtë shembull shërbimi ynë që merret me njoftimet Push, ripërdoret si një server i plotë. Ai ofron një API. Dhe për këtë ndërvepron zhvillimi ynë i ri.
Në atë kohë ne po përdornim versionin 4 të NodeJS. Tani (në vitin 2017 — shënim i redaktorit) në zhvillimet e reja po përdorim versionin 7 të NodeJS. Nuk ka probleme në komponentët e rinj për të tërhequr versionet e reja të bibliotekave.
Nëse është e nevojshme, mund të kryhet një riorganizim dhe të rritet versioni i NodeJS për shërbimin e njoftimeve Push.
Dhe nëse ne mund të ruajmë përputhshmërinë për API-në, atëherë mund ta zëvendësojmë atë në projekte të tjera që janë përdorur më parë.
Çfarë nevojitet për të shtuar Docker? Shtojmë në depozitën tonë Dockerfile, i cili përshkruan varësitë e nevojshme. Në këtë shembull, komponentet janë të ndara sipas logjikës. Ky është një grup minimal për zhvilluesin e backend-it.
Kur krijojmë një projekt të ri, krijojmë Dockerfile, përshkruajmë ekosistemin e nevojshëm (Python, Ruby, NodeJS). Në docker-compose përshkruhet varësia e nevojshme — baza e të dhënave. Përcaktojmë se na nevojitet një bazë në këtë version, duke ruajtur të dhënat aty ku duhet.
Ne përdorim një kontejner të tretë për shërbimin e skedarëve statikë me nginx. Është parashikuar mundësia e ngarkimit të imazheve. Backend-i i vendos ato në një vëllim të përgatitur paraprakisht, i cili gjithashtu është montuar në kontejnerin me nginx që ofron skedarët statikë.
Për të ruajtur konfigurimin e nginx dhe mysql, ne kemi shtuar një dosje Docker, ku ruajmë konfigurimet e nevojshme. Kur zhvilluesi bën git clone të depozitës në makinën e tij, ai merr një projekt tashmë të gatshëm për zhvillim lokal. Nuk lind pyetja se cili port ose cilat cilësime duhet të aplikohen.
Më tej, kemi disa komponentë: administratori, inform-API, njoftime push.
Për të nisur të gjitha këto, krijuam një depo të re, të quajtur dockerized-app. Aktualisht, ne përdorim disa depove për çdo komponent. Ato ndahen logjikisht — në GitLab duket si një dosje, ndërsa në makinën e zhvilluesit, është një dosje për projektin përkatës. Nën këtë nivel ndodhen komponentët që do të kombinohen.
Ky është një shembull i përmbajtjes së dockerized-app. Ne po ashtu e nxjerrim këtu katalogun Docker, ku plotësojmë konfigurimet e nevojshme për bashkëveprimin e të gjithë komponentëve. Ka një README.md, ku përshkruhet shkurtimisht si të nisni projektin.
Këtu kemi aplikuar dy skedarë docker-compose. Kjo është bërë për të pasur mundësinë për ta nisur hap pas hapi. Kur zhvilluesi punon me kernin, nuk i nevojiten njoftimet Push, kështu që ai thjesht nis skedarin docker-compose dhe për këtë arsye ekonomizohet burimi.
Nëse ka nevojë për integrim me njoftimet Push, atëherë aktivizohet docker-compose.yaml dhe docker-compose-push.yaml.
Duke qenë se docker-compose.yaml dhe docker-compose-push.yaml ndodhen në të njëjtën dosje, krijohet automatikisht një rrjet virtual i vetëm.
Përshkrimi i komponenteve. Ky është një skedar më i gjerë që përgjigjet për grumbullimin e komponentëve. Çfarë është e veçantë këtu? Këtu ne prezantojmë komponentin balancer.
Ky është një imazh Docker i gatshëm, në të cilin funksionon nginx dhe një aplikacion që dëgjon socket-in e Docker-it. Ai rigjeneron konfigurimin e nginx-it dinamikisht, ndërsa konteinerët aktivizohen dhe deaktivizohen. Trajtimi me komponentët shpërndahet sipas emrave të domain-ëve të tretë.
Për mjedisin e zhvillimit përdorim domain-in .dev — api.informer.dev. Aplikacionet me domain .dev janë të arritshme në kompjuterin lokal të zhvilluesit.
Më pas konfigurimet kalojnë në çdo projekt dhe të gjithë projektet запускаются në të njëjtën kohë.
Nëse e paraqesim grafisht, klienti është shfletuesi ynë ose ndonjë mjet, me të cilin ne kryejmë kërkesa në balancer.
Balancer-i, nëpërmjet emrit të domain-it, përcakton në cilin konteiner duhet të i drejtohemi.
Kjo mund të jetë nginx, që ofron JS të panelit administrativ. Mund të jetë gjithashtu nginx, që ofron API ose skedarë statikë, që dorëzohen nga nginx në formën e ngarkesave të imazheve.
Në diagram, shihet se konteinerët janë të bashkuar në një rrjet virtual dhe janë të fshehur pas një proxy.
Në makinën e zhvilluesit, mund të qaseni në kontejner duke ditur IP-në, por ne në parim nuk e përdorim këtë. Praktikisht nuk ka nevojë për qasje të drejtpërdrejtë.
Cila është një shembull që mund të shikoni për të dockerizuar aplikacionin tuaj? Për mendimin tim, një shembull i mirë është imazhi zyrtar docker për MySQL.
Ai është mjaft kompleks. Ka shumë versione. Por funksionaliteti i tij lejon të përmbushë një gamë të gjerë nevojash që mund të lindin gjatë zhvillimit të mëtejshëm. Nëse shkoni pak më thellë dhe kuptoni se si ndërveprojnë të gjitha këto, mendoj se nuk do të keni probleme me implementimin e pavarur.
Në hub.docker.com zakonisht ka lidhje me github.com, ku jepen të dhënat e papërpunuara nga të cilat mund të krijoni vetë imazhin.
Më pas, në këtë depo ka skripti docker-endpoint.sh, i cili përgjigjet për inicializimin e parë dhe për trajtimin e mëtejshëm të fillimit të aplikacionit.
Në këtë shembull gjithashtu ka mundësinë e konfigurimit nëpërmjet variablave të mjedisit. Duke përcaktuar një variabël mjedisi gjatë nisjes së një konteineri të vetme ose përmes docker-compose, mund të themi se na nevojitet të përcaktojmë një fjalëkalim bosh për docker për root në MySQL, ose ndonjë fjalëkalim tjetër që dëshirojmë.
Ka mundësinë të krijojmë një fjalëkalim rastësor. Ne themi se na nevojitet një përdorues, na nevojitet të vendosim një fjalëkalim për përdoruesin dhe na nevojitet të krijojmë një bazë të dhënash.
Në projektet tona kemi pak unifikuar Dockerfile-in që përgjigjet për inicializimin. Aty e kemi përmirësuar për nevojat tona duke bërë thjesht zgjerimin e të drejtave të përdoruesit që aplikacioni përdor. Kjo na lejoi më pas të krijonim lehtësisht një bazë të dhënash nga konsola e aplikacionit. Në aplikacionet Ruby ka një komandë për krijimin, ndryshimin dhe fshirjen e bazave të dhënash.
Ky është një shembull se si duket një version konkret i MySQL në github.com. Dockerfile-i mund të hapet dhe të shikohet se si ndodh instalimi atje.
docker-endpoint.sh është skripti që menaxhon pikën e hyrjes. Në fillim, disa veprime përgatitore janë të nevojshme, dhe të gjitha këto veprime janë përfshirë në skriptin e inicializimit.
Të kalojmë në pjesën e dytë.
Për ruajtjen e kodit burimor, kemi kaluar në gitlab. Kjo është një sistem mjaft i fuqishëm, i cili ka një интерфейс vizual.
Një nga komponentët e Gitlab është Gitlab CI. Ai lejon përshkrimin e një rendi komandash, të cilat do të përdoren për të organizuar sistemin e dorëzimit të kodit ose për të nisur testimin automatike.
Raporti mbi Gitlab CI 2 — një raport nga Ruby Russia club — është mjaft i detajuar dhe ndoshta do t'ju интересojë.
Tani do të shqyrtojmë se çfarë kërkohet për të aktivizuar Gitlab CI. Për të nisur Gitlab CI, mjafton të vendosim skedarin .gitlab-ci.yml në rrënjën e projektit.
Këtu përshkruajmë se çfarë dëshirojmë të ekzekutojmë si një sekuencë gjendjesh, si teste ose implementime.
Ekzekutojmë skriptet që thërrasin në mënyrë direkte ndërtimin e aplikacionit tonë me docker-compose. Ky është një shembull për backend.
Më pas, ne themi se është e nevojshme të përfundojmë migrimet për ndryshimin e bazës së të dhënave dhe të përfundojmë testet.
Nëse skriptet ekzekutohen siç duhet dhe nuk kthejnë një kod gabimi, sistemi kalon në fazën e dytë të publikuar.
Faza e publikuar është realizuar aktualisht për stagim. Nuk kemi organizuar një rinisje pa ndërprerje.
Ne mbyllim detyrimisht të gjithë kontejnerët dhe pastaj i ngremë përsëri të gjithë kontejnerët, të ndërtuar në fazën e parë gjatë testimit.
Kryejmë migrimet e bazave të të dhënave për mjedisin e tanishëm, të shkruara nga zhvilluesit.
Ka një shënim që kjo të aplikohet vetëm për degën master.
Nuk kryhet me ndryshime në degët e tjera.
Ka mundësi për të organizuar publikime sipas degëve.
Për të organizuar më tej këtë, ne duhet të instalojmë Gitlab Runner.
Kjo utilit është e shkruar në Golang. Ajo është një skedar i vetëm siç është e zakonshme në botën e Golang, i cili nuk kërkon asnjë varësi.
Kur e aktivizojmë, regjistrojmë Gitlab Runner.
Marrim një çelës në ndërfaqen web të Gitlab.
Pastaj thërrasim komandën e inicializimit në linjën e komandës.
Konfigurojmë Gitlab Runner në modin e dialogut (Shell, Docker, VirtualBox, SSH).
Kodi në Gitlab Runner do të ekzekutohet me çdo komitim, në varësi të konfigurimit .gitlab-ci.yml.
Si duket kjo në GitLab në ndërfaqen e web-it. Pas lidhjes së GitLab CI, shfaqet një flamur që tregon në cilin gjendje ndodhet ndërtimi aktualisht.
Duke parë, shohim se para 4 minutash është bërë një commit që kaloi të gjitha testet dhe nuk bëri probleme.
Mund të shohim më në detaje për ndërtimet. Këtu shohim se janë kaluar dy gjendje. Gjendja e testimit dhe gjendja e deploy-it në staging.
Nëse klikojmë në një ndërtim të veçantë, atje do të ketë daljen e komandave që u ekzekutuan në proces sipas .gitlab-ci.yml.
Kështu duket historia e produktit tonë. Shohim që ka pasur përpjekje të suksesshme. Kur testet dështojnë, ato nuk kalojnë në hapin tjetër dhe kodi në staging nuk azhurnohet.
Cilat probleme zgjidhëm në staging kur implementuam docker? Sistema jonë përbëhet nga komponente të ndryshme dhe kishim nevojë të rinisnim vetëm disa nga komponentet që ishin azhurnuar në repositorin, jo të gjithë sistemin.
Për këtë na duhej të ndanim gjithçka në dosje të veçanta.
Pas pas këtij hapi, hasëm një problem sepse Docker-compose krijon një hapësirë rrjeti për çdo dosje dhe nuk sheh komponentët e fqinjit.
Për ta anashkaluar këtë, krijuam një rrjet në Docker manualisht. Në Docker-compose shkruam se për këtë projekt duhet të përdorë një rrjet të tillë.
Kështu, çdo komponent që fillon me këtë rrjet sheh komponentët në pjesë të tjera të sistemit.
Problemi tjetër është ndarja staging mes disa projekteve.
Për të bërë që gjithçka të duket bukur dhe sa më afër production, është mirë të përdoret porta 80 ose 443, të cilat përdoren gjerësisht në WEB.
Si e zgjidhëm këtë? E caktuam një Gitlab Runner për të gjithë projektet e mëdha.
Gitlab lejon të drejtohen disa Gitlab Runner të shpërndara, të cilat thjesht do të marrin të gjitha detyrat në rend të rastësishëm.
Për të shmangur çdo shkak që do të krijonte kaos, e limituam grupin tonë të projekteve me një Gitlab Runner, i cili me volumet tona funksionon pa probleme.
E nxorëm nginx-proxy në një skrypt të veçantë fillimi dhe aty shënuam rrjetet e të gjitha projekteve.
Projekti ynë ka një rrjet të vet, ndërsa balanceri ka disa rrjete sipas emrave të projekteve. Ai mund të prokurojë më tej sipas emrave të domeve.
Kërkesat tona vijnë përmes domenit në portin 80 dhe menaxhohen në një grup kontejnerash, të cilët shërbejnë këtë domen.
Cilat ishin problemet e tjera? Kjo është ajo që sipas default, të gjithë kontejnerët ekzekutohen nga përdoruesi root. Ky root nuk është i njëjtë me root-in e sistemit.
Megjithatë, nëse hyni në kontejner, atëherë do të jeni root dhe dosja që krijojmë në këtë kontejner merr të drejta root.
Nëse një zhvillues hyn në kontejner dhe ekzekuton disa komanda që gjenerojnë skedarë, pastaj del nga kontejneri, ai në direktorinë e tij të punës ka një skedar, të cilin nuk ka akses.
Si mund ta zgjidhim këtë? Mund të shtojmë përdorues që do të jenë në kontejner.
Cilat probleme u shfaqën kur shtuam përdoruesin?
Kur krijojmë një përdorues, shpesh nuk përputhen ID-të e grupit (UID) dhe ID-të e përdoruesit (GID).
Për të zgjidhur këtë problem, në kontejner përdorim përdorues me ID 1000.
Në rastin tonë, kjo përputhet me faktin se pothuajse të gjithë zhvilluesit përdorin sistemin operativ Ubuntu. Në Ubuntu, përdoruesi i parë ka ID 1000.
Cilat janë planet tona?
Të rilexojmë dokumentacionin për Docker. Projekti po zhvillohet aktivisht, dokumentacioni po ndryshon. Të dhënat që janë marrë dy-tre muaj më parë, tashmë po skadojnë ngadalë.
Disa nga problemet që kemi zgjidhur, shumë mund të jenë zgjidhur tashmë me mjete standarde.
Dëshira është të kalojmë më tej dhe të kalojmë drejtpërdrejt në orkestrimin.
Një nga shembujt është mekanizmi i ndërtuar brenda Docker, i quajtur Docker Swarm, që vjen gatishëm. Dëshirojmë të drejtojmë diçka në prodhim duke përdorur teknologjinë Docker Swarm.
Krijimi i kontejnerëve e bën të vështirë punën me loget. Tani loget janë të izoluar. Ato janë të përhapura nëpër kontejnerë. Një nga detyrat është të sigurojmë akses të lehtë në loget përmes një ndërfaqeje web.
Burimi: habr.com
