Files
esh-pfi-infrastructure/stacks/ana-ml2-proxy
vh 913d2d2a6c feat(homepage): wire ana-ml2 back into discovery via socat proxy on ana-docker
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.
2026-09-07 16:34:13 -07:00
..

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.