Navrhujem prečítať si prepis správy Alexandra Sigacheva z Inventosu „Proces vývoja a testovania s Docker + Gitlab CI“
Tí, ktorí práve začínajú implementovať vývojový a testovací proces založený na Docker + Gitlab CI, si často kladú základné otázky. kde začať? Ako organizovať? Ako testovať?
Táto správa je dobrá, pretože hovorí štruktúrovaným spôsobom o procese vývoja a testovania pomocou Docker a Gitlab CI. Samotná správa je z roku 2017. Myslím, že z tejto správy sa môžete dozvedieť základy, metodiku, nápad, skúsenosti s používaním.
Koho to zaujíma, prosím pod mačku.
Moje meno je Alexander Sigachev. Pracujem pre Inventos. Poviem vám o mojich skúsenostiach s používaním Dockera a o tom, ako ho postupne implementujeme na projektoch vo firme.
Téma prezentácie: Vývojový proces pomocou Docker a Gitlab CI.
Toto je moja druhá prednáška o Dockerovi. V čase prvej správy sme Docker vo vývoji používali iba na vývojárskych strojoch. Počet zamestnancov, ktorí využívali Docker, bol približne 2-3 ľudia. Postupne sa nazbierali skúsenosti a posunuli sme sa o kúsok ďalej. Odkaz na náš .
Čo bude v tejto správe? Podelíme sa o skúsenosti o tom, aké hrable sme nazbierali, aké problémy sme vyriešili. Nie všade to bolo krásne, ale bolo dovolené ísť ďalej.
Naše motto je: ukotviť všetko, čo nám príde pod ruku.
Aké problémy riešime?
Ak je v spoločnosti niekoľko tímov, programátor je zdieľaný zdroj. Existujú štádiá, keď je programátor vyradený z jedného projektu a daný na určitý čas do iného projektu.
Aby programátor rýchlo pochopil, potrebuje si čo najskôr stiahnuť zdrojový kód projektu a spustiť prostredie, čo mu umožní posunúť sa ďalej v riešení problémov tohto projektu.
Zvyčajne, ak začínate od nuly, potom je v projekte málo dokumentácie. Informácie o nastavení sú dostupné len pre staromilcov. Zamestnanci si svoje pracovisko zriadia svojpomocne za jeden alebo dva dni. Aby sme to urýchlili, použili sme Docker.
Ďalším dôvodom je štandardizácia nastavení vo Vývoji. Podľa mojich skúseností vývojári vždy prevezmú iniciatívu. V každom piatom prípade je zadaná vlastná doména, napríklad vasya.dev. Vedľa neho sedí jeho sused Petya, ktorého doménou je petya.dev. Vyvíjajú webovú stránku alebo nejaký komponent systému pomocou tohto názvu domény.
Keď sa systém rozrastie a tieto názvy domén sa začnú dostávať do konfigurácií, dôjde ku konfliktu vývojového prostredia a cesta k lokalite sa prepíše.
To isté sa deje s nastaveniami databázy. Niekto si s bezpečnosťou hlavu neláme a pracuje s prázdnym root heslom. Vo fáze inštalácie MySQL niekoho požiadal o heslo a ukázalo sa, že heslo je 123. Často sa stáva, že konfigurácia databázy sa neustále mení v závislosti od potvrdenia vývojára. Niekto opravil, niekto neopravil konfiguráciu. Boli triky, keď sme vybrali nejaký druh testovacej konfigurácie .gitignore a každý vývojár musel nainštalovať databázu. To sťažilo začiatok. Okrem iného je potrebné pamätať na databázu. Databáza musí byť inicializovaná, musí byť zadané heslo, musí byť zaregistrovaný používateľ, musí byť vytvorená tabuľka atď.
Ďalším problémom sú rôzne verzie knižníc. Často sa stáva, že developer pracuje s rôznymi projektmi. Existuje projekt Legacy, ktorý začal pred piatimi rokmi (od roku 2017 – pozn. red.). V čase uvedenia na trh sme začínali s MySQL 5.5. Sú aj moderné projekty, kde sa snažíme implementovať modernejšie verzie MySQL, napríklad 5.7 alebo staršie (v roku 2017 – pozn. red.)
Každý, kto pracuje s MySQL, vie, že tieto knižnice so sebou prinášajú závislosti. Je dosť problematické prevádzkovať 2 základne spolu. Prinajmenšom je pre starých klientov problematické pripojiť sa k novej databáze. To zase vytvára niekoľko problémov.
Ďalší problém je, keď vývojár pracuje na lokálnom počítači, používa lokálne zdroje, lokálne súbory, lokálnu RAM. Všetka interakcia v čase vývoja riešenia problémov prebieha v rámci toho, že funguje na jednom stroji. Príkladom je, keď máme backend servery v Production 3 a vývojár ukladá súbory do koreňového adresára a odtiaľ nginx berie súbory, aby odpovedal na požiadavku. Keď sa takýto kód dostane do produkcie, ukáže sa, že súbor je prítomný na jednom z 3 serverov.
Smer mikroslužieb sa teraz vyvíja. Keď rozdelíme naše veľké aplikácie na nejaké malé komponenty, ktoré sa navzájom ovplyvňujú. To vám umožňuje vybrať technológie pre konkrétny balík úloh. Umožňuje tiež zdieľať prácu a povinnosti medzi vývojármi.
Frondend-developer, vyvíjajúci na JS, nemá takmer žiadny vplyv na Backend. Backend developer zase vyvíja, v našom prípade Ruby on Rails a nezasahuje do Frondendu. Interakcia sa vykonáva pomocou API.
Ako bonus sme s pomocou Dockera mohli recyklovať zdroje na Stagingu. Každý projekt si vzhľadom na svoje špecifiká vyžadoval určité nastavenia. Fyzicky bolo potrebné vyčleniť buď virtuálny server a nakonfigurovať ich samostatne, alebo zdieľať nejaké variabilné prostredie a projekty sa mohli v závislosti od verzie knižníc navzájom ovplyvňovať.
Nástroje. Čo používame?
- Samotný Docker. Dockerfile popisuje závislosti jednej aplikácie.
- Docker-compose je balík, ktorý spája niekoľko našich aplikácií Docker.
- Na ukladanie zdrojového kódu používame GitLab.
- Na systémovú integráciu používame GitLab-CI.
Správa pozostáva z dvoch častí.
Prvá časť bude hovoriť o tom, ako bol Docker spustený na strojoch vývojárov.
Druhá časť bude hovoriť o tom, ako interagovať s GitLab, ako spúšťame testy a ako zavádzame do Stagingu.
Docker je technológia, ktorá umožňuje (pomocou deklaratívneho prístupu) popísať potrebné komponenty. Toto je príklad Dockerfile. Tu vyhlasujeme, že dedíme z oficiálneho obrazu Ruby:2.3.0 Docker. Obsahuje nainštalovanú verziu Ruby 2.3. Nainštalujeme potrebné knižnice zostavení a NodeJS. Opisujeme, že vytvárame adresár /app. Nastavte adresár aplikácie ako pracovný adresár. Do tohto adresára umiestnime požadovaný minimálny súbor Gemfile a Gemfile.lock. Potom vytvoríme projekty, ktoré inštalujú tento obraz závislosti. Označujeme, že kontajner bude pripravený na počúvanie na externom porte 3000. Posledným príkazom je príkaz, ktorý priamo spúšťa našu aplikáciu. Ak vykonáme príkaz na spustenie projektu, aplikácia sa pokúsi spustiť a spustiť zadaný príkaz.
Toto je minimálny príklad súboru docker-compose. V tomto prípade ukážeme, že medzi dvoma kontajnermi existuje spojenie. Toto je priamo do databázovej služby a webovej služby. Naše webové aplikácie vo väčšine prípadov vyžadujú nejaký druh databázy ako backend na ukladanie údajov. Keďže používame MySQL, príklad je s MySQL - ale nič nám nebráni použiť inú databázu (PostgreSQL, Redis).
Preberáme z oficiálneho zdroja z centra Docker obraz MySQL 5.7.14 bez zmien. Z aktuálneho adresára zhromažďujeme obrázok, ktorý je zodpovedný za našu webovú aplikáciu. Pri prvom spustení nám zbiera obrázok. Potom spustí príkaz, ktorý tu vykonávame. Ak sa vrátime späť, uvidíme, že príkaz na spustenie cez Puma bol definovaný. Puma je služba napísaná v rubíne. V druhom prípade prepíšeme. Tento príkaz môže byť ľubovoľný v závislosti od našich potrieb alebo úloh.
Tiež popisujeme, že potrebujeme preposlať port na našom hostiteľskom počítači vývojára z 3000 3000 na XNUMX XNUMX na kontajnerovom porte. Deje sa tak automaticky pomocou iptables a jeho mechanizmu, ktorý je priamo zabudovaný v Dockeri.
Vývojár môže rovnako ako predtým získať prístup k akejkoľvek dostupnej IP adrese, napríklad 127.0.0.1 je lokálna alebo externá IP adresa počítača.
Posledný riadok hovorí, že webový kontajner závisí od db kontajnera. Keď zavoláme spustenie webového kontajnera, docker-compose nám najskôr spustí databázu. Už pri štarte databázy (v skutočnosti po spustení kontajnera! To nezaručuje pripravenosť databázy) sa spustí aplikácia, náš backend.
Tým sa zabráni chybám, keď sa databáza nevyvolá, a ušetria sa zdroje, keď zastavíme kontajner databázy, čím sa uvoľnia zdroje pre iné projekty.
Čo nám dáva využitie dockerizácie databázy na projekte. Opravujeme verziu MySQL pre všetkých vývojárov. Tým sa zabráni niektorým chybám, ktoré sa môžu vyskytnúť, keď sa verzie líšia, keď sa zmení syntax, konfigurácia, predvolené nastavenia. To vám umožňuje zadať spoločný názov hostiteľa pre databázu, prihlasovacie meno a heslo. Odchádzame od zoo mien a konfliktov v konfiguračných súboroch, ktoré sme mali predtým.
Máme možnosť použiť optimálnejšiu konfiguráciu pre Vývojové prostredie, ktorá sa bude líšiť od predvolenej. MySQL je predvolene nakonfigurovaný pre slabé počítače a jeho výkon je hneď po vybalení veľmi slabý.
Docker vám umožňuje použiť interpreter Python, Ruby, NodeJS, PHP požadovanej verzie. Zbavíme sa potreby používania nejakého správcu verzií. Predtým Ruby používal balík rpm, ktorý vám umožňoval meniť verziu v závislosti od projektu. Umožňuje tiež vďaka kontajneru Docker plynule migrovať kód a verzovať ho spolu so závislosťami. Nemáme problém pochopiť verziu interpreta aj kódu. Ak chcete aktualizovať verziu, spustite starý kontajner a zdvihnite nový kontajner. Ak sa niečo pokazilo, môžeme spustiť novú nádobu, zdvihnúť starú nádobu.
Po vytvorení imidžu budú kontajnery vo vývoji aj vo výrobe rovnaké. To platí najmä pre veľké inštalácie.
Na frontende používame JavaScipt a NodeJS.
Teraz tu máme posledný projekt na ReacJS. Vývojár spustil všetko v kontajneri a vyvíjal pomocou hot-reload.
Ďalej sa spustí úloha zostavy JavaScipt a kód skompilovaný do statiky sa zadá prostredníctvom prostriedkov na úsporu nginx.
Tu som uviedol schému nášho posledného projektu.
Aké úlohy boli vyriešené? Mali sme potrebu vybudovať systém, s ktorým budú mobilné zariadenia interagovať. Dostávajú údaje. Jednou z možností je posielať push notifikácie do tohto zariadenia.
Čo sme pre to urobili?
Do aplikácie sme rozdelili komponenty ako: admin časť na JS, backend, ktorý funguje cez REST rozhranie pod Ruby on Rails. Backend interaguje s databázou. Vygenerovaný výsledok je odovzdaný klientovi. Administračný panel komunikuje s backendom a databázou cez rozhranie REST.
Mali sme tiež potrebu posielať push notifikácie. Predtým sme mali projekt, ktorý implementoval mechanizmus, ktorý je zodpovedný za doručovanie upozornení na mobilné platformy.
Vyvinuli sme nasledujúcu schému: operátor z prehliadača interaguje s admin panelom, admin panel interaguje s backendom, úlohou je posielať Push notifikácie.
Push notifikácie interagujú s iným komponentom, ktorý je implementovaný v NodeJS.
Zostavujú sa fronty a následne sa odosielajú upozornenia podľa ich mechanizmu.
Sú tu nakreslené dve databázy. Momentálne s pomocou Dockera používame 2 nezávislé databázy, ktoré spolu nijako nesúvisia. Okrem toho majú spoločnú virtuálnu sieť a fyzické údaje sú uložené v rôznych adresároch na počítači vývojára.
To isté, ale v číslach. Tu je dôležité opätovné použitie kódu.
Ak sme predtým hovorili o opätovnom použití kódu vo forme knižníc, potom sa v tomto príklade naša služba, ktorá reaguje na upozornenia Push, opätovne používa ako kompletný server. Poskytuje API. A náš nový vývoj už s tým interaguje.
V tom čase sme používali verziu 4 NodeJS. Teraz (v roku 2017 – pozn. red.) v poslednom vývoji používame verziu 7 NodeJS. V nových komponentoch nie je problém zapojiť nové verzie knižníc.
Ak je to potrebné, môžete refaktorovať a zvýšiť verziu NodeJS zo služby oznámení Push.
A ak dokážeme zachovať kompatibilitu API, bude možné ho nahradiť inými projektmi, ktoré boli predtým používané.
Čo potrebujete pridať Docker? Do nášho úložiska pridávame súbor Dockerfile, ktorý popisuje potrebné závislosti. V tomto príklade sú komponenty rozdelené logicky. Toto je minimálna množina backendového vývojára.
Pri vytváraní nového projektu vytvoríme Dockerfile, popíšeme požadovaný ekosystém (Python, Ruby, NodeJS). V docker-compose popisuje potrebnú závislosť – databázu. Opisujeme, že potrebujeme databázu takej a takej verzie, ukladať dáta tam a tam.
Na statické podávanie používame samostatný tretí kontajner s nginx. Je možné nahrať obrázky. Backend ich dáva do vopred pripraveného objemu, ktorý je namontovaný aj v kontajneri s nginx, ktorý dáva statiku.
Na uloženie konfigurácie nginx, mysql sme pridali priečinok Docker, do ktorého ukladáme potrebné konfigurácie. Keď vývojár urobí git klon úložiska na svojom počítači, už má pripravený projekt na lokálny vývoj. Nie je pochýb o tom, aký port alebo aké nastavenia použiť.
Ďalej tu máme niekoľko komponentov: admin, inform-API, push notifikácie.
Aby sme to všetko mohli spustiť, vytvorili sme ďalšie úložisko, ktoré sme nazvali dockerized-app. V súčasnosti používame pred každým komponentom niekoľko úložísk. Len sa logicky líšia – v GitLabe to vyzerá ako priečinok, ale na vývojárskom stroji priečinok pre konkrétny projekt. O úroveň nižšie sú komponenty, ktoré sa budú kombinovať.
Toto je len príklad obsahu dockerizovanej aplikácie. Prinášame sem aj adresár Docker, v ktorom vypĺňame konfigurácie potrebné pre interakcie všetkých komponentov. Existuje súbor README.md, ktorý stručne popisuje, ako spustiť projekt.
Tu sme použili dva súbory docker-compose. Toto sa robí preto, aby bolo možné bežať v krokoch. Keď vývojár pracuje s jadrom, nepotrebuje upozornenia push, jednoducho spustí súbor docker-compose a podľa toho sa zdroj uloží.
Ak je potrebné integrovať sa s upozorneniami push, spustí sa docker-compose.yaml a docker-compose-push.yaml.
Keďže docker-compose.yaml a docker-compose-push.yaml sú v priečinku, automaticky sa vytvorí jedna virtuálna sieť.
Popis komponentov. Toto je pokročilejší súbor, ktorý je zodpovedný za zhromažďovanie komponentov. Čo je tu pozoruhodné? Tu predstavujeme komponent balancer.
Toto je hotový obrázok Docker, ktorý spúšťa nginx a aplikáciu, ktorá počúva na zásuvke Docker. Dynamické, keď sa kontajnery zapínajú a vypínajú, obnovuje konfiguráciu nginx. Manipuláciu s komponentmi distribuujeme podľa názvov domén tretej úrovne.
Pre vývojové prostredie používame doménu .dev - api.informer.dev. Aplikácie s doménou .dev sú dostupné na lokálnom počítači vývojára.
Ďalej sa konfigurácie prenesú do každého projektu a všetky projekty sa spustia naraz.
Graficky sa ukazuje, že klientom je náš prehliadač alebo nejaký nástroj, pomocou ktorého robíme požiadavky na balancer.
Nástroj na vyrovnávanie názvov domén určuje, ktorý kontajner sa má kontaktovať.
Môže to byť nginx, ktorý dáva adminovi JS. Môže to byť nginx, ktorý poskytuje API, alebo statické súbory, ktoré sa nginx poskytujú vo forme nahrávania obrázkov.
Diagram ukazuje, že kontajnery sú prepojené virtuálnou sieťou a skryté za proxy.
Na vývojárskom počítači môžete pristupovať ku kontajneru so znalosťou IP, ale v zásade to nepoužívame. Priamy prístup prakticky nie je potrebný.
Na ktorý príklad sa pozrieť pri ukotvení vašej aplikácie? Podľa mňa je dobrým príkladom oficiálny docker image pre MySQL.
Je to dosť náročné. Existuje veľa verzií. Jeho funkčnosť vám však umožňuje pokryť mnohé potreby, ktoré môžu vzniknúť v procese ďalšieho vývoja. Ak strávite čas a zistíte, ako to všetko spolu súvisí, potom si myslím, že nebudete mať žiadne problémy so sebarealizáciou.
Hub.docker.com zvyčajne obsahuje odkazy na github.com, ktorý obsahuje priamo nespracované údaje, z ktorých si môžete vytvoriť obrázok sami.
Ďalej sa v tomto úložisku nachádza skript docker-endpoint.sh, ktorý je zodpovedný za počiatočnú inicializáciu a za ďalšie spracovanie spúšťania aplikácie.
Aj v tomto príklade je možnosť konfigurácie pomocou premenných prostredia. Definovaním premennej prostredia pri spustení jedného kontajnera alebo prostredníctvom docker-compose môžeme povedať, že musíme nastaviť prázdne heslo pre docker na root na MySQL alebo čokoľvek chceme.
Existuje možnosť vytvorenia náhodného hesla. Hovoríme, že potrebujeme používateľa, musíme nastaviť heslo pre používateľa a musíme vytvoriť databázu.
V našich projektoch sme mierne zjednotili Dockerfile, ktorý je zodpovedný za inicializáciu. Tam sme to upravili podľa našich potrieb, aby to bolo len rozšírenie používateľských práv, ktoré aplikácia využíva. To nám umožnilo neskôr jednoducho vytvoriť databázu z aplikačnej konzoly. Aplikácie Ruby majú príkaz na vytváranie, úpravu a odstraňovanie databáz.
Toto je príklad toho, ako vyzerá konkrétna verzia MySQL na github.com. Môžete otvoriť súbor Dockerfile a zistiť, ako tam prebieha inštalácia.
docker-endpoint.sh je skript zodpovedný za vstupný bod. Počas úvodnej inicializácie sú potrebné niektoré prípravné kroky a všetky tieto akcie sa vykonajú práve v inicializačnom skripte.
Prejdime k druhej časti.
Pre ukladanie zdrojových kódov sme prešli na gitlab. Ide o pomerne výkonný systém, ktorý má vizuálne rozhranie.
Jednou zo súčastí Gitlabu je Gitlab CI. Umožňuje vám opísať postupnosť príkazov, ktoré sa neskôr použijú na organizáciu systému doručovania kódu alebo na spustenie automatického testovania.
Gitlab CI 2 talk - reportáž z klubu Ruby Russia - dosť podrobná a snáď vás zaujme.
Teraz sa pozrieme na to, čo je potrebné na aktiváciu Gitlab CI. Aby sme mohli spustiť Gitlab CI, stačí vložiť súbor .gitlab-ci.yml do koreňového adresára projektu.
Tu popisujeme, že chceme vykonať postupnosť stavov ako test, nasadenie.
Na zostavenie našej aplikácie spúšťame skripty, ktoré priamo volajú docker-compose. Toto je len príklad backendu.
Ďalej hovoríme, že je potrebné spustiť migrácie na zmenu databázy a spustenie testov.
Ak sa skripty vykonajú správne a nevrátia chybový kód, systém prejde do druhej fázy nasadenia.
Fáza nasadenia je v súčasnosti implementovaná pre fázovanie. Neorganizovali sme reštart s nulovým prestojom.
Všetky nádoby násilne uhasíme a potom opäť zdvihneme všetky nádoby zozbierané v prvej fáze počas testovania.
Pre aktuálnu premennú prostredia spúšťame migrácie databázy, ktoré napísali vývojári.
Existuje poznámka, že to platí iba pre hlavnú vetvu.
Pri zmene iných pobočiek sa nevykoná.
Je možné organizovať rollouty podľa pobočiek.
Aby sme to mohli ďalej organizovať, musíme nainštalovať Gitlab Runner.
Tento nástroj je napísaný v Golangu. Ide o jeden súbor, ako je to bežné vo svete Golang, ktorý nevyžaduje žiadne závislosti.
Pri spustení zaregistrujeme Gitlab Runner.
Kľúč získame vo webovom rozhraní Gitlabu.
Potom na príkazovom riadku zavoláme inicializačný príkaz.
Nastaviť Gitlab Runner interaktívne (Shell, Docker, VirtualBox, SSH)
Kód na Gitlab Runner sa spustí pri každom odovzdaní v závislosti od nastavenia .gitlab-ci.yml.
Ako to vyzerá vizuálne v Gitlabe vo webovom rozhraní. Po pripojení GItlab CI máme príznak, ktorý zobrazuje aktuálny stav zostavy.
Vidíme, že pred 4 minútami bol vykonaný commit, ktorý prešiel všetkými testami a nespôsobil žiadne problémy.
Môžeme sa bližšie pozrieť na zostavy. Tu vidíme, že dva štáty už prešli. Stav testovania a stav nasadenia na stagingu.
Ak klikneme na konkrétny build, tak tam bude konzolový výstup príkazov, ktoré boli spustené v procese podľa .gitlab-ci.yml.
Takto vyzerá história našich produktov. Vidíme, že tam boli úspešné pokusy. Po odoslaní testov neprejde k ďalšiemu kroku a fázový kód sa neaktualizuje.
Aké úlohy sme riešili na stagingu, keď sme implementovali docker? Náš systém sa skladá z komponentov a potrebovali sme reštart, iba časť komponentov, ktoré boli aktualizované v úložisku, a nie celý systém.
Aby sme to urobili, museli sme všetko rozbiť do samostatných priečinkov.
Keď sme to urobili, mali sme problém s tým, že Docker-compose vytvára vlastný sieťový priestor pre každého tátoša a nevidí susedove komponenty.
Aby sme to obišli, vytvorili sme sieť v Dockeri ručne. V Docker-compose bolo napísané, že pre tento projekt používate takúto sieť.
Každý komponent, ktorý začína touto sieťou, teda vidí komponenty v iných častiach systému.
Ďalším problémom je rozdelenie inscenácie na viacero projektov.
Keďže aby to všetko vyzeralo krásne a čo najbližšie k výrobe, je dobré použiť port 80 alebo 443, ktorý sa používa všade na WEBE.
Ako sme to vyriešili? Všetkým veľkým projektom sme pridelili jedného Gitlab Runnera.
Gitlab vám umožňuje spustiť niekoľko distribuovaných Gitlab Runnerov, ktoré jednoducho zoberú postupne všetky úlohy a spustia ich.
Aby sme nemali dom, obmedzili sme skupinu našich projektov na jeden Gitlab Runner, ktorý bez problémov zvláda naše objemy.
Presunuli sme nginx-proxy do samostatného spúšťacieho skriptu a pridali sme mriežky pre všetky projekty v ňom.
Náš projekt má jednu mriežku a balancer má niekoľko mriežok podľa názvov projektov. Môže ďalej proxy podľa názvov domén.
Naše požiadavky prichádzajú cez doménu na porte 80 a riešia sa do skupiny kontajnerov, ktorá obsluhuje túto doménu.
Aké ďalšie problémy sa vyskytli? To je to, čo všetky kontajnery štandardne spúšťajú ako root. Toto je root, ktorý sa nerovná koreňovému hostiteľovi systému.
Ak však zadáte kontajner, bude to root a súbor, ktorý vytvoríme v tomto kontajneri, získa práva root.
Ak vývojár vstúpil do kontajnera a urobil tam nejaké príkazy, ktoré generujú súbory, potom kontajner opustil, potom má vo svojom pracovnom adresári súbor, ku ktorému nemá prístup.
Ako sa to dá vyriešiť? Môžete pridať používateľov, ktorí budú v kontajneri.
Aké problémy sa vyskytli, keď sme pridali používateľa?
Pri vytváraní používateľa často nemáme rovnaké ID skupiny (UID) a ID používateľa (GID).
Na vyriešenie tohto problému v kontajneri používame používateľov s ID 1000.
V našom prípade sa to zhodovalo so skutočnosťou, že takmer všetci vývojári používajú OS Ubuntu. A na Ubuntu má prvý používateľ ID 1000.
Máme plány?
Prečítajte si dokumentáciu Docker. Projekt sa aktívne rozvíja, dokumentácia sa mení. Údaje, ktoré boli prijaté pred dvoma alebo tromi mesiacmi, sú už pomaly zastarané.
Niektoré z problémov, ktoré sme riešili, sú dosť možno už vyriešené štandardnými prostriedkami.
Takže už chcem ísť ďalej a ísť priamo do orchestrácie.
Jedným z príkladov je vstavaný mechanizmus Dockera s názvom Docker Swarm, ktorý sa dodáva z krabice. Chcem spustiť niečo vo výrobe založené na technológii Docker Swarm.
Neresiace sa kontajnery znepríjemňujú prácu s polenami. Teraz sú guľatiny izolované. Sú rozptýlené po kontajneroch. Jednou z úloh je pohodlný prístup k protokolom cez webové rozhranie.
Zdroj: hab.com