Odporúčam oboznámiť sa s interpretáciou prezentácie Alexandra Sigacheva z Inventos „Proces vývoja a testovania pomocou Docker + Gitlab CI“
Tí, ktorí práve začínajú s implementáciou procesu vývoja a testovania založeného na Docker + Gitlab CI, sa často pýtajú na základné otázky. Odkiaľ začať? Ako organizovať? Ako testovať?
Táto prezentácia je dobrá tým, že štruktúrovane opisuje proces vývoja a testovania s využitím Docker a Gitlab CI. Samotná prezentácia je z roku 2017. Myslím, že z tejto prezentácie sa dajú načerpať základy, metodológia, myšlienky a skúsenosti.
Kto má záujem, prosím, pod kat.
Volám sa Alexander Sigachev. Pracujem v spoločnosti Inventos. Povieme si o mojich skúsenostiach s Dockerom a o tom, ako ho postupne implementujeme do projektov v spoločnosti.
Téma prezentácie: Proces vývoja s využitím Docker a Gitlab CI.
Toto je moja druhá prezentácia o Dockeri. V čase prvej prezentácie sme Docker používali len v prostredí vývoja na počítačoch vývojárov. Počet zamestnancov, ktorí používali Docker, bol približne 2-3 osoby. Postupne sme získali skúsenosti a posunuli sa ďalej. Odkaz na našu .
Čo bude v tejto prezentácii? Podelíme sa o našu skúsenosť, aké prekážky sme nazbierali, aké problémy sme ako vyriešili. Nie všetko bolo elegantné, ale umožnilo nám to posunúť sa ďalej.
Naše motto: dockerizuj všetko, čo nám príde pod ruky.
Aké problémy riešime?
Keď je v spoločnosti niekoľko tímov, programátor je zdieľaným zdrojom. Sú fázy, keď programátora vytiahnu z jedného projektu a poskytnú ho na určitý čas do iného projektu.
Aby sa programátor rýchlo zapracoval, je potrebné, aby si stiahol zdrojový kód projektu a čo najrýchlejšie spustil prostredie, ktoré mu umožní ďalej pracovať na úlohách tohto projektu.
Zvyčajne, ak sa začína od nuly, tak dokumentácia v projekte je zanedbaná. Informácie o tom, ako nastaviť, majú len starí zamestnanci. Zamestnanci si samostatne nastavujú svoje pracovné prostredie za jeden-dva dni. Aby sa to urýchlilo, sme použili Docker.
Ďalší dôvod — to je štandardizácia nastavení v prostredí vývoja. Podľa mojich skúseností, 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. Spoločne vyvíjajú webovú stránku alebo nejakú súčasť systému, používajúc tieto domény.
Keď sa systém rozrastá a tieto doménové mená začínajú preniknúť do konfigurácií, vzniká konflikt vývojových prostredí a cesta k webovej lokalite sa prepíše.
To isté sa deje s nastaveniami databázy. Niekto sa nezaoberá bezpečnosťou a pracuje s prázdnym heslom root. Niekto iný na fáze inštalácie MySQL vyžaduje heslo, a to sa ukáže ako 123. Často sa stáva, že konfigurácia databázy sa neustále menila v závislosti od commitov vývojára. Niekto opravil, niekto neopravoval konfiguráciu. Boli finty, keď sme presúvali nejakú testovaciu konfiguráciu do .gitignore a každý vývojár musel nainštalovať databázu. To sťažovalo proces spustenia. Okrem všetkého treba pamätať aj na databázu. Databázu treba inicializovať, zapísať heslo, definovať používateľa, vytvoriť tabuľku a tak ďalej.
Ďalší problém — to sú rôzne verzie knižníc. Často sa stáva, že vývojár pracuje na rôznych projektoch. Existuje Legacy projekt, ktorý sa začínal pred piatimi rokmi (od roku 2017 — pozn. red.). Pri rozbehu 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 novšie (v roku 2017 — pozn. red.)
Ten, kto pracuje s MySQL, vie, že tieto knižnice so sebou ťahajú závislosti. Dosť problematické je spustiť 2 databázy súčasne. Aspoň starých klientov je ťažké pripojiť k novej databáze. To vnáša do procesu niekoľko problémov.
Ďalší problém nastáva, keď vývojár pracuje na lokálnom stroji, používa lokálne zdroje, lokálne súbory, lokálnu RAM. Všetka interakcia počas vývoja riešení prebieha v rámci toho, čo funguje na jednom stroji. Príkladom môže byť situácia, keď máme v produkcii 3 backendové servery, a vývojár ukladá súbory do koreňového adresára, odkiaľ nginx načítava 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 smer mikroslužieb. Keď rozdelíme naše veľké aplikácie na menšie komponenty, ktoré medzi sebou vzájomne komunikujú. To umožňuje vybrať technológie pre konkrétny súbor úloh. Takisto to umožňuje rozdeliť prácu a zónu zodpovednosti medzi vývojárov.
Frontend vývojár, ktorý vyvíja na JS, prakticky nemá vplyv na backend. Backend vývojár na druhej strane vyvíja, v našom prípade, Ruby on Rails a neprekáža frontend. Interakcia prebieha pomocou API.
Ako bonus, pomocou Dockeru sa nám podarilo optimalizovať zdroje na stagingu. Každý projekt vzhľadom na svoju špecifiku vyžadoval určité nastavenia. Fyzicky bolo potrebné vyčleniť buď virtuálny server a samostatne ich nastaviť, alebo rozdeľovať nejaké premenlivé prostredie, pričom projekty mohli v závislosti od verzií knižníc ovplyvňovať navzájom.
Nástroje. Čo používame?
- Prímo samotný Docker. V Dockerfile sú popísané závislosti jednej aplikácie.
- Docker-compose — je to zoskupenie, ktoré spája niekoľko našich Docker aplikácií.
- GitLab používame na ukladanie zdrojového kódu.
- GitLab-CI používame na systémovú integráciu.
Prezentácia sa skladá z dvoch častí.
Prvá časť sa zameriava na to, ako sme spúšťali Docker na strojoch vývojárov.
Druhá časť sa zameriava na to, ako interagovať s GitLabom, ako spúšťame testy a ako nasadzujeme na staging.
Docker je technológia, ktorá umožňuje (používajúc deklaratívny prístup) opísať potrebné komponenty. To je príklad Dockerfile. Tu oznamujeme, že dedíme z oficiálneho Docker obrazu Ruby:2.3.0. Obsahuje nainštalovaný Ruby verzie 2.3. Inštalujeme potrebné knižnice na zostavenie a NodeJS. Oznámime, ž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. Potom vykonáme zostavenie projektov, ktoré inštalujú závislosti tohto obrazu. Uvádzame, že kontajner bude pripravený počúvať na externom porte 3000. Posledný príkaz je ten, ktorý priamo spúšťa našu aplikáciu. Ak vykonáme príkaz na spustenie projektu, aplikácia sa pokúsi vykonať a spúšťa uvedený príkaz.
Toto je minimálny príklad súboru docker-compose. V tomto prípade ukazujeme, ako sú prepojené dva kontajnery. Ide o službu databázy a webovú službu. Naše webové aplikácie v drvivej väčšine prípadov vyžadujú na ukladanie údajov nejakú databázu ako backend. Keďže používame MySQL, použijeme príklad s MySQL — nič však nebráni použitiu inej databázy (PostgreSQL, Redis).
Sťahujeme oficiálny obraz MySQL 5.7.14 bez zmien z Docker hub. Obraz, ktorý zodpovedá našej webovej aplikácii, zostavujeme z aktuálneho adresára. Pri prvom spustení nám zostaví obraz. Potom spustí príkaz, ktorý tu vykonávame. Ak sa vrátime späť, uvidíme, že bola určená príkaz na spustenie cez Puma. Puma je služba napísaná v Ruby. V druhom prípade prepisujeme. Tento príkaz môže byť akýkoľvek v závislosti od našich potrieb alebo úloh.
Tiež popisujeme, že je potrebné preniesť port z našej hostiteľskej mašiny, vývojového stroja, z portu 3000 na port 3000 kontajnera. To sa vykonáva automaticky pomocou iptables a jeho mechanizmu, ktorý je priamo zabudovaný v Dockeri.
Vývojár sa môže rovnako ako predtým obrátiť na akúkoľvek dostupnú IP adresu, napríklad 127.0.0.1, miestnu alebo externú 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. Po naštartovaní databázy (v skutočnosti — po spustení kontajnera! Pripravenosť DB to nezaručuje) sa spustí naša aplikácia, náš backend.
To umožňuje vyhnúť sa chybám, keď databáza nie je spustená, a šetrí zdroje, keď zastavujeme kontajner databázy, čím uvoľňujeme tieto prostriedky pre iné projekty.
Čo nám dáva používanie dockerizácie databázy v projekte. U všetkých vývojárov fixujeme verziu MySQL. To pomáha predchádzať niektorým chybám, ktoré môžu vzniknúť pri nesúlade verzií, keď sa mení syntax, konfigurácia, predvolené nastavenia. Umožňuje nám určiť spoločné hostname pre databázu, prihlasovacie meno a heslo. Odchádzame od toho zverinca mien a konfliktov v konfiguračných súboroch, ktoré boli predtým.
Máme možnosť používať optimálnejšiu konfiguráciu pre vývojové prostredie, ktorá sa bude líšiť od predvolenej. MySQL je predvolene nakonfigurované na slabšie zariadenia a jeho výkon je v základnej verzii veľmi nízky.
Docker umožňuje používať interpretrátory Python, Ruby, NodeJS, PHP v potrebnej verzii. Zbavujeme sa potreby používať nejakého manažéra verzií. Predtým sme pre Ruby používali rpm balík, ktorý umožňoval meniť verziu v závislosti od projektu. Takisto to umožňuje, vďaka Docker kontajneru, plynule migrovať kód a verziovať ho spolu so závislosťami. Nemáme problém pochopiť verziu ako interpretrátora, tak aj kódu. Pre aktualizáciu verzie je potrebné zrušiť starý kontajner a spustiť nový kontajner. 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 rovnaké. To je obzvlášť aktuálne pre veľké inštalácie.
Na frontend používame JavaScript a NodeJS.
Aktuálne máme náš posledný projekt na ReactJS. Vývojár spúšťal všetky kontajnery a vyvíjal s použitím hot-reload.
Následne sa spúšťa úloha na zostavenie JavaScriptu a kód, ktorý bol zostavený do statických súborov, sa dodáva cez nginx, čím sa šetria zdroje.
Tu som priložil schému nášho posledného projektu.
Aké úlohy sme riešili? Vznikla nám potreba vybudovať systém, s ktorým interagujú mobilné zariadenia. Tieto získavajú dáta. Jedna z možností je poslať push notifikácie na toto zariadenie.
Čo sme preto urobili?
Rozdelili sme aplikáciu na také komponenty ako: administratívna časť na JS, backend, ktorý pracuje cez REST rozhranie pod Ruby on Rails. Backend interaguje s databázou. Výsledok, ktorý sa generuje, sa odovzdáva klientovi. Administratívka s backendom a databázou interaguje cez REST rozhranie.
Takisto 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.
Vypracovali sme takúto schému: operátor z prehľadávača interaguje s adminstráciou, administrácia interaguje s backendom, je nastavená úloha, že treba poslať Push notifikácie.
Push notifikácie interagujú s iným komponentom, ktorý je implementovaný na NodeJS.
Vytvárajú sa fronty a následne ide podľa svojho mechanizmu odosielanie oznámení.
Tu sú znázornené dve databázy. V súčasnosti používame pomocou Dockeru 2 nezávislé databázy, ktoré nie sú nijako prepojené. Okrem toho, že majú spoločnú virtuálnu sieť, fyzické dáta sú uložené v rôznych adresároch na stroji vývojára.
To isté, ale v číslach. Tu je dôležité opätovné využívanie kódu.
Ak sme predtým hovorili o opätovnom využívaní kódu vo forme knižníc, v tomto prípade náš servis, ktorý zodpovedá za Push oznámenia, sa opätovne využíva ako kompletný server. Poskytuje API. A s ním interaguje už naša nová vyvinutá aplikácia.
V tom čase sme používali 4. verziu NodeJS. Teraz (v roku 2017 — pozn. red.) v nových projektoch používame 7. verziu NodeJS. Nie sú problémy s novými komponentmi využívať nové verzie knižníc.
Ak bude potrebné, môžeme vykonať refaktoring a aktualizovať verziu NodeJS na servise Push oznámení.
Ak sa nám podarí udržať kompatibilitu podľa API, bude možné ho vymeniť v iných projektoch, ktoré boli použité predtým.
Čo je potrebné na pridanie Dockeru? Pridáme do nášho repozitára Dockerfile, ktorý popisuje potrebné závislosti. V tomto príklade sú komponenty rozdelené podľa logiky. Toto je minimálny súbor pre backend vývojára.
Pri vytváraní nového projektu vytvárame Dockerfile, opisujeme potrebnú ekosystému (Python, Ruby, NodeJS). V docker-compose opisujeme potrebnú závislosť — databázu. Opíšeme, že potrebujeme verziu databázy takúto, a uchovávať dáta tam a tam.
Na podávanie statiky používame samostatný tretí kontajner s nginx. Je predpokladaná možnosť načítania obrázkov. Backend ich uklada do vopred pripraveného zväzku, ktorý je takisto pripojený k nginx kontajneru, ktorý poskytuje statiku.
Aby sme uchovávali konfiguráciu nginx, mysql, pridali sme do zložky Docker priečinok, v ktorom uchovávame potrebné konfigurácie. Keď vývojár vykoná git clone repozitára na svoj stroj, dostane už projekt pripravený na lokálny vývoj. Nevzniká otázka, aký port alebo aké nastavenia aplikovať.
Ďalej máme niekoľko komponentov: administrátor, informačné API, push oznámenia.
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 sa logicky odlišujú — v GitLabe to vyzerá ako priečinok, zatiaľ čo na počítači vývojára ide o priečinok pre konkrétny projekt. Na nižšej úrovni sa nachádzajú komponenty, ktoré budú zlúčené.
Toto je príklad obsahu dockerized-app. Taktiež sem vnášame Docker priečinok, v ktorom plníme konfigurácie potrebné pre interakcie všetkých komponentov. Obsahuje README.md, v ktorom je stručne popísané, ako spustiť projekt.
Tu sme použili dva súbory docker-compose. Je to urobené s cieľom mať možnosť spúšťať ich postupne. Keď vývojár pracuje s jadrom a nepotrebuje Push notifikácie, spustí jednoducho súbor docker-compose a tým sa šetrí zdroj.
Ak je potrebná integrácia s Push notifikáciami, spustí sa docker-compose.yaml a docker-compose-push.yaml.
Keďže docker-compose.yaml a docker-compose-push.yaml sú v tom istom priečinku, automaticky sa vytvorí jednotná virtuálna sieť.
Popis komponentov. Je to rozšírený súbor, ktorý zodpovedá za zloženie komponentov. Čo je tu výnimočné? Tu zavádzame komponent vyrovnávača.
Toto je hotový Docker obraz, v ktorom beží nginx a aplikácia, ktorá počúva na Docker socket. Dynamicky, pri zapínaní a vypínaní kontajnerov, regeneruje konfiguráciu nginx. Interakcie s komponentami rozdeľujeme podľa doménových mien tretej úrovne.
Pre vývojové prostredie používame doménu .dev — api.informer.dev. Aplikácia s doménou .dev je prístupná na lokálnom počítači vývojára.
Ďalej sa prenesú konfigurácie do každého projektu a spustia sa všetky projekty súčasne.
Ak by sme to graficky znázornili, klientom je náš prehliadač alebo nejaký nástroj, ktorým zasielame požiadavky na vyrovnávač.
Vyrovnávač podľa doménového mena určuje, ku ktorému kontajneru je potrebné sa obracať.
Môže to byť nginx, ktorý poskytuje JS administrátorskej sekcie. Môže to byť nginx, ktorý poskytuje API alebo statické súbory, ktoré sú odovzdávané nginx vo forme nahrávania obrázkov.
Na schéme je vidieť, že kontajnery sú spojené v virtuálnej sieti a skryté za proxy.
Na vývojárskom počítači môžete pristupovať k kontajneru pomocou IP, ale my to vo všeobecnosti nepoužívame. Priama potreba prístupu sa prakticky nevyskytuje.
Aký príklad si pozrieť, aby ste dockerizovali svoju aplikáciu? Podľa môjho názoru je dobrým príkladom oficiálny docker obraz pre MySQL.
Je dosť komplikovaný. Existuje veľa verzií. Ale jeho funkčnosť pokryje mnohé potreby, ktoré môžu vzniknúť v priebehu ďalšieho vývoja. Ak strávite čas a pochopíte, ako to celé interaguje, myslím, že pri samostatnej implementácii nebudete mať problémy.
Na hub.docker.com zvyčajne nájdete odkazy na github.com, kde sú uvedené surové dáta, z ktorých si môžete sami zostaviť obraz.
Ďalej v tomto repozitári sa nachádza skript docker-endpoint.sh, ktorý zodpovedá za prvotnú inicializáciu a za ďalšie spracovanie spustenia aplikácie.
Taktiež v tomto príklade existuje možnosť konfigurácie pomocou premenných prostredia. Určení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, je potrebné nastaviť používateľovi heslo a je potrebné vytvoriť databázu.
Vo svojich projektoch sme trochu zjednotili Dockerfile, ktorý zodpovedá za inicializáciu. Tam sme ho upravili podľa svojich potrieb na jednoduché rozšírenie práv používateľa, ktoré používa aplikácia. To nám umožnilo jednoducho vytvoriť databázu z konzoly aplikácie. V Ruby aplikáciách je príkaz na vytvorenie, zmenu a odstránenie databáz.
Tento príklad ukazuje, ako vyzerá konkrétna verzia MySQL na github.com. Dockerfile si môžete otvoriť a pozrieť sa, ako prebieha inštalácia.
docker-endpoint.sh je skript, ktorý zodpovedá za vstupný bod. Pri prvotnej inicializácii sú potrebné určité činnosti na prípravu a všetky tieto činnosti sú presunuté práve do skriptu inicializácie.
Prechodíme k druhej časti.
Na ukladaní zdrojových kódov sme prešli na gitlab. To je dosť silný systém, ktorý má vizuálne rozhranie.
Jednou z komponent Gitlab je Gitlab CI. Permituje opisovať sekvenciu príkazov, ktoré sa potom použijú na organizovanie systému dodávky kódu alebo na spustenie automatického testovania.
Prezentácia o Gitlab CI 2 — prezentácia z Ruby Russia klubu — dostatočne podrobná a možno vás zaujme.
Teraz si prejdeme, čo je potrebné na aktivovanie Gitlab CI. Na spustenie Gitlab CI nám stačí umiestniť súbor .gitlab-ci.yml do koreňa projektu.
Tu opisujeme, čo chceme vykonávať v sekvencii stavov ako testy a nasadenie.
Vykonávame skripty, ktoré priamo volajú docker-compose na zostavenie našej aplikácie. Toto je ako príklad backendu.
Ďalej uvádzame, že je potrebné spustiť migrácie na zmenu databázy a vykonať testy.
Ak skripty prebehnú správne a nevrátia chybový kód, systém prechádza do druhej fázy nasadenia.
Fáza nasadenia je momentálne realizovaná pre staging. Neorganizovali sme bezproblémový reštart.
Násilne zastavujeme všetky kontajnery a potom ich znova spúšťame, pričom sú zostavené z prvého kroku počas testovania.
Vykonávame migrácie databáz pre aktuálne premenné prostredie, ktoré napísali vývojári.
Existuje poznámka, že toto sa má aplikovať iba na vetvu master.
Pri zmene iných vetiev sa nevykonáva.
Existuje možnosť organizovať vydania podľa vetiev.
Aby sme to mohli ďalej zorganizovať, musíme nainštalovať Gitlab Runner.
Tento nástroj je napísaný v Golangu. Je to jedinečný súbor, ako je obvyklé vo svete Golang, ktorý nevyžaduje žiadne závislosti.
Pri spustení registrujeme Gitlab Runner.
V webovom rozhraní Gitlab získame kľúč.
Potom voláme príkaz na inicializáciu v príkazovom riadku.
Nastavujeme Gitlab Runner v dialógovom režime (Shell, Docker, VirtualBox, SSH)
Kód na Gitlab Runner bude vykonávať pri každom komite v závislosti od nastavenia .gitlab-ci.yml.
Ako to vyzerá vizuálne v Gitlab v webovom rozhraní. Po pripojení Gitlab CI sa objaví vlajka, ktorá ukazuje, v akom stave je zostavenie v súčasnosti.
Vidíme, že pred 4 minútami bol vytvorený commit, ktorý prešiel všetkými testami a nespôsobil problémy.
Môžeme sa na buildy pozrieť podrobnejšie. Tu vidíme, že sme už prešli dvoma stavmi. Stav testovania a stav nasadenia na staging.
Ak klikneme na konkrétny build, zobrazí sa tu konzolový výstup príkazov, ktoré boli spustené podľa .gitlab-ci.yml.
Takto vyzerá história nášho produktu. Vidíme, že existovali úspešné pokusy. Keď testy zlyhajú, nenastane prechod na ďalší krok 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 mali sme potrebu reštartovať iba tie komponenty, ktoré boli aktualizované v repozitári, nie celý systém.
Na to sme museli rozmiestniť všetko 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é priestory, ktoré nevidia susedné komponenty.
Aby sme to obhliadli, vytvorili sme sieť v Dockeri ručne. V Docker-compose sme uviedli, že pre tento projekt používame takú sieť.
Takto každý komponent, ktorý sa spúšťa s touto sieťou, vidí komponenty v iných častiach systému.
Ďalší problém – rozdelenie stagingu medzi viacerými projektmi.
Pretože aby to všetko vyzeralo pekne a čo najbližšie k produkcii, je dobré používať port 80 alebo 443, ktorý sa vo WEB-u používa vo veľkom.
Ako sme to vyriešili? Priradili sme jeden Gitlab Runner všetkým veľkým projektom.
Gitlab umožňuje spustiť niekoľko distribuovaných Gitlab Runnerov, ktoré jednoducho v náhodnom poradí preberajú všetky úlohy a vykonávajú ich.
Aby sme predišli chaosu, obmedzili sme skupinu našich projektov na jeden Gitlab Runner, ktorý pri našich objemoch zvláda bez problémov.
Nginx-proxy sme vyčlenili do samostatného spúšťacieho skriptu a v ňom sme uviedli sieť všetkých projektov.
Náš projekt má jednu sieť, zatiaľ čo vyrovnávač má niekoľko sietí podľa názvov projektov. Môže sprostredkovať po doménových menách ďalej.
Žiadosti prichádzajú na doménu na porte 80 a sú smerované do skupiny kontajnerov, ktorá obsluhuje túto doménu.
Aké ďalšie problémy vznikli? Je to, že všetky kontajnery sa predvolene spúšťajú pod používateľom root. Tento root nie je rovný rootu hostiteľského systému.
Ak sa však dostanete do kontajnera, bude to root a súbor, ktorý vytvoríme v tomto kontajneri, získa práva root.
Ak sa vývojár prihlásil do kontajnera a vykonal tam nejaké príkazy, ktoré vytvárajú súbory, potom po odhlásení sa z kontajnera má v svojej pracovnej priečinke súbor, k ktorému nemá prístup.
Ako sa to dá 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, používame v kontajneri používateľov s ID 1000.
V našom prípade to zodpovedalo tomu, že takmer všetci vývojári používajú OS Ubuntu. A u OS Ubuntu má prvý používateľ ID 1000.
Aké sú naše plány?
Prečítať si dokumentáciu k Dockeru. Projekt sa aktívne vyvíja, dokumentácia sa mení. Údaje, ktoré boli získané pred dvoma-tromi mesiacmi, už pomaly zastarávajú.
Časť problémov, ktoré sme riešili, je celkom možné, že už boli vyriešené štandardnými prostriedkami.
Veľmi by sme chceli pokračovať a prejsť priamo k orchestrácii.
Jedným z príkladov je vstavaný mechanizmus Docker Swarm, ktorý je k dispozícii priamo. Chceli by sme spustiť niečo v produkcii na základe technológie Docker Swarm.
Vytváranie kontajnerov spôsobuje nepohodlie pri práci s logmi. Teraz sú logy izolované. Sú rozptýlené po kontajneroch. Jednou z úloh je vytvoriť pohodlný prístup k logom cez webové rozhranie.
Zdroj: habr.com
