Dovoľujem si predstaviť prehľad správy Alexandra Sigačeva z Inventos „Proces vývoja a testovania s Dockerom + Gitlab CI“
Tí, ktorí len začínajú zavádzať proces vývoja a testovania na báze Dockeru + Gitlab CI, sa často pýtajú základné otázky. Odkiaľ začať? Ako usporiadať? Ako testovať?
Táto správa je dobrá tým, že štruktúrovaným spôsobom hovorí o procese vývoja a testovania s využitím Dockera a Gitlab CI. Samotná správa je z roku 2017. Myslím si, že z tejto správy možno čerpať základy, metodológiu, myšlienku a skúsenosti s využitím.
Kto má záujem, prosím, pod kat.
Volám sa Alexander Sigačev. Pracujem v spoločnosti Inventos. Povediem o svojich skúsenostiach s Dockerom a o tom, ako ho postupne zavádzame v projektoch spoločnosti.
Téma správy: Proces vývoja s využitím Dockera a Gitlab CI.
Toto je moja druhá správa o Dockeri. V čase prvej správy sme používali Docker len v Development na strojoch vývojárov. Počet zamestnancov, ktorí používali Docker, bol okolo 2-3 ľudí. Postupne sme nabrali skúsenosti a posunuli sa ďalej. Odkaz na našu .
Čo bude v tejto správe? Podelíme sa o skúsenosti o tom, aké prekážky sme narazili, aké problémy sme ako vyriešili. Nebolo to vždy pekné, ale umožnilo nám to posunúť sa ďalej.
Naším motom: dockerizuj všetko, čo sa dá.
Aké problémy riešime?
Keď je v spoločnosti niekoľko tímov, programátor je zdieľaný zdroj. Niekedy nastanú fázy, keď programátora vytrhnú z jedného projektu a dajú ho na nejaký čas do iného projektu.
Aby sa programátor rýchlo zorientoval, musí si stiahnuť zdrojový kód projektu a čo najrýchlejšie spustiť prostredie, ktoré mu umožní pokračovať v riešení úloh tohto projektu.
Zvyčajne, ak začíname od nuly, v projekte je málo dokumentácie. Informácie o tom, ako nastaviť, majú iba starí zamestnanci. Zamestnanci si obvykle nastavia svoje pracovné miesto za jeden až dva dni. Aby sme to urýchlili, použili sme Docker.
Ďalší dôvod – štandardizácia nastavení v Development. Podľa mojej skúsenosti sa vývojári vždy prejavujú iniciatívu. V každom piatom prípade sa zavádza vlastná doména, napríklad vasya.dev. Vedľa sedí sused Petya, ktorý má doménu petya.dev. Vyvíjajú webovú stránku alebo nejakú komponentu systému, používajúc túto doménu.
Keď sa systém zväčšuje a tieto doménové mená sa začnú objavovať v konfiguráciách, nastáva konflikt vývojových prostredí a cesta k webovej stránke sa prepíše.
To isté sa deje s nastaveniami databázy. Niekto si nerobí starosti s bezpečnosťou a pracuje s prázdnym heslom root. Niekto mal pri inštalácii MySQL požiadavku na heslo a heslo sa ukázalo ako 123. Často sa stáva, že konfigurácia databázy sa neustále menila v závislosti od zmeny vývojára. Niekto to opravil, niekto to neopravoval. Boli triky, kedy sme vyňali nejakú testovaciu konfiguráciu a .gitignore každý vývojár musel nainštalovať databázu. To komplikovalo proces spúštania. Okrem toho je potrebné pamätať si aj na databázu. Databázu je potrebné inicializovať, nastaviť heslo, nastaviť používateľa, vytvoriť tabuľku a tak ďalej.
Ďalším problémom sú rôzne verzie knižníc. Často sa stáva, že vývojár pracuje na rôznych projektoch. Existuje Legacy projekt, ktorý sme začali pred piatimi rokmi (od roku 2017 – poznámka redakcie). Pri jeho spustení sme začínali s MySQL 5.5. Existujú aj moderné projekty, kde sa snažíme zavádzať už modernejšie verzie MySQL, napríklad 5.7 alebo staršie (v roku 2017 – poznámka redakcie).
Ten, kto pracuje s MySQL, vie, že tieto knižnice so sebou ťahajú závislosti. Je dosť problematické spustiť 2 databázy spolu. Aspoň starších klientov je problematické pripojiť k novej databáze. To zase vyvoláva niekoľko problémov.
Ďalším problémom 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šetky interakcie počas vývoja riešenia problémov prebiehajú v rámci toho, že to funguje na jednom počítači. Príkladom môže byť, keď máme v produkcii 3 backend servery, a vývojár uloží súbory do koreňového adresára a odtiaľ nginx berie súbory na odpoveď na požiadavku. Keď sa takýto kód dostane do produkcie, zistí sa, že súbor je prítomný na jednom z 3 serverov.
V súčasnosti sa rozvíja oblasť mikroslužieb. Keď rozdeľujeme naše veľké aplikácie na menšie komponenty, ktoré medzi sebou komunikujú. To nám umožňuje vybrať technológie špecifické pre daný súbor úloh. Taktiež to umožňuje rozdeliť prácu a zóny zodpovednosti medzi vývojármi.
Frontend vývojár, ktorého práca s JS, prakticky neovplyvňuje backend. Backend vývojár na druhej strane vyvíja, v našom prípade, Ruby on Rails a nezasahuje do frontendu. Interakcia prebieha prostredníctvom API.
Ako bonus, pomocou Dockeru sa nám podarilo optimalizovať zdroje na Stagingu. Každý projekt, vzhľadom na jeho špecifiká, vyžadoval určité nastavenia. Fyzicky bolo potrebné vyčleniť buď virtuálny server a nastaviť ho samostatne, alebo zdieľať nejaké premenlivé prostredie, pričom projekty si mohli vzájomne ovplyvniť v závislosti od verzií knižníc.
Nástroje. Čo používame?
- Samotný Docker. V Dockerfile sú popísané závislosti jednej aplikácie.
- Docker-compose — to je spojenie, ktoré spája niekoľko našich Docker aplikácií.
- GitLab používame na uchovávanie zdrojového kódu.
- GitLab-CI používame na systémovú integráciu.
Prednáška pozostáva z dvoch častí.
Prvá časť rozpráva o tom, ako sme spúšťali Docker na pracovných staniciach vývojárov.
Druhá časť sa zameriava na to, ako spolupracovať s GitLabom, ako spúšťame testy a ako nasadzujeme na Staging.
Docker je technológia, ktorá umožňuje (použitím deklaratívneho prístupu) popísať potrebné komponenty. Toto je príklad Dockerfile. Tu vyhlasujeme, že dedíme z oficiálneho Docker obrazu Ruby:2.3.0. Obsahuje nainštalovaný Ruby verzie 2.3. Inštalujeme potrebné knižnice a NodeJS. Popisujeme, že vytvárame adresár /app. Určujeme adresár app ako pracovný adresár. Do tohto adresára umiestňujeme potrebný minimálny Gemfile a Gemfile.lock. Následne vykonávame zostavenie projektov, ktoré inštalujú závislosti tohto obrazu. Uvádzame, že kontajner bude pripravený počúvať na vonkajšom porte 3000. Posledný príkaz je príkaz, ktorý priamo spúšťa našu aplikáciu. Ak vykonáme príkaz na spustenie projektu, aplikácia sa pokúsi vykonať a spustí uvedený príkaz.
Toto je minimálny príklad súboru docker-compose. V tomto prípade ukazujeme, ako dochádza k prepojeniu dvoch kontajnerov. Ide o službu databázy a webovú službu. Naše webové aplikácie vo väčšine prípadov vyžadujú ako backend na ukladanie dát nejakú databázu. Keďže používame MySQL, uvádzame príklad s MySQL — ale nič nám nebráni používať inú databázu (PostgreSQL, Redis).
Bereme z oficiálneho zdroja na Docker hub obraz MySQL 5.7.14 bez zmien. Obraz, ktorý zodpovedá našej webovej aplikácii, zostavujeme z aktuálneho adresára. Pri prvom spustení zostaví obraz. Potom spúšťa príkaz, ktorý tu vykonávame. Ak sa vrátime späť, uvidíme, že bola definovaná príkaz na spustenie cez Puma. Puma — služba napísaná v Ruby. V druhom prípade prepisujeme. Tento príkaz môže byť ľubovoľný v závislosti od našich potrieb alebo úloh.
Tiež opisujeme, že je potrebné presmerovať port na našej hostiteľskej mašine vývojára z 3000 na port 3000 kontajnera. Toto sa vykonáva automaticky pomocou iptables a vlastného mechanizmu, ktorý je zakomponovaný v Dockeri.
Vývojár sa môže tiež ako predtým obrátiť na akúkoľvek dostupnú IP adresu, napríklad 127.0.0.1 lokálnu alebo vonkajšiu IP adresu stroja.
Posledný riadok hovorí, že kontajner web závisí od kontajnera db. Keď spúšťame kontajner web, predtým docker-compose spustí našu databázu. Už pri štarte databázy (v skutočnosti — po spustení kontajnera! Pripravenosť DB to nezaručuje) spustí našu aplikáciu, náš backend.
To umožňuje vyhnúť sa chybám, keď databáza nie je spustená, a šetrí zdroje, keď zastavíme kontajner databáz, čím oslobodzujeme samotné zdroje pre iné projekty.
Čo nám dáva použitie dockerizácie databázy v projekte. U všetkých vývojárov zaznamenávame verziu MySQL. To pomáha predchádzať niektorým chybám, ktoré môžu vzniknúť pri rozdieloch vo verziách, keď sa mení syntax, konfigurácia, predvolené nastavenia. To umožňuje uviesť spoločné hostname pre databázu, login, heslo. Odchádzame od toho zoologického zmätku mien a konfliktov v konfiguračných súboroch, ktoré boli 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 nastavené na slabé stroje a jeho výkon je z krabice veľmi nízky.
Docker umožňuje používať interpretátory Python, Ruby, NodeJS a PHP v požadovanej verzii. Zbavujeme sa potreby používať nejakého manažéra verzií. Predtým sme pre Ruby používali rpm balík, ktorý umožňoval zmeniť verziu v závislosti od projektu. Taktiež nám Docker kontajner umožňuje hladko migrovať kód a verziovať ho spolu so závislosťami. Nemáme problém určiť verziu ako interpretátora, tak aj kódu. Na aktualizáciu verzie je potrebné zrušiť starý kontajner a spustiť nový. Ak sa niečo pokazí, môžeme zrušiť nový kontajner a spustiť starý kontajner.
Po zostavení obrazu budú kontajnery v prostredí vývoja aj produkcie identické. To je obzvlášť dôležité pre veľké inštalácie.
Na frontend používame JavaScript a NodeJS.
Teraz máme posledný projekt na ReacJS. Vývojár spustil všetky kontajnery a vyvíjal s použitím hot-reload.
Následne sa spúšťa úloha na zostavenie JavaScriptu a kód, zostavený do statiky, sa poskytuje cez nginx, čím šetríme zdroje.
Tu som predložil schému nášho posledného projektu.
Aké úlohy sme riešili? Vznikla potreba vybudovať systém, s ktorým komunikujú mobilné zariadenia. Tie dostávajú dáta. Jednou z možností je posielať push notifikácie do týchto zariadení.
Čo sme pre to urobili?
Rozdelili sme aplikáciu na také komponenty ako: administračná časť na JS, backend, ktorý pracuje cez REST rozhranie pod Ruby on Rails. Backend komunikuje s databázou. Výsledok, ktorý sa generuje, sa posiela klientovi. Admin panel komunikuje s backend a databázou cez REST rozhranie.
Taktiež sme mali potrebu posielať Push notifikácie. Predtým sme mali projekt, v ktorom bol implementovaný mechanizmus, ktorý zodpovedá za doručovanie notifikácií na mobilné platformy.
Vyvinuli sme takú schému: operátor z prehliadača komunikuje s administrátorským rozhraním, administrátorské rozhranie komunikuje s backendom, kde sa nastaví úloha, že treba poslať Push notifikácie.
Push notifikácie komunikujú s inou súčasťou, ktorá je implementovaná na NodeJS.
Tvorí sa fronta a pokračuje odosielanie upozornení podľa svojho mechanizmu.
Tu sú znázornené dve databázy. V súčasnosti používame pomocou Docker dve nezávislé databázy, ktoré nie sú navzájom prepojené. Okrem toho, že majú spoločnú virtuálnu sieť, fyzické dáta sa ukladajú v rôznych adresároch na stroji vývojára.
To isté, ale v číslach. Tu je dôležité znovu používanie kódu.
Ak sme predtým hovorili o znovu používaní kódu vo forme knižníc, v tomto prípade náš servis, ktorý zodpovedá za Push upozornenia, je znovu použitý ako plne funkčný server. Poskytuje API, s ktorým interaguje naša nová vyvinutá aplikácia.
V tom čase sme používali verziu NodeJS 4. Teraz (v roku 2017 — pozn. red.) v nových projektoch používame verziu NodeJS 7. Nie sú žiadne problémy pri zapojení nových verzií knižníc do nových komponentov.
V prípade potreby je možné vykonať refaktoring a zvýšiť verziu NodeJS na servise Push upozornení.
A ak budeme môcť zachovať kompatibilitu s API, môžeme ho nahradiť v iných projektoch, ktoré boli použité skôr.
Čo potrebujeme na pridanie Dockeru? Pridáme do nášho repozitára Dockerfile, ktorý popisuje potrebné závislosti. V tomto prípade sú komponenty rozdelené podľa logiky. Toto je minimálny súbor pre backendového vývojára.
Pri vytváraní nového projektu vytvoríme Dockerfile a popíšeme potrebný ekosystém (Python, Ruby, NodeJS). V docker-compose popisujeme potrebnú závislosť — databázu. Popisujeme, že potrebujeme databázu určitých verzií, ktorá uchováva dáta tam a tam.
Na podávanie statických súborov používame samostatný tretí kontajner s nginx. Je predpokladaná možnosť nahrávania obrázkov. Backend ich ukladá do vopred pripraveného zväzku, ktorý je tiež pripojený k nginx kontajneru, ktorý poskytuje statiku.
Na uloženie konfigurácie nginx a mysql sme pridali priečinok Docker, v ktorom uchovávame potrebné konfigurácie. Keď si vývojár urobí git clone repozitára na svoj stroj, získava už projekt, ktorý je pripravený na lokálny vývoj. Nevzniká otázka, aký port alebo aké nastavenia aplikovať.
Následne máme niekoľko komponentov: administrátor, informačné API, push upozornenia.
Aby sme to všetko spustili, vytvorili sme ďalší repozitár, ktorý sme nazvali dockerized-app. V súčasnosti používame niekoľko repozitárov pre každý komponent. Tieto repozitáre sa logicky líšia — v GitLabe to vyzerá ako priečinok, zatiaľ čo na počítači developera je to priečinok pre konkrétny projekt. Na nižšej úrovni sú komponenty, ktoré sa budú spájať.
Toto je príklad obsahu dockerized-app. Rovnako sem umiestňujeme Docker adresár, v ktorom napĺňame konfigurácie potrebné na interakciu všetkých komponentov. Je tu README.md, v ktorom je stručne opísané, ako spustiť projekt.
Tu sme použili dva docker-compose súbory. Toto je urobené, aby sme mali možnosť spúšťať to stupňovito. Keď developer pracuje s jadrom a nepotrebuje Push notifikácie, spúšťa len docker-compose súbor a tým sa šetrí zdroj.
Ak je potrebná integrácia s Push notifikáciami, spúšťa 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í jednotná virtuálna sieť.
Opis komponentov. Toto je rozsiahlejší súbor, ktorý zodpovedá za zber komponentov. Čo je na ňom pozoruhodné? Tu zavádzame komponent vyrovnávač zaťaženia.
Toto je hotový Docker obraz, v ktorom sa spúšťa nginx a aplikácia, ktorá načúva Docker socketu. Dynamicky, pri zapínaní a vypínaní kontajnerov, regeneruje konfiguračný súbor nginx. Prístup k komponentom je rozdelený podľa doménových mien 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 developera.
Ďalej sa prenesú konfigurácie pre každý projekt a všetky projekty sa spustia spoločne súčasne.
Ak by sme to graficky znázornili, klientom je náš prehliadač alebo nejaký nástroj, ktorým vykonávame požiadavky na vyrovnávač zaťaženia.
Vyrovnávač zaťaženia pomocou doménového mena určuje, na ktorý kontajner je potrebné sa obrátiť.
Môže to byť nginx, ktorý poskytuje JS administrácie. Môže to byť nginx, ktorý poskytuje API alebo statické súbory, ktoré nginx poskytuje vo forme sťahovania obrázkov.
Na schéme je vidno, že kontajnery sú spojené do virtuálnej siete a skryté za proxy.
Na vývojárskom počítači je možné pristupovať ku kontajneru pomocou IP, ale v zásade to nepoužívame. Priame oslovenie v podstate nie je potrebné.
Aký príklad si pozrieť, aby som dockerizoval svoju aplikáciu? Podľa mňa je dobrým príkladom oficiálny docker obraz pre MySQL.
Je dostatočne zložitý. Existuje veľa verzií. Ale jeho funkcie pokrývajú množstvo potrieb, ktoré môžu vzniknúť počas ďalšieho vývoja. Ak si nájdete čas a pochopíte, ako to všetko funguje, myslím, že v samostatnom implementovaní nebudete mať problémy.
Na hub.docker.com zvyčajne existujú odkazy na github.com, kde sú zahrnuté priamo surové údaje, z ktorých si môžete sami zostaviť obraz.
Ďalej sa v tomto repozitári nachádza skript docker-endpoint.sh, ktorý zodpovedá za počiatočnú inicializáciu a za ďalšie spracovanie spustenia aplikácie.
Taktiež v tomto príklade je možnosť konfigurácie pomocou premenných prostredia. Stanovením premenných prostredia pri spustení jednotlivého kontajnera alebo cez docker-compose môžeme povedať, že potrebujeme nastaviť prázdne heslo pre docker pre root na MySQL, alebo nejaké, ktoré chceme.
Existuje možnosť vytvoriť náhodné heslo. Hovoríme, že potrebujeme používateľa, potrebujeme nastaviť používateľovi heslo a potrebujeme vytvoriť databázu.
Vo svojich projektoch sme trochu unifikovali Dockerfile, ktorý zodpovedá za inicializáciu. Tam sme ho prispôsobili svojim potrebám tak, aby robil jednoducho rozšírenie práv používateľa, ktoré používa aplikácia. To umožnilo jednoducho vytvoriť databázu z konzoly aplikácie. V Ruby aplikáciách je príkaz na vytváranie, zmeny a odstraňovanie databáz.
Tento príklad ukazuje, ako vyzerá konkrétna verzia MySQL na github.com. Dockerfile si môžete otvoriť a pozrieť, ako prebieha inštalácia.
docker-endpoint.sh je skript zodpovedajúci za vstupný bod. Pri počiatočnej inicializácii sú potrebné určité kroky na prípravu a všetky tieto kroky sú vyčlenené práve do skriptu inicializácie.
Prechádzame k druhej časti.
Na uchovávanie zdrojových kódov sme prešli na gitlab. Je to dostatočne mocný systém, ktorý má vizuálne rozhranie.
Jednou z komponent Gitlab je Gitlab CI. Umožňuje popisovať sled príkazov, ktoré sa následne použijú na organizovanie systému dodávania kódu alebo spustenia automatického testovania.
Prezentácia o Gitlab CI 2 — prezentácia z Ruby Russia club — je dostatočne podrobná a možno vás zaujme.
Teraz si povieme, čo je potrebné na aktiváciu Gitlab CI. Na spustenie Gitlab CI nám stačí do koreňa projektu umiestniť súbor .gitlab-ci.yml.
Tu popisujeme, aké úlohy chceme vykonávať v sekvenčnom poradí, ako sú testy a nasadenie.
Vykonávame skripty, ktoré priamo spúšťajú docker-compose zostavu našej aplikácie. Toto je príklad pre backend.
Potom hovoríme, že je potrebné spustiť migrácie zmien databázy a vykonať testy.
Ak skripty prebehli správne a nevrátili chybový kód, systém prejde do druhej etapy nasadenia.
Etapa nasadenia je momentálne realizovaná pre staging. Neprebehlo žiadne bezprerušené reštartovanie.
Nútene vypneme všetky kontajnery a potom všetky kontajnery znova spustíme, zostavené v prvej etape pri testovaní.
Spúšťame migrácie databáz pre aktuálne prostredie, ktoré napísali vývojári.
Je poznámka, že to treba aplikovať iba na vetvu master.
Pri zmene iných vetiev sa nevykonáva.
Existuje možnosť organizovať nasadenie podľa vetiev.
Aby sme to ďalej zorganizovali, musíme nainštalovať Gitlab Runner.
Tento nástroj je napísaný v Golangu. Je to jediný súbor, ako je zvykom vo svete Golangu, ktorý si nevyžaduje žiadne závislosti.
Pri spustení registrujeme Gitlab Runner.
Získame v webovom rozhraní Gitlab kľúč.
Potom zavoláme príkaz na inicializáciu v príkazovom riadku.
Nastavujeme Gitlab Runner v interaktívnom režime (Shell, Docker, VirtualBox, SSH)
Kód na Gitlab Runner vykoná pri každom commite podľa nastavenia .gitlab-ci.yml.
Ako to vizuálne vyzerá v Gitlab v webovom rozhraní. Po pripojení Gitlab CI sa objaví vlajka, ktorá ukazuje, v akom stave je aktuálna zostava.
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 podrobnejšie pozrieť na buildy. Tu vidíme, že už prešli dvoma stavmi. Stav testovania a stav nasadenia na staging.
Ak klikneme na konkrétny build, bude tam konzolový výstup príkazov, ktoré boli spustené v procese podľa .gitlab-ci.yml.
Takto vyzerá história nášho produktu. Vidíme, že boli úspešné pokusy. Keď testy zlyhajú, ďalší krok sa nepremieňa a kód na staging sa neaktualizuje.
Aké úlohy sme riešili na staging, keď sme zaviedli docker? Náš systém sa skladá z komponentov a vznikla potreba reštartovať len časť komponentov, ktoré boli aktualizované v repozitári, a nie celý systém.
Na to sme museli všetko roztriediť do samostatných priečinkov.
Po tom, čo sme to urobili, sme narazili na problém, že Docker-compose vytvára pre každý priečinok svoje vlastné sieťové prostredie a nevidí komponenty susedov.
Aby sme to obišli, vytvorili sme sieť v Dockeri manuálne. V Docker-compose sme špecifikovali, aby pre tento projekt používal túto sieť.
Týmto spôsobom každý komponent, ktorý sa spúšťa s touto sieťou, vidí komponenty v iných častiach systému.
Ďalší problém - to je rozdelenie staging medzi niekoľkými projektmi.
Aby to všetko vyzeralo pekne a čo najbližšie k production, je dobré používať port 80 alebo 443, ktorý sa bežne používa vo WEBe.
Ako sme to vyriešili? Pridelili sme jedného Gitlab Runnera všetkým veľkým projektom.
Gitlab umožňuje spustiť niekoľko distribuovaných Gitlab Runnerov, ktoré budú jednoducho po poradí v chaotickom poradí brať všetky úlohy a spracovávať ich.
Aby sme predišli chaosu, obmedzili sme skupinu našich projektov jedným Gitlab Runnerom, ktorý si s našimi objemami bez problémov poradí.
Nginx-proxy sme presunuli do samostatného spúšťacieho skriptu a tam sme špecifikovali siete všetkých projektov.
Náš projekt má jednu sieť, zatiaľ čo vyvažovač má niekoľko sietí podľa názvov projektov. Môže proxy ďalej podľa doménových mien.
Žiadosti prichádzajú na doménu na porte 80 a sú spracovávané v skupine kontajnerov, ktorá obsluhuje túto doménu.
Aké ďalšie problémy sme mali? To, že predvolene všetky kontajnery sa vykonávajú pod používateľom root. Tento root nie je rovný rootu hostiteľského systému.
Ak sa však prihlásite do kontajnera, bude to root a súbor, ktorý vytvoríme v tomto kontajneri, dostane práva root.
Ak sa vývojár prihlásil do kontajnera a vykonal tam nejaké príkazy, ktoré generujú súbory, potom po odhlásení z kontajnera v jeho pracovnom adresári bude mať súbor, ku ktorému nemá prístup.
Ako to môžeme vyriešiť? Môžeme pridať používateľov, ktorí budú v kontajneri.
Aké problémy nastali, keď sme pridali používateľa?
Pri vytváraní používateľa sa nám často nezhodujú ID skupiny (UID) a ID používateľa (GID).
Aby sme tento problém vyriešili, v kontajneri používame používateľov s ID 1000.
V našom prípade to súhlasí s tým, že prakticky všetci vývojári používajú OS Ubuntu. U OS Ubuntu má prvý používateľ ID 1000.
Aké máme plány?
Prečítať si dokumentáciu k Dockeru. Projekt sa aktívne vyvíja, dokumentácia sa mení. Údaje, ktoré sme získali pred dvoma-tromi mesiacmi, už pomaly zastarávajú.
Niektoré problémy, ktoré sme riešili, sú už pravdepodobne vyriešené štandardnými prostriedkami.
Tak veľmi by sme chceli postúpiť ďalej a prejsť priamo k orchestrácii.
Jedným z príkladov je zabudovaný mechanizmus v Dockeri s názvom Docker Swarm, ktorý je k dispozícii out-of-the-box. Radi by sme spustili niečo v produkcii na báze technológie Docker Swarm.
Generovanie kontajnerov komplikuje prácu s logmi. Teraz sú logy izolované. Sú rozptýlené po kontajneroch. Jednou z úloh je sprístupniť logy cez webové rozhranie.
Zdroj: habr.com
