Unë propozoj të lexoni transkriptin e raportit të Alexander Sigachev nga Inventos "Procesi i zhvillimit dhe testimit me Docker + Gitlab CI"
Ata që sapo kanë filluar të zbatojnë procesin e zhvillimit dhe testimit bazuar në Docker + Gitlab CI shpesh bëjnë pyetje themelore. Ku të fillojë? Si të organizoni? Si të testoni?
Ky raport është i mirë sepse flet në mënyrë të strukturuar për procesin e zhvillimit dhe testimit duke përdorur Docker dhe Gitlab CI. Vetë raporti është i vitit 2017. Mendoj se nga ky raport mund të mësoni bazat, metodologjinë, idenë, përvojën e përdorimit.
Kush kujdeset, ju lutem nën mace.
Emri im është Aleksandër Sigaçev. Unë punoj për Inventos. Unë do t'ju tregoj për përvojën time të përdorimit të Docker dhe se si po e zbatojmë gradualisht në projekte në kompani.
Tema e prezantimit: Procesi i zhvillimit duke përdorur Docker dhe Gitlab CI.
Ky është biseda ime e dytë për Docker. Në kohën e raportit të parë, ne përdorëm vetëm Docker in Development në makinat e zhvilluesve. Numri i punonjësve që përdorën Docker ishte rreth 2-3 persona. Gradualisht, u fitua përvoja dhe ne u larguam pak më tej. Lidhje me tonën .
Çfarë do të jetë në këtë raport? Ne do të ndajmë përvojën tonë në lidhje me atë që kemi mbledhur, çfarë problemesh kemi zgjidhur. Jo kudo ishte e bukur, por lejohej të vazhdonte më tej.
Motoja jonë është: lidhni gjithçka që na vjen në dorë.
Çfarë problemesh po zgjidhim?
Kur ka disa ekipe në një kompani, programuesi është një burim i përbashkët. Ka faza kur një programues tërhiqet nga një projekt dhe i jepet për ca kohë një projekti tjetër.
Në mënyrë që programuesi të kuptojë shpejt, ai duhet të shkarkojë kodin burimor të projektit dhe të nisë mjedisin sa më shpejt të jetë e mundur, gjë që do t'i lejojë atij të lëvizë më tej duke zgjidhur problemet e këtij projekti.
Zakonisht, nëse filloni nga e para, atëherë ka pak dokumentacion në projekt. Informacioni se si të konfigurohet është i disponueshëm vetëm për personat e vjetër. Punonjësit e vendosin vetë 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 cilësimeve në Zhvillim. Në përvojën time, zhvilluesit marrin gjithmonë iniciativën. Në çdo rast të pestë, futet një domen me porosi, për shembull, vasya.dev. I ulur pranë tij është fqinji i tij Petya, domeni i të cilit është petya.dev. Ata zhvillojnë një faqe interneti ose disa komponentë të sistemit duke përdorur këtë emër domain.
Kur sistemi rritet dhe këta emra domenesh fillojnë të futen në konfigurime, lind një konflikt i mjedisit të zhvillimit dhe shtegu i faqes rishkruhet.
E njëjta gjë ndodh me cilësimet e bazës së të dhënave. Dikush nuk shqetësohet me sigurinë dhe punon me një fjalëkalim bosh root. Në fazën e instalimit, MySQL i kërkoi dikujt një fjalëkalim dhe fjalëkalimi doli të ishte 123. Shpesh ndodh që konfigurimi i bazës së të dhënave ndryshon vazhdimisht në varësi të angazhimit të zhvilluesit. Dikush korrigjoi, dikush nuk korrigjoi konfigurimin. Kishte truke kur nxorëm një lloj konfigurimi testues .gitignore dhe secili zhvillues duhej të instalonte bazën e të dhënave. Kjo e bëri të vështirë fillimin. Është e nevojshme, ndër të tjera, të mbani mend për bazën e të dhënave. Baza e të dhënave duhet të inicializohet, duhet të futet një fjalëkalim, duhet të regjistrohet një përdorues, duhet të krijohet një tabelë etj.
Një problem tjetër janë versionet e ndryshme të bibliotekave. Shpesh ndodh që një zhvillues të punojë me projekte të ndryshme. Ekziston një projekt "Trashëgimia" që filloi pesë vjet më parë (nga 2017 - red. shënim). Në kohën e nisjes, ne filluam me MySQL 5.5. Ka edhe projekte moderne ku ne përpiqemi të zbatojmë versione më moderne të MySQL, për shembull, 5.7 ose më të vjetra (në 2017 - shënim red.)
Kushdo që punon me MySQL e di se këto biblioteka sjellin varësi me to. Është mjaft problematike të ekzekutohen 2 baza së bashku. Të paktën, klientët e vjetër janë problematikë për t'u lidhur me bazën e re të të dhënave. Kjo nga ana tjetër krijon disa probleme.
Problemi tjetër është kur një zhvillues punon në një makinë lokale, ai përdor burime lokale, skedarë lokalë, RAM lokale. I gjithë ndërveprimi në kohën e zhvillimit të një zgjidhjeje për problemet kryhet në kuadrin e faktit se funksionon në një makinë. Një shembull është kur kemi serverë backend në Production 3, dhe zhvilluesi ruan skedarët në direktoriumin rrënjë dhe prej andej nginx merr skedarë për t'iu përgjigjur kërkesës. Kur një kod i tillë futet në Production, rezulton se skedari është i pranishëm në një nga 3 serverët.
Drejtimi i mikroshërbimeve po zhvillohet tani. Kur i ndajmë aplikacionet tona të mëdha në disa komponentë të vegjël që ndërveprojnë me njëri-tjetrin. Kjo ju lejon të zgjidhni teknologjitë për një grumbull të caktuar detyrash. Gjithashtu ju lejon të ndani punën dhe përgjegjësitë midis zhvilluesve.
Zhvilluesi i Frondend, që po zhvillohet në JS, nuk ka pothuajse asnjë ndikim në Backend. Zhvilluesi i backend-it, nga ana tjetër, zhvillon, në rastin tonë, Ruby on Rails dhe nuk ndërhyn me Frondend. Ndërveprimi kryhet duke përdorur API.
Si bonus, me ndihmën e Docker, ne ishim në gjendje të riciklojmë burimet në Staging. Çdo projekt, për shkak të specifikave të tij, kërkonte cilësime të caktuara. Fizikisht, ishte e nevojshme të ndahej ose një server virtual dhe t'i konfigurohej veçmas, ose të ndahej një lloj mjedisi i ndryshueshëm dhe projektet, në varësi të versionit të bibliotekave, mund të ndikonin njëri-tjetrin.
Mjetet. Çfarë përdorim?
- Docker vetë. Dockerfile përshkruan varësitë e një aplikacioni të vetëm.
- Docker-compose është një paketë që bashkon disa nga aplikacionet tona Docker.
- Ne përdorim GitLab për të ruajtur kodin burimor.
- Ne përdorim GitLab-CI për integrimin e sistemit.
Raporti përbëhet nga dy pjesë.
Pjesa e parë do të flasë për mënyrën se si u ekzekutua Docker në makinat e zhvilluesve.
Pjesa e dytë do të flasë për mënyrën se si të ndërveprojmë me GitLab, si i ekzekutojmë testet dhe si do të kalojmë në Staging.
Docker është një teknologji që lejon (duke përdorur një qasje deklarative) për të përshkruar komponentët e nevojshëm. Ky është një shembull Dockerfile. Këtu ne deklarojmë se po trashëgojmë nga imazhi zyrtar i Ruby:2.3.0 Docker. Ai përmban të instaluar versionin Ruby 2.3. Ne instalojmë bibliotekat e nevojshme të ndërtimit dhe NodeJS. Ne përshkruajmë se kemi krijuar një direktori /app. Vendosni direktorinë e aplikacionit si drejtorinë e punës. Në këtë direktori vendosim Gemfile minimale të kërkuar dhe Gemfile.lock. Më pas ndërtojmë projektet që instalojnë këtë imazh të varësisë. Ne tregojmë se kontejneri do të jetë gati për të dëgjuar në portin e jashtëm 3000. Komanda e fundit është komanda që lëshon drejtpërdrejt aplikacionin tonë. Nëse ekzekutojmë komandën e fillimit të projektit, aplikacioni do të përpiqet të ekzekutojë dhe ekzekutojë komandën e specifikuar.
Ky është një shembull minimal i një skedari docker-compose. Në këtë rast, tregojmë se ekziston një lidhje midis dy kontejnerëve. Kjo është drejtpërdrejt në shërbimin e bazës së të dhënave dhe në shërbimin e internetit. Aplikacionet tona në ueb në shumicën e rasteve kërkojnë një lloj bazë të dhënash si një backend për ruajtjen e të dhënave. Meqenëse ne përdorim MySQL, shembulli është me MySQL - por asgjë nuk na pengon të përdorim ndonjë bazë të dhënash tjetër (PostgreSQL, Redis).
Ne marrim nga burimi zyrtar nga qendra Docker imazhin e MySQL 5.7.14 pa ndryshime. Ne mbledhim imazhin që është përgjegjës për aplikacionin tonë në ueb nga direktoria aktuale. Ai mbledh një imazh për ne gjatë lëshimit të parë. Pastaj ekzekuton komandën që po ekzekutojmë këtu. Nëse kthehemi pas, do të shohim se komanda e nisjes nëpërmjet Puma është përcaktuar. Puma është një shërbim i shkruar në Ruby. Në rastin e dytë, ne anashkalojmë. Kjo komandë mund të jetë arbitrare në varësi të nevojave ose detyrave tona.
Ne përshkruajmë gjithashtu se duhet të përcjellim një port në makinën tonë pritës të zhvilluesit nga 3000 në 3000 në portin e kontejnerit. Kjo bëhet automatikisht duke përdorur iptables dhe mekanizmin e tij, i cili është i ngulitur drejtpërdrejt në Docker.
Zhvilluesi gjithashtu, si më parë, mund të hyjë në çdo adresë IP të disponueshme, për shembull, 127.0.0.1 është adresa IP lokale ose e jashtme e makinës.
Rreshti i fundit thotë se kontejneri i uebit varet nga kontejneri db. Kur thërrasim fillimin e kontejnerit të uebit, docker-compose së pari do të nisë bazën e të dhënave për ne. Tashmë në fillim të bazës së të dhënave (në fakt, pas lëshimit të kontejnerit! Kjo nuk garanton gatishmërinë e bazës së të dhënave) do të nisë aplikacioni, backend-i ynë.
Kjo shmang gabimet kur baza e të dhënave nuk shfaqet dhe kursen burimet kur ndalojmë kontejnerin e bazës së të dhënave, duke liruar kështu burimet për projekte të tjera.
Çfarë na jep përdorimin e dokerizimit të bazës së të dhënave në projekt. Ne rregullojmë versionin e MySQL për të gjithë zhvilluesit. Kjo shmang disa gabime që mund të ndodhin kur versionet ndryshojnë, kur sintaksa, konfigurimi, cilësimet e paracaktuar ndryshojnë. Kjo ju lejon të specifikoni një emër të përbashkët pritës për bazën e të dhënave, hyrjen, fjalëkalimin. Ne po largohemi nga kopshti zoologjik i emrave dhe konflikteve në skedarët e konfigurimit që kishim më parë.
Ne kemi mundësinë të përdorim një konfigurim më optimal për mjedisin e Zhvillimit, i cili do të ndryshojë nga standardi. MySQL është konfiguruar për makineri të dobëta si parazgjedhje dhe performanca e tij jashtë kutisë është shumë e dobët.
Docker ju lejon të përdorni interpretuesin Python, Ruby, NodeJS, PHP të versionit të dëshiruar. Ne heqim qafe nevojën për të përdorur një lloj menaxheri të versionit. Më parë, Ruby përdori një paketë rpm që ju lejonte të ndryshoni versionin në varësi të projektit. Ai gjithashtu lejon, falë kontejnerit Docker, të migrojë pa probleme kodin dhe ta versionojë atë së bashku me varësitë. Nuk kemi asnjë problem të kuptojmë versionin e interpretuesit dhe kodit. Për të përditësuar versionin, ulni kontejnerin e vjetër dhe ngrini enën e re. Nëse diçka shkoi keq, ne mund ta ulim enën e re, ta ngremë enën e vjetër.
Pas ndërtimit të imazhit, kontejnerët si në Zhvillim ashtu edhe në Prodhim do të jenë të njëjta. Kjo është veçanërisht e vërtetë për instalimet e mëdha.
Në Frontend ne përdorim JavaScipt dhe NodeJS.
Tani kemi projektin e fundit në ReacJS. Zhvilluesi ekzekutoi gjithçka në kontejner dhe u zhvillua duke përdorur rifreskimin e nxehtë.
Më pas, hapet detyra e montimit JavaScipt dhe kodi i përpiluar në statikë jepet përmes burimeve të kursimit të nginx.
Këtu kam dhënë skemën e projektit tonë të fundit.
Cilat detyra u zgjidhën? Kishim nevojë të ndërtonim një sistem me të cilin ndërveprojnë pajisjet celulare. Ata marrin të dhëna. Një mundësi është të dërgoni njoftime push në këtë pajisje.
Çfarë kemi bërë për këtë?
Ne kemi ndarë në aplikacion komponentë të tillë si: pjesa e administratorit në JS, backend, i cili funksionon përmes ndërfaqes REST nën Ruby on Rails. Backend-i ndërvepron me bazën e të dhënave. Rezultati që gjenerohet i jepet klientit. Paneli i administratorit ndërvepron me backend-in dhe bazën e të dhënave nëpërmjet ndërfaqes REST.
Ne kishim gjithashtu nevojë për të dërguar njoftime push. Para kësaj, ne kishim një projekt që zbatoi një mekanizëm që është përgjegjës për dërgimin e njoftimeve në platformat celulare.
Ne kemi zhvilluar skemën e mëposhtme: një operator nga shfletuesi ndërvepron me panelin e administratorit, paneli i administratorit ndërvepron me prapavijën, detyra është të dërgoni njoftime Push.
Njoftimet Push ndërveprojnë me një komponent tjetër që zbatohet në NodeJS.
Ndërtohen radhët dhe më pas dërgohen njoftimet sipas mekanizmit të tyre.
Këtu janë tërhequr dy baza të dhënash. Për momentin, me ndihmën e Docker, ne përdorim 2 baza të dhënash të pavarura që nuk kanë asnjë lidhje me njëra-tjetrën. Përveç kësaj, ata kanë një rrjet të përbashkët virtual dhe të dhënat fizike ruhen në drejtori të ndryshme në makinën e zhvilluesit.
E njëjta gjë, por në numër. Këtu është i rëndësishëm ripërdorimi i kodit.
Nëse më parë folëm për ripërdorimin e kodit në formën e bibliotekave, atëherë në këtë shembull, shërbimi ynë që i përgjigjet njoftimeve Push ripërdoret si një server i plotë. Ai siguron një API. Dhe zhvillimi ynë i ri tashmë ndërvepron me të.
Në atë kohë, ne përdornim versionin 4 të NodeJS. Tani (në vitin 2017 - shënim red.) në zhvillimet e fundit ne përdorim versionin 7 të NodeJS. Nuk ka asnjë problem në komponentët e rinj për të përfshirë versionet e reja të bibliotekave.
Nëse është e nevojshme, mund të rifaktoroni dhe ngrini versionin NodeJS nga shërbimi i njoftimit Push.
Dhe nëse mund të ruajmë pajtueshmërinë API, atëherë do të jetë e mundur ta zëvendësojmë atë me projekte të tjera që janë përdorur më parë.
Çfarë ju nevojitet për të shtuar Docker? Ne shtojmë një Dockerfile në depon tonë, i cili përshkruan varësitë e nevojshme. Në këtë shembull, komponentët ndahen logjikisht. Ky është grupi minimal i një zhvilluesi mbështetës.
Kur krijojmë një projekt të ri, ne krijojmë një Dockerfile, përshkruajmë ekosistemin e dëshiruar (Python, Ruby, NodeJS). Në docker-compose, ai përshkruan varësinë e nevojshme - bazën e të dhënave. Ne përshkruajmë se kemi nevojë për një bazë të dhënash të një versioni të tillë dhe të tillë, të ruajmë të dhënat atje dhe atje.
Ne përdorim një enë të tretë të veçantë me nginx për të shërbyer statike. Është e mundur të ngarkoni foto. Backend i vendos ato në një vëllim të përgatitur paraprakisht, i cili gjithashtu montohet në një enë me nginx, i cili jep staticitetin.
Për të ruajtur konfigurimin nginx, mysql, shtuam një dosje Docker në të cilën ruajmë konfigurimet e nevojshme. Kur një zhvillues bën një klon git të një depoje në kompjuterin e tij, ai tashmë ka një projekt gati për zhvillim lokal. Nuk ka dyshim se çfarë porti ose çfarë cilësimesh duhet të aplikoni.
Tjetra, ne kemi disa komponentë: admin, inform-API, njoftime shtytëse.
Për të filluar të gjitha këto, ne krijuam një depo tjetër, të cilën e quajtëm dockerized-app. Për momentin ne përdorim disa depo para çdo komponenti. Ato janë thjesht logjikisht të ndryshme - në GitLab duket si një dosje, por në makinën e zhvilluesit, një dosje për një projekt specifik. Një nivel më poshtë janë komponentët që do të kombinohen.
Ky është një shembull vetëm i përmbajtjes së aplikacionit të dockerized. Ne sjellim këtu edhe direktorinë Docker, në të cilën plotësojmë konfigurimet e kërkuara për ndërveprimet e të gjithë komponentëve. Ekziston një README.md që përshkruan shkurtimisht se si të ekzekutohet projekti.
Këtu kemi aplikuar dy skedarë docker-compose. Kjo është bërë në mënyrë që të jetë në gjendje të kandidojë në hapa. Kur një zhvillues punon me bërthamën, ai nuk ka nevojë për njoftime shtytëse, ai thjesht lëshon një skedar docker-compose dhe, në përputhje me rrethanat, burimi ruhet.
Nëse ka nevojë për t'u integruar me njoftimet push, atëherë docker-compose.yaml dhe docker-compose-push.yaml lëshohen.
Meqenëse docker-compose.yaml dhe docker-compose-push.yaml janë në një dosje, krijohet automatikisht një rrjet i vetëm virtual.
Përshkrimi i komponentëve. Ky është një skedar më i avancuar që është përgjegjës për mbledhjen e komponentëve. Çfarë është e shquar këtu? Këtu prezantojmë komponentin balancues.
Ky është një imazh i gatshëm Docker që ekzekuton nginx dhe një aplikacion që dëgjon në folenë Docker. Dinamik, ndërsa kontejnerët ndizen dhe fiken, ai rigjeneron konfigurimin nginx. Ne shpërndajmë trajtimin e komponentëve sipas emrave të domeneve të nivelit të tretë.
Për mjedisin e Zhvillimit, ne përdorim domenin .dev - api.informer.dev. Aplikacionet me një domen .dev janë të disponueshme në makinën lokale të zhvilluesit.
Më tej, konfigurimet transferohen në secilin projekt dhe të gjitha projektet lëshohen së bashku në të njëjtën kohë.
Grafikisht, rezulton se klienti është shfletuesi ynë ose ndonjë mjet me të cilin ne i bëjmë kërkesa balancuesit.
Balancuesi i emrit të domenit përcakton se cilin kontejner duhet të kontaktojë.
Mund të jetë nginx, i cili i jep administratorit JS. Ky mund të jetë nginx, i cili jep API, ose skedarë statikë, të cilët i jepen nginx në formën e ngarkimeve të imazheve.
Diagrami tregon se kontejnerët janë të lidhur nga një rrjet virtual dhe të fshehur pas një përfaqësuesi.
Në makinën e zhvilluesit, ju mund të përdorni kontejnerin duke ditur IP-në, por në parim ne nuk e përdorim këtë. Praktikisht nuk ka nevojë për qasje të drejtpërdrejtë.
Cilin shembull duhet të shikoni për të lidhur aplikacionin tuaj? Sipas mendimit tim, një shembull i mirë është imazhi zyrtar i dokerit për MySQL.
Është mjaft sfiduese. Ka shumë versione. Por funksionaliteti i tij ju lejon të mbuloni shumë nevoja që mund të lindin në procesin e zhvillimit të mëtejshëm. Nëse kaloni kohë dhe kuptoni se si ndërvepron e gjithë kjo, atëherë mendoj se nuk do të keni probleme në vetë-zbatimin.
Hub.docker.com zakonisht përmban lidhje me github.com, e cila përmban të dhëna të papërpunuara drejtpërdrejt nga të cilat mund ta ndërtoni vetë imazhin.
Më tej në këtë depo ka një skript docker-endpoint.sh, i cili është përgjegjës për inicializimin fillestar dhe për përpunimin e mëtejshëm të nisjes së aplikacionit.
Gjithashtu në këtë shembull, ekziston aftësia për të konfiguruar duke përdorur variablat e mjedisit. Duke përcaktuar një variabël mjedisi gjatë ekzekutimit të një kontejneri të vetëm ose përmes docker-compose, mund të themi se duhet të vendosim një fjalëkalim bosh që docker të rrënjoset në MySQL ose çfarëdo që duam.
Ekziston një mundësi për të krijuar një fjalëkalim të rastësishëm. Ne themi se kemi nevojë për një përdorues, duhet të vendosim një fjalëkalim për përdoruesin dhe duhet të krijojmë një bazë të dhënash.
Në projektet tona, ne unifikuam pak Dockerfile, i cili është përgjegjës për inicializimin. Atje e korrigjuam atë sipas nevojave tona për ta bërë atë vetëm një zgjerim të të drejtave të përdoruesit që përdor aplikacioni. Kjo na lejoi të krijonim thjesht një bazë të dhënash nga tastiera e aplikacionit më vonë. Aplikacionet Ruby kanë një komandë për krijimin, modifikimin dhe fshirjen e bazave të të dhënave.
Ky është një shembull se si duket një version specifik i MySQL në github.com. Mund të hapni Dockerfile dhe të shihni se si po shkon instalimi atje.
docker-endpoint.sh është skripti përgjegjës për pikën hyrëse. Gjatë inicializimit fillestar, kërkohen disa hapa përgatitor, dhe të gjitha këto veprime merren vetëm në skriptin e inicializimit.
Le të kalojmë në pjesën e dytë.
Për të ruajtur kodet burimore, kaluam në gitlab. Ky është një sistem mjaft i fuqishëm që ka një ndërfaqe vizuale.
Një nga komponentët e Gitlab është Gitlab CI. Kjo ju lejon të përshkruani një sekuencë komandash që do të përdoren më vonë për të organizuar një sistem të shpërndarjes së kodit ose për të kryer testimin automatik.
Biseda Gitlab CI 2 - raport nga klubi Ruby Russia - mjaft i detajuar dhe ndoshta do t'ju interesojë.
Tani do të shohim se çfarë kërkohet për të aktivizuar Gitlab CI. Për të nisur Gitlab CI, ne vetëm duhet të vendosim skedarin .gitlab-ci.yml në rrënjën e projektit.
Këtu përshkruajmë se duam të ekzekutojmë një sekuencë gjendjesh si një test, vendosje.
Ne ekzekutojmë skriptet që thërrasin drejtpërdrejt docker-compose për të ndërtuar aplikacionin tonë. Ky është vetëm një shembull mbështetës.
Më pas, themi se është e nevojshme të ekzekutohen migrimet për të ndryshuar bazën e të dhënave dhe për të ekzekutuar teste.
Nëse skriptet ekzekutohen saktë dhe nuk kthen një kod gabimi, atëherë sistemi vazhdon në fazën e dytë të vendosjes.
Faza e vendosjes aktualisht është zbatuar për skenë. Ne nuk organizuam një rinisje pa ndërprerje.
Ne i shuajmë me forcë të gjitha kontejnerët dhe më pas i ngremë përsëri të gjithë kontejnerët, të mbledhur në fazën e parë gjatë testimit.
Ne po ekzekutojmë për variablin aktual të mjedisit migrimet e bazës së të dhënave që janë shkruar nga zhvilluesit.
Ekziston një shënim që kjo vlen vetëm për degën kryesore.
Kur ndryshimi i degëve të tjera nuk ekzekutohet.
Është e mundur të organizohen hapje sipas degëve.
Për ta organizuar këtë më tej, duhet të instalojmë Gitlab Runner.
Ky mjet është shkruar në Golang. Është një skedar i vetëm, siç është e zakonshme në botën Golang, e cila nuk kërkon ndonjë varësi.
Në fillim, ne regjistrojmë Gitlab Runner.
Ne e marrim çelësin në ndërfaqen e internetit Gitlab.
Pastaj ne thërrasim komandën e inicializimit në vijën e komandës.
Konfiguro Gitlab Runner në mënyrë interaktive (Shell, Docker, VirtualBox, SSH)
Kodi në Gitlab Runner do të ekzekutohet në çdo kryerje, në varësi të cilësimeve .gitlab-ci.yml.
Si duket vizualisht në Gitlab në ndërfaqen e internetit. Pasi të kemi lidhur GItlab CI, kemi një flamur që tregon gjendjen e ndërtimit për momentin.
Shohim që 4 minuta më parë është bërë një angazhim, i cili ka kaluar të gjitha testet dhe nuk ka sjellë asnjë problem.
Ne mund t'i hedhim një vështrim më të afërt ndërtimeve. Këtu shohim se tashmë kanë kaluar dy shtete. Statusi i testimit dhe statusi i vendosjes në skenë.
Nëse klikojmë në një ndërtim specifik, atëherë do të ketë një dalje konsole të komandave që janë ekzekutuar në proces sipas .gitlab-ci.yml.
Kështu duket historia jonë e produktit. Ne shohim se ka pasur përpjekje të suksesshme. Kur dorëzohen testet, ai nuk vazhdon në hapin tjetër dhe kodi i fazës nuk përditësohet.
Çfarë detyrash zgjidhëm në skenë kur zbatuam docker? Sistemi ynë përbëhet nga komponentë dhe ne kishim nevojë të rinisnim, vetëm një pjesë të komponentëve që u përditësuan në depo, dhe jo të gjithë sistemin.
Për ta bërë këtë, ne duhej të copëtonim gjithçka në dosje të veçanta.
Pasi e bëmë këtë, patëm një problem me faktin se Docker-compose krijon hapësirën e vet të rrjetit për çdo baba dhe nuk i sheh komponentët e fqinjit.
Për të lëvizur, ne krijuam rrjetin në Docker me dorë. Ishte shkruar në Docker-compose që ju përdorni një rrjet të tillë për këtë projekt.
Kështu, çdo komponent që fillon me këtë rrjetë sheh komponentë në pjesë të tjera të sistemit.
Çështja tjetër është ndarja e skenës nëpër projekte të shumta.
Pasi që e gjithë kjo të duket bukur dhe sa më afër prodhimit, është mirë të përdoret porti 80 ose 443, i cili përdoret kudo në WEB.
Si e zgjidhëm? Ne kemi caktuar një Gitlab Runner për të gjitha projektet kryesore.
Gitlab ju lejon të ekzekutoni disa Gitlab Runners të shpërndarë, të cilët thjesht do t'i marrin të gjitha detyrat me radhë në një mënyrë kaotike dhe do t'i ekzekutojnë ato.
Për të mos pasur shtëpi, e kufizuam grupin e projekteve tona në një Gitlab Runner, i cili përballon pa probleme me vëllimet tona.
Ne zhvendosëm nginx-proxy në një skript të veçantë fillestar dhe shtuam rrjete për të gjitha projektet në të.
Projekti ynë ka një rrjet, dhe balancuesi ka disa rrjete sipas emrave të projekteve. Ai mund të proksohet më tej me emra domenesh.
Kërkesat tona vijnë përmes domenit në portin 80 dhe zgjidhen në një grup kontejnerësh që i shërben këtij domeni.
Çfarë problemesh të tjera kishte? Kjo është ajo që të gjithë kontejnerët funksionojnë si rrënjë si parazgjedhje. Kjo është rrënjë e pabarabartë me pritësin rrënjë të sistemit.
Sidoqoftë, nëse futni kontejnerin, ai do të jetë root dhe skedari që krijojmë në këtë kontejner merr të drejta rrënjësore.
Nëse zhvilluesi ka hyrë në kontejner dhe ka bërë disa komanda atje që gjenerojnë skedarë, pastaj ka lënë kontejnerin, atëherë ai ka një skedar në drejtorinë e tij të punës që nuk ka qasje.
Si mund të zgjidhet? Mund të shtoni përdorues që do të jenë në kontejner.
Çfarë problemesh lindën kur shtuam përdoruesin?
Kur krijojmë një përdorues, shpesh nuk kemi të njëjtën ID të grupit (UID) dhe ID të përdoruesit (GID).
Për të zgjidhur këtë problem në kontejner, ne përdorim përdoruesit me ID 1000.
Në rastin tonë, kjo përkoi me faktin se pothuajse të gjithë zhvilluesit përdorin Ubuntu OS. Dhe në Ubuntu, përdoruesi i parë ka një ID prej 1000.
A kemi plane?
Lexoni dokumentacionin e Docker. Projekti po zhvillohet në mënyrë aktive, dokumentacioni po ndryshon. Të dhënat e marra dy-tre muaj më parë tashmë po bëhen dalëngadalë.
Disa nga problemet që ne i zgjidhëm me shumë mundësi janë zgjidhur tashmë me mjete standarde.
Kështu që unë dua të shkoj më tej tashmë për të shkuar direkt në orkestrimin.
Një shembull është mekanizmi i integruar i Docker i quajtur Docker Swarm, i cili del nga kutia. Unë dua të ekzekutoj diçka në prodhim bazuar në teknologjinë Docker Swarm.
Kontejnerët e vezëve e bëjnë të papërshtatshme punën me trungje. Tani shkrimet janë të izoluara. Ato janë të shpërndara nëpër kontejnerë. Një nga detyrat është të bëni akses të përshtatshëm në regjistrat përmes ndërfaqes së internetit.
Burimi: www.habr.com