ana-ml2 is up but not reachable cross-site from ESH (return-route gap on ana-ml2, no SSH access to fix it). New stacks/ana-ml2-proxy: a pinned alpine/socat relay on ana-docker (host net) exposing 10.250.50.70:2354 -> ana-ml2 10.250.50.54:2375. Homepage docker.yaml ana-ml2-docker re-enabled pointed at the proxy. Verified: esh-docker-vm reaches ana-ml2's docker (29.3.1) through it; /api/services returns in 0s with 111 services; ana-ml2's inference seats (gen, coder, embed, rerank, reward, image-bench, dockge) render. Reversible: point back at 10.250.50.54:2375 and compose-down the proxy once ana-ml2 routes to ESH.
1.3 KiB
ana-ml2-proxy
A one-container socat TCP relay on ana-docker that exposes ana-ml2's
Docker API (10.250.50.54:2375) as 10.250.50.70:2354, so the Homepage
dashboard on esh-docker-vm can discover ana-ml2's containers.
Why it exists
ana-ml2 is up and its docker API is reachable from within Anaheim, but not
cross-site from ESH — there's a return-route gap on ana-ml2 and no SSH path to
it from the ops seats to fix its routing. ana-docker is on the same Anaheim
subnet (reaches 10.250.50.54:2375 directly) and is reachable from ESH, so
it relays. This avoids a mesh-route change (the kind that has black-holed sites)
and needs no access to ana-ml2 itself.
Plaintext, trusted mesh-internal only — the same posture as the fleet's other
plaintext :2375 docker hosts in stacks/homepage/conf/docker.yaml.
Deploy
scripts/deploy-stack.sh ana-docker ana-ml2-proxy --compose
ssh infra-ops@10.250.50.70 'cd /opt/docker/compose/ana-ml2-proxy && sudo docker compose up -d'
Homepage's docker.yaml ana-ml2-docker entry points at 10.250.50.70:2354
(the proxy), not 10.250.50.54:2375 directly.
Undo
Once ana-ml2 has a working return route to ESH, point Homepage's ana-ml2-docker
back at 10.250.50.54:2375 and docker compose down this stack.