Docker 1.6

Vyšel Docker 1.6, open-source platforma pro běh a distribuci linuxových kontejnerů. Nová verze přináší štítky pro kontejnery a image, více backendů pro logy (vč. syslog), rychlejší stahování z nového Registry 2.0 a další změny. Současně vycházejí nové verze podpůrných nástrojů Compose 1.2, Swarm 0.2, Machine 0.2 a preview klienta pro Windows.

17.4.2015 20:21 | washeck | Nová verze

Komentáře

[petrfm]

Chapu spravne, ze to je v podstate alternativa openvz? A pokud ano, je to lepsi, pripadne v cem? P.

[noo]

Je to spíš něco jako userspace pro aplikace. Místo virtuálního stroje se spouštějí aplikace a o přidělování systémových zdrojů se stará právě Docker. Je to jako kontejner, ve kterém se spouští aplikace a samotná kovová skořápka je vlastně backend starající se o přidělování zdrojů.

[aaa]

Nechapes.

Je to nastroj, ako pustat aplikacie vo vzdy rovnakom prostredi. Je to "lepsi chroot", ktory sa dokaze reprodukovatelne a efektivne vytvorit, pricom sa o to uzivatel nestara. Iba si napise skript, ako vytvorit testovacie prostredie z nejakej sablony a voila - ono sa to spravi a prostredie bude vyzerat vzdy rovnako. Nebude to pritom neefektivne ako keby sa to robilo vzdy od zaciatku.

Vdaka nemu mozem vyvijat na presne rovnakom prostredi, na akom sa bude testovat a na akom to pobezi. Nestane sa, ze pri vyvoji a testovani unikne niekomu chyba, ktora sa vyskytuje iba pri specifickej konfiguracii serveru. V pripade klient-server aplikacie je to este lepsie, kedze staci testovat raz a netreba skusat n² konfiguracii pre n roznych systemov.

O dokonalu izolaciu sa nesnazi - rovnako ako chroot alebo LXC (http://seclists.org/oss-sec/2014/q2/576).

[snajpa]

Ale chape. Dockeristi nechapou, co je kontejnerova virtualizace. Staci napsat kratkej bashovej skriptik, kterej mi udela OpenVZ template s aplikaci vevnitr a mam presne to samy, co je docker, minus praseni s portforwardovanim na hostiteli. Nebo ne?

[snajpa]

Respektive, jsem tim spis chtel rict, ze Dockeristi nechapou, ze tu kontejnerova virtualizace byla davno pred nimi a snazi se veci reinventovat, akorat trochu na hlavu padnutym zpusobem. Chudaci admini potom.

[podlesh]

Chápu že Docker je momentálně velmi populární a jeho používání se lavinovitě šíří a to může někomu vadit. Na zklidnění doporučuji si vždy vzpomenout na to, že přesně takhle už dvacet let sere BSD-čkaře linux! A to včetně hlášky "snazi se veci reinventovat, akorat trochu na hlavu padnutym zpusobem" (tu jsem viděl mockrát).

Myslím že by pro zdejší čtenáře bylo přínosnější napsat, že existují i jiné alternativy a mají nějaké konkrétní výhody (a třeba i nevýhody) z praxe. Nebo alespoň odkázat na google.

[snajpa]

Mne "vadi" (realne je mi celkem jedno, pokud to nemusim ja pouzivat) bezhlave prosazovani technologie, ktera umoznuje ignoranci. A Docker na ignoranci vcelku stavi. Podporovat neaktualizovatelnost a nesystemovost mi proste nesedi. Tam mi ta paralela s BSD vs. Linuxem moc nesedi, ale chapu, co se tim snazis rict a i to je, uznavam, trochu faktor, proc si o Dockeru nemyslim nic dobreho - ale urcite ne primarni.

[Stanislav Petr]

Pockej, co je na Dockeru neaktualizovatelny? Prave kvuli systemu deploymentu/aktualizaci jsem Docker nasazoval... Ono dokud mas tech stroji relativne malo, tak je Docker fakt jenom pritez, ale jakmile se staras o stovky instanci nejaky aplikace, potrebujes zajistit jednotny prostredi, aktualizaci a oddeleni dat od kodu, je Docker vybornej nastroj.

[snajpa]

On ten pristup, ktery Docker zaujima, vede k tomu, ze bude stav podobny jako v pripade milionu router-krabicek s linuxem. Podeployovane vsechny mozne single-purpose instance vsude mozne a pak celej ten bordel aktualizuj nejak rozumne. Misto toho, aby veci bezely nad jednim distrem a clovek se zabyval prave tim, jak udelat to distro vic multi-tenant, radsi naklonujeme distro milionkrat a budeme pozorovat ruzne variabilni stavy zamrazeni tech kontejneru v case. Kdybychom ale hledeli na kazdy kontejner jako na oddelenou instalaci, ktere je potreba venovat veskerou peci s tim souvisejici, skoncime stejne u toho, ze potrebujeme nejaky configuration-management, kterym ovladat instalace v case. Docker ekosystem tohle bude muset zase obloukem reinventnout. Mozna uz reinventuje, nesleduju to, mam k nemu averzi. Mne staci kontejnery rovnou

[Lukáš Lánský]

Ovládání instalací v čase ne, prostě se pozmění definice toho, jak má stroj vypadat. Staré instalace se zahodí a všechno se povytváří znovu.

Z programátorského hlediska je nádherný, že existuje přesný zdroj pravdy o všech aspektech prostředí, který nespoléhá na ruční zásahy a veškeré administrátorské woodoo tunění v něm musí být zachyceno, zdokumentováno, zaverzováno.

[Filip Jirsák]

Docker není žádný zázračný nástroj, který by uměl něco, čeho nelze docílit i jinými nástroji. Ostatně je to jenom pár běžných nástrojů šikovně poskládaných do sebe. Oproti kontejnerové virtualizaci to má například možnost dědění kontejnerů. Vytvoříte si obraz se základem distribuce, od něj si oddědíte obraz s webovým serverem, od něj obraz s aplikací a od něj obraz s vaší konkrétní konfigurací. No a když pak potřebujete pět různých konfigurací pro pět různých webů, máte ty obrazy pod tím společné (a sdílejí místo na disku), a větví se to až u toho posledního obrazu.

Není to nic, co by nešlo udělat jinými nástroji - akorát tady už ty nástroje máte úhledně zabalené v jednom balíčku, máte k tomu jednotné rozhraní, takže vaše kontejnery budou kompatibilní s kontejnery někoho jiného, máte k tomu veřejné repository, kde už spoustu obrazů najdete, takže je nemusíte vyrábět od začátku.

[snajpa]

Aha. Proto se mi to zda jako zbytecnost. Tohle totiz muj bezny setup s OpenVZ a ZFS umi taky. A podobne setupy jsem mel davno pred Dockerem a prisly mi vcelku jako samozrejmost. Navrhoval jsem na tom i komplexnejsi setupy, ale od te dedicnosti jsem nakonec vzdycky ustoupil, protoze z veci dela akorat neprehledny gulas (i kdyz mate tooly, co ty vztahy dobre vizualizuji, atd.). Na disku pak tuhnou stare verze, ktere zabiraji misto a zneprehlednuji setupy - to vzdycky po case, kdyz se vytvori kontejner a pak si zije svym zivotem. Jedinou moznosti by bylo kontejnery mazat a vyrabet znova od nejcerstvejsiho image, ale tenhle pristup ma vetsi downtime, nez kontejner zaktualizovat primo vevnitr. Vzdycky jsem nakonec v navrhu od sdilenych zakladu ustoupil, protoze jedine, co to setrilo, bylo misto na disku, ale nakonec to bylo vzdycky nejmene prakticke reseni v dlouhodobem meritku.

[Josef Kufner]

Místo na disku umí ušetřit i offline deduplikace, ať už na úrovni souborů, tak na úrovni bloků. Takže pak se celkem nabízí používat běžné distribuce s jejich balíčky a na pozadí uklízet duplicity. Asi bych jen důsledně oddělil relativně statický systém od uživatelských dat, kde nemá cenu plýtvat čas na deduplikaci.

[Filip Jirsák]

V případě Dockeru ale ty modifikace neprovádíte ručně, ale popíšete v konfiguračním souboru, co se má udělat. V tomhle je to velmi podobné Gentoo ebuildům - nevytváříte balíček, ale popis, jak se má balíček vytvořit. Tím pádem je ten postup jednak zdokumentovaný, jednak je možné jej kdykoli opakovat. A když přejdete na novou verzi, bude postup nejspíš velmi podobný - takže ten balíček jenom trochu upravíte.

Samozřejmě, pokud někdo spravuje více strojů, má na to své skripty a nástroje, aby opakovanou činnost nemusel dělat pořád dokola. Jenže pokud je to jenom jeden stroj, který se stěhuje jednou za několik let, je s těmi skripty zbytečně velká režie, takže se na to každý vykašle. S Dockerem je ale ta režie minimální (už jenom proto, že pro to existují návody a postupy, ze kterých víte, že tohle už někomu fungovalo), takže se to vyplatí i v takovýchto případech. A hlavně je to univerzální, takže jeden Docker image bez úprav spustíte na domácím PC s Ubuntu, na Google Cloudu nebo na Amazon EC2.

Ale jak už jsem psal, není to nic, co by nešlo řešit jiným způsobem, důležité je ale to, že to dostanete úhledně zabalené a převázané mašlí, stačí to začít používat. Asi jako když vývojáři řeknete, že svůj opensource může zveřejnit, ať si pořídí server a naučí se ho spravovat, nainstaluje na něm Git, stará se o jeho účty, vybere si na server nějakou wiki a systém na sledování úloh - a vedle toho se najednou objeví GitHub, kde to všechno má na jedno kliknutí.

[snajpa]

Takze by se Docker vic jak kousek softu dal povazovat za filozofii ohledne deploymentu aplikaci. Kterou vetsina adminu vetsich systemu uz nejakym zpusobem dodrzuje, ale Docker by se dal povazovat za jeden z prvnich projektu, ktery to recyklovatelne a snadno zpristupnuje i ostatnim. No jsem zvedavy, kam ten trend distribuce softwaru pujde, mame proti sobe hromadu pristupu a spis se mi zda, ze jdeme smerem vetsi fragmentace, nez unifikace. Sranda je to Diky vsem za relevantni komentare k veci.

[Sid]

Hlavne nie tak nahlas, ako to zoberie clovek co prave si mysli, ze objavil ameriku a ty mu prezradis, ze tam bol uz niekto 200 rokov pred nim.

[podlesh]

Chapu spravne, ze to je v podstate alternativa openvz? A pokud ano, je to lepsi, pripadne v cem? P.

Ne tak docela: alternativou openvz je LXC a Docker je "user-friendly" nadstavba nad LXC.

Bohužel zkušenosti nemám, takže konkrétně porovnat nedokážu.

[snajpa]

Tak ono LXC samotne se co do pouzitelnosti s OpenVZ neda dost dobre srovnat, pokud chce clovek kontejnery, ma na vyber z OpenVZ... a z ... OpenVZ. LXC maji pred sebou jeste velky kus prace v kernelu a jeste, mnohem vetsi, kus prace v user-space, aby z toho byla technologie na urovni pouzitelnosti OpenVZ.

[snajpa]

A abych byl spravedlivy, ani jedna z tech technologii podle mne nedosahuje urovne Solaris Zones, chybi jim ten stupen integrace napric celym systemem, ktery Zones maji. U OpenVZ by se takova integrace dala dosahnout, u LXC to ale nepujde tak jednoduse, pokud se neshodneme na jednom zpusobu, jak kontejnery vytvaret. Kontejner je pri LXC totiz vcelku virtualni pojem, vznika tim, ze se z pohledu jadra "nahodou" sejde proces v XY namespacech. Docker je tedy jednou z moznosti, jak pouziti LXC technologii standardizovat, ale mne se zda jako vcelku nestastny, protoze zbytecne omezuje a kontejnery jim vytvorene neni dobre chapat jako nezavisle a oddelene instance systemu.

A to vsechno je kvuli "nesystemovemu" pristupu vyvojaru danych technologii, je v mode radsi vymyslet dalsi a dalsi pojmenovanou technologii se svoji novou filozofii, ale prosadit jeden koncept napric vsemi komponentami se nedari. Nejvic mi na LXC chybi absence unikatniho identifikatoru kontejneru v jadre, bez nej si neumim dost dobre predstavit napriklad integraci BTRFS s kontejnery tak, jak to na Solarisu Zones maji se ZFS.

[Lol Phirae]

Oooo bóoože, už zase "systémově" sjednoducujeme. Napiš Lennartovi, tuším, že v tom již soudružsky něco podniká, budete si rozumět.

[snajpa]

Pouzival jsi nekdy Solaris, nebo jenom pindas, aniz bys mel nejmensi tuseni, o cem vlastne mluvim?

[radix]

... ale prosadit jeden koncept napric vsemi komponentami se nedari.

IMHO tohle proste v "bazarovych" projektech prakticky nejde. Kazdy ma sve vlastni koncepty, na nejakou unifikaci chybi centralni autorita.