Přejít k navigační liště

Zdroják » Různé » Docker a Windows

Docker a Windows

Články Různé

Docker na Windows může mít více podob, podíváme se na ně.

Nálepky:

Text vyšel původně na autorově webu.

předchozím článku o Dockeru jsem se jen letmo zmínil o použití Dockeru ve Windows. Tímto článkem bych chtěl objasnit, jak se věci mají, protože Docker na Windows může mít mnoho podob. Nicméně pořád platí, že tooling i způsob přemýšlení je stále stejný, což považuji za jednu z největších výhod Dockeřího ekosystému.

Začněme úplně základním rozdělením – Linuxové a Windows kontejnery. Pro Docker s Linuxovými kontejnery se většinou používá prosté označení “Docker” (příp. “Linux Containers”), pro nativní Docker na Windows pak “Windows Containers“. Pojem “Docker for Windows” se používá spíše pro tooling, který umožňuje provozovat Linuxové kontejnery na Windows.
Tyto kontejnery jsou vzájemně nekompatibilní – tzn. není možné provozovat Linuxové kontejnery jako nativní procesy ve Windows, ani není možné provozovat Windows kontejnery na Linuxu. Nicméně je možné pohodlně provozovat Linuxové kontejnery na Windows díky virtualizaci (virtuální stroj s Linuxem, na kterém je nainstalovaný Docker).

Windows Containers

Windows Containers je možné provozovat jen na Windows 10 (Professional, Enterprise a Education) a Windows Server 2016.

Podle způsobu izolace se Windows Containers dělí na dvě skupiny: “Windows Server Containers” a “Hyper-V Containers“. Jaká izolace bude použita, se specifikuje pomocí přepínače “–isolation” při volání “docker run“. Pro Windows Server 2016 je default “process“, pro Windows 10 “hyperv“.

Windows Server Containers je přesná obdoba Linuxových kontejnerů, tedy nový kontejner je jen další proces na tom samém Windows kernelu, který už na daném hostu běží. Tato izolace je dostupná jen na Windows Serveru 2016 (proto je to tam defaultní volba).

Na Windows 10 je jedinou možností, jak pustit Windowsí kontejner, hyperv izolace, tedy Hyper-V Containers. Ta funguje tak, že se pro každý nový kontejner vytvoří miniaturní, speciálně připravená, verze Windows uvnitř Hyper-V virtuální mašiny, tedy pro každý kontejner další virtuálka.

Windows Containers s hyperv isolation (jediná volba na Windows 10) tedy startují o něco déle (nižší jednotky sekund) a řeknou si o více RAMky. Protože ale na Windows 10 budete typicky provozovat kontejnery kvůli vývoji, tak jsem neměl pocit, že by mě to nějak omezovalo.

HOST OS ISOLATION USE-CASE
Windows 10 hyperv Development
Windows Server 2016 process Production
Windows Server 2016 hyperv Legacy applications?

Pokud jste pracovali s Linuxovými kontejnery, tak jistě víte, že existuje jediná absolutní bázová image – je to prázdná image jménem “scratch” – z té jsou odvozené všechny Linuxové image.

Windows Containers mají dvě bázové image, ze kterých můžete vyjít:

  • Microsoft/windowsservercore budete potřebovat, pokud se rozhodnete provozovat nějakou legacy aplikaci, např. která vyžaduje plný .NET Framework. Velikost této bázové image je cca 5 GB.
  • Naproti tomu microsoft/nanoserver má “jen” cca 400 MB a je určena pro běh aplikací, které jsou napsány “s cloudem v mysli”. Tato bázová image např. vůbec neobsahuje Services (“init systém ve Windows”), WMI ani PowerShell.

Linux Containers na Windows

Jak už jsem předestřel, Linuxové kontejnery je možné provozovat na Windows díky virtualizaci. Tzn. běží virtuální mašina s Linuxem uvnitř, a v Linuxu je nainstalovaný Docker, s kterým si povídá docker tooling z nativního prostředí (tedy normálně z CMD ve Windows). S konfigurací toho všeho si vůbec nemusíte lámat hlavu – Docker for Windows pro vás všechno připraví.

V této konfiguraci tedy běhají všechny spuštěné Linuxové kontejnery uvnitř té samé virtuální mašiny. Pro vývoj to používám léta a funguje to bez problémů.

V listopadu ovšem Docker oznámil, že v případě Linuxových kontejnerů na Windows půjde cestou LCOW. O co jde? V tomto případě poběží Docker daemon jako Windowsí proces, který bude pro každý Linuxový kontejner spouštět novou malou virtuální mašinu s Linuxem.

Od tohoto kroku si slibuji to, že bude brzo možné na Windows provozovat Windowsí a Linuxové kontejnery vedle sebe. Bude totiž existovat jediný Docker daemon, který bude schopný pouštět Windowsí i Linuxové kontejnery (nyní je nutné přepínat, na kterého daemona má být Docker tooling nasměrovaný).

Shrnutí

Pokud vyvíjíte na Windows, tak máte v případě Dockeru spoustu možností. Můžete pohodlně připravovat aplikace, které poběží v produkci na Windows nebo Linuxu. Jediné, co se zatím dělá špatně, je případ aplikace běžící na Windows, ale mající třeba databázi na Linuxu. Díky LCOW se ale i tady blýská na lepší časy.

Z hlediska produkčního nasazení je možné provozovat nativní Windowsí kontejnery na Windows Serveru 2016 a můžete přitom využívat stejný tooling jako v případě Linuxových kontejnerů. Windowsí kontejnery provozujeme produkčně už cca rok a až na drobné problémy všechno perfektně funguje.

O základech Dockeru jsem také povídal v Havitu v rámci tzv. vzdělávacích okének, a v Zonky. Pokud by se Vám líbilo školení základů Dockeru (z pohledu vývojáře) ve Vaší firmě, neváhejte mne kontaktovat!

Komentáře

Odebírat
Upozornit na
guest
1 Komentář
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
Zobrazit všechny komentáře
harrison314

Skoda ze Docker for Windows nemyslel na komunitny vyvoj na Win 10 Home cez VirtualBox.

Hermes místo OpenClaw?

AI
Komentáře: 2
Většina AI agentů v roce 2026 vám nabízí pohodlí výměnou za kontrolu — běží na cizí infrastruktuře, ukládají vaše data neznámo kam a fungují jen tak, jak je jejich tvůrci navrhli. Hermes od Nous Research jde opačným směrem: je open-source, nainstalujete si ho na vlastní server za pár dolarů měsíčně, připojíte k libovolnému LLM a necháte ho, aby si sám psal vlastní schopnosti podle toho, co od něj potřebujete. Výsledek? Agent, který skutečně patří vám a po pár týdnech používání rozumí vašemu setupu lépe než kterýkoli komerční asistent. Podívejme se, co Hermes umí, jak ho rozjet a pro koho dává smysl.

Robots.txt nestačí. AI crawleři mění, jak weby chrání obsah

Robots.txt zůstává základní signál pro slušné crawlery, ale už neumí popsat hlavní problém: stejný veřejný obsah může sloužit klasickému vyhledávání, AI odpovědím, tréninku modelů i načtení na pokyn uživatele. Provozovatel webu proto musí oddělit účel přístupu, ověřovat identitu botů, měřit dopad na infrastrukturu a u hodnotného obsahu řešit i vynucení pravidel mimo samotný robots.txt.

Jak funguje WordPress Cron a proč občas selhává

„Cron mi nějak neběhá." Klasická věta, která ve WordPress světě může znamenat cokoli od špatně nastavené WP_SITEURL, přes loopback zablokovaný Cloudflarem, až po fatal error v callbacku, který nechal viset transient doing_cron. WP-Cron totiž není skutečný scheduler — je to pseudo-cron závislý na návštěvnosti webu a HTTP loopbacku, se všemi pastmi, které si dokážete představit. Tenhle článek je hloubkový průchod jeho vnitřnostmi: co se reálně děje při spawn_cron(), kde vznikají race conditions, proč selhává a čím ho v produkci nahradit.