Siūlau perskaityti Aleksandro Sigačiovo pranešimo iš Inventos "Kūrimo ir testavimo procesas su Docker + Gitlab CI" stenogramą
Tie, kurie tik pradeda diegti kūrimo ir testavimo procesą, pagrįstą Docker + Gitlab CI, dažnai užduoda pagrindinius klausimus. Kur pradėti? Kaip organizuoti? Kaip išbandyti?
Ši ataskaita yra gera, nes joje struktūriškai kalbama apie kūrimo ir testavimo procesą naudojant Docker ir Gitlab CI. Pati ataskaita yra iš 2017 m. Manau, kad iš šio pranešimo galite sužinoti pagrindus, metodiką, idėją, naudojimo patirtį.
Kam rūpi, prašau po katinu.
Mano vardas Aleksandras Sigačiovas. Aš dirbu „Inventos“. Papasakosiu apie savo patirtį naudojant Docker ir kaip palaipsniui tai diegiame projektuose įmonėje.
Pristatymo tema: Kūrimo procesas naudojant Docker ir Gitlab CI.
Tai antras mano pokalbis apie Dockerį. Pirmosios ataskaitos metu kūrėjo įrenginiuose naudojome tik „Docker in Development“. „Docker“ naudojo apie 2–3 žmones. Pamažu kaupėsi patirtis ir pajudėjome šiek tiek toliau. Nuoroda į mūsų .
Kas bus šiame pranešime? Pasidalinsime patirtimi, kokį grėblį surinkome, kokias problemas išsprendėme. Ne visur buvo gražu, bet leido judėti toliau.
Mūsų šūkis yra: sumontuokite viską, ką tik galime gauti.
Kokias problemas sprendžiame?
Kai įmonėje yra kelios komandos, programuotojas yra bendras šaltinis. Būna etapų, kai programuotojas ištraukiamas iš vieno projekto ir kuriam laikui atiduodamas kitam projektui.
Kad programuotojas greitai suprastų, jam reikia atsisiųsti projekto šaltinio kodą ir kuo greičiau paleisti aplinką, kuri leistų judėti toliau sprendžiant šio projekto problemas.
Paprastai, jei pradedate nuo nulio, projekte yra mažai dokumentų. Informacija apie tai, kaip nustatyti, prieinama tik seniems žmonėms. Darbuotojai savo darbo vietą įsirengia patys per vieną ar dvi dienas. Norėdami tai paspartinti, panaudojome „Docker“.
Kita priežastis – kūrimo nustatymų standartizavimas. Mano patirtis rodo, kad kūrėjai visada imasi iniciatyvos. Kas penktu atveju įvedamas pasirinktinis domenas, pavyzdžiui, vasya.dev. Šalia jo sėdi jo kaimynė Petya, kurios domenas yra petya.dev. Naudodami šį domeno pavadinimą, jie kuria svetainę arba tam tikrą sistemos komponentą.
Kai sistema auga ir šie domenų vardai pradeda patekti į konfigūracijas, kyla kūrimo aplinkos konfliktas ir svetainės kelias perrašomas.
Tas pats atsitinka su duomenų bazės nustatymais. Kažkas nesirūpina saugumu ir dirba su tuščiu root slaptažodžiu. Diegimo etape MySQL ko nors paprašė slaptažodžio ir slaptažodis pasirodė esąs 123. Dažnai atsitinka taip, kad duomenų bazės konfigūracija nuolat keičiasi priklausomai nuo kūrėjo įsipareigojimo. Kažkas pataisė, kažkas nepataisė konfigūracijos. Buvo gudrybių, kai išėmėme kažkokią bandomąją konfigūraciją .gitignore ir kiekvienas kūrėjas turėjo įdiegti duomenų bazę. Dėl to buvo sunku pradėti. Be kita ko, būtina atsiminti apie duomenų bazę. Reikia inicijuoti duomenų bazę, įvesti slaptažodį, užregistruoti vartotoją, sukurti lentelę ir pan.
Kita problema – skirtingos bibliotekų versijos. Dažnai atsitinka taip, kad kūrėjas dirba su skirtingais projektais. Yra projektas „Legacy“, prasidėjęs prieš penkerius metus (nuo 2017 m. – red. pastaba). Paleidimo metu pradėjome nuo MySQL 5.5. Taip pat yra modernių projektų, kur bandome įdiegti modernesnes MySQL versijas, pavyzdžiui, 5.7 ar senesnes (2017 m. – red. pastaba)
Kiekvienas, kuris dirba su MySQL, žino, kad šios bibliotekos turi priklausomybių. Gana problematiška kartu paleisti 2 bazes. Bent jau seniems klientams sunku prisijungti prie naujos duomenų bazės. Tai savo ruožtu sukelia keletą problemų.
Kita problema, kai kūrėjas dirba vietiniame kompiuteryje, jis naudoja vietinius išteklius, vietinius failus, vietinę RAM. Visa sąveika kuriant problemų sprendimą vyksta atsižvelgiant į tai, kad ji veikia vienoje mašinoje. Pavyzdys yra, kai 3 gamybos versijoje turime backend serverius, o kūrėjas išsaugo failus šakniniame kataloge, o iš ten nginx paima failus, kad atsakytų į užklausą. Kai toks kodas patenka į gamybą, paaiškėja, kad failas yra viename iš 3 serverių.
Mikropaslaugų kryptis šiuo metu vystosi. Kai suskirstome savo dideles programas į keletą mažų komponentų, kurie sąveikauja tarpusavyje. Tai leidžia pasirinkti technologijas konkrečiam užduočių krūvui. Tai taip pat leidžia kūrėjams pasidalyti darbu ir pareigomis.
„Frondend-developer“, kuriantis JS, beveik neturi įtakos „Backend“. Užpakalinės programos kūrėjas savo ruožtu kuria, mūsų atveju, „Ruby on Rails“ ir netrukdo „Frondend“. Sąveika atliekama naudojant API.
Kaip premiją, padedant „Docker“, galėjome pakartotinai panaudoti „Stage“ išteklius. Kiekvienas projektas dėl jo specifikos reikalavo tam tikrų nustatymų. Fiziškai reikėjo skirti arba virtualų serverį ir juos sukonfigūruoti atskirai, arba dalintis kokia nors kintama aplinka ir projektai, priklausomai nuo bibliotekų versijos, galėjo turėti įtakos vienas kitam.
Įrankiai. Ką mes naudojame?
- Pats dokeris. Dockerfile aprašo vienos programos priklausomybes.
- „Docker-compose“ yra rinkinys, kuriame yra keletas „Docker“ programų.
- Mes naudojame GitLab šaltinio kodui saugoti.
- Sistemos integravimui naudojame GitLab-CI.
Ataskaita susideda iš dviejų dalių.
Pirmoje dalyje bus kalbama apie tai, kaip „Docker“ buvo paleistas kūrėjų įrenginiuose.
Antroje dalyje bus kalbama apie tai, kaip bendrauti su „GitLab“, kaip vykdome testus ir kaip pradedame naudoti „Staging“.
Docker yra technologija, leidžianti (naudojant deklaratyvųjį metodą) apibūdinti reikiamus komponentus. Tai yra Dockerfile pavyzdys. Čia pareiškiame, kad paveldime iš oficialaus Ruby:2.3.0 Docker vaizdo. Jame įdiegta Ruby versija 2.3. Įdiegiame reikiamas kūrimo bibliotekas ir NodeJS. Mes aprašome, kad kuriame katalogą /app. Programos katalogą nustatykite kaip darbo katalogą. Šiame kataloge talpiname reikiamą minimalų Gemfile ir Gemfile.lock. Tada kuriame projektus, kurie įdiegia šį priklausomybės vaizdą. Nurodome, kad konteineris bus paruoštas klausytis išoriniame prievade 3000. Paskutinė komanda yra komanda, kuri tiesiogiai paleidžia mūsų programą. Jei vykdysime projekto pradžios komandą, programa bandys paleisti ir paleisti nurodytą komandą.
Tai minimalus dokerio kūrimo failo pavyzdys. Šiuo atveju parodome, kad tarp dviejų konteinerių yra ryšys. Tai yra tiesiai į duomenų bazės paslaugą ir žiniatinklio paslaugą. Mūsų žiniatinklio programoms daugeliu atvejų reikia tam tikros duomenų bazės kaip duomenų saugojimo sistemos. Kadangi mes naudojame MySQL, pavyzdys yra su MySQL, bet niekas netrukdo mums naudoti kitos duomenų bazės (PostgreSQL, Redis).
Iš oficialaus šaltinio iš Docker centro paimame MySQL 5.7.14 vaizdą be pakeitimų. Vaizdą, kuris yra atsakingas už mūsų žiniatinklio programą, renkame iš dabartinio katalogo. Pirmojo paleidimo metu jis surenka mums vaizdą. Tada jis paleidžia komandą, kurią čia vykdome. Jei grįšime atgal, pamatysime, kad paleidimo komanda per Puma buvo apibrėžta. Puma yra paslauga, parašyta rubino kalba. Antruoju atveju mes nepaisome. Ši komanda gali būti savavališka, atsižvelgiant į mūsų poreikius ar užduotis.
Taip pat aprašome, kad turime persiųsti savo kūrėjo pagrindinio kompiuterio prievadą nuo 3000 iki 3000 konteinerio prievade. Tai atliekama automatiškai naudojant iptables ir jos mechanizmą, kuris yra tiesiogiai įdėtas į Docker.
Kūrėjas taip pat, kaip ir anksčiau, gali pasiekti bet kurį turimą IP adresą, pavyzdžiui, 127.0.0.1 yra vietinis arba išorinis įrenginio IP adresas.
Paskutinėje eilutėje rašoma, kad žiniatinklio konteineris priklauso nuo db konteinerio. Kai iškviečiame žiniatinklio sudėtinio rodinio pradžią, „docker-compose“ pirmiausia paleis duomenų bazę už mus. Jau pradėjus kurti duomenų bazę (tiesą sakant, po konteinerio paleidimo! Tai negarantuoja duomenų bazės parengties) paleis taikomąją programą, mūsų backend.
Taip išvengiama klaidų, kai duomenų bazė nėra iškviesta, ir taupomi ištekliai, kai sustabdome duomenų bazės konteinerį, taip atlaisvinant resursų kitiems projektams.
Kas suteikia mums galimybę projekte naudoti duomenų bazių prijungimą. Taisome MySQL versiją visiems kūrėjams. Taip išvengiama kai kurių klaidų, kurios gali atsirasti, kai skiriasi versijos, pasikeičia sintaksė, konfigūracija, numatytieji nustatymai. Tai leidžia nurodyti bendrą pagrindinio kompiuterio pavadinimą duomenų bazei, prisijungimo vardą, slaptažodį. Mes tolstame nuo pavadinimų ir konfliktų zoologijos sodo konfigūracijos failuose, kuriuos turėjome anksčiau.
Mes turime galimybę kūrimo aplinkai naudoti optimalesnę konfigūraciją, kuri skirsis nuo numatytosios. Pagal numatytuosius nustatymus „MySQL“ yra sukonfigūruotas silpniems įrenginiams ir jo našumas yra labai prastas.
Docker leidžia naudoti norimos versijos Python, Ruby, NodeJS, PHP interpretatorių. Atsikratome poreikio naudoti kažkokią versijų tvarkyklę. Anksčiau „Ruby“ naudojo rpm paketą, leidžiantį pakeisti versiją priklausomai nuo projekto. Tai taip pat leidžia „Docker“ konteinerio dėka sklandžiai perkelti kodą ir versti jį kartu su priklausomybėmis. Mums nėra problemų suprasti ir vertėjo, ir kodo versiją. Norėdami atnaujinti versiją, nuleiskite seną sudėtinį rodinį ir pakelkite naują. Jei kas nors nepavyko, galime nuleisti naują konteinerį, pakelti seną.
Sukūrus vaizdą, kūrimo ir gamybos konteineriai bus vienodi. Tai ypač pasakytina apie didelius įrenginius.
„Frondend“ naudojame „JavaScipt“ ir „NodeJS“.
Dabar turime paskutinį ReacJS projektą. Kūrėjas paleido viską, kas yra konteineryje, ir sukūrė naudodamas karštąjį perkrovimą.
Tada paleidžiama „JavaScipt“ surinkimo užduotis, o kodas, sudarytas į statinius, pateikiamas naudojant „nginx“ taupymo išteklius.
Čia pateikiau mūsų paskutinio projekto schemą.
Kokios užduotys buvo išspręstos? Mums reikėjo sukurti sistemą, su kuria sąveikauja mobilieji įrenginiai. Jie gauna duomenis. Viena iš galimybių yra siųsti tiesioginius pranešimus į šį įrenginį.
Ką mes dėl to padarėme?
Į programą suskirstėme tokius komponentus kaip: JS administratoriaus dalis, backend, kuri veikia per REST sąsają pagal Ruby on Rails. Užpakalinė programa sąveikauja su duomenų baze. Sugeneruotas rezultatas atiduodamas klientui. Administratoriaus skydelis sąveikauja su pagrindine programa ir duomenų baze per REST sąsają.
Taip pat turėjome siųsti tiesioginius pranešimus. Prieš tai turėjome projektą, kuriame įdiegtas mechanizmas, atsakingas už pranešimų pristatymą į mobiliąsias platformas.
Mes sukūrėme tokią schemą: operatorius iš naršyklės sąveikauja su administratoriaus skydeliu, administratoriaus skydelis sąveikauja su užpakaline sistema, užduotis yra siųsti Push pranešimus.
Push pranešimai sąveikauja su kitu komponentu, kuris įdiegtas NodeJS.
Sudaromos eilės, o tada pranešimai siunčiami pagal jų mechanizmą.
Čia sudarytos dvi duomenų bazės. Šiuo metu su Docker pagalba naudojame 2 nepriklausomas duomenų bazes, kurios niekaip nesusijusios viena su kita. Be to, jie turi bendrą virtualų tinklą, o fiziniai duomenys saugomi skirtinguose kūrėjo įrenginio kataloguose.
Tas pats, bet skaičiais. Čia svarbu pakartotinai naudoti kodą.
Jei anksčiau kalbėjome apie pakartotinį kodo naudojimą bibliotekų pavidalu, tai šiame pavyzdyje mūsų paslauga, kuri reaguoja į Push pranešimus, pakartotinai naudojama kaip visas serveris. Tai suteikia API. Ir mūsų naujoji plėtra jau sąveikauja su ja.
Tuo metu naudojome 4 NodeJS versiją. Dabar (2017 m. – red. pastaba) naujausiuose patobulinimuose naudojame 7 NodeJS versiją. Naujuose komponentuose nėra problemų, susijusių su naujomis bibliotekų versijomis.
Jei reikia, galite pertvarkyti ir pakelti NodeJS versiją iš Push pranešimų tarnybos.
Ir jei galime išlaikyti API suderinamumą, jį bus galima pakeisti kitais anksčiau naudotais projektais.
Ko reikia norint pridėti „Docker“? Prie savo saugyklos pridedame Dockerfile, kuriame aprašomos būtinos priklausomybės. Šiame pavyzdyje komponentai suskirstyti logiškai. Tai yra minimalus užpakalinės programos kūrėjo rinkinys.
Kurdami naują projektą sukuriame Dockerfile, aprašome norimą ekosistemą (Python, Ruby, NodeJS). Docker-compose jis apibūdina būtiną priklausomybę – duomenų bazę. Aprašome, kad reikia tokios ir tokios versijos duomenų bazės, saugoti duomenis ten ir ten.
Statiniam aptarnavimui naudojame atskirą trečiąjį konteinerį su nginx. Yra galimybė įkelti nuotraukas. Backend deda juos į iš anksto paruoštą tūrį, kuris taip pat montuojamas į konteinerį su nginx, kuris suteikia statiškumo.
Norėdami išsaugoti nginx, mysql konfigūraciją, įtraukėme Docker aplanką, kuriame saugome reikiamas konfigūracijas. Kai kūrėjas savo kompiuteryje atlieka saugyklos git kloną, jis jau turi projektą, paruoštą vietiniam vystymui. Nekyla klausimų, kokį prievadą ar kokius nustatymus taikyti.
Be to, turime keletą komponentų: administratorius, inform-API, tiesioginiai pranešimai.
Norėdami visa tai pradėti, sukūrėme kitą saugyklą, kurią pavadinome dockerized-app. Šiuo metu prieš kiekvieną komponentą naudojame kelias saugyklas. Jie tiesiog logiškai skiriasi – GitLab tai atrodo kaip aplankas, o kūrėjo kompiuteryje – konkretaus projekto aplankas. Vienu lygiu žemiau yra komponentai, kurie bus sujungti.
Tai tik dockerized-app turinio pavyzdys. Čia taip pat pateikiame Docker katalogą, kuriame užpildome visų komponentų sąveikai reikalingas konfigūracijas. Yra README.md, kuriame trumpai aprašoma, kaip vykdyti projektą.
Čia pritaikėme du „Docker“ kūrimo failus. Tai daroma tam, kad būtų galima bėgti žingsniais. Kai kūrėjas dirba su branduoliu, jam nereikia tiesioginių pranešimų, jis tiesiog paleidžia dokerio kūrimo failą ir atitinkamai išsaugomas išteklius.
Jei reikia integruoti su tiesioginiais pranešimais, paleidžiami docker-compose.yaml ir docker-compose-push.yaml.
Kadangi docker-compose.yaml ir docker-compose-push.yaml yra aplanke, automatiškai sukuriamas vienas virtualus tinklas.
Komponentų aprašymas. Tai sudėtingesnis failas, atsakingas už komponentų rinkimą. Kas čia nuostabaus? Čia pristatome balansavimo komponentą.
Tai paruoštas „Docker“ vaizdas, kuriame veikia „nginx“ ir programa, kuri klausosi „Docker“ lizde. Dinaminis, kai konteineriai įjungiami ir išjungiami, jis atkuria nginx konfigūraciją. Mes platiname komponentų tvarkymą trečiojo lygio domenų vardais.
Kūrimo aplinkai naudojame .dev domeną – api.informer.dev. Programos su .dev domenu pasiekiamos kūrėjo vietiniame kompiuteryje.
Be to, konfigūracijos perkeliamos į kiekvieną projektą ir visi projektai paleidžiami kartu tuo pačiu metu.
Grafiškai išeina, kad klientas yra mūsų naršyklė arba koks nors įrankis, su kuriuo pateikiame užklausas balansuotojui.
Domeno vardo balansavimo priemonė nustato, su kuriuo konteineriu susisiekti.
Tai gali būti nginx, kuris suteikia administratoriui JS. Tai gali būti nginx, suteikiantis API, arba statiniai failai, kurie suteikiami nginx įkeliant vaizdus.
Diagrama rodo, kad konteineriai yra sujungti virtualiu tinklu ir paslėpti už tarpinio serverio.
Kūrėjo kompiuteryje galite pasiekti konteinerį žinodami IP, bet iš esmės mes to nenaudojame. Tiesioginės prieigos praktiškai nereikia.
Į kurį pavyzdį reikėtų atkreipti dėmesį, kad programa būtų prijungta prie doko? Mano nuomone, geras pavyzdys yra oficialus MySQL docker vaizdas.
Tai gana sudėtinga. Yra daug versijų. Tačiau jo funkcionalumas leidžia patenkinti daugybę poreikių, kurie gali iškilti tolesnio tobulinimo procese. Jei praleisite laiką ir išsiaiškinsite, kaip visa tai sąveikauja, manau, kad neturėsite problemų įgyvendindami save.
Hub.docker.com paprastai pateikiamos nuorodos į github.com, kurioje yra neapdorotų duomenų, iš kurių galite patys sukurti vaizdą.
Be to, šioje saugykloje yra scenarijus docker-endpoint.sh, kuris yra atsakingas už pradinį inicijavimą ir tolesnį programos paleidimo apdorojimą.
Taip pat šiame pavyzdyje yra galimybė konfigūruoti naudojant aplinkos kintamuosius. Apibrėždami aplinkos kintamąjį, kai paleisite vieną konteinerį arba naudodami „docker-compose“, galime pasakyti, kad turime nustatyti tuščią slaptažodį, kad „docker“ galėtų įsitvirtinti „MySQL“ arba bet kuriame kitame norime.
Yra galimybė sukurti atsitiktinį slaptažodį. Mes sakome, kad mums reikia vartotojo, turime nustatyti vartotojui slaptažodį ir sukurti duomenų bazę.
Savo projektuose šiek tiek suvienijome Dockerfile, kuris yra atsakingas už inicijavimą. Ten pataisėme ją pagal savo poreikius, kad tai būtų tik programos naudojamų vartotojo teisių išplėtimas. Tai leido mums vėliau tiesiog sukurti duomenų bazę iš programos konsolės. „Ruby“ programos turi komandą duomenų bazėms kurti, keisti ir ištrinti.
Tai pavyzdys, kaip atrodo konkreti MySQL versija github.com. Galite atidaryti „Dockerfile“ ir pamatyti, kaip ten vyksta diegimas.
docker-endpoint.sh yra scenarijus, atsakingas už įėjimo tašką. Pradinio inicijavimo metu reikia atlikti tam tikrus pasiruošimo veiksmus ir visi šie veiksmai atliekami tik inicijavimo scenarijuje.
Pereikime prie antrosios dalies.
Norėdami išsaugoti šaltinio kodus, perėjome į „gitlab“. Tai gana galinga sistema, turinti vaizdinę sąsają.
Vienas iš „Gitlab“ komponentų yra „Gitlab CI“. Tai leidžia aprašyti komandų seką, kuri vėliau bus naudojama kodo pristatymo sistemai organizuoti arba automatiniam testavimui vykdyti.
Gitlab CI 2 pokalbis - reportažas iš Ruby Russia klubo - gana išsamus ir galbūt jus sudomins.
Dabar pažiūrėsime, ko reikia norint suaktyvinti Gitlab CI. Norėdami paleisti Gitlab CI, tereikia įdėti .gitlab-ci.yml failą į projekto šaknį.
Čia aprašome, kad norime vykdyti būsenų seką, pavyzdžiui, testą, diegimą.
Vykdome scenarijus, kurie tiesiogiai iškviečia docker-compose, kad sukurtume programą. Tai tik backend pavyzdys.
Toliau sakome, kad norint pakeisti duomenų bazę ir atlikti testus, būtina vykdyti perkėlimą.
Jei scenarijai vykdomi teisingai ir nepateikia klaidos kodo, sistema pereina į antrąjį diegimo etapą.
Diegimo etapas šiuo metu yra įdiegtas sustojimui. Mes neorganizavome paleidimo be prastovos.
Visus konteinerius gesiname jėga, o tada vėl pakeliame visus konteinerius, surinktus pirmajame bandymo etape.
Mes naudojame dabartinį aplinkos kintamąjį, duomenų bazių perkėlimą, kurį parašė kūrėjai.
Yra pastaba, kad tai taikoma tik pagrindinei šakai.
Keičiant kitas šakas nevykdoma.
Galima organizuoti išleidimus pagal filialus.
Norėdami tai toliau organizuoti, turime įdiegti „Gitlab Runner“.
Ši programa parašyta Golang kalba. Tai vienas failas, kaip įprasta Golango pasaulyje, kuriam nereikia jokių priklausomybių.
Paleidžiant užregistruojame „Gitlab Runner“.
Raktą gauname „Gitlab“ žiniatinklio sąsajoje.
Tada komandų eilutėje iškviečiame inicijavimo komandą.
„Gitlab Runner“ nustatymas interaktyviai („Shell“, „Docker“, „VirtualBox“, SSH)
„Gitlab Runner“ kodas bus vykdomas kiekvieną kartą, atsižvelgiant į .gitlab-ci.yml nustatymą.
Kaip ji vizualiai atrodo Gitlab žiniatinklio sąsajoje. Prijungę GItlab CI, turime vėliavėlę, kuri rodo dabartinę kūrimo būseną.
Matome, kad prieš 4 minutes buvo padarytas įsipareigojimas, kuris išlaikė visus testus ir nesukėlė jokių problemų.
Galime atidžiau pažvelgti į konstrukcijas. Čia matome, kad jau praėjo dvi valstybės. Testavimo būsena ir diegimo būsena.
Jei spustelėsite konkretų kūrinį, bus konsolės išvestis komandų, kurios buvo paleistos procese pagal .gitlab-ci.yml.
Taip atrodo mūsų gaminių istorija. Matome, kad buvo sėkmingų bandymų. Pateikus testus, jis nepereina į kitą veiksmą ir sustojimo kodas neatnaujinamas.
Kokias užduotis sprendėme scenoje diegdami docker? Mūsų sistemą sudaro komponentai ir mums reikėjo iš naujo paleisti tik dalį komponentų, kurie buvo atnaujinti saugykloje, o ne visą sistemą.
Norėdami tai padaryti, turėjome viską suskirstyti į atskirus aplankus.
Kai tai padarėme, turėjome problemų dėl to, kad „Docker-compose“ sukuria savo tinklo erdvę kiekvienam tėčiui ir nemato kaimyno komponentų.
Norėdami apeiti, tinklą Docker sukūrėme rankiniu būdu. Docker-compose buvo parašyta, kad tokį tinklą naudojate šiam projektui.
Taigi kiekvienas komponentas, kuris prasideda šiuo tinkleliu, mato komponentus kitose sistemos dalyse.
Kitas klausimas yra suskirstymas į kelis projektus.
Kadangi tam, kad visa tai atrodytų gražiai ir kuo arčiau gamybos, gerai naudoti 80 arba 443 prievadą, kuris naudojamas visur WEB.
Kaip mes tai išsprendėme? Visiems dideliems projektams priskyrėme vieną Gitlab Runner.
„Gitlab“ leidžia paleisti keletą paskirstytų „Gitlab Runners“, kurie tiesiog chaotiškai imsis visas užduotis iš eilės ir jas vykdys.
Kad neturėtume namo, savo projektų grupę apribojome vienu Gitlab Runner, kuris be problemų susidoroja su mūsų apimtimis.
Mes perkėlėme nginx-proxy į atskirą paleisties scenarijų ir pridėjome visų jame esančių projektų tinklelius.
Mūsų projektas turi vieną tinklelį, o balansyras turi keletą tinklelių pagal projektų pavadinimus. Jis gali būti toliau naudojamas pagal domenų vardus.
Mūsų užklausos gaunamos per 80 prievado domeną ir išsprendžiamos į konteinerių grupę, kuri aptarnauja šį domeną.
Kokių dar problemų buvo? Tai pagal numatytuosius nustatymus visi konteineriai veikia kaip root. Tai šaknis nelygi sistemos šakniniam šeimininkui.
Tačiau jei įvesite konteinerį, jis bus root, o failas, kurį sukuriame šiame konteineryje, gaus root teises.
Jei kūrėjas įėjo į konteinerį ir ten atliko keletą komandų, kurios generuoja failus, tada paliko konteinerį, tada jis turi failą savo darbo kataloge, prie kurio jis neturi prieigos.
Kaip tai galima išspręsti? Galite pridėti naudotojų, kurie bus sudėtiniame rodinyje.
Kokių problemų kilo, kai įtraukėme vartotoją?
Kurdami vartotoją dažnai neturime to paties grupės ID (UID) ir vartotojo ID (GID).
Norėdami išspręsti šią konteinerio problemą, naudojame vartotojus su ID 1000.
Mūsų atveju tai sutapo su tuo, kad beveik visi kūrėjai naudoja Ubuntu OS. O Ubuntu pirmasis vartotojas turi 1000 ID.
Ar turime planų?
Perskaitykite Docker dokumentaciją. Projektas aktyviai vystomas, keičiasi dokumentacija. Prieš du ar tris mėnesius gauti duomenys jau pamažu pasensta.
Kai kurios problemos, kurias išsprendėme, tikriausiai jau išspręstos standartinėmis priemonėmis.
Taigi jau noriu eiti toliau, kad eičiau tiesiai į orkestravimą.
Vienas iš pavyzdžių yra „Docker“ įmontuotas mechanizmas, vadinamas „Docker Swarm“, kuris išeina iš dėžutės. Noriu paleisti kažką gamyboje, pagrįstoje Docker Swarm technologija.
Dėl neršto konteinerių nepatogu dirbti su rąstais. Dabar rąstai yra izoliuoti. Jie yra išsibarstę po konteinerius. Viena iš užduočių – padaryti patogią prieigą prie žurnalų per žiniatinklio sąsają.
Šaltinis: www.habr.com