Files
windmill/docker/DockerfileCaddyL4
Ruben Fiszel 2f6c35b15b fix(self-host): unbreak self-hosted Caddy after the caddy-l4 syntax change (#10156)
* fix(self-host): accept pre-2.11 Caddyfiles in the caddy-l4 image

The Caddyfile is a bind-mounted file the user owns, so `docker compose pull`
updates the image but never their config. #10106 and #10113 changed the syntax
the image requires (native caddy-l4 `route { proxy { upstream } }`, and a
non-empty `bind`), which strands every existing self-host on their next pull:

  Error: adapting config using caddyfile: parsing caddyfile tokens for 'layer4':
  wrong argument count or unexpected line ending after 'proxy', at line 4

Normalize legacy Caddyfiles in the entrypoint instead. Only rewrite when the
config cannot be used as-is, and on any failure exec caddy against the user's
original file so it reports a real error against what they wrote.

The bind rewrite is not cosmetic: an empty `bind {$ADDRESS}` adapts and
validates cleanly on caddy >= 2.9 but drops the whole HTTP site, so a
syntax-only shim would trade a restart loop for a container that boots clean
and serves nothing on :80.

The reference for correctness is the image published before #10106
(sha-989c9e6): whatever it adapts today is what self-hosters run, so the shim
must reproduce it byte for byte. docker/test-caddy-compat.sh asserts that over
five legacy variants, plus the :80 listener under an unset ADDRESS, every
--config spelling, relative and glob imports, and the no-op on the current
Caddyfile.

Details worth knowing:
- `to a b` becomes one `upstream` per address; `upstream a b` would be a single
  upstream with two dials, which is a different load-balancing topology.
- The rewrite lands next to the original, because caddy resolves `import`
  relative to the importing file and a glob import would otherwise silently
  expand to nothing.
- The image has no ENTRYPOINT and CMD ["caddy", ...], so an existing
  `command:` override starts with a `caddy` token the entrypoint absorbs.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(self-host): route ws_mp and ws_debug to the extra gateway

reverse_proxy only reads its first argument as a matcher, so

  reverse_proxy /ws/* /ws_mp/* /ws_debug/* http://windmill_extra:3000

adapts to a single /ws/* route whose upstreams are `ws_mp/*:80`,
`ws_debug/*:80` and `windmill_extra:3000`. LSP therefore round-robins across
two garbage hostnames and connects only one time in three, while /ws_mp/* and
/ws_debug/* match no route at all and fall through to windmill_server:8000.

Use a named matcher so all three paths reach the gateway. Verified with traffic
against separate windmill_server and windmill_extra backends: before, /ws/lsp
fails and /ws_mp/room reaches windmill_server; after, all three reach the
gateway with the path preserved and /user/login still reaches windmill_server.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(self-host): pin the caddy-l4 image to an explicit version

:latest and the bind-mounted ./Caddyfile it has to agree with are updated by
different mechanisms, so they drift. Publish an explicit version alongside
:latest and pin docker-compose.yml to it, so a checkout is self-consistent:
compose, Caddyfile and image version now move together in one commit.

CI fails the build when docker/caddy-l4.version and the docker-compose.yml pin
disagree, and runs the compatibility-shim tests before publishing. The path
filter now covers the entrypoint, the normalizer, the Caddyfile and
docker-compose.yml, so a change to any guarded input actually triggers the
workflow rather than leaving the check unrun.

:latest keeps being published, since existing deployments reference it and that
is how they pick up the compatibility shim.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(self-host): make the caddy-l4 version tag publishable before the pin merges

docker-compose.yml pins an exact tag, but the version tag was gated on the
default branch, so the tag only appeared after the pin had already merged.
Between the merge and the build finishing, a fresh `docker compose up -d` off
main fails with "manifest unknown", and a failed build leaves main permanently
referencing an image that does not exist.

Drop the gate so the tag can be published from the branch via
workflow_dispatch before merging the pin. The version is immutable, so
republishing it from main is a no-op, and only pushes to main and manual
dispatch run this workflow, so a branch cannot claim the tag by accident.
:latest stays gated on main.

Also check the version file against the caddy version the Dockerfile pins.
Without it, a caddy bump that forgets the version file publishes a tag naming
the wrong caddy.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(self-host): do not log Caddyfile contents from the compat shim

The shim logged a unified diff of the rewrite, which carries three lines of
context around each change. A Caddyfile is user-owned and can hold basic_auth
hashes, proxy Authorization headers or TLS provider tokens, and container logs
are routinely shipped off the host, so normalizing a customized config could
copy secrets into them. Reproduced with a basic_auth bcrypt hash landing in the
log as context around the bind rewrite.

Log the number of rewritten lines and the path to the rewritten file instead.
It sits next to the original, so an operator can diff it themselves.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-16 16:39:33 +02:00

24 lines
1.0 KiB
Plaintext

FROM caddy:2.11.4-builder-alpine AS builder
# caddy-l4 natively registers the `layer4` global option used by the Caddyfile.
# Do NOT also add RussellLuo/caddy-ext/layer4: it registers the same global
# option, and building both panics with "global option 'layer4' already registered".
RUN xcaddy build \
--with github.com/mholt/caddy-l4@bd96009ea7373869bb07d61055554f966b1f5088
FROM caddy:2.11.4-alpine
COPY --from=builder /usr/bin/caddy /usr/bin/caddy
COPY caddy-compat-normalize.awk /usr/local/lib/caddy-compat/normalize.awk
COPY entrypoint-caddy.sh /usr/local/bin/entrypoint-caddy.sh
RUN chmod +x /usr/local/bin/entrypoint-caddy.sh
# The base image has no ENTRYPOINT and puts `caddy` in CMD, so setting an
# ENTRYPOINT here both resets CMD (restated below) and changes what a user's
# existing `command:` override means. The entrypoint absorbs a leading `caddy`
# token so both forms keep working.
ENTRYPOINT ["/usr/local/bin/entrypoint-caddy.sh"]
CMD ["run", "--config", "/etc/caddy/Caddyfile", "--adapter", "caddyfile"]