Docker Desktop na Windows

Vytvořeno: 1.4.2026 | Aktualizováno: 29.10.2026 10:47

Docker Desktop je nejjednodušší způsob, jak na Windows rozchodit Docker pro běh Linux kontejnerů. Pro běžné použití a pro otevření připraveného projektu ve Visual Studio Code se na Windows typicky používá WSL 2 backend.

• Windows 10 nebo 11
• práva správce pro instalaci
• stažený instalátor Docker Desktop
• Visual Studio Code

Pro běžné použití není potřeba ručně nastavovat Ubuntu ve WSL. Důležité je hlavně to, aby Docker Desktop měl funkční WSL 2 backend.

1. Stáhnout Docker Desktop z oficiální stránky.
2. Spustit instalátor.
3. Dokončit instalaci podle průvodce.
4. Spustit Docker Desktop.
5. Pokud Docker naběhne bez chyby, není potřeba nic dalšího řešit.

Pokud Docker Desktop při instalaci nebo při prvním spuštění hlásí, že chybí WSL 2 nebo že je potřeba WSL aktualizovat, je potřeba otevřít PowerShell jako správce a spustit tyto příkazy:

wsl --install
wsl --update

Po dokončení je vhodné restartovat Windows a znovu spustit Docker Desktop.

Pokud příkaz wsl –install nahlásí, že už je WSL nainstalované, je to v pořádku. V takovém případě obvykle stačí wsl –update a restart systému.

Visual Studio Code stačí stáhnout z oficiální stránky, spustit instalátor a editor otevřít. Pro tento návod není potřeba nic složitě nastavovat navíc.

Ve Visual Studio Code Dev Containers otevřít záložku rozšíření klávesovou zkratkou Ctrl+Shift+X, vyhledat Dev Containers od autora Anysphere a rozšíření nainstalovat. Pokud místo VS Code používáš Cursor nebo jiný podobný editor, princip je stejný: do editoru se nainstaluje rozšíření Dev Containers od autora Anysphere.

1. Otevřít složku projektu ve Visual Studio Code.
2. Stisknout F1.
3. Spustit příkaz Dev Containers: Reopen in Container.

Editor pak vytvoří a spustí kontejner podle připraveného .devcontainer nastavení.

Po úspěšné instalaci lze v PowerShellu spustit tyto příkazy:

docker version
docker ps

Pokud příkazy nevrátí chybu, Docker běží správně a je připravený pro otevření projektu.

Pokud jsou operace jako git status, otevírání souborů nebo instalace závislostí v devcontaineru extrémně pomalé, problém může být v tom, že projekt leží na Windows filesystemu a do kontejneru je připojený přes bind mount. Praktický postup je popsaný v samostatném návodu Zrychlení Docker devcontaineru na Windows přes WSL2.

VS Code Server při práci se vzdálenými soubory spouští mimo jiné hlídač změn a rozšíření pro Git a npm. Pokud je otevřený velmi rozsáhlý workspace, jejich automatická činnost může dlouho zatěžovat procesor. Následující zkušenost pochází z Remote-SSH do Docker kontejneru na Raspberry Pi s Alpine Linuxem, nikoli z Docker Desktop na Windows. Slouží jako vodítko pro diagnostiku jiného systému, ne jako důkaz stejné příčiny na Windows nebo v devcontaineru.

Měl jsem otevřený celý domovský adresář jako workspace. Obsahoval přes 1,5 milionu souborů, přibližně 85 000 složek, 57 Git repozitářů a symbolické odkazy mimo domovský adresář. Load average dosahoval 8,04 na čtyřjádrovém Raspberry Pi. Hodnota zahrnuje zátěž celého systému, nejen VS Code.

Měření ukázalo tyto činnosti:

• Rozšíření vscode.npm spustilo rg, aby vyhledalo soubory package.json pro panel NPM Scripts. Proces běžel přes devět minut a využíval 135 % CPU; přepínač --follow jej vedl i přes symbolické odkazy.
• Proces fileWatcher s knihovnou @parcel/watcher procházel strom souborů. Využíval 70–98 % CPU, za 7,5 minuty nedoběhl a jeho paměť RSS vzrostla na 532 MB.
• Git v procesu extensionHost využíval 5–15 % CPU při práci s 57 repozitáři.

1. Zjisti, jak velký workspace je otevřený, kolik obsahuje repozitářů a zda symbolické odkazy vedou do dalších rozsáhlých stromů. Nejmenší změnou může být otevřít jen potřebnou složku projektu. V popsaném případě jsem ale potřeboval ponechat otevřený celý domov.
2. V prostředí, kde běží VS Code Server, sleduj procesy a jejich příkazové řádky. Rozliš fileWatcher, extensionHost, případné procesy rg a ostatní zátěž. Hodnota nad 100 % CPU může znamenat využití více než jednoho jádra.
3. U dlouho běžícího hlídače zkontroluj také spotřebu paměti, otevřené soubory a počet inotify hlídačů. Nulový počet sám o sobě nedokazuje, že proces inotify nepoužívá: může ještě probíhat úvodní procházení stromu.
4. Změň jen potřebná nastavení, restartuj vzdálenou relaci VS Code a po dokončení úvodního průchodu změř stav znovu. Výsledek porovnej s původním měřením a zkontroluj i dopady na používané funkce.

Příklad kontroly v Linuxu; příkaz ps předpokládá variantu s podporou uvedených přepínačů. Příkazy spusť v kontejneru nebo systému, kde běží server, ne automaticky v PowerShellu na Windows:

ps -eo pid,ppid,pcpu,rss,args | grep -E '[f]ileWatcher|[e]xtensionHost|[r]g '

Po výběru správného PID hlídače lze prozkoumat jeho otevřené deskriptory a inotify záznamy. Doplň vlastní PID; přístup k /proc závisí na oprávněních a konfiguraci systému:

P=1234  # nahraď PID procesu fileWatcher
ls -l /proc/$P/fd
for f in /proc/$P/fd/*; do
  if [ "$(readlink "$f")" = "anon_inode:inotify" ]; then
    grep -c '^inotify ' "/proc/$P/fdinfo/${f##*/}"
  fi
done

Prázdný výstup nebo nula vyžadují další kontrolu: ověř PID, oprávnění a to, zda hlídač ještě neprochází strom. Otevřené složky a rostoucí RSS mohou napovědět, kde pracuje. Počet hlídačů není sám o sobě měřítkem vytížení CPU.

V uvedeném prostředí pomohlo upravit vzdálené nastavení VS Code Serveru v ~/.vscode-server/data/Machine/settings.json. Přesné cesty a vhodné výjimky závisí na systému. Soubor nejprve zkontroluj a změny začleň do existující konfigurace; nepřepisuj ji naslepo. Následující cesty jsou anonymizované příklady a je nutné je nahradit skutečnými absolutními cestami:

{
  "npm.autoDetect": "off",
  "search.followSymlinks": false,
  "git.autoRepositoryDetection": "openEditors",
  "files.watcherExclude": {
    "/home/uzivatel/projekt-a/runs": true,
    "/home/uzivatel/projekt-a/tasks": true,
    "**/node_modules": true,
    "**/.venv": true,
    "**/__pycache__": true
  }
}

Po restartu VS Code v tomto konkrétním měření hlídač procházel strom přibližně 80 sekund, potom využíval 0,5–2,4 % CPU, měl 28 154 inotify hlídačů a 176 MB RSS. Load average klesl na 2,21; jde o hodnotu celého systému a nelze ji připsat výhradně VS Code.

V testované verzi @parcel/watcher bylo důležité vyloučit samotnou složku, ne jen její obsah. Vzor zakončený /** dovolil hlídači do složky vstoupit a při úvodním průchodu zkoumat její položky. Na jednom stromu vyšlo měření takto:

• Cesta s hvězdičkou a koncovým /**: 11,3–11,8 s.
• Cesta s hvězdičkou, ale bez koncového /**: 8,4 s.
• Konkrétní absolutní cesta k vyloučené složce bez koncového /**: 1,2–1,3 s.

Pro toto prostředí se proto osvědčily konkrétní absolutní cesty bez závěrečného /**. Pro složky stejného jména na různých místech lze zvážit obecný vzor jako **/node_modules. Výsledek závisí na verzi VS Code, knihovně, struktuře stromu a skutečných cestách: po změně jej znovu změř. Při přidání další velké složky může být potřeba doplnit její vlastní výjimku.

• npm.autoDetect: off vypne automatickou detekci npm skriptů: zmizí panel NPM Scripts a automaticky nalezené npm úlohy. Skripty lze dál spouštět v terminálu.
• search.followSymlinks: false zabrání hledání obsahu za symbolickými odkazy. Chování rychlého otevření souboru pomocí Ctrl+P nebylo ověřeno.
• git.autoRepositoryDetection: openEditors omezí automatickou detekci na repozitáře související s otevřenými soubory. Další lze otevřít přes Git: Open Repository; Git v terminálu funguje dál.
• Ve složkách vyloučených pomocí files.watcherExclude se změny nemusí samy projevit v Exploreru; použij Refresh. Nebylo ověřeno, zda editor rozpozná externí změnu už otevřeného souboru v takové složce.
• Obecná výjimka jako **/temp nebo **/vendor zasáhne každou složku daného jména, tedy případně i vlastní zdrojové soubory. Vylučuj jen to, u čeho je tento dopad přijatelný.

Nastavení je vhodné zálohovat. Při smazání ~/.vscode-server, například při vytvoření nového kontejneru, může zmizet i vzdálená konfigurace. Před obnovou porovnej zálohu s případným existujícím souborem. Po upgradu VS Code znovu ověř chování výjimek, protože se může změnit.

1. Náhradní test místo skutečné knihovny: první výjimky končily /**. Odhad pomocí find -prune vypadal příznivě, ale find složku vynechal celou a nechoval se stejně jako hlídač. Po restartu hlídač dál využíval 93–98 % CPU. Teprve test se stejnou knihovnou @parcel/watcher ukázal rozdíl. Chování výjimek je potřeba ověřit skutečným nástrojem a následným měřením procesu.
2. Chybný výklad nulového počtu inotify hlídačů: nula byla nejprve považována za důkaz, že proces inotify nepoužívá. Ve skutečnosti ještě nedokončil úvodní průchod. Pomohla kontrola rostoucí RSS a otevřených složek v /proc/<pid>/fd.
3. Podhodnocené počty složek: první sčítání mělo limit osm sekund na každou složku. Velké stromy se proto nestihly projít celé. Výsledek nelze vydávat za přesný počet; vždy kontroluj, zda měření doběhlo bez časového limitu.

• není potřeba ručně otevírat Ubuntu a něco v něm nastavovat
• není potřeba ručně vytvářet kontejnery předem
• není potřeba ručně upravovat .devcontainer, pokud je už připravený v projektu

• Docker Desktop on Windows - oficiální dokumentace
• Docker Desktop WSL 2 backend - oficiální dokumentace
• Visual Studio Code
• Visual Studio Code Dev Containers - oficiální dokumentace