Auto-detect Rancher Desktop and Podman container runtimes#399
Conversation
There was a problem hiding this comment.
This PR makes lstk auto-discover Rancher Desktop / Podman daemons and degrade gracefully when port 443 can't be published; the design is careful and the test coverage is strong.
-
thought(non-blocking): on
internal/container/start.go— instartWithOptionalPortFallback, whenrt.Removefails you return the original bind error and leave a created-but-never-started container behind under the same name, so the nextlstk startwould hit a name-conflict. The comment acknowledges the tradeoff, but surfacing a hint (or the leftover container name) in that error path would save the user from a confusing follow-up failure. -
question(non-blocking): on
internal/runtime/docker_context.go—resolveDockerContextHostnow dials the context socket (200ms timeout) insideNewDockerRuntimewhenever a non-default context is set, which puts a synchronous probe on thestart/status/stoppath. It's almost certainly negligible, but was that hot-path cost a conscious call versus honoring the context without the reachability probe? -
praise: the two-layer handling — a preflight dial for host-busy ports plus a start-time retry for daemon bind-denied ports, with the evidence pair (
rt.Flavor()+DetectInstalledFlavor()) driving runtime-specific hints and Windows' named-pipe blind spot explicitly handled — is a genuinely thorough take on a messy cross-runtime problem, and the CLAUDE.md/docs updates capture the reasoning clearly. @skyrpex
Generated by Claude Code
What
lstknow works out of the box with Rancher Desktop and Podman, alongside Docker Desktop, Colima, OrbStack, and Lima:lstknow also resolves the current Docker CLI context (docker context use …/DOCKER_CONTEXT). An explicitDOCKER_HOSTstill always wins.rdctl start,podman machine start,colima start, …) instead of always assuming Docker Desktop.lstknow starts without 443 and prints a warning with a runtime-specific fix. HTTPS stays available on the edge port (4566 serves both HTTP and HTTPS). If you explicitly configured 443 viaGATEWAY_LISTEN, a conflict remains a hard error.Why
Users on Rancher Desktop or Podman had to manually export
DOCKER_HOST, and then still hit a fatal, cryptic port-443 error on startup. Discovery and startup should just work across Docker-API-compatible runtimes (DEVX-639, DEVX-637).How to test
lstk start— auto-detected via~/.rd/docker.sockor therancher-desktopdocker context. With Kubernetes enabled, expect the 443 warning with the Traefik hint (transcript below).podman machine init && podman machine start, quit other runtimes, thenlstk start— auto-detected via the podman machine socket; also works via a manually created context (docker context create podman --docker "host=unix://$(podman machine inspect --format '{{.ConnectionInfo.PodmanSocket.Path}}')" && docker context use podman). In rootless mode, expect the 443 warning with the--rootfulhint (transcript below).lstk start— auto-detected as before.DOCKER_HOST=unix://… lstk startmust beat context and auto-detection.lstk startshould suggest the start command for whatever runtime is installed.Before / after
Before (any runtime that cannot bind 443 — fatal):
After (rootless Podman machine — the daemon rejects the 443 bind at start time,
lstkretries without it):After (Rancher Desktop with Traefik holding 443 — caught by the preflight, before the image pull):
Closes DEVX-637
Towards DEVX-639