Úvod do Dockeru (1)

18. 9. 2019 | Mark Stopka | Systém | 14256×

Docker se na technologické scéně pohybuje již od roku 2013, spousta společností, jež implementují své aplikace s využitím architektury orientované na microservices technologií Docker využívá. Docker je kontejnerizační technologie, která však kromě oddělení jednotlivých aplikací, jež běží v jednotlivých kontejnerech, umožňuje také tvorbu aplikačních obrazů, které lze nasadit jak v demonstračním, tak produkčním prostředí.

Stručná historie Dockeru

Společnost Docker Inc., jež za touto technologií stojí, byla založena v roce 2010, první verze Dockeru byla prezentována na konferenci PyCon v roce 2013 a uvolněna jako open-source v březnu téhož roku. V této době Docker ještě využíval pod kapotou LXC. O rok později, s verzí 0.9, již však Docker využíval přímo API poskytované linuxovým jádrem, samotná aplikace byla přepsána do jazyka Go.

V září 2013 RedHat a Docker oznámili spolupráci v rámci produktů Fedora, Red Hat Enterprise Linux a OpenShift. V listopadu 2014 se Docker dostal do prostředí Amazon Web Services v rámci produktů Amazon Elastic Compute Cloud (EC2). V prosinci 2014 se dalším významným partnerem stala společnost IBM, která jej integrovala do produktové řady IBM Cloud.

V roce 2015 společnost Docker ve spolupráci s dalšími oznámila, že společně pracují na nezávislém standardu pro aplikační kontejnery, který bude nezávislý jak na samotném poskytovateli softwarového řešení, tak na druhu operačního systému.

V současné době lze v Dockeru provozovat aplikace jak pro Linux, tak pro Windows; podpora těchto aplikačních kontejnerů je součástí Windows 10 a Windows Server 2016.

K čemu je Docker vlastně dobrý?

Docker je další z dílků skládačky, která se skloňuje v mnoha podobách, mezi které patří mimo jiné princip Microservices, Infrastructure as a Code, agilní vývoj, Continuous Delivery a DevOps. Docker umožňuje vývojářům připravit pro běh jejich aplikace optimální běhové (runtime) prostředí a zajistit tak větší spolehlivost aplikace a zjednodušit její nasazení. Lidem zodpovědným za bezpečnost IT prostředí v organizaci pak umožňuje automaticky jednotlivé komponenty potřebné pro běh aplikace zkoumat z pohledu objevených zranitelností prostřednictvím plně automatizovaných nástrojů, a poté mohou požadavek na aktualizaci konkrétních závislostí předat zpět vývojářům, kteří aktualizují patřičný aplikační obraz (image).

Nový aktualizovaný aplikační obraz pak mohou vývojáři nasadit buď ručně, nebo automaticky v rámci automatizované CI/CD pipeline. Docker tak umožňuje snadno udržovat aplikační prostředí v aktualizované podobě, zjednodušuje nasazování nových verzí aplikací a přímo vybízí k využití microservices architektury, kdy každý kontejner vykonává jednu specifickou úlohu; tyto jednotlivé kontejnery jsou pak prostřednictvím různých API propojeny mezi sebou tak, aby doručily plnou funkcionalitu aplikace jako celku.

Docker tak nachází uplatnění od vývojářských stanic přes testovací prostředí a integrační testování až po samotné produkční prostředí pro danou aplikaci. Docker lze nasadit jako plně manuálně řízené řešení, tak lze využít orchestračních technologií jako Docker Swarm, Kubernetes nebo Apache Mesos. Podobně jako v případě RPM nebo DEB balíčků, aplikační obrazy Docker se ukládají do veřejného nebo soukromého repozitáře.

Kromě oficiálního repozitáře Docker pod názvem “registry” je podpora pro repozitář Docker image implementována také do GitLab, JFrog Artifactory a dalších řešení poskytujících repozitáře pro různé artefakty.

Jak Docker funguje na pozadí?

Byť jsme si v předchozí části článku řekli, že Docker umí dělat aplikační kontejnery pro platformy jak Windows, tak Linux, rozdíly mezi jednotlivými implementacemi na Windows a Linuxu se v tomto seriálu zabývat nebudeme; budeme se soustřeďovat na detaily implementace na linuxové platformě.

V Linuxu se pro zajištění izolace jednotlivých aplikačních kontejnerů využívají jmenné prostory linuxového jádra a řídící skupiny (cgroups). Samotné jmenné prostory v minimální variantě začalo jádro Linux podporovat v roce 2002 a řídící skupiny pak v roce 2007. Sjednocení jmenných prostorů a řídících skupin proběhlo v roce 2016 spolu s jádrem verze 4.6. Ve stejném roce Docker rozdělil své monolitické řešení do menších celků, které se vzájemně abstrahují, samotné ovládání jádra obstarává kontejnerový runtime engine runC. Nad ním pak stojí služba containerd, která poskytuje další abstrakci spojenou s řízením jednotlivých kontejnerů. Až nad těmito samotnými službami pak stojí samotný Docker Engine, který se stará o stažení obrazu daného kontejneru, jeho rozbalení, spuštění a případné napojení na sdílené prostředky, jako jsou virtuální síťová rozhraní, diskové prostory (volumes) a podobně.

V příštím díle tohoto seriálu si spustíme testovací Docker image a vytvoříme první odvozený Docker image s vlastní jednoduchou aplikací. Do té doby, pokud si budete chtít zkoušet jednotlivé praktické ukázky Dockeru, pak si vás dovolím požádat o to, abyste postupovali podle návodu vhodného pro vaši linuxovou distribuci a nainstalovali si Docker Engine, systém řešení závislostí vaši distribuce by se měl postarat o to, aby se nainstalovaly i všechny potřebné závislosti.

       

Komentáře

[bigBRAMBOR]

uvidíme jak to bude vypadat dále, zatím takový nehodnotitelný štěk.

[Bystroushaak]

To dělá často redakce. Pošleš jim článek a oni ho rozřežou na několik dílů, asi kvůli reklamě.

[Käyttäjä 11133]

Ja to takhle poslal, dokud to redakce nehodi do systemu nevidis jak to vypada, ve Wordu to vypadalo dlouhe a pak uz nebyl cas to mergnout s druhym dilem.

[KOLEGA]

ve Wordu? :(

[Käyttäjä 11133]

Ano, on uz Linux umi Active Directory GPO a dalsi korporatni nutnosti? Ja tedka silim z toho ze musim prijit na to jak se konfiguruje OpenLDAP abych pro ABCLinuxu mohl rozchodit CI pipeline a trosku tu aplikacni cast poupdatovat...

[Jiří J.]

No jasně! Zlí jazykové říkaj, že je Linux až moc korporátní.

[bigBRAMBOR]

jak daleko se planujes dostat, ovladani dockeru je jedna vec, vytvoreni vlatniho kontejneru urcite ano, co dal, compose, swarm? Co podman?

[Käyttäjä 11133]

Build, multi-stage build, Swarm, K8s.

[Käyttäjä 11133]

Compose se rovnou vyhnu a budeme delat se single node Swarmem a docker stacky / services...

[martin]

Compose se rovnou vyhnu

Z jakeho duvodu?

[Roman]

Compose napr. neumoznuje vice instanci jedne sluzby (replicas), coz se hodi pro bezvypadkovy rolling update. A samozrejme moznost mit vic nodes (serveru). Ale prace se Swarmem je podobna compose, resp. jde compose file nasadit jako stack.

[citanus]

jo podman by me taky zajimal : )

[xvasek]

Do jaké to doby jsme se dostali... Asi jsem už moc starý, jdu si na uklidnění napsat nějaký oneliner v Perlu.

[Käyttäjä 11133]

Muzes ho pak zabalit do Dockeru a mit z toho micro-service . Kdyz posles ten one-liner, muzu ho v pristim dile pouzit jako example :-p.

[johnyK]

sem rad , ze ses do toho pustil - psat zde clanky, Tisnovsky na rootu namuze napsat vsechno.

Celou tu kontejnerizaci moc nechapu a priznam se, ze mi nepomohl ani ten tvuj clanek. Ale ta tvoje poznamka ohledne tech microservice mi privedla na myslenku, jestli by se muj problem (popis nize) nedal tak nejak resit.

Tedy, pouzivam uz 20 let databazi, ktera je vo forme share-library a linkuje k primo s aplikaci (neco jako sqlite). Ale funguje to jen do verze centos 5 (tedy to odpovidajici jadro, ktere se s centos5 dodava), pod centos 6 databaze uz nefunguje. Dodavatel sice nabizi i verze pro novejsi jadra, ale chce za to 4000 $, coz je pro par zakazniku bolestive.

Chci to resit tak, ze vezmu virtulni stroj (hyperV) na kterem budou 2 hostovane systemy - aplikace pod centos6 a database pod centos5. Asi pres unix-sockety (to musim napsat) se budu z aplikace dotazovat te databaze.

Otazka je, zdali bych vystacil jen s jednou instalaci centos6 a konejnerem, kde by byla ta databazova cast?

[ET]

Chci to resit tak, ze vezmu virtulni stroj (hyperV) na kterem budou 2 hostovane systemy - aplikace pod centos6 a database pod centos5. Asi pres unix-sockety (to musim napsat) se budu z aplikace dotazovat te databaze.

IMHO idealni pro kontejnery (ja to tak pouzivam)

* DB s cent5 zavri do samotneho kontejneru (idealne bez sitovky a nasdilej ven jen adresar s DB ux socketem)

* APP do samotneho kontejneru s nasdilenym adresarem s DB ux socketem (nepises, jestli APP bezi pouze na cent6, v dalsim/jinem kontejneru muzes zkusit zmigrovat na cent7 ;)

pokud nejaky program nepodporuje ux sockety, muzes pouzit nastroj socat, e.g.:

socat UNIX-LISTEN:/cesta/k/db-socketu.sock,reuseaddr,fork TCP:127.0.0.1:$DB_PORT
socat TCP-LISTEN:$DB_PORT,reuseaddr,fork UNIX-CLIENT:/cesta/k/db-socketu.sock

[bigBRAMBOR]

otazka na jak dlouho to je, nevim jestli jeste vubec existuje image centos 5, nebo bude muset si cely image postavit celý znova a to je uz podstatne vice prace. A stejne za par let muze prijit na to, ze image uz nepujde v dockeru natahnout, vypadne podpora napr. filesystemu a pápá.

[Käyttäjä 11133]

Nejnizsi verze na Docker Hub je verze 6.6.

[Jendа]

Já teda Docker neznám, ale představuju si to jako omezený chroot nebo OpenVZ když ještě frčelo.

otazka na jak dlouho to je, nevim jestli jeste vubec existuje image centos 5, nebo bude muset si cely image postavit celý znova a to je uz podstatne vice prace

Mohlo by stačit zkopírovat rootfs stávajícího serveru a databázi spustit.

A stejne za par let muze prijit na to, ze image uz nepujde v dockeru natahnout, vypadne podpora napr. filesystemu a pápá.

FS je záležitostí jádra (pokud tedy zrovna DB nemá nějaká FS-specific quirky) a to se používá hostitelské. Jediné co mě napadá (šlo to kolem když se upgradovalo jádro v Debianu) je že bude potřeba zapnout vsyscall.

[Josef Kufner]

Mohlo by stačit zkopírovat rootfs stávajícího serveru a databázi spustit.

Jedna z výhod Dockeru je, že ke každému obrazu máš popis, jak ten obraz vytvořit. Tedy skript, který tam vše nainstaluje. Pokud zkopíruješ existující server, tak zkopíruješ i hromadu bordelu, který může později překážet a dělat potíže. Na druhou stranu, pokud je cílem jen udržovat zastaralou službu tak, jak teď je, a pokud ten server není moc zabordelený, tak je to docela rozumná a relativně bezpracná volba.

Nicméně postavit si image pro kontejner je o jednom příkazu a nainstalování pár věcí. Tedy pokud použiješ něco integrovaného se systémem (systemd-nspawn nebo lxc). Docker je trochu těžší na přemluvení, aby v něm fungoval systemd a nějak slušně to interagovalo s okolím.

[Heron]

Jedna z výhod Dockeru

No to by mě právě nejvíc zajímalo, v čem je docker tak super výhodný. Protože technologicky tam není nic, co by neuměly jaily, lxc, nspawn (openvz neznám, ale asi taky).

Pokud přeskočím hype (který mě docela štve), tak docker nabízí hotové image "na všechno", takže "admin" nemusí umět nic nainstalovat a na pár řádků v dockerfile mu to odněkud (takže bezpečnostní riziko) postahuje někým vytvořené image programů.

A setkal jsem se s argumentací, že mít i nativní programy, které jsou jinak běžně dostupné v repositáři distribuce, v dockeru, je výhodnější, protože si v dockerfile lze zvolit, kam se má který datový adresář namountouvat. Když jsem opáčil, že to je v linuxu už asi 28 let, tak jsem se dozvěděl, že to není ono. Tak nevím. Připadá mi to celé takové zvláštní. Máme tady technologie, které umožňují dělat totéž a lidi si raději instalují docker místo toho, aby v konfigu služby změnili umístění datového adresáře nebo si jej namountovali tam kam potřebují. Navíc vidím zásadní problém z hlediska bezpečnosti. Lidé si zvykli stahovat image a neznají jejich původ. Navíc to často ani neupdatují. Čest výjimkám, jsou lidé, kteří si image dělají sami včetně automatických update.

[Käyttäjä 11133]

takže "admin" nemusí umět nic

Cela pointa DevOps je ze neni zadny admin.

na pár řádků v dockerfile mu to odněkud (takže bezpečnostní riziko) postahuje někým vytvořené image programů.

To nekdo v produkcnim bezpecnem prostredi dela tak maximalne na vyzkouseni nejake nove aplikace, v produkci mas samozrejme image primo od vyrobce te dane aplikace, nebo si tvoris image vlastni.

Lidé si zvykli stahovat image a neznají jejich původ.

Lidi si na sve pracovni stanice a sebou managovane servery instaluji bezpecnosti hrozby uz davno, byt treba jinak; organizace na to maji bezpecnostni politiky, IT governance procesy a interni a externi auditory.

[Heron]

No chtěl jsem k tomu napsat pěkný rant komentář o srážce s realitou, ale raději jsem ho smazal. Jedna věc je prohlásit "devops adminy nepotřebuje" a druhá je potom, jak to kdo pochopí v praxi.

Takže se místo toho budu těšit na další díly a snad budu mít kam odkazovat jisté neadminy.

[Bystroushaak]

Já teďkon zažívám ve firmě přechod ze serverů na OpenShift a s touhle myšlenkou se taky často střetávám. Reálně toho člověk musí umět pořád stejně, jen se adminování přehazuje na programátory. A zrovna Docker, resp. OpenShift jako orchestrace k němu má tendence vyrábět spoustu problémů, které bez něj vůbec neexistovaly.

[Käyttäjä 11133]

OpenShift jako orchestrace k němu má tendence vyrábět spoustu problémů, které bez něj vůbec neexistovaly

Ale podle toho co jsem slysel, pokud se vam to podari uspesne nasadit budete prvni uspesna implementace OpenShiftu v CR :).

[Heron]

jen se adminování přehazuje na programátory

Což považuju za problém, protože admini a programátoři jsou zcela odlišný druh zvířete (neříkám lepší / horší). Nejlepší je, pokud tyto dva spolu spolupracují a kromě potřeb vývoje se taky hledí na potřeby to potom udržovat v chodu. (I když chápu, že v době, kdy je technologie, která před půl rokem ještě ani neexistovala, považována za zastaralou, je toto hledisko pro některé lidi asi méně důležité.)

[Käyttäjä 11133]

K cemu potrebujes adminy, kdyz mas cloud?

[Josef Kufner]

Jaily, lxc, nspawn a podobné umí kontejnery stejně nebo lépe než Docker. Co jsem se s Docekerem potkal, tak hodně věcí mne celkem pila krev. Ale zrovna to, že ke každému image existuje předpis, Dockerfile, který říká, jak se image vytvoří, je velice hezká.

Když se udělá kontejner v systemd-nspawn nebo lxc, tak prostě nasypu něco do chrootu a ten spustím v kontejneru. Po pár aktualizacích už nevím, jak bych ten kontejner postavil znovu a co v něm přesně je. Můžu tam mít větší či menší bordel, ale to už to nezachrání.

Docker postail svůj ekosystém na tom, že je předpis, který říká jak ten kontejner vyrobit, a kdykoliv můžu vše zahodit a vrátit se na začátek. Pokaždé na ten stejný začátek. Vlastně ani tak nejde o ten kontejner, jako spíš o to, že se spustí ten předpis a dřívější kontejner je jen někde nakešovaný. To je podle mne ten hlavní důvod, proč je Docker tak úspěšný. Ostatní kontejnerovací technologie toto postrádají a většinou to vůbec neřeší.

[Heron]

Docker postail svůj ekosystém na tom, že je předpis, který říká jak ten kontejner vyrobit, a kdykoliv můžu vše zahodit a vrátit se na začátek. Pokaždé na ten stejný začátek. Vlastně ani tak nejde o ten kontejner, jako spíš o to, že se spustí ten předpis a dřívější kontejner je jen někde nakešovaný. To je podle mne ten hlavní důvod, proč je Docker tak úspěšný. Ostatní kontejnerovací technologie toto postrádají a většinou to vůbec neřeší.

To můžu mít pomocí jiných technologií taky. Ansible playbook + výchozí template kontejner s minimální instalací OS. Z template udělám "image" (zfs filesystem / btrfs subvolume), pustím na to ansible a jsem na konci.

[Käyttäjä 11133]

To můžu mít pomocí jiných technologií taky.

Ano, i auto si muzes postavit sam, otazka je jestli to bude snazsi a levnejsi nez si koupit auto uz od existujiciho vyrobce ze seriove vyroby; siti servisnich stanic vsude po svete,...

[Heron]

To je trochu rozdíl, ansible můžu použít i na HW, dokonce stejný playbook, jako používám v npawnu nebo v kvm.

Tj je to něco jiného, než postavit si to sám. Jde to trochu bokem.

Btw. asi se k tomu dostaneš v dalších dílech, ale jaká je best practices pro vytváření image? Bylo mi tvrzeno, že se to běžně dělá tak, že pokud někdo distribuuje nějaký software, který vyžaduje konfiguraci (změny v /etc/), tak prostě přímo hrábne do těch souborů v /etc/ a udělá z toho image. To mi přijde dost nedokumentované. Když totéž změním pomocí ansible, tak to mám alespoň v tom playbooku. Zatímco v image nikdo nepozná, jestli je tam změna nebo ne. (Snad mi jde rozumět.)

[Käyttäjä 11133]

To je trochu rozdíl, ansible můžu použít i na HW, dokonce stejný playbook, jako používám v npawnu nebo v kvm.

V prostredi s nejakou formou governance tezko, virtualni stroje budes monitorovat jinak nez fyzicke servery, konteinery,...

Btw. asi se k tomu dostaneš v dalších dílech, ale jaká je best practices pro vytváření image? Bylo mi tvrzeno, že se to běžně dělá tak, že pokud někdo distribuuje nějaký software, který vyžaduje konfiguraci (změny v /etc/), tak prostě přímo hrábne do těch souborů v /etc/ a udělá z toho image.

Takovy je best-practice... Ty nahrazovane konfiguraky mas soucasti toho git repozitare ze ktereho buildis ten image a delas replacement; pokud potrebujes aby se konfigurak menil na zaklade nejakych ENV promennych pri spusteni konteineru, tak do udelas v Docker entrypoint skriptu.

[Heron]

No tak pokud je to v gitu a ten repos je dodávaný s tím image, tak možná. Ale co jsem pochopil, tak voni prostě změní konf přímo v image a nazdar.

To už mi fakt přijde lepší (ve smyslu je k tomu víc dokumentace), někomu říct: hele, minimální debian, nainstaluj ansible s pušť tam tohle (playbook). Minimální debian zná a co mu s tím provede ten playbook si v něm může po nocích přečíst.

[Käyttäjä 11133]

No tak pokud je to v gitu a ten repos je dodávaný s tím image, tak možná.

Muze byt, nemusi, kdyz mas OSS appku tak v tom neni problem, ale kdyz takhle distribuujes treba SAP tak ten Git bude uvnitr SAPu (jako organizace) a SAP bude distribuovat jenom binarni image s nejakymi nadefinovanymi parametry, ale to se nijak nelisi od dostribuce binarniho instalatoru SAPu, Oracle DB,...

Ale co jsem pochopil, tak voni prostě změní konf přímo v image a nazdar.

Tak to delaji blbe, co ti k tomu mam rict? Je to nastroj a lidi ho muzou pouzivat spatne stejne jako jine nastroje...

To už mi fakt přijde lepší (ve smyslu je k tomu víc dokumentace), někomu říct: hele, minimální debian, nainstaluj ansible s pušť tam tohle (playbook). Minimální debian zná a co mu s tím provede ten playbook si v něm může po nocích přečíst.

Ten playbook se ale da spustit i v tom Docker konteineru, ze... Deploynout novy konteiner a pripojit ho k load-balanceru je rychlejsi nez bootstrapnout novou VM, a spustit v nem ten playbook, takze dokazes rychleji horizontalne skalovat aplikaci v ramci spicek dane aplikace.

[Heron]

Tak to delaji blbe, co ti k tomu mam rict?

Nic, právě proto jsem se na to ptal. To že to dělají blbě mě napadlo taky a to byl důvod mé otázky.

Ten playbook se ale da spustit i v tom Docker konteineru, ze...

Ano.

Deploynout novy konteiner a pripojit ho k load-balanceru je rychlejsi nez bootstrapnout novou VM

Se nemusí bootstapovat od nuly. Udělat btrfs / zfs clone stávajícího hotového template a spustit (nwpawn / jail) je otázkou sekund. (Do dvou sekund mám nový testovací jail pro testování webových appek a takových připravených templatů tu mám víc pro různé účely.) (Stejně ten docker používá btrfs resp nějaký systém layerů, takže toto je stejné.)

(Ano já vím, nemám k tomu hotovou tu infra okolo a nemám si sám navrhovat auto, vím, nepiš to ).

[kralyk z abclinuxu]

Zběžně jsem prolítl vlákno a jedné věci nerozumim: Ptáš se k čemu je Docker a pak popisuješ, jak děláš +- to samé co Docker pomocí jiného softwaru. Neodpověděl sis tím pádem sám?

Osobně znám Docker jen z omezeného uživatelského hlediska, ale přijde mi především jako frontend k izolačním/namespace fíčurám jádra a taky definice nějakých standardů, které se pak staly do nějaké míry multiplatformní (AFAIK). Takže vlastně tak trochu něco jako LUKS v oblasti šifrování disku.

[Heron]

Zběžně jsem prolítl vlákno a jedné věci nerozumim: Ptáš se k čemu je Docker a pak popisuješ, jak děláš +- to samé co Docker pomocí jiného softwaru. Neodpověděl sis tím pádem sám?

No ptám, protože před dockerem jsme tady měli jaily, lxc, nspawn, openvz a další, tak mě zajímá, proč někdo místo tohoto používá právě docker (včetně "vtipné" historie OverlayFS). A když jsem se o tom bavil s několika lidmi, tak mi říkali různé featury dockeru a já jsem jenom reagoval "no jasně, to můžeš udělat i mimo docker a je to tam už 20 let". Takže oni byli nadšení, vyhypovaní a ani nevěděli, že to tady bylo už dávno.

Další věc, která mi nebyla jasná, byla právě konfigurace image. Fakt se mi nechtělo věřit, že by někdo ručně natvrdo měnil soubory a čekal jsem nějakou sofistikovanou věc (lepší než ansible) zabudovanou přímo do dockeru, která to ulehčí. Ale odpověď: "prostě se to změní ručně" mě teda uzemnila.

Takže moje zjištění "proč docker" jsou: hype a hotové image pro neadminy. V čemž vidím velké bezpečností riziko.

Ano, lze to dělat i dobře, lze si stavět vlastní image a updatovat je, to nepopírám. Ale to se nijak neliší od provozování nspawnů / jailů nad btrfs / zfs.

A od seriálu očekávám (přál bych si), že se dostane k technologiím, které si doma na koleně neudělám a bude tam jasná přidaná hodnota dockeru.

[Käyttäjä 11133]

Takže moje zjištění "proč docker" jsou: hype a hotové image pro neadminy. V čemž vidím velké bezpečností riziko.

Velke bezpecnostni riziko treba v automatizovanem vulnarability scanningu a alertingu pro kazdou image, ktera vypadne z CI/CD pipeline? Aha...

Ano, lze to dělat i dobře, lze si stavět vlastní image a updatovat je, to nepopírám. Ale to se nijak neliší od provozování nspawnů / jailů nad btrfs / zfs.

Lisi se to v tom, ze kolem toho existuje cely ekosistem podpurnych nastroju, ktere mezi sebou spolupracuji a jsou integrovany, treba NetApp Kubernetes Service.

A od seriálu očekávám (přál bych si), že se dostane k technologiím, které si doma na koleně neudělám a bude tam jasná přidaná hodnota dockeru.

V serialu je jasne napsano, ze Docker skrze runc a containerd stavi abstrakcni vrstvu nad jiz existujicimi vlastnosmi jadra, stejne jako uvadi kdy ty featury byly do toho jadra zavedene, pokud si chces stavet vlastni letadlo, ja ti v tom branit nebudu, ale pokud bych ja zakladal aerolinku tak si je koupim od Boeingu, nebo Airbusu.

[kralyk z abclinuxu]

Takže moje zjištění "proč docker" jsou: hype a hotové image pro neadminy. V čemž vidím velké bezpečností riziko.

Možná přívětivější tooling?

Ačkoliv, co jsem posledně používal docker, tak to zas tak přívětivé nebylo a třeba error reporting byl dost špatnej.

Ano, lze to dělat i dobře, lze si stavět vlastní image a updatovat je, to nepopírám. Ale to se nijak neliší od provozování nspawnů / jailů nad btrfs / zfs.

Hm, já třeba zrovna s btrfs moc kámoš nejsem (nepovažuju ho za dostatečně stabilní pro produkční nasazení) a zfs je na linuxu pořád trochu cizí (ale nevim, jakej je nejnovější stav). Jde to i bez nich?

[Heron]

Hm, já třeba zrovna s btrfs moc kámoš nejsem (nepovažuju ho za dostatečně stabilní pro produkční nasazení) a zfs je na linuxu pořád trochu cizí (ale nevim, jakej je nejnovější stav). Jde to i bez nich?

ZFS používám jen na FreeBSD (z licenčních důvodů). Ano, jde to i bez nich, kontejnery nevyžadují mít COW FS ani nic podobného. Jen místo clone budeš muset dělat skutečnou kopii celého root adresáře, nebudeš moci dělat snapshoty (nebo opět jen kompletní kopií nebo využít zálohovací technologie, které vykopírují jen změněné soubory) a tak podobně. Ale na funkci to nemá vliv.

[Josef Kufner]

Další věc, která mi nebyla jasná, byla právě konfigurace image. Fakt se mi nechtělo věřit, že by někdo ručně natvrdo měnil soubory a čekal jsem nějakou sofistikovanou věc (lepší než ansible) zabudovanou přímo do dockeru, která to ulehčí. Ale odpověď: "prostě se to změní ručně" mě teda uzemnila.

Pointa je v tom, že ty nedistribuuješ image, ale popis (skript) k jeho výrobě – Dockerfile. V tom souboru je popsáno, které soubory a jak se mají upravit či přepsat. Vlastní existence nějakého obrazu čehosi je už nepodstatný implementační detail, aby se na každé spuštění kontejneru nečekalo týden. Tedy žádné ruční úpravy image, který by se pak někam nahrával, se nedělají. Upravíš skript, který ty úpravy provede a ten šíříš. Pokud chceš někomu ušetřit čas na sestavení image, tak můžeš uploadnout do Docker repozitáře i ten nakešovaný image.

[Käyttäjä 11133]

Tedy žádné ruční úpravy image, který by se pak někam nahrával, se nedělají

To je takova polovicni pravda, na Docker Hub jde uploadovat i uz hotove sestavene Docker images bez Dockerfile receptu... a taky to tak nekteri delaji, ale takove image nenasazuju ani na otestovani appky pokud nepochazi od duveryhondeho vendora.

[Bystroushaak]

Takže moje zjištění "proč docker" jsou: hype a hotové image pro neadminy. V čemž vidím velké bezpečností riziko.

Imho spíš funkční orchestrace. Docker registry a Dockerfile jsou dvě věci, které imho nic jiného nenabízelo. Jeden čas jsem taky používal lxc, ale to fungovalo stylem "urob si sám". Osobně třeba ansible nepovažuji za nějak štastnější řešení. Čímž nechci obhajovat Docker, tam mi spousta věcí taky přijde dost ujetá.

[cezz]

Ja osobne si tak trochu myslim, ze zasadny dovod preco Docker uspel je:

a) Uzivatelska privetivost. Ano, lxc, openvz boli skor (mozno aj nspawn, nie som si isty aky stary je ten projekt), ale ked vezmes cestu od cerstvo nainstalovaneho laptopu k beziacemu kontajneru s aplikaciou, tak Docker je otazka par minut. (apt install docker-ce, docker build.. a docker run..). Lxc a podobne musis este riesit ten extra tooling okolo. (napriklad spominany Ansible) Ak by si povedal, ze to zas tak vela prace navyse nie je, tak asi suhlasim, ale rozdiel tam je.

b) Microservices. Docker bol proste v spravny cas na spravnom mieste. Prave ked zacal nastupovat tento trend, Docker bol relativne popularny a hodil sa na microservices. V podstate sa zviezol na celom trende. Keby vtedy Canonical zapracoval a potlacil LXD, alebo niekto iny nejaku inu kontajnerovu technologiu, verim tomu ze by dnes situacia vyzerala inak.

Samozrejme ked sa rozhodujes dnes, tak hype a podobne nie je na mieste. (a nebol ani vtedy, ale tak sa nastavuju trendy - niekedy bohuzial) Dnes je to o tom, ze je okolo Dockeru kopec nastrojov ktore si pri inych kontajneroch musis casto implementovat sam. Konkretne ked sa bavime o infrastrukture, tak napriklad Kubernetes. Dnes uz proste nie je otazka, ci budes pouzivat Docker, pretoze musis lebo pouzivas Kubernetes ako sluzbu a alternativa by bola implementovat si nieco vlastne a platit ludi ktori by to prevadzkovali co dlho trva a stoji peniaze.

Aby sme sa rozumeli, nemyslim, ze Docker je nejaka uzasna technologia. Aj co sa tyka implementacie lightweight kontajnerov, tak tu su lepsie alternativy (rkt, podman, nspawn,..) oproti ktorym ma Docker casto zasadne nevyhody. Ale ked mas obmedzeny cas, pocet ludi a financie, tak proste pouzijes to co ma okolo seba vyvinuty ekosystem nastrojov a co vies aspon ciastocne pouzit ako outsourced sluzbu. A to je myslim, momentalne ta najzasadnejsia vyhoda Dockeru.

A od seriálu očekávám (přál bych si), že se dostane k technologiím, které si doma na koleně neudělám a bude tam jasná přidaná hodnota dockeru.

Je mozne, ze pre teba konkretne nema Docker nejaky zasadny prinos. Myslim, ze ze keby tam bola nejaka pridana hodnota, tak uz by si ho pouzival, vyzeras ako clovek co siahne po najlepsom nastroji na danu pracu. Nie vsetci ale maju luxus nieco riesit "doma na kolene" ci uz z nedostatku casu, alebo aj vedomosti, lebo to nie je ich core business.

[Käyttäjä 11133]

Ostatne je to i v clanku zmineno, ze je ta adopce tlacena principem infrastructure as a code.

[kralyk z abclinuxu]

Pokud přeskočím hype (který mě docela štve), tak docker nabízí hotové image "na všechno", takže "admin" nemusí umět nic nainstalovat a na pár řádků v dockerfile mu to odněkud (takže bezpečnostní riziko) postahuje někým vytvořené image programů.

Tady nutno podotknout, že Docker Hub v tomhle ohledu nemá právě dobrou pověst...

[bigBRAMBOR]

FS je záležitostí jádra filesystem jsem zvolil zcela záměrně, docker používá onion filesystem, tusim ze puvodne AUFS, ten pak byl vyrazen z járda, docker zkousel matlat neco svého, ted pouzivá overlay2. Uvnitr je pak XFS Nebo EXT4. Takze do verze kernelu 4.neco se pouzivaji image s AUFS, potom s overlay2. Natáhnout starší image vytvorený s AUFS do dnesniho dockeru jsem ani nezkousel, rychlejsi je vygenerovat nový image, kdyz uz clovek ma vytvoreny docker.file.

[Josef Kufner]

Takle používám Spectrum, které chce starý Debian. Uděláš kontejner, který je v podstatě jen takový lepší chroot a necháš to tam spokojeně chrochtat. Díky odříznutí od světa tě nemusí trápit zastaralost a (ne)bezpečnost. Vystavíš si ven jen ten socket, který potřebuješ, a máš klid.

Ani bych nedoporučoval na takové věci Docker. Ten se hodí spíš na vývoj a testování. Na takovéto služby je lepší vzít systemd-nspawn, neboť pak máš systemd v kontejneru integrovaný se systemd v hostitelském systému (viz systemctl --machine) a kontejner máš jen jako další službu. Do kontejneru stačí hodit dostatečně nový systemd (touto dobou už až tak nový není) a dbus, aby to mělo jak komunikovat, jinak netřeba nic navíc.

[petr_p]

Nevystačil, protože kontejnery sdílí jádro a ty máš problém s kompatibilitou jádra.

[Jendа]

Jak se vlastně stane že nějaký userspace přestane fungovat s novým jádrem? Myslel jsem, že v Linuxu se zpětná kompatibilita drží až absurdně nesmyslně.

[cezz]

Uz si nespominam detaily, ale zazil som ze sa kontajner spraval trochu inak na laptope a inak v produkcnom nasadeni na serveri prave preto, ze tam bola odlisna verzia jadra. (Treba mat na pamati, ze spatna kompatibilita sa naozaj dodrzuje, ale kompatibilita dopredu je tiez faktor)

Cize je to mozne, ale v praxi a pre bezne aplikacie to zas taky faktor nie je.

[petr_p]

Občas se obětuje existující rozhraní, protože se usoudí, že nové bude výhodnější nebo že staré nikdo nepoužívá. Častěji to je ale nevědomá změna v nějakém obskurním případě. Takhle jsem dvakrát přepisoval sledování ukončení cizího procesu přes ptrace(). S jádrem 5.3.0 bych to mohl přepsat na pidfd, což je konečně čisté řešení. V případě distribučních jader vypnutí starého rozhraní často bývá obchodní rozhodnutím, protože si tak distributor snižuje náklady na údržbu.

[johnyK]

aha, ERP-kolega od Gottwaldova jeste zije

jinak oneliner v Perlu nepiseme ale kopirujeme z toho, co nam nalezl google. Mam to vyzkousene, je to prumerne asi o 30 vterin rychlejsi.

[xvasek]

Tak to počkej počkej, pomalu ty vědátore, co je to google? To má být jako nějaká novější verze altavisty nebo co? Tady jsem vlastní rukou napsal generátor hlášek při odchodu z rachoty:

perl -e "my @x = ('jdu domu', 'koncim', 'balim to', 'nakaslat', 'bych se na to', 'co ja tu vlastne jeste delam'); print @x[rand @x], \"\n\""

Taky jsem zjistil, že z internetů zmizel yarpenův generátor nadávek, který by drobným rozšířením výše uvedeného mohl začít zase existovat, ale obsahuje moc sprostých slov pro školní příklad dockeru.

Abych nebyl za úplnou konzervu, tak docker chápu a dokonce i používám, ale začíná mi být smutno po době, kdy si člověk prostě otevřel textový editor a v něm napsal pár řádků a zkompiloval to nebo to spustil. (A když se mu to líbilo, mohl si to uložit na kazetu...)

[Aleš]

Koukám do diskuze a je to tu samý admin.

Po pravdě nemáme zatím žádného zákazníka, který by produkční systémy měl v Dockeru. Prakticky všechny servery jsou virtuály, ale jsou to stále "kompletní" systémy.

Pro mě je Docker především pískoviště, které mohu používat když nejsou cílové systémy k dispozici. Mám jeden obecný "základ" ve kterém je toho na poměry Dockeru až nezdravě mnoho a z něj různé forky podle zákazníků nebo (verzí) aplikací.

Původně jsem to měl jen pro sebe, ale postupně a velmi zvolna se to šíří i mezi kolegy. V našem případě totiž mít zdrojové je kódy kolikrát k ničemu, když nemáte i devel prostředí proti kterému vyvíjet. A je mnohem lepší mít ho v dockeru, než na korporátním virtuálu, na který se nedostanete, když nemáte spojení na Internet.

Nepotřebuji Kubernetes ani Swarm. Bylo by pěkné mít CI, ale na to bohužel není čas a síla. Mám to *pro sebe*, abych si ušetřil práci. Málokdy na něčem dělám s někým jiným paralelně, ale je to dobré když někomu předáváte práci. Brzy dostanu nový notebook. Snad to stěhování bude i díky Dockeru o něco menší opruz.

---

Dřív jsem používal VMware a fungovalo to stejně. Jen image byly *podstatně* větší a měly tendenci se "zanášet bordelem". Docker je prostě jen o něco "elegantnější".

---

A jako vývojář pro adminy:

* Netoužím po tom, aby se moje "prasácké" image dostaly kamkoliv blízko produkce či testovky

* Chraň Bůh, abych se musel starat o nějaký server

[...]

https://www.root.cz/zpravicky/naucte-se-pracovat-s-dockerem-a-kontejnery-skoleni/

12000 vs zdarma, stale je motivace? Psat zadara pro bussiness usery to chce odvahu

[Käyttäjä 11133]

Psat zadara pro bussiness usery to chce odvahu

Nebo to proste cloveka bavi :).

[Aleš Kapica]

Faktem je, že většina lidí lidí si neví rady, i přes to, že jim veškeré informace a know-how naservíruješ až pod nos. Když se nad tím zamyslíš, tak 12 litrů za to, že jim někdo věnuje dva dny svého času, aby jim to ukázal a vysvětlil, není zas tak moc. Obzvláště, v zemi, kde si mnozí nechají raději vrtat koleno, než by si nechali něco vysvětlit za prachy.

[czYbph0]

Bude prosím ještě seriál pokračovat?

[안전놀이터]

Pretty good post. I have just stumbled upon your blog and enjoyed reading your blog posts very much. I am looking for new posts to get more precious info. Big thanks for the useful info. 안전놀이터

[Adilkhatri]

검증된 파워볼사이트 를 찾으신다면 eos파워볼사이트 가 있는 파워볼사이트추천 에서 파워볼 을 즐기시길 바랍니다. 5년 이상 운영된 메이저업체 이며 지금까지 많은분들께 사랑받은 안전한파워볼사이트 입니다. 안전한파워볼사이트

[Adilkhatri]

So parcel to happen over your astounding site. Your blog acquires me a phenomenal exchange of charming.. Salubrious part alongside the scene. 먹튀검증업체 순위