Začal 10. augusta v Slurme , v ktorej ho rozoberáme kompletne – od základných abstrakcií až po parametre siete.
V tomto článku budeme hovoriť o histórii Dockeru a jeho hlavných abstrakciách: Image, Cli, Dockerfile. Prednáška je určená pre začiatočníkov, takže je nepravdepodobné, že by bola zaujímavá pre skúsených používateľov. Nebude tam žiadna krv, slepé črevo ani hlboké ponorenie. Úplne základy.
Čo je Docker
Pozrime sa na definíciu Dockera z Wikipédie.
Docker je softvér na automatizáciu nasadzovania a správy aplikácií v kontajnerových prostrediach.
Z tejto definície nie je nič jasné. Je obzvlášť nejasné, čo znamená „v prostrediach, ktoré podporujú kontajnerizáciu“. Aby sme to zistili, vráťme sa v čase. Začnime érou, ktorú bežne nazývam „monolitická éra“.
Monolitická éra
Monolitická éra je začiatok roku 2000, kedy boli všetky aplikácie monolitické s množstvom závislostí. Vývoj trval dlho. Zároveň nebolo veľa serverov, všetci sme ich poznali po mene a monitorovali sme ich. Existuje také vtipné prirovnanie:
Domáce zvieratá sú domáce zvieratá. V monolitickej ére sme sa k našim serverom správali ako k domácim miláčikom, udržiavali sme ich a zveľaďovali sme ich a odfukovali sme prach. A pre lepšiu správu zdrojov sme použili virtualizáciu: vzali sme server a rozdelili ho na niekoľko virtuálnych strojov, čím sme zabezpečili izoláciu prostredia.
Virtualizačné systémy založené na hypervízore
Každý pravdepodobne počul o virtualizačných systémoch: VMware, VirtualBox, Hyper-V, Qemu KVM atď. Poskytujú izoláciu aplikácií a správu zdrojov, ale majú aj nevýhody. Na virtualizáciu potrebujete hypervízor. A hypervízor je réžia zdrojov. A samotný virtuálny stroj je zvyčajne celý kolos – ťažký obraz obsahujúci operačný systém, Nginx, Apache a možno aj MySQL. Obraz je veľký a virtuálny stroj je nepohodlný na obsluhu. V dôsledku toho môže byť práca s virtuálnymi strojmi pomalá. Na vyriešenie tohto problému boli na úrovni jadra vytvorené virtualizačné systémy.
Virtualizačné systémy na úrovni jadra
Virtualizáciu na úrovni jadra podporujú systémy OpenVZ, Systemd-nspawn, LXC. Pozoruhodným príkladom takejto virtualizácie je LXC (Linux Containers).
LXC je virtualizačný systém na úrovni operačného systému na spustenie viacerých izolovaných inštancií operačného systému Linux na jednom uzle. LXC nepoužíva virtuálne stroje, ale vytvára virtuálne prostredie s vlastným procesným priestorom a sieťovým zásobníkom.
LXC v podstate vytvára kontajnery. Aký je rozdiel medzi virtuálnymi strojmi a kontajnermi?
Kontajner nie je vhodný na izoláciu procesov: vo virtualizačných systémoch na úrovni jadra sa nachádzajú zraniteľné miesta, ktoré im umožňujú uniknúť z kontajnera k hostiteľovi. Preto, ak potrebujete niečo izolovať, je lepšie použiť virtuálny stroj.
Rozdiely medzi virtualizáciou a kontajnerizáciou je možné vidieť na diagrame.
Existujú hardvérové hypervízory, hypervízory nad OS a kontajnery.
Hardvérové hypervízory sú skvelé, ak naozaj chcete niečo izolovať. Pretože je možné izolovať na úrovni pamäťových stránok a procesorov.
Existujú hypervízory ako program a existujú kontajnery a budeme o nich hovoriť ďalej. Kontajnerizačné systémy nemajú hypervízor, ale existuje kontajnerový engine, ktorý vytvára a spravuje kontajnery. Táto vec je ľahšia, takže vďaka práci s jadrom je réžia menšia alebo žiadna.
Čo sa používa na kontajnerizáciu na úrovni jadra
Hlavné technológie, ktoré vám umožňujú vytvoriť kontajner izolovaný od iných procesov, sú priestory názvov a riadiace skupiny.
Menné priestory: PID, Networking, Mount a User. Je ich viac, ale pre ľahšie pochopenie sa zameriame na tieto.
PID Namespace obmedzuje procesy. Keď napríklad vytvoríme PID Namespace a umiestnime tam proces, stane sa to s PID 1. Zvyčajne v systémoch je PID 1 systemd alebo init. Preto, keď umiestnime proces do nového menného priestoru, dostane aj PID 1.
Networking Namespace vám umožňuje obmedziť/izolovať sieť a umiestniť do nej svoje vlastné rozhrania. Pripojiť je obmedzenie súborového systému. Používateľ — obmedzenie pre používateľov.
Riadiace skupiny: Pamäť, CPU, IOPS, Sieť – celkovo asi 12 nastavení. Inak sa nazývajú aj C-skupiny (“C-skupiny”).
Kontrolné skupiny spravujú prostriedky pre kontajner. Prostredníctvom kontrolných skupín môžeme povedať, že kontajner by nemal spotrebovať viac ako určité množstvo zdrojov.
Aby kontajnerizácia fungovala naplno, používajú sa ďalšie technológie: Capabilities, Copy-on-write a iné.
Schopnosti sú, keď hovoríme procesu, čo môže a čo nemôže robiť. Na úrovni jadra sú to jednoducho bitmapy s mnohými parametrami. Napríklad užívateľ root má plné oprávnenia a môže robiť všetko. Časový server môže zmeniť systémový čas: má možnosti na Time Capsule, a to je všetko. Pomocou privilégií môžete flexibilne konfigurovať obmedzenia pre procesy, a tým sa chrániť.
Systém Copy-on-write nám umožňuje pracovať s obrázkami Docker a využívať ich efektívnejšie.
Docker má momentálne problémy s kompatibilitou s Cgroups v2, takže tento článok sa zameriava špeciálne na Cgroups v1.
Vráťme sa však do histórie.
Keď sa virtualizačné systémy objavili na úrovni jadra, začali sa aktívne používať. Réžia na hypervízore zmizla, ale niektoré problémy zostali:
- veľké obrázky: do toho istého OpenVZ tlačia operačný systém, knižnice, kopu rôzneho softvéru a nakoniec sa obrázok aj tak ukáže ako dosť veľký;
- Neexistuje žiadny normálny štandard pre balenie a dodanie, takže problém závislostí zostáva. Existujú situácie, keď dva kusy kódu používajú rovnakú knižnicu, ale s rôznymi verziami. Môže medzi nimi dôjsť ku konfliktu.
Na vyriešenie všetkých týchto problémov prišla ďalšia éra.
Kontajnerová éra
Keď prišla éra kontajnerov, filozofia práce s nimi sa zmenila:
- Jeden proces - jeden kontajner.
- Všetky závislosti, ktoré proces potrebuje, doručíme do svojho kontajnera. To si vyžaduje rezanie monolitov na mikroslužby.
- Čím menší je obrázok, tým lepšie – je tam menej možných zraniteľností, rýchlejšie sa to roluje atď.
- Prípady sa stávajú efemérnymi.
Pamätáte si, čo som povedal o domácich miláčikoch vs. Predtým boli prípady ako domáce zvieratá, ale teraz sa stali ako dobytok. Predtým existoval monolit - jedna aplikácia. Teraz je to 100 mikroslužieb, 100 kontajnerov. Niektoré kontajnery môžu mať 2-3 repliky. Stáva sa pre nás menej dôležité kontrolovať každý kontajner. Dôležitejšia je pre nás dostupnosť samotnej služby: čo táto sada kontajnerov robí. To mení prístupy k monitorovaniu.
V rokoch 2014-2015 Docker prekvital - technológia, o ktorej budeme teraz hovoriť.
Docker zmenil filozofiu a štandardizoval balenie aplikácií. Pomocou Docker môžeme zabaliť aplikáciu, odoslať ju do úložiska, odtiaľ stiahnuť a nasadiť.
Všetko, čo potrebujeme, vložíme do kontajnera Docker, takže problém so závislosťou je vyriešený. Docker zaručuje reprodukovateľnosť. Myslím, že veľa ľudí sa stretlo s nereprodukovateľnosťou: všetko vám funguje, dotlačíte to do výroby a tam to prestane fungovať. S Dockerom tento problém zmizne. Ak sa váš kontajner Docker spustí a urobí to, čo potrebuje, potom s vysokou pravdepodobnosťou začne vo výrobe a tam urobí to isté.
Odbočka o réžii
O režijných nákladoch sa vždy vedú spory. Niektorí ľudia veria, že Docker nenesie dodatočnú záťaž, pretože používa jadro Linuxu a všetky jeho procesy potrebné na kontajnerizáciu. Napríklad: „Ak poviete, že Docker je nad hlavou, potom je nad hlavou linuxové jadro.“
Na druhej strane, ak pôjdete hlbšie, v Dockeri je skutočne niekoľko vecí, o ktorých možno povedať, že sú nad hlavou.
Prvým je menný priestor PID. Keď proces umiestnime do menného priestoru, je mu pridelené PID 1. Zároveň má tento proces ďalšie PID, ktoré sa nachádza na hostiteľskom mennom priestore, mimo kontajnera. Napríklad sme spustili Nginx v kontajneri, stal sa z neho PID 1 (hlavný proces). A na hostiteľovi má PID 12623. A je ťažké povedať, aká je to réžia.
Druhá vec sú Cgroups. Zoberme si Cgroups podľa pamäte, teda schopnosti obmedziť pamäť kontajnera. Keď je povolená, aktivujú sa počítadlá a účtovanie pamäte: jadro musí pochopiť, koľko stránok bolo alokovaných a koľko je ešte voľných pre tento kontajner. Je to možno réžia, ale nevidel som žiadne presné štúdie o tom, ako to ovplyvňuje výkon. A sám som si nevšimol, že aplikácia spustená v Dockeri zrazu zaznamenala prudký pokles výkonu.
A ešte jedna poznámka k výkonu. Niektoré parametre jadra sa prenášajú z hostiteľa do kontajnera. Najmä niektoré parametre siete. Preto, ak chcete v Dockeri spustiť napríklad niečo výkonné, niečo, čo bude aktívne využívať sieť, musíte aspoň upraviť tieto parametre. Napríklad nejaký nf_conntrack.
O koncepte Docker
Docker sa skladá z niekoľkých komponentov:
- Docker Daemon je rovnaký kontajnerový engine; spúšťa kontajnery.
- Docker CII je nástroj na správu Docker.
- Dockerfile - návod na vytvorenie obrazu.
- Obrázok — obrázok, z ktorého sa nádoba vyvaľuje.
- Kontajner.
- Docker register je úložisko obrázkov.
Schematicky to vyzerá asi takto:
Démon Docker beží na Docker_host a spúšťa kontajnery. Existuje klient, ktorý posiela príkazy: zostaviť obrázok, stiahnuť obrázok, spustiť kontajner. Démon Docker prejde do registra a vykoná ich. Klient Docker môže pristupovať lokálne (do soketu Unix) aj cez TCP zo vzdialeného hostiteľa.
Poďme si prejsť každý komponent.
Démon Docker - toto je serverová časť, funguje na hostiteľskom počítači: sťahuje obrázky a spúšťa z nich kontajnery, vytvára sieť medzi kontajnermi, zbiera protokoly. Keď povieme „vytvor obraz“, démon to robí tiež.
Docker CLI — Klientska časť Docker, pomôcka konzoly na prácu s démonom. Opakujem, môže to fungovať nielen lokálne, ale aj cez sieť.
Základné príkazy:
docker ps - zobrazí kontajnery, ktoré sú momentálne spustené na hostiteľovi Docker.
obrázky docker – zobrazujú obrázky stiahnuté lokálne.
docker search <> – hľadanie obrázka v registri.
docker pull <> - stiahne obrázok z registra do počítača.
zostava docker < > - zhromaždiť obrázok.
docker run <> - spustí kontajner.
docker rm <> - vyberte kontajner.
docker logs <> - protokoly kontajnera
docker start/stop/restart <> - práca s kontajnerom
Ak ovládate tieto príkazy a ste si istí v ich používaní, považujte sa za 70 % skúsených v Docker na užívateľskej úrovni.
Dockerfile - návod na vytvorenie obrazu. Takmer každý príkaz je nová vrstva. Pozrime sa na príklad.
Takto vyzerá súbor Docker: príkazy vľavo, argumenty vpravo. Každý príkaz, ktorý je tu (a vo všeobecnosti napísaný v súbore Dockerfile), vytvorí novú vrstvu v obrázku.
Dokonca aj pri pohľade na ľavú stranu môžete zhruba pochopiť, čo sa deje. Hovoríme: „vytvorte pre nás priečinok“ - toto je jedna vrstva. Ďalšia vrstva je „Zabezpečte fungovanie priečinka“ a tak ďalej. Vrstvená torta uľahčuje život. Ak vytvorím ďalší súbor Dockerfile a zmením niečo v poslednom riadku – spustím niečo iné ako „python“ „main.py“, alebo nainštalujem závislosti z iného súboru – predchádzajúce vrstvy sa znova použijú ako vyrovnávacia pamäť.
Obraz - toto je balenie kontajnerov, kontajnery sa spúšťajú z obrázka. Ak sa na Docker pozrieme z pohľadu správcu balíkov (ako keby sme pracovali s balíkmi deb alebo rpm), tak image je v podstate balík rpm. Prostredníctvom yum install môžeme aplikáciu nainštalovať, odstrániť, nájsť v úložisku a stiahnuť. Tu je to približne rovnaké: kontajnery sa spúšťajú z obrázka, sú uložené v registri Docker (podobne ako yum v úložisku) a každý obrázok má hash SHA-256, názov a značku.
Obrázok je vytvorený podľa pokynov zo súboru Dockerfile. Každá inštrukcia z Dockerfile vytvorí novú vrstvu. Vrstvy je možné znova použiť.
Dockerov register je úložisko obrázkov Docker. Podobne ako OS má Docker verejný štandardný register - dockerhub. Môžete si však vytvoriť svoje vlastné úložisko, svoj vlastný register Docker.
Kontajner - čo sa spustí z obrázka. Vytvorili sme obrázok podľa pokynov z Dockerfile, potom ho spustíme z tohto obrázku. Tento kontajner je izolovaný od ostatných kontajnerov a musí obsahovať všetko potrebné na fungovanie aplikácie. V tomto prípade jeden kontajner - jeden proces. Stáva sa, že musíte urobiť dva procesy, ale to je trochu v rozpore s ideológiou Docker.
Požiadavka „jeden kontajner, jeden proces“ súvisí s menným priestorom PID. Keď sa proces s PID 1 spustí v priestore názvov, ak náhle zanikne, zanikne aj celý kontajner. Ak tam bežia dva procesy: jeden je živý a druhý mŕtvy, kontajner bude stále žiť. Ale to je otázka Best Practices, o nich si povieme v iných materiáloch.
Ak si chcete podrobnejšie preštudovať funkcie a celý program kurzu, kliknite na odkaz: “".
Autor: Marcel Ibraev, certifikovaný administrátor Kubernetes, praktický inžinier v Southbridge, rečník a vývojár kurzov Slurm.
Zdroj: hab.com