Windows Manage Server installer: use Docker instead of Podman #11

New issue

Closed

opened 2026-07-30 09:37:22 +02:00 by amiryahaya · 0 comments

amiryahaya commented

2026-07-30 09:37:22 +02:00

Owner

Summary

The Windows Manage Server installer currently auto-installs Podman when no container runtime is present. We need it to use Docker instead.

Current behaviour

get.ps1 (bootstrapper, manage-server mode) — when Test-ComposeRuntime finds neither docker nor podman already installed and working, it unconditionally installs Podman: enables WSL2 if needed, then winget install -e --id RedHat.Podman (get.ps1:94-140), then podman machine init --now. Docker is never the auto-install target — only used if the operator already has it.
install.ps1 already prefers Docker over Podman when both are present/working (install.ps1:51-64: tries docker info first, falls back to podman info), but since get.ps1 only ever auto-installs Podman, a fresh machine with neither runtime always ends up on Podman.
upgrade.ps1 and uninstall.ps1 both iterate @('docker', 'podman') for runtime detection (upgrade.ps1:37-43, uninstall.ps1:29-35) and have Podman-specific handling (starting the Podman machine if the daemon probe fails).
install.ps1 also carries a Podman-specific workaround for a rootless-on-Windows limitation: Podman's WSL2 backend runs rootless and can't auto-create /etc/triton inside the VM, so the installer writes a compose.override.yaml that swaps the TLS bind-mount for a named volume (install.ps1:192-215, see the comment there for the full explanation).
README.md:133-134,232 documents this as the intended behaviour ("the installer will install Podman automatically").

Desired behaviour

Switch the Windows auto-install path to Docker Desktop instead of Podman.

Open questions for whoever picks this up

Scope: does "use Docker instead of Podman" mean (a) just change what get.ps1 auto-installs when nothing is present, while still accepting a manually-installed Podman (current docker-preferred detection in install.ps1/upgrade.ps1/uninstall.ps1 already does this), or (b) drop Podman support entirely and require Docker? (b) would let the rootless-workaround block in install.ps1:192-215 be deleted, but also breaks compatibility for anyone who already installed on Podman.
Unattended install fit: the current flow installs the Podman CLI only (no GUI) specifically so get.ps1 can run silently under an elevated, non-interactive PowerShell session (get.ps1:117-118, "no GUI"). Docker Desktop is normally a GUI application tied to a logged-in user session and typically needs to be launched/accepted once interactively — worth confirming winget install -e --id Docker.DockerDesktop (or an unattended install flag) actually works cleanly from a script running as Administrator with no user present, the same way the current Podman CLI install does.
Licensing: Docker Desktop is free for personal use/small business/education but requires a paid subscription for larger commercial deployments — worth confirming this is acceptable for Triton's enterprise customers before making it the default auto-installed runtime.

Affected files (in `triton-install`, `manage-server/`)

get.ps1 — auto-install target (winget install -e --id RedHat.Podman → Docker equivalent)
install.ps1 — runtime detection/preference order, Podman rootless TLS-volume workaround
upgrade.ps1, uninstall.ps1 — runtime detection loop, Podman-machine-start handling
README.md — Windows requirements/support-matrix documentation

## Summary The Windows Manage Server installer currently auto-installs **Podman** when no container runtime is present. We need it to use **Docker** instead. ## Current behaviour - `get.ps1` (bootstrapper, `manage-server` mode) — when `Test-ComposeRuntime` finds neither `docker` nor `podman` already installed and working, it unconditionally installs Podman: enables WSL2 if needed, then `winget install -e --id RedHat.Podman` (`get.ps1:94-140`), then `podman machine init --now`. Docker is never the auto-install target — only used if the operator already has it. - `install.ps1` already *prefers* Docker over Podman when both are present/working (`install.ps1:51-64`: tries `docker info` first, falls back to `podman info`), but since `get.ps1` only ever auto-installs Podman, a fresh machine with neither runtime always ends up on Podman. - `upgrade.ps1` and `uninstall.ps1` both iterate `@('docker', 'podman')` for runtime detection (`upgrade.ps1:37-43`, `uninstall.ps1:29-35`) and have Podman-specific handling (starting the Podman machine if the daemon probe fails). - `install.ps1` also carries a Podman-specific workaround for a rootless-on-Windows limitation: Podman's WSL2 backend runs rootless and can't auto-create `/etc/triton` inside the VM, so the installer writes a `compose.override.yaml` that swaps the TLS bind-mount for a named volume (`install.ps1:192-215`, see the comment there for the full explanation). - `README.md:133-134,232` documents this as the intended behaviour ("the installer will install Podman automatically"). ## Desired behaviour Switch the Windows auto-install path to Docker Desktop instead of Podman. ## Open questions for whoever picks this up 1. **Scope**: does "use Docker instead of Podman" mean (a) just change what `get.ps1` auto-installs when nothing is present, while still accepting a manually-installed Podman (current `docker`-preferred detection in `install.ps1`/`upgrade.ps1`/`uninstall.ps1` already does this), or (b) drop Podman support entirely and require Docker? (b) would let the rootless-workaround block in `install.ps1:192-215` be deleted, but also breaks compatibility for anyone who already installed on Podman. 2. **Unattended install fit**: the current flow installs the Podman *CLI only* (no GUI) specifically so `get.ps1` can run silently under an elevated, non-interactive PowerShell session (`get.ps1:117-118`, "no GUI"). Docker Desktop is normally a GUI application tied to a logged-in user session and typically needs to be launched/accepted once interactively — worth confirming `winget install -e --id Docker.DockerDesktop` (or an unattended install flag) actually works cleanly from a script running as Administrator with no user present, the same way the current Podman CLI install does. 3. **Licensing**: Docker Desktop is free for personal use/small business/education but requires a paid subscription for larger commercial deployments — worth confirming this is acceptable for Triton's enterprise customers before making it the default auto-installed runtime. ## Affected files (in `triton-install`, `manage-server/`) - `get.ps1` — auto-install target (`winget install -e --id RedHat.Podman` → Docker equivalent) - `install.ps1` — runtime detection/preference order, Podman rootless TLS-volume workaround - `upgrade.ps1`, `uninstall.ps1` — runtime detection loop, Podman-machine-start handling - `README.md` — Windows requirements/support-matrix documentation

amiryahaya referenced this issue from a commit

2026-08-13 08:01:29 +02:00

Windows: auto-install Docker Desktop instead of Podman

amiryahaya referenced this issue from a pull request that will close it,

2026-08-13 08:01:37 +02:00

Windows: auto-install Docker Desktop instead of Podman #17

amiryahaya closed this issue

2026-08-13 08:02:49 +02:00