kevinveenbirkenbachandClaude Opus 5.5 c59e2838d6 fix(swarm): reach gitea, shopware and fider from inside their containers ...

In swarm, `docker stack deploy` drops the host IP of a short port mapping,
so a `127.0.0.1:<ports.local>` publish lands on the ingress routing mesh
on every node. The provisioning of these three roles only worked because
the mesh answered on the host:

- web-app-gitea waited for `DOCKER_REACH_HOST:<ports.local.http>` with
  wait_for and polled `/api/v1/version` there with uri_retry.
- web-app-shopware waited for `DOCKER_REACH_HOST:<ports.local.http>`.
- web-app-fider bootstrapped its first tenant in swarm by POSTing to
  `127.0.0.1:<ports.local.http>` on the hosting node.

As long as these calls depend on the mesh, container_ports cannot stop
publishing loopback ports in swarm. The probes now run inside the
service's own container through the resolved `<PREFIX>_LOCAL_CID` on
`<PREFIX>_HOST_NODE`, against the internal port:

- Gitea uses the curl it ships. The first wait accepts any HTTP answer,
  as wait_for did. The post-migration wait still requires 200.
- Shopware runs the wget probe its compose healthcheck already uses.
- Fider ships no HTTP client, so bash writes the tenant POST to
  /dev/tcp. The body comes in on stdin and the status line is checked
  for 200/201.

Fider's compose path is unchanged. The compose render of all three roles
is unchanged. The host-side ingress guard from svc-swarm-node stays in
place until the remaining host-side consumers are moved.

Refs #1089

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-29 00:01:20 +01:00

..

main.yml

fix(swarm): reach gitea, shopware and fider from inside their containers

2026-10-29 00:01:20 +01:00