====== Docker Desktop na Windows ======

//Vytvořeno: **1.4.2026** | Aktualizováno: **~~LASTMOD~~**//

[[https://docs.docker.com/desktop/setup/install/windows-install/|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 [[https://code.visualstudio.com/|Visual Studio Code]] se na Windows typicky používá [[https://docs.docker.com/desktop/features/wsl/|WSL 2 backend]].

===== Co je potřeba =====

  * Windows 10 nebo 11
  * práva správce pro instalaci
  * stažený instalátor Docker Desktop
  * [[https://code.visualstudio.com/|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.

===== Instalace Docker Desktop =====

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

===== Kdy je potřeba WSL =====

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:

<code powershell>
wsl --install
wsl --update
</code>

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.

===== Instalace Visual Studio Code =====

[[https://code.visualstudio.com/|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.

===== Instalace pluginu Dev Containers =====

Ve [[https://code.visualstudio.com/docs/devcontainers/containers|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''.

===== Jak otevřít připravený projekt =====

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

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

===== Jak ověřit, že Docker běží =====

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

<code powershell>
docker version
docker ps
</code>

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

===== Pomalé diskové operace v devcontaineru =====

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 [[infrastruktura:kontejnery:zrychleni-docker-devcontaineru-na-windows-pres-wsl2|Zrychlení Docker devcontaineru na Windows přes WSL2]].

===== VS Code Server a vysoké vytížení procesoru =====

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.

==== Příznak a zjištěná příčina ====

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.

==== Postup diagnostiky ====

  - 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.
  - 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.
  - 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.
  - 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:

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

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:

<code bash>
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
</code>

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.

==== Úprava nastavení ====

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:

<code json>
{
  "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
  }
}
</code>

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.

==== Jak zapisovat výjimky hlídače ====

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.

==== Dopady nastavení ====

  * ''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.

==== Chyby při původní opravě ====

  - **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.
  - **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''.
  - **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.

===== Co není potřeba řešit =====

  * 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

===== Zdroje =====

  * [[https://docs.docker.com/desktop/setup/install/windows-install/|Docker Desktop on Windows - oficiální dokumentace]]
  * [[https://docs.docker.com/desktop/features/wsl/|Docker Desktop WSL 2 backend - oficiální dokumentace]]
  * [[https://code.visualstudio.com/|Visual Studio Code]]
  * [[https://code.visualstudio.com/docs/devcontainers/containers|Visual Studio Code Dev Containers - oficiální dokumentace]]