Mi proponas legi la transskribon de la raporto de Alexander Sigachev el Inventos "Procezo de disvolviĝo kaj testado kun Docker + Gitlab CI"
Tiuj, kiuj ĵus komencas efektivigi la procezon de disvolviĝo kaj testado bazita sur Docker + Gitlab CI, ofte demandas bazajn demandojn. Kie komenci? Kiel organizi? Kiel testi?
Ĉi tiu raporto estas bona ĉar ĝi parolas en strukturita maniero pri la procezo de disvolviĝo kaj testado uzante Docker kaj Gitlab CI. La raporto mem estas de 2017. Mi pensas, ke el ĉi tiu raporto oni povas lerni la bazojn, metodikon, ideon, sperton de uzo.
Kiu zorgas, bonvolu sub la kato.
Mi nomiĝas Aleksandr Sigaĉev. Mi laboras por Inventos. Mi rakontos al vi pri mia sperto pri uzado de Docker kaj kiel ni iom post iom efektivigas ĝin en projektoj en la kompanio.
Prezenta temo: Disvolva procezo uzante Docker kaj Gitlab CI.
Jen mia dua parolado pri Docker. En la momento de la unua raporto, ni nur uzis Docker en Disvolviĝo sur programistoj. La nombro da dungitoj kiuj uzis Docker estis proksimume 2-3 homoj. Iom post iom oni akiris sperton kaj ni iom plu moviĝis. Ligo al nia .
Kio estos en ĉi tiu raporto? Ni dividos nian sperton pri kia rastilo ni kolektis, kiajn problemojn ni solvis. Ne ĉie ĝi estis bela, sed permesita pluiri.
Nia devizo estas: doku ĉion, kion ni povas atingi.
Kiajn problemojn ni solvas?
Kiam estas pluraj teamoj en firmao, la programisto estas komuna rimedo. Estas etapoj kiam programisto estas eltirita el unu projekto kaj donita por iom da tempo al alia projekto.
Por ke la programisto rapide komprenu, li devas elŝuti la fontkodon de la projekto kaj lanĉi la medion kiel eble plej baldaŭ, kio permesos al li plue movi solvante la problemojn de ĉi tiu projekto.
Kutime, se vi komencas de nulo, tiam estas malmulte da dokumentado en la projekto. Informoj pri kiel agordi disponeblas nur por malnovuloj. Dungitoj starigas sian laborejon memstare en unu aŭ du tagoj. Por akceli ĉi tion, ni uzis Docker.
La sekva kialo estas la normigado de agordoj en Disvolviĝo. Laŭ mia sperto, programistoj ĉiam prenas la iniciaton. En ĉiu kvina kazo, kutima domajno estas enigita, ekzemple, vasya.dev. Sidas apud li lia najbaro Petya, kies domajno estas petya.dev. Ili disvolvas retejon aŭ iun komponanton de la sistemo uzante ĉi tiun domajnan nomon.
Kiam la sistemo kreskas kaj ĉi tiuj domajnaj nomoj komencas eniri agordojn, ekestas Disvolva medio-konflikto kaj la retejo-vojo estas reverkita.
La sama okazas kun datumbaza agordo. Iu ne ĝenas pri sekureco kaj laboras kun malplena radika pasvorto. En la instala stadio, MySQL petis iun pasvorton kaj la pasvorto montriĝis 123. Ofte okazas, ke la datumbaza agordo konstante ŝanĝas depende de la kompromiso de la programisto. Iu korektis, iu ne korektis la agordon. Estis lertaĵoj kiam ni elprenis ian testan agordon .gitignore kaj ĉiu programisto devis instali la datumbazon. Ĉi tio malfaciligis komenci. Necesas, interalie, memori pri la datumbazo. La datumbazo devas esti pravigita, pasvorto devas esti enigita, uzanto devas esti registrita, tabelo devas esti kreita, ktp.
Alia problemo estas malsamaj versioj de bibliotekoj. Ofte okazas, ke programisto laboras kun malsamaj projektoj. Estas Legacy-projekto kiu komenciĝis antaŭ kvin jaroj (de 2017 - red. noto). En la momento de lanĉo, ni komencis kun MySQL 5.5. Ekzistas ankaŭ modernaj projektoj kie ni provas efektivigi pli modernajn versiojn de MySQL, ekzemple, 5.7 aŭ pli malnova (en 2017 - red. noto)
Ĉiu, kiu laboras kun MySQL, scias, ke ĉi tiuj bibliotekoj kunportas dependencojn. Estas sufiĉe probleme prizorgi 2 bazojn kune. Almenaŭ, malnovaj klientoj malfacilas konekti al la nova datumbazo. Ĉi tio siavice kreas plurajn problemojn.
La sekva problemo estas kiam programisto laboras sur loka maŝino, li uzas lokajn rimedojn, lokajn dosierojn, lokan RAM. Ĉiu interago en la momento de disvolvado de solvo al problemoj estas efektivigita en la kadro de tio, ke ĝi funkcias sur unu maŝino. Ekzemplo estas kiam ni havas backend-servilojn en Produktado 3, kaj la programisto konservas dosierojn al la radika dosierujo kaj de tie nginx prenas dosierojn por respondi al la peto. Kiam tia kodo eniras en Produktadon, rezultas, ke la dosiero ĉeestas sur unu el la 3 serviloj.
La direkto de mikroservoj disvolviĝas nun. Kiam ni dividas niajn grandajn aplikojn en kelkajn malgrandajn komponantojn, kiuj interagas unu kun la alia. Ĉi tio ebligas al vi elekti teknologiojn por specifa stako da taskoj. Ĝi ankaŭ permesas vin dividi laboron kaj respondecojn inter programistoj.
Frondend-programisto, evoluanta sur JS, havas preskaŭ neniun influon sur Backend. La backend-programisto, siavice, disvolvas, en nia kazo, Ruby on Rails kaj ne malhelpas Frondend. La interago estas farita per la API.
Kiel gratifiko, kun la helpo de Docker, ni povis recikli rimedojn sur Staging. Ĉiu projekto, pro siaj specifaĵoj, postulis certajn agordojn. Fizike, estis necese asigni aŭ virtualan servilon kaj agordi ilin aparte, aŭ kunhavigi ian varian medion kaj projektoj povus, depende de la versio de la bibliotekoj, influi unu la alian.
Iloj. Kion ni uzas?
- Docker mem. La Dockerfile priskribas la dependecojn de ununura aplikaĵo.
- Docker-compose estas pakaĵo, kiu kunigas kelkajn el niaj Docker-aplikoj.
- Ni uzas GitLab por konservi la fontkodon.
- Ni uzas GitLab-CI por sistema integriĝo.
La raporto konsistas el du partoj.
La unua parto parolos pri kiel Docker funkciis sur la maŝinoj de programistoj.
La dua parto parolos pri kiel interagi kun GitLab, kiel ni kuras testojn kaj kiel ni eliras al Staging.
Docker estas teknologio kiu permesas (uzante deklaran aliron) priskribi la necesajn komponentojn. Ĉi tio estas ekzemplo de Dockerfile. Ĉi tie ni deklaras, ke ni heredas de la oficiala Ruby:2.3.0 Docker-bildo. Ĝi enhavas Ruby-version 2.3 instalitan. Ni instalas la postulatajn konstrubibliotekojn kaj NodeJS. Ni priskribas, ke ni kreas dosierujon /app. Agordu la aplikan dosierujon kiel la labordosierujon. En ĉi tiu dosierujo ni metas la bezonatajn minimumajn Gemfile kaj Gemfile.lock. Ni tiam konstruas la projektojn, kiuj instalas ĉi tiun dependecan bildon. Ni indikas, ke la ujo estos preta por aŭskulti sur ekstera haveno 3000. La lasta komando estas la komando, kiu rekte lanĉas nian aplikaĵon. Se ni plenumas la projektan startkomandon, la aplikaĵo provos ruli kaj ruli la specifitan komandon.
Ĉi tio estas minimuma ekzemplo de docker-compose dosiero. En ĉi tiu kazo, ni montras, ke estas rilato inter du ujoj. Ĉi tio estas rekte en la datumbaza servo kaj la retservo. Niaj TTT-aplikoj plejofte postulas ian datumbazon kiel backend por stoki datumojn. Ĉar ni uzas MySQL, la ekzemplo estas kun MySQL - sed nenio malhelpas nin uzi alian datumbazon (PostgreSQL, Redis).
Ni prenas el la oficiala fonto de la Docker-nabo la bildon de MySQL 5.7.14 sen ŝanĝoj. Ni kolektas la bildon kiu respondecas pri nia retejo-aplikaĵo el la nuna dosierujo. Ĝi kolektas bildon por ni dum la unua lanĉo. Tiam ĝi rulas la komandon, kiun ni ekzekutas ĉi tie. Se ni revenos, ni vidos, ke la lanĉa komando per Puma estis difinita. Puma estas servo skribita en Ruby. En la dua kazo, ni superregas. Ĉi tiu komando povas esti arbitra depende de niaj bezonoj aŭ taskoj.
Ni ankaŭ priskribas, ke ni devas plusendi havenon sur nia programisto gastiga maŝino de 3000 ĝis 3000 sur la ujo-haveno. Ĉi tio estas farita aŭtomate uzante iptables kaj ĝian mekanismon, kiu estas rekte enigita en Docker.
La programisto ankaŭ povas, kiel antaŭe, aliri ajnan disponeblan IP-adreson, ekzemple, 127.0.0.1 estas la loka aŭ ekstera IP-adreso de la maŝino.
La lasta linio diras, ke la TTT-ujo dependas de la db-ujo. Kiam ni vokas la komencon de la retejo-ujo, docker-compose unue komencos la datumbazon por ni. Jam ĉe la komenco de la datumbazo (fakte, post la lanĉo de la ujo! Ĉi tio ne garantias la pretecon de la datumbazo) lanĉos la aplikaĵon, nia backend.
Ĉi tio evitas erarojn kiam la datumbazo ne estas alportita kaj ŝparas rimedojn kiam ni haltigas la datumbazan ujon, tiel liberigante rimedojn por aliaj projektoj.
Kio donas al ni la uzon de datumbaza dokerigo en la projekto. Ni riparas la version de MySQL por ĉiuj programistoj. Ĉi tio evitas iujn erarojn, kiuj povas okazi kiam versioj diverĝas, kiam la sintakso, agordo, defaŭltaj agordoj ŝanĝiĝas. Ĉi tio permesas al vi specifi komunan gastigan nomon por la datumbazo, ensaluto, pasvorto. Ni foriras de la zoo de nomoj kaj konfliktoj en la agordaj dosieroj, kiujn ni havis pli frue.
Ni havas la ŝancon uzi pli optimuman agordon por la Disvolva medio, kiu diferencas de la defaŭlta. MySQL estas agordita por malfortaj maŝinoj defaŭlte kaj ĝia agado ekster la skatolo estas tre malbona.
Docker permesas uzi la interpretilon Python, Ruby, NodeJS, PHP de la dezirata versio. Ni forigas la bezonon uzi ian version-manaĝeron. Antaŭe, Ruby uzis rpm-pakaĵon, kiu permesis al vi ŝanĝi la version depende de la projekto. Ĝi ankaŭ ebligas, danke al la Docker-ujo, glate migri la kodon kaj versio ĝin kune kun dependecoj. Ni ne havas problemon kompreni la version de kaj la interpretisto kaj la kodo. Por ĝisdatigi la version, mallevu la malnovan ujon kaj levu la novan ujon. Se io misfunkciis, ni povas mallevi la novan ujon, levi la malnovan ujon.
Post konstruado de la bildo, la ujoj en kaj Disvolviĝo kaj Produktado estos la samaj. Ĉi tio validas precipe por grandaj instalaĵoj.
En Frontend ni uzas JavaScipt kaj NodeJS.
Nun ni havas la lastan projekton pri ReacJS. La programisto prizorgis ĉion en la ujo kaj disvolviĝis per varma reŝargi.
Poste, la kunigotasko de JavaScipt estas lanĉita kaj la kodo kompilita en statiko estas donita per nginx-ŝparado de rimedoj.
Ĉi tie mi donis la skemon de nia lasta projekto.
Kiuj taskoj estis solvitaj? Ni devis konstrui sistemon kun kiu interagas porteblaj aparatoj. Ili ricevas datumojn. Unu ebleco estas sendi puŝajn sciigojn al ĉi tiu aparato.
Kion ni faris por ĉi tio?
Ni dividis en la aplikaĵon tiajn komponantojn kiel: la administran parton sur JS, la backend, kiu funkcias per la REST-interfaco sub Ruby on Rails. La backend interagas kun la datumbazo. La rezulto kiu estas generita estas donita al la kliento. La administra panelo interagas kun la backend kaj la datumbazo per la REST-interfaco.
Ni ankaŭ devis sendi puŝajn sciigojn. Antaŭ tio, ni havis projekton, kiu efektivigis mekanismon, kiu respondecas pri livero de sciigoj al moveblaj platformoj.
Ni evoluigis la sekvan skemon: operatoro de la retumilo interagas kun la administra panelo, la administra panelo interagas kun la backend, la tasko estas sendi Push-sciojn.
Puŝaj sciigoj interagas kun alia komponento, kiu estas efektivigita en NodeJS.
Vicoj estas konstruitaj kaj sciigoj estas senditaj laŭ sia propra mekanismo.
Du datumbazoj estas desegnitaj ĉi tie. Nuntempe, helpe de Docker, ni uzas 2 sendependajn datumbazojn, kiuj neniel rilatas unu al la alia. Krome, ili havas komunan virtualan reton, kaj fizikaj datumoj estas konservitaj en malsamaj dosierujoj sur la maŝino de la programisto.
La sama sed en nombroj. Ĉi tie gravas reuzo de kodo.
Se pli frue ni parolis pri reuzado de kodo en la formo de bibliotekoj, tiam en ĉi tiu ekzemplo, nia servo, kiu respondas al Puŝaj sciigoj, estas reuzata kiel kompleta servilo. Ĝi provizas API. Kaj nia nova evoluo jam interagas kun ĝi.
Tiutempe ni uzis version 4 de NodeJS. Nun (en 2017 - red. noto) en lastatempaj evoluoj ni uzas version 7 de NodeJS. Ne estas problemo en novaj komponantoj por impliki novajn versiojn de bibliotekoj.
Se necese, vi povas refaktori kaj altigi la version NodeJS de la Push-sciiga servo.
Kaj se ni povas konservi API-kongruon, tiam eblos anstataŭigi ĝin per aliaj projektoj, kiuj antaŭe estis uzataj.
Kion vi bezonas por aldoni Docker? Ni aldonas Dockerfile al nia deponejo, kiu priskribas la necesajn dependecojn. En ĉi tiu ekzemplo, la komponantoj estas rompitaj logike. Ĉi tiu estas la minimuma aro de backend-programisto.
Kreante novan projekton, ni kreas Dockerfile, priskribas la deziratan ekosistemon (Python, Ruby, NodeJS). En docker-compose, ĝi priskribas la necesan dependecon - la datumbazon. Ni priskribas, ke ni bezonas datumbazon de tia kaj tia versio, stoki datumojn tie kaj tie.
Ni uzas apartan trian ujon kun nginx por servi statikan. Eblas alŝuti bildojn. Backend metas ilin en antaŭpreparitan volumon, kiu ankaŭ estas muntita en ujo kun nginx, kiu donas la statikon.
Por stoki la nginx, mysql-agordon, ni aldonis Docker-dosierujon, en kiu ni stokas la necesajn agordojn. Kiam programisto faras git-klonon de deponejo sur sia maŝino, li jam havas projekton preta por loka evoluo. Ne estas demando pri kia haveno aŭ kiaj agordoj apliki.
Poste, ni havas plurajn komponantojn: admin, inform-API, push sciigoj.
Por komenci ĉion ĉi, ni kreis alian deponejon, kiun ni nomis dockerized-app. Nuntempe ni uzas plurajn deponejojn antaŭ ĉiu komponanto. Ili estas nur logike malsamaj - en GitLab ĝi aspektas kiel dosierujo, sed sur la maŝino de la programisto, dosierujo por specifa projekto. Unu nivelo malsupren estas la komponantoj, kiuj estos kombinitaj.
Ĉi tio estas ekzemplo de nur la enhavo de dockerized-app. Ni ankaŭ alportas la dosierujon Docker ĉi tien, en kiu ni plenigas la agordojn necesajn por la interagoj de ĉiuj komponantoj. Estas README.md kiu mallonge priskribas kiel ruli la projekton.
Ĉi tie ni aplikis du docker-compose dosierojn. Ĉi tio estas farita por povi kuri en paŝoj. Kiam programisto laboras kun la kerno, li ne bezonas puŝajn sciigojn, li simple lanĉas docker-komponan dosieron kaj, sekve, la rimedo estas konservita.
Se necesas integri kun puŝaj sciigoj, tiam docker-compose.yaml kaj docker-compose-push.yaml estas lanĉitaj.
Ĉar docker-compose.yaml kaj docker-compose-push.yaml estas en dosierujo, aŭtomate kreiĝas ununura virtuala reto.
Priskribo de komponantoj. Ĉi tio estas pli altnivela dosiero, kiu respondecas pri la kolekto de komponantoj. Kio estas rimarkinda ĉi tie? Ĉi tie ni enkondukas la ekvilibran komponenton.
Ĉi tio estas preta bildo de Docker, kiu rulas nginx kaj aplikaĵon, kiu aŭskultas sur la ingo Docker. Dinamika, ĉar ujoj estas ŝaltitaj kaj malŝaltitaj, ĝi regeneras la nginx-agordon. Ni distribuas la uzadon de komponantoj per trianivelaj domajnaj nomoj.
Por la Disvolva medio, ni uzas la domajnon .dev - api.informer.dev. Aplikoj kun .dev domajno estas haveblaj sur la loka maŝino de la programisto.
Plue, agordoj estas translokigitaj al ĉiu projekto kaj ĉiuj projektoj estas lanĉitaj kune samtempe.
Grafike, rezultas, ke la kliento estas nia retumilo aŭ iu ilo per kiu ni faras petojn al la ekvilibristo.
La domajna nomo-balancilo determinas kiun ujon kontakti.
Ĝi povas esti nginx, kiu donas al la administranto JS. Ĉi tio povas esti nginx, kiu donas la API, aŭ statikaj dosieroj, kiuj estas donitaj al nginx en formo de bildaj alŝutoj.
La diagramo montras, ke la ujoj estas konektitaj per virtuala reto kaj kaŝitaj malantaŭ prokurilo.
Sur la maŝino de la programisto, vi povas aliri la ujon konante la IP, sed principe ni ne uzas ĉi tion. Preskaŭ ne necesas rekta aliro.
Kiun ekzemplon rigardi por dokerigi vian aplikaĵon? Laŭ mi, bona ekzemplo estas la oficiala docker-bildo por MySQL.
Ĝi estas sufiĉe defia. Estas multaj versioj. Sed ĝia funkcieco permesas vin kovri multajn bezonojn, kiuj povas aperi en la procezo de plua evoluo. Se vi pasigas tempon kaj eltrovos kiel ĉio interagas, tiam mi pensas, ke vi ne havos problemojn en mem-efektivigo.
Hub.docker.com kutime enhavas ligilojn al github.com, kiu enhavas krudajn datumojn rekte el kiuj vi povas mem konstrui la bildon.
Plue en ĉi tiu deponejo estas docker-endpoint.sh skripto, kiu respondecas pri la komenca inicialigo kaj por plua prilaborado de la lanĉo de la aplikaĵo.
Ankaŭ en ĉi tiu ekzemplo, ekzistas la kapablo agordi uzante mediovariablojn. Difinante median variablon kiam vi rulas ununuran ujon aŭ per docker-compose, ni povas diri, ke ni devas agordi malplenan pasvorton por ke docker enradikiĝu sur MySQL aŭ kion ajn ni volas.
Estas eblo por krei hazardan pasvorton. Ni diras, ke ni bezonas uzanton, ni devas agordi pasvorton por la uzanto, kaj ni devas krei datumbazon.
En niaj projektoj, ni iomete unuigis la Dockerfile, kiu respondecas pri inicialigo. Tie ni korektis ĝin laŭ niaj bezonoj por fari ĝin nur etendo de la uzantrajtoj kiujn la aplikaĵo uzas. Ĉi tio permesis al ni simple krei datumbazon de la aplikaĵa konzolo poste. Ruby-aplikoj havas komandon por krei, modifi kaj forigi datumbazojn.
Ĉi tio estas ekzemplo de kiel aspektas specifa versio de MySQL sur github.com. Vi povas malfermi la Dockerfile kaj vidi kiel la instalado okazas tie.
docker-endpoint.sh estas la skripto respondeca por la enirpunkto. Dum la komenca inicialigo, kelkaj preparpaŝoj estas postulataj, kaj ĉiuj ĉi tiuj agoj estas elprenitaj nur en la komenca skripto.
Ni transiru al la dua parto.
Por konservi la fontkodojn, ni ŝanĝis al gitlab. Ĉi tio estas sufiĉe potenca sistemo, kiu havas vidan interfacon.
Unu el la komponantoj de Gitlab estas Gitlab CI. Ĝi permesas vin priskribi sekvencon de komandoj, kiuj poste estos uzataj por organizi kodan liveran sistemon aŭ ruli aŭtomatan testadon.
Gitlab CI 2 parolado - raporto de Ruby Russia klubo - sufiĉe detala kaj eble ĝi interesos vin.
Nun ni rigardos kio necesas por aktivigi Gitlab CI. Por komenci Gitlab CI, ni nur bezonas meti la dosieron .gitlab-ci.yml en la radikon de la projekto.
Ĉi tie ni priskribas, ke ni volas ekzekuti sekvencon de statoj kiel testo, deploji.
Ni efektivigas skriptojn, kiuj rekte vokas docker-compose por konstrui nian aplikaĵon. Ĉi tio estas nur backend ekzemplo.
Poste, ni diras, ke necesas ruli migradojn por ŝanĝi la datumbazon kaj fari testojn.
Se la skriptoj estas ekzekutitaj ĝuste kaj ne resendas erarkodon, tiam la sistemo pasas al la dua etapo de deplojo.
La deploja stadio estas nuntempe efektivigita por enscenigo. Ni ne organizis rekomencon de nula malfunkcio.
Ni perforte estingas ĉiujn ujojn, kaj poste ni levas ĉiujn ujojn denove, kolektitajn en la unua etapo dum testado.
Ni kuras por la nuna mediovariablo la datumbazajn migradojn, kiuj estis skribitaj de la programistoj.
Estas noto, ke ĉi tio validas nur por la majstra branĉo.
Kiam ŝanĝanta aliajn branĉojn ne estas ekzekutita.
Eblas organizi landojn per branĉoj.
Por organizi ĉi tion plu, ni devas instali Gitlab Runner.
Ĉi tiu utileco estas skribita en Golang. Ĝi estas unuopa dosiero, kiel estas ofta en la Golang-mondo, kiu ne postulas ajnajn dependecojn.
Ĉe ekfunkciigo, ni registras la Gitlab Runner.
Ni ricevas la ŝlosilon en la interfaco de Gitlab.
Tiam ni vokas la komencan komandon sur la komandlinio.
Agordu Gitlab Runner interage (Shell, Docker, VirtualBox, SSH)
La kodo sur Gitlab Runner efektiviĝos ĉe ĉiu komit, depende de la agordo .gitlab-ci.yml.
Kiel ĝi aspektas vide en Gitlab en la retinterfaco. Post kiam ni konektis GItlab CI, ni havas flagon kiu montras la staton de la konstruo nuntempe.
Ni vidas, ke kommit estis farita antaŭ 4 minutoj, kiu trapasis ĉiujn provojn kaj ne kaŭzis problemojn.
Ni povas rigardi pli detale la konstruaĵojn. Ĉi tie ni vidas, ke du ŝtatoj jam pasis. Testa statuso kaj deplojo statuso sur enscenigo.
Se ni klakas sur specifa konstruo, tiam estos konzola eligo de la komandoj, kiuj estis rulitaj en la procezo laŭ .gitlab-ci.yml.
Jen kiel aspektas nia produkthistorio. Ni vidas, ke estis sukcesaj provoj. Kiam testoj estas senditaj, ĝi ne iras al la sekva paŝo kaj la sursceniga kodo ne estas ĝisdatigita.
Kiajn taskojn ni solvis pri enscenigo kiam ni efektivigis docker? Nia sistemo konsistas el komponantoj kaj ni devis rekomenci, nur parton de la komponantoj, kiuj estis ĝisdatigitaj en la deponejo, kaj ne la tutan sistemon.
Por fari tion, ni devis disbati ĉion en apartajn dosierujojn.
Post kiam ni faris tion, ni havis problemon kun la fakto, ke Docker-compose kreas sian propran retan spacon por ĉiu paĉjo kaj ne vidas la komponantojn de la najbaro.
Por ĉirkaŭiri, ni kreis la reton en Docker permane. Estis skribite en Docker-compose, ke vi uzas tian reton por ĉi tiu projekto.
Tiel, ĉiu komponanto, kiu komenciĝas per ĉi tiu maŝo, vidas komponantojn en aliaj partoj de la sistemo.
La sekva numero dividas enscenigon tra pluraj projektoj.
Ĉar por ke ĉio ĉi aspektu bele kaj kiel eble plej proksime al produktado, estas bone uzi pordon 80 aŭ 443, kiu estas uzata ĉie en la TTT-ejo.
Kiel ni solvis ĝin? Ni asignis unu Gitlab Runner al ĉiuj ĉefaj projektoj.
Gitlab permesas ruli plurajn distribuitajn Gitlab Runners, kiuj simple prenos ĉiujn taskojn laŭvice en kaosa maniero kaj ruli ilin.
Por ke ni ne havu domon, ni limigis la grupon de niaj projektoj al unu Gitlab Runner, kiu senprobleme traktas niajn volumojn.
Ni movis nginx-proxy en apartan startskripton kaj aldonis kradojn por ĉiuj projektoj en ĝi.
Nia projekto havas unu kradon, kaj la ekvilibristo havas plurajn kradojn laŭ projektnomoj. Ĝi povas prokuri plu per domajnaj nomoj.
Niaj petoj venas tra la domajno sur la haveno 80 kaj estas solvitaj en kontenera grupo kiu servas ĉi tiun domajnon.
Kiuj aliaj problemoj estis tie? Jen kion ĉiuj ujoj funkcias kiel radiko defaŭlte. Ĉi tio estas radiko neegala al la radika gastiganto de la sistemo.
Tamen, se vi eniras la ujon, ĝi estos radiko kaj la dosiero, kiun ni kreas en ĉi tiu ujo, ricevas radikrajtojn.
Se la programisto eniris la ujon kaj faris tie kelkajn komandojn, kiuj generas dosierojn, tiam forlasis la ujon, tiam li havas dosieron en sia labordosierujo, al kiu li ne havas aliron.
Kiel ĝi povas esti solvita? Vi povas aldoni uzantojn, kiuj estos en la ujo.
Kiuj problemoj aperis kiam ni aldonis la uzanton?
Kiam ni kreas uzanton, ni ofte ne havas la saman grupan ID (UID) kaj uzantan ID (GID).
Por solvi ĉi tiun problemon en la ujo, ni uzas uzantojn kun ID 1000.
En nia kazo, ĉi tio koincidis kun la fakto, ke preskaŭ ĉiuj programistoj uzas Ubuntu-OS. Kaj ĉe Ubuntu, la unua uzanto havas identigilon de 1000.
Ĉu ni havas planojn?
Legu la dokumentaron de Docker. La projekto aktive disvolviĝas, la dokumentaro ŝanĝiĝas. La datumoj, kiujn oni ricevis antaŭ du aŭ tri monatoj, jam malrapide malmoderniĝas.
Kelkaj el la problemoj, kiujn ni solvis, estas tre eble jam solvitaj per normaj rimedoj.
Do mi volas iri plu jam por iri rekte al la orkestrado.
Unu ekzemplo estas la enkonstruita mekanismo de Docker nomita Docker Swarm, kiu eliras el la skatolo. Mi volas funkciigi ion en produktado bazita sur Docker Swarm-teknologio.
Generaj ujoj maloportunes labori kun ŝtipoj. Nun la ŝtipoj estas izolitaj. Ili estas disigitaj tra ujoj. Unu el la taskoj estas fari oportunan aliron al la protokoloj per la retinterfaco.
fonto: www.habr.com