Ik stel foar dat jo it transkripsje fan it rapport lêze troch Alexander Sigachev fan Inventos "Utwikkelings- en testproses mei Docker + Gitlab CI"
Dejingen dy't krekt begjinne mei it ymplementearjen fan it ûntwikkelings- en testproses basearre op Docker + Gitlab CI freegje faaks basisfragen. Wêr te begjinnen? Hoe te organisearjen? Hoe te testen?
Dit rapport is goed om't it op in strukturearre manier praat oer it ûntwikkelings- en testproses mei Docker en Gitlab CI. It rapport sels is fan 2017. Ik tink dat jo út dit rapport de basis, metodyk, idee en ûnderfining fan gebrûk kinne ophelje.
Wa makket it út, asjebleaft ûnder de kat.
Myn namme is Alexander Sigachev. Ik wurkje foar Inventos. Ik sil jo fertelle oer myn ûnderfining mei it brûken fan Docker en hoe't wy it stadichoan ymplementearje op projekten yn it bedriuw.
Underwerp fan it rapport: Untwikkelingsproses mei Docker en Gitlab CI.
Dit is myn twadde praat oer Docker. Op it momint fan it earste rapport brûkten wy Docker allinich yn Untwikkeling op ûntwikkelmasines. It oantal meiwurkers dat Docker brûkte wie sawat 2-3 minsken. Stadichoan waard ûnderfining opdien en binne wy wat fierder gien. Link nei ús .
Wat sil yn dit rapport stean? Wy sille ús ûnderfining diele oer hokker raken wy sammele, hokker problemen wy hawwe oplost. It wie net oeral moai, mar it liet ús fierder.
Us motto: dokke alles wat wy yn hannen krije.
Hokker problemen oplosse wy?
As in bedriuw ferskate teams hat, is de programmeur in dielde boarne. D'r binne stadia as in programmeur út ien projekt wurdt lutsen en in skoft oan in oar projekt jûn wurdt.
Om in programmeur fluch te begripen, moat hy de boarnekoade fan it projekt downloade en sa gau mooglik in omjouwing lansearje, wêrtroch hy fierder kin foarútgean by it oplossen fan de problemen fan dit projekt.
As jo meastentiids begjinne, is d'r net folle dokumintaasje yn it projekt. Allinnich oldtimers hawwe ynformaasje oer hoe't se it ynstelle. Meiwurkers sette har wurkplak yn ien of twa dagen op harsels yn. Om dit te fersnellen, hawwe wy Docker brûkt.
De folgjende reden is de standerdisearring fan ynstellings yn Untwikkeling. Yn myn ûnderfining nimme ûntwikkelders altyd it inisjatyf. Yn elk fyfde gefal wurdt in oanpaste domein ynfierd, bygelyks vasya.dev. Neist my sit myn buorfrou Petya, waans domein petya.dev is. Se ûntwikkelje in webside as in systeemkomponint mei dizze domeinnamme.
As it systeem groeit en dizze domeinnammen begjinne te wurde opnommen yn 'e konfiguraasje, ûntstiet in konflikt yn Untwikkelingsomjouwings en wurdt it sidepaad opnij skreaun.
Itselde ding bart mei databaseynstellingen. Guon minsken dogge gjin muoite mei feiligens en wurkje mei in leech root-wachtwurd. Op it ynstallaasjestadium frege MySQL immen foar in wachtwurd en it wachtwurd die bliken 123. It bart faak dat de databankkonfiguraasje konstant feroaret ôfhinklik fan 'e commit fan' e ûntwikkelder. Immen hat korrizjearre, immen hat de konfiguraasje net korrizjearre. D'r wiene trúkjes doe't wy wat testkonfiguraasje yn sette .gitignore en elke ûntwikkelder moast de databank ynstallearje. Dit makke it startproses dreger. Under oare dingen moatte jo ûnthâlde oer de databank. De databank moat inisjalisearre wurde, in wachtwurd moat registrearre wurde, in brûker moat registrearre wurde, in teken moat oanmakke wurde, ensfh.
In oar probleem is ferskate ferzjes fan bibleteken. It bart faak dat in ûntwikkelder wurket oan ferskate projekten. D'r is in Legacy-projekt, dat fiif jier lyn begon (fan 2017 - redaksjenotysje). Oan it begjin binne wy begon mei MySQL 5.5. D'r binne ek moderne projekten wêr't wy besykje mear moderne ferzjes fan MySQL te ymplementearjen, bygelyks 5.7 of âlder (yn 2017 - redaksjenotysje)
Elkenien dy't wurket mei MySQL wit dat dizze biblioteken ôfhinklikens drage. It is frij problematysk om 2 databases tegearre út te fieren. Op syn minst is it problematysk om âlde kliïnten te ferbinen mei de nije databank. Dit op syn beurt jout oanlieding ta ferskate problemen.
It folgjende probleem is as in ûntwikkelder wurket op in lokale masine, hy brûkt lokale boarnen, lokale triemmen, lokale RAM. Alle ynteraksje op it momint fan it ûntwikkeljen fan in oplossing foar problemen wurdt útfierd yn it ramt fan it feit dat it wurket op ien masine. In foarbyld soe wêze as wy backend-tsjinners hawwe yn Production 3, en de ûntwikkelder bewarret bestannen yn 'e root-map en dêrwei nimt nginx de bestannen om te reagearjen op it fersyk. As sa'n koade yn Produksje komt, docht bliken dat it bestân oanwêzich is op ien fan 3 servers.
De rjochting fan mikrotsjinsten is op it stuit ûntwikkele. As wy ús grutte applikaasjes ferdiele yn guon lytse komponinten dy't mei-inoar ynteraksje. Hjirmei kinne jo technologyen selektearje foar in spesifike taakstapel. Hjirmei kinne jo ek it wurk en ferantwurdlikensgebiet ferdiele tusken ûntwikkelders.
In frontend-ûntwikkelder, ûntwikkele yn JS, hat praktysk gjin ynfloed op 'e efterkant. De backend-ûntwikkelder ûntwikkelet op syn beurt, yn ús gefal, Ruby on Rails en ynterfereart net mei Frondend. Ynteraksje wurdt útfierd mei de API.
As bonus koenen wy mei Docker boarnen recycle op Staging. Elk projekt, fanwege syn spesifikaasjes, easke bepaalde ynstellings. Fysiek wie it nedich om in firtuele tsjinner te allocearjen en se apart te konfigurearjen, of in soarte fan fariabele omjouwing te ferdielen en projekten koene elkoar beynfloedzje, ôfhinklik fan 'e ferzje fan' e bibleteken.
Tools. Wat brûke wy?
- Docker sels. In Dockerfile beskriuwt de ôfhinklikens fan in inkele applikaasje.
- Docker-compose is in bondel dy't ferskate fan ús Docker-applikaasjes byinoar bringt.
- Wy brûke GitLab om boarnekoade op te slaan.
- Wy brûke GitLab-CI foar systeemyntegraasje.
It rapport bestiet út twa dielen.
It earste diel sil jo fertelle hoe't jo Docker útfiere op 'e masines fan' e ûntwikkelders.
It twadde diel sil prate oer hoe't jo kinne ynteraksje mei GitLab, hoe't wy tests útfiere en hoe't wy útrolje nei Staging.
Docker is in technology dy't (mei in deklarative oanpak) mooglik makket om de nedige komponinten te beskriuwen. Dit is in foarbyld Dockerfile. Hjir ferklearje wy dat wy erfje fan 'e offisjele Docker-ôfbylding fan Ruby: 2.3.0. It befettet Ruby ferzje 2.3 ynstalleare. Wy ynstallearje de nedige gearkomste biblioteken en NodeJS. Wy beskriuwe dat wy in map meitsje /app. Wy jouwe de app-map ta as de wurkmap. Yn dizze map pleatse wy de fereaske minimale Gemfile en Gemfile.lock. Dan bouwe wy projekten dy't dizze ôfhinklikensôfbylding ynstallearje. Wy jouwe oan dat de kontener klear is om te harkjen op eksterne poarte 3000. It lêste kommando is it kommando dat ús applikaasje direkt start. As wy it projekt run kommando útfiere, sil de applikaasje besykje it opjûne kommando út te fieren en út te fieren.
Dit is in minimaal foarbyld fan in docker-compose-bestân. Yn dit gefal litte wy sjen dat der in ferbining is tusken twa konteners. Dit is direkt yn 'e databanktsjinst en webtsjinst. Us webapplikaasjes fereaskje yn 'e measte gefallen in soarte fan database as backend foar it opslaan fan gegevens. Om't wy MySQL brûke, is it foarbyld mei MySQL - mar neat foarkomt dat wy in oare databank brûke (PostgreSQL, Redis).
Wy nimme de MySQL 5.7.14-ôfbylding sûnder feroaringen fan 'e offisjele boarne fan' e Docker-hub. Wy sammelje de ôfbylding dy't ferantwurdlik is foar ús webapplikaasje út 'e hjoeddeistige map. By de earste lansearring sammelet er in byld foar ús. Dan rint it it kommando dat wy hjir útfiere. As wy werom geane, sille wy sjen dat it startkommando waard definiearre fia Puma. Puma is in tsjinst skreaun yn Ruby. Yn it twadde gefal wy oerskriuwe. Dit kommando kin willekeurich wêze ôfhinklik fan ús behoeften of taken.
Wy beskriuwe ek dat wy de haven moatte trochstjoere op ús ûntwikkelderhostmasine fan 3000 nei 3000 kontenerhaven. Dit wurdt automatysk dien mei iptables en in eigen meganisme, dat direkt yn Docker ynbêde is.
De ûntwikkelder kin, lykas earder, tagong krije ta elk beskikber IP-adres, bygelyks 127.0.0.1 lokaal of ekstern IP-adres fan 'e masine.
De lêste rigel seit dat de webcontainer hinget fan 'e db-container. As wy de webkontainer neame om te starten, sil docker-compose earst de database foar ús starte. Al by it begjin fan 'e databank (yn feite, nei de lansearring fan' e kontener! Dit garandearret de reeheid fan 'e databank net) sil ús applikaasje, ús backend, starte.
Hjirmei kinne wy flaters foarkomme as de databank net op is en kinne ús boarnen bewarje as wy de databankkontener stopje, en dêrmei boarnen frijmeitsje foar oare projekten.
Wat jout it brûken fan database dockerization op in projekt ús? Wy opnimme de MySQL-ferzje foar alle ûntwikkelders. Hjirmei kinne jo guon flaters foarkomme dy't foarkomme kinne as ferzjes divergje, as de syntaksis, konfiguraasje en standertynstellingen feroarje. Hjirmei kinne jo in mienskiplike hostnamme opjaan foar de databank, login, wachtwurd. Wy geane fuort fan 'e bistetún fan nammen en konflikten yn konfiguraasjebestannen dy't earder bestien.
Wy hawwe de kâns om in mear optimale konfiguraasje te brûken foar de Untwikkelingsomjouwing, dy't sil ferskille fan 'e standert. MySQL is standert konfigureare foar swakke masines en har prestaasjes bûten it fak is heul leech.
Docker lit jo de Python, Ruby, NodeJS, PHP-interpreter fan 'e winske ferzje brûke. Wy ferwiderje de needsaak om in soarte fan ferzjebehearder te brûken. Earder waard in rpm-pakket brûkt foar Ruby, wêrtroch jo de ferzje kinne feroarje ôfhinklik fan it projekt. Mei tank oan de Docker-kontener kinne jo dit ek soepel migrearje koade en ferzje it tegearre mei ôfhinklikens. Wy hawwe gjin probleem om de ferzje fan sawol de tolk as de koade te begripen. Om de ferzje te aktualisearjen, moatte jo de âlde kontener ferleegje en de nije kontener ferheegje. As der wat mis giet, kinne wy de nije kontener ferleegje, de âlde kontener ferheegje.
Nei it bouwen fan it byld sille de konteners yn sawol Untwikkeling as Produksje itselde wêze. Dit is benammen wier foar grutte ynstallaasjes.
Op Frontend brûke wy JavaScipt en NodeJS.
No hawwe wy ús lêste projekt op ReacJS. De ûntwikkelder lansearre alles yn 'e kontener en ûntwikkele mei hot-reload.
Dêrnei wurdt de taak fan it gearstallen fan JavaScipt lansearre en de statysk gearstalde koade wurdt ferstjoerd fia nginx, wêrtroch boarnen besparje.
Hjir haw ik in diagram jûn fan ús lêste projekt.
Hokker problemen hawwe jo oplost? Wy hiene in ferlet om in systeem te bouwen wêrmei mobile apparaten ynteraksje. Se krije gegevens. Ien fan 'e mooglikheden is om push-notifikaasjes nei dit apparaat te stjoeren.
Wat hawwe wy hjirfoar dien?
Wy hawwe de applikaasje ferdield yn de folgjende komponinten: in admin-diel yn JS, in backend dat wurket fia in REST-ynterface ûnder Ruby on Rails. Backend ynteraksje mei de databank. It resultaat dat wurdt generearre wurdt jûn oan de klant. It adminpaniel ynteraksje mei de backend en database fia in REST-ynterface.
Wy hiene ek ferlet om Push-notifikaasjes te stjoeren. Dêrfoar hienen wy in projekt wêryn in meganisme waard ymplementearre dat ferantwurdlik wie foar it leverjen fan notifikaasjes oan mobile platfoarms.
Wy hawwe it folgjende skema ûntwikkele: de operator fan 'e browser ynteraksje mei it adminpaniel, it adminpaniel ynteraktearret mei it backend, de taak is om Push-notifikaasjes te stjoeren.
Push-notifikaasjes ynteraksje mei in oare komponint dat is ymplementearre yn NodeJS.
Wachtrijen wurde boud en notifikaasjes wurde ferstjoerd neffens har eigen meganisme.
Twa databanken wurde hjir tekene. Op it stuit brûke wy Docker 2 ûnôfhinklike databases dy't op gjin inkelde manier mei elkoar ferbûn binne. Neist it feit dat se in mienskiplik firtuele netwurk hawwe, en fysike gegevens wurde opslein yn ferskate mappen op 'e masine fan' e ûntwikkelder.
Itselde, mar yn getallen. Hergebrûk fan koade is hjir wichtich.
As wy earder praat hawwe oer it werbrûken fan koade yn 'e foarm fan biblioteken, dan wurdt yn dit foarbyld ús tsjinst, dy't reagearret op Push-notifikaasjes, opnij brûkt as in folsleine server. It biedt in API. En ús nije ûntwikkeling ynteraktearret dêrmei.
Op dat stuit brûkten wy ferzje 4 fan NodeJS. No (yn 2017 - notysje fan redaksje) yn ús lêste ûntjouwings brûke wy ferzje 7 fan NodeJS. D'r is gjin probleem yn nije komponinten om nije ferzjes fan bibleteken te belûken.
As it nedich is, kinne jo de NodeJS-ferzje fan 'e Push-notifikaasjetsjinst refaktorearje en ferheegje.
En as wy API-kompatibiliteit kinne behâlde, dan sil it mooglik wêze om it te ferfangen mei oare projekten dy't earder waarden brûkt.
Wat hawwe jo nedich om Docker ta te foegjen? Wy foegje in Dockerfile ta oan ús repository, dy't de nedige ôfhinklikens beskriuwt. Yn dit foarbyld binne de komponinten logysk ferdield. Dit is de minimale kit foar in backend-ûntwikkelder.
By it meitsjen fan in nij projekt meitsje wy in Dockerfile en beskriuwe it winske ekosysteem (Python, Ruby, NodeJS). Yn docker-compose beskriuwt it de nedige ôfhinklikens - de databank. Wy beskriuwe dat wy in databank fan sa en sa'n ferzje nedich hawwe, om dêr en dêr gegevens op te slaan.
Wy brûke in aparte tredde kontener mei nginx om statyske ynhâld te tsjinjen. It is mooglik om foto's te uploaden. De backend set se yn in pre-prepared folume, dat is ek monteard yn in kontener mei nginx, dat jout statyske gegevens.
Om de nginx- en mysql-konfiguraasje op te slaan, hawwe wy in Docker-map tafoege wêryn wy de nedige konfiguraasjes opslaan. As in ûntwikkelder in git-kloon makket fan in repository op syn masine, hat hy al in projekt klear foar lokale ûntwikkeling. D'r is gjin fraach oer hokker haven of hokker ynstellings moatte tapasse.
Dêrnei hawwe wy ferskate komponinten: admin, info-API, push-notifikaasjes.
Om dit alles te starten, hawwe wy in oar repository makke mei de namme dockerized-app. Wy brûke op it stuit meardere repositories foar elke komponint. Se binne gewoan logysk oars - yn GitLab liket it op in map, mar op 'e masine fan' e ûntwikkelders liket it op in map foar in spesifyk projekt. Ien nivo hjirûnder binne de komponinten dy't sille wurde kombinearre.
Dit is in foarbyld fan de ynhâld fan dockerized-app. Wy pleatse hjir ek in Docker-map, wêryn wy de konfiguraasjes ynfolje dy't nedich binne foar de ynteraksjes fan alle komponinten. D'r is in README.md dy't koart beskriuwt hoe't jo it projekt starte.
Hjir hawwe wy twa docker-compose-bestannen tapast. Dit wurdt dien om stadichoan lansearje te kinnen. As in ûntwikkelder mei de kernel wurket, hat hy gjin Push-notifikaasjes nedich, hy lanseart gewoan it docker-compose-bestân en dêrtroch wurde boarnen bewarre.
As der ferlet is fan yntegraasje mei Push-notifikaasjes, dan wurde docker-compose.yaml en docker-compose-push.yaml lansearre.
Sûnt docker-compose.yaml en docker-compose-push.yaml binne yn 'e map, wurdt automatysk in inkele firtuele netwurk oanmakke.
Beskriuwing fan komponinten. Dit is in mear avansearre triem dy't ferantwurdlik is foar it sammeljen fan komponinten. Wat is hjir opfallend? Hjir yntrodusearje wy de balancer komponint.
Dit is in klearmakke Docker-ôfbylding dy't nginx rint en in applikaasje dy't harket nei de Docker-socket. Dynamysk, as konteners yn- en útskeakele wurde, wurdt de nginx-konfiguraasje regenerearre. Wy fersprieden de ôfhanneling fan komponinten mei gebrûk fan domeinnammen op tredde nivo.
Foar de ûntwikkelingsomjouwing brûke wy it .dev-domein - api.informer.dev. Applikaasjes mei in .dev-domein binne beskikber op de lokale masine fan de ûntwikkelder.
Dan wurde de konfiguraasjes oerdroegen oan elk projekt en wurde alle projekten tagelyk lansearre.
As wy it grafysk ôfbyldzje, docht bliken dat de kliïnt ús browser is as in soarte fan ark wêrmei't wy oanfragen oan 'e balancer meitsje.
De balancer bepaalt hokker kontener tagong moat wurde op basis fan de domeinnamme.
Dit kin nginx wêze, dy't JS leveret oan it adminpaniel. Dit kin dien wurde troch nginx, dy't de API leveret, of statyske bestannen, dy't wurde levere troch nginx yn 'e foarm fan it laden fan ôfbyldings.
It diagram lit sjen dat de konteners ferbûn binne mei in firtuele netwurk en ferburgen efter in proxy.
Op de masine fan 'e ûntwikkelder kinne jo tagong krije ta de kontener mei it witten fan it IP, mar yn prinsipe brûke wy dit net. D'r is praktysk gjin ferlet fan direkte kontakt.
Hokker foarbyld moat ik sjen om myn applikaasje te dockerisearjen? Yn myn miening is in goed foarbyld de offisjele dockerôfbylding foar MySQL.
It is frij yngewikkeld. Der binne in protte ferzjes. Mar syn funksjonaliteit lit jo in protte behoeften dekke dy't miskien ûntsteane yn it proses fan fierdere ûntwikkeling. As jo de tiid nimme en begripe hoe't it allegear ynteraksje, dan tink ik dat jo gjin problemen sille hawwe om it sels te ymplementearjen.
Hub.docker.com befettet meastentiids keppelings nei github.com, wêr't rau gegevens direkt wurde levere wêrfan jo sels in ôfbylding kinne bouwe.
Fierder yn dit repository is d'r in skript docker-endpoint.sh, dat ferantwurdlik is foar de inisjele inisjalisaasje en fierdere ferwurking fan applikaasje-lansearring.
Ek yn dit foarbyld is d'r de mooglikheid fan konfiguraasje mei help fan omjouwingsfariabelen. Troch in omjouwingsfariabele te definiearjen by it útfieren fan in inkele kontener of fia docker-compose, kinne wy sizze dat wy in leech wachtwurd moatte ynstelle foar docker foar root op MySQL of wat wy wolle.
D'r is in opsje om in willekeurich wachtwurd te meitsjen. Wy sizze dat wy in brûker nedich binne, wy moatte in wachtwurd ynstelle foar de brûker, en wy moatte in databank meitsje.
Yn ús projekten hawwe wy de Dockerfile in bytsje ferienige, dy't ferantwurdlik is foar inisjalisaasje. Dêr hawwe wy it oanpast oan ús behoeften om gewoan de brûkersrjochten út te wreidzjen dy't de applikaasje brûkt. Dit makke it mooglik om yn 'e takomst gewoan in database te meitsjen fan' e applikaasjekonsole. Ruby-applikaasjes hawwe kommando's foar it meitsjen, wizigjen en wiskjen fan databases.
Dit is in foarbyld fan hoe't in spesifike ferzje fan MySQL derút sjocht op github.com. Jo kinne de Dockerfile iepenje en sjen hoe't de ynstallaasje dêr plakfynt.
docker-endpoint.sh skript ferantwurdlik foar it yngongspunt. Tidens inisjalisaasje binne guon tariedingsaksjes ferplicht en al dizze aksjes binne opnommen yn it inisjalisaasjeskript.
Lit ús gean nei it twadde diel.
Wy binne oergien nei gitlab om boarnekoades op te slaan. Dit is in frij krêftich systeem dat in fisuele ynterface hat.
Ien fan 'e Gitlab-komponinten is Gitlab CI. It lit jo in searje kommando's beskriuwe dy't letter sille wurde brûkt om in systeem foar levering fan koade te organisearjen of automatyske testen út te fieren.
Ferslach oer Gitlab CI 2 - it rapport fan 'e Ruby Russia-klub is frij detaillearre en kin jo ynteressearje.
No sille wy sjen nei wat nedich is om Gitlab CI te aktivearjen. Om Gitlab CI te starten, moatte wy gewoan de .gitlab-ci.yml-bestân yn 'e root fan it projekt sette.
Hjir beskriuwe wy dat wy wolle útfiere in folchoarder fan steaten lykas test, ynset.
Wy fiere skripts út dy't direkt de docker-compose build fan ús applikaasje neame. Dit is in foarbyld fan allinich de backend.
Dêrnei sizze wy dat it nedich is om migraasjes út te fieren om de databank te feroarjen en tests út te fieren.
As de skripts korrekt wurde útfierd en gjin flaterkoade werombringe, dan giet it systeem troch nei de twadde faze fan ynset.
De ynsetfaze is op it stuit ymplementearre foar staging. Wy hawwe gjin opstart sûnder downtime organisearre.
Wy twinge alle konteners út, en dan ferheegje wy alle konteners wer, sammele yn 'e earste faze by testen.
Litte wy de databankmigraasjes útfiere dy't waarden skreaun troch de ûntwikkelders foar de hjoeddeistige fariabele omjouwing.
D'r is in opmerking dat dit allinich tapast wurde moat op 'e mastertûke.
Wurket net by it feroarjen fan oare tûken.
It is mooglik om rollouts lâns tûken te organisearjen.
Om dit fierder te organisearjen, moatte wy Gitlab Runner ynstallearje.
Dit hulpprogramma is skreaun yn Golang. It is in inkeld bestân lykas gewoan yn 'e Golang-wrâld, dy't gjin ôfhinklikens nedich is.
By it opstarten registrearje wy Gitlab Runner.
Wy ûntfange de kaai yn 'e Gitlab-webynterface.
Dan neame wy it inisjalisaasjekommando op 'e kommandorigel.
Gitlab Runner konfigurearje yn dialoochmodus (Shell, Docker, VirtualBox, SSH)
De koade op Gitlab Runner sil útfiere op elke commit ôfhinklik fan de .gitlab-ci.yml ynstelling.
Hoe't it visueel sjocht yn Gitlab yn 'e webynterface. Nei it ferbinen fan GItlab CI hawwe wy in flagge dy't sjen lit yn hokker steat de bou op it stuit is.
Wy sjogge dat 4 minuten lyn in commit waard makke dy't alle testen slagge en gjin problemen feroarsake.
Wy kinne de bouwurken yn mear detail besjen. Hjir sjogge wy dat twa steaten al foarby binne. Teststatus en ynsetstatus by staging.
As wy klikke op in spesifike build, der sil wêze konsole útfier fan de kommando's dy't waarden lansearre yn it proses neffens .gitlab-ci.yml.
Dit is hoe't it ferhaal fan ús produkt derút sjocht. Wy sjogge dat der súksesfolle pogingen west hawwe. As de tests wurde yntsjinne, geane se net nei de folgjende stap en de stagingkoade wurdt net bywurke.
Hokker problemen hawwe wy oplost by it opstellen doe't wy docker ymplementearren? Us systeem bestiet út komponinten en wy moasten allinich guon fan 'e komponinten opnij starte dy't yn 'e repository waarden bywurke, en net it heule systeem.
Om dit te dwaan, moasten wy alles skiede yn aparte mappen.
Nei't wy dit dien hawwe, hienen wy in probleem mei it feit dat Docker-compose in eigen netwurkromte foar elke map makket en de komponinten fan syn buorman net sjocht.
Om om te kommen, hawwe wy it netwurk manuell makke yn Docker. Yn Docker-compose waard skreaun dat jo sa'n netwurk moatte brûke foar dit projekt.
Sa, elke komponint dy't begjint mei dit mesh sjocht komponinten yn oare dielen fan it systeem.
It folgjende probleem is it ferdielen fan staging tusken ferskate projekten.
Om't dit alles moai en sa ticht mooglik by de produksje sjocht, is it goed om poarte 80 of 443 te brûken, dy't oeral yn it WEB wurdt brûkt.
Hoe hawwe wy dit oplost? Wy hawwe ien Gitlab Runner tawiisd oan alle grutte projekten.
Gitlab lit jo ferskate ferspraat Gitlab Runners lansearje, dy't gewoan alle taken ien foar ien yn in chaotyske folchoarder sille nimme en se útfiere.
Om hûsproblemen te foarkommen, hawwe wy de groep fan ús projekten beheind ta ien Gitlab Runner, dy't sûnder problemen mei ús folumes omgaat.
Wy hawwe nginx-proxy ferpleatst nei in apart lansearskript en skreau de rasters fan alle projekten dêryn.
Us projekt hat ien raster, en de balancer hat ferskate rasters basearre op projektnammen. It kin proxy fierder troch domeinnammen.
Us oanfragen komme fia it domein op haven 80 en wurde oplost nei in groep konteners dy't dit domein tsjinnet.
Hokker oare problemen wiene der? Dit is wat alle konteners standert as root rinne. Dit is de root-ûngelikense roothost fan it systeem.
As jo lykwols de kontener ynfiere, sil it root wêze en it bestân dat wy yn dizze kontener meitsje ûntfangt rootrjochten.
As in ûntwikkelder de kontener ynfierde en dêr wat kommando's makke dy't bestannen genereare, dan de kontener ferliet, dan hat hy yn syn wurkmap in bestân dêr't hy gjin tagong hat.
Hoe kin dit oplost wurde? Jo kinne brûkers tafoegje dy't yn 'e kontener sille wêze.
Hokker problemen ûntstienen doe't wy de brûker tafoege?
By it oanmeitsjen fan in brûker komme de groep-ID (UID) en brûkers-ID (GID) faak net oerien.
Om dit probleem op te lossen yn 'e kontener brûke wy brûkers mei ID 1000.
Yn ús gefal foel dit gear mei it feit dat hast alle ûntwikkelders Ubuntu OS brûke. En yn Ubuntu OS hat de earste brûker ID 1000.
Hawwe wy plannen?
Lês de Docker-dokumintaasje opnij. It projekt is aktyf ûntwikkeljen, dokumintaasje feroaret. Gegevens dy't twa of trije moanne lyn krigen binne, wurde stadichoan ferâldere.
Guon fan 'e problemen dy't wy hawwe oplost binne mooglik al mei standertmiddels oplost.
Ik wol echt trochgean en direkt nei orkestraasje gean.
Ien foarbyld is Docker's ynboude meganisme neamd Docker Swarm, dy't út 'e doaze komt. Ik soe graach wat lansearje yn produksje basearre op Docker Swarm-technology.
Spawning konteners makket wurkjen mei logs ûngemaklik. No binne de logs isolearre. Se wurde ferspraat yn konteners. Ien fan 'e taken is om maklike tagong te meitsjen ta logs fia in webynterface.
Boarne: www.habr.com