Context
Currently nemesis8 serve runs on the host and spawns one-shot containers per request. A gateway-in-container mode would run the gateway process itself inside a container, binding the Docker socket through (-v /var/run/docker.sock:/var/run/docker.sock or Podman equivalent) so it can still spawn sibling containers.
Use cases
- Fully containerized deployment (no host Rust binary needed at runtime)
- Running nemesis8 as a service inside a Docker Compose stack or Kubernetes pod
- Isolated gateway with controlled socket access
What changes
nemesis8 serve --containerized — wraps the gateway in a docker run call with socket bind-mount and port mapping, then detachesGATEWAY_URL for spawned sibling containers: use the gateway's container name or Docker network IP (not host.docker.internal), since gateway and agents are on the same Docker bridge- Single-instance check: current check pings
localhost:{port} — needs to also check for a running container with a gateway label via Docker API
Dependency
Builds on #19 and #21.
Context
Currently
nemesis8 serveruns on the host and spawns one-shot containers per request. A gateway-in-container mode would run the gateway process itself inside a container, binding the Docker socket through (-v /var/run/docker.sock:/var/run/docker.sockor Podman equivalent) so it can still spawn sibling containers.Use cases
What changes
nemesis8 serve --containerized— wraps the gateway in adocker runcall with socket bind-mount and port mapping, then detachesGATEWAY_URLfor spawned sibling containers: use the gateway's container name or Docker network IP (nothost.docker.internal), since gateway and agents are on the same Docker bridgelocalhost:{port}— needs to also check for a running container with a gateway label via Docker APIDependency
Builds on #19 and #21.