Files
bot-bottle/Dockerfile.infra
T
didericis 8d7e5956e1
lint / lint (push) Successful in 2m6s
test / unit (pull_request) Successful in 1m7s
test / integration (pull_request) Successful in 24s
test / coverage (pull_request) Successful in 1m19s
feat(firecracker): run the gateway data plane in the infra VM too (Stage B, 2/n)
The single infra VM now runs BOTH the orchestrator control plane and the
gateway data plane (egress / supervise / git-http), multi-tenant against
the local control plane — the single-VM shape from the Stage B design.

- Dockerfile.infra: the firecracker infra image = the gateway image +
  the baked control-plane source (FROM bot-bottle-gateway, COPY
  bot_bottle). Reuses the gateway payload rather than copying mitmproxy/
  gitleaks into a third image; the docker backend keeps its two separate
  images.
- infra_vm: build from source (gateway then infra image), and the PID-1
  init now also launches `gateway_init` with
  BOT_BOTTLE_ORCHESTRATOR_URL=http://127.0.0.1:8099. Adds `gateway_ca_pem`
  (fetch the mitmproxy CA over SSH) and the agent-facing port constants.
- init exports PATH — a bare-init shell resolves its own execs via a
  built-in default path, but that isn't in the environment, so
  gateway_init's `python3 ...` daemons would otherwise fail to spawn.

Verified on a KVM host: infra VM boots, control plane /health -> 200, and
egress:9099 / supervise:9100 / git-http:9420 all listen and are reachable
from the host over the TAP link; the gateway CA is retrievable. (git-gate
stays down until a bottle provisions its per-bottle entrypoint/creds, same
as a fresh docker gateway — non-fatal, the supervisor keeps the rest up.)

Next: agent->gateway VM-to-VM routing so bbfc* VMs reach these ports at
the infra VM and nowhere else.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WBMWTEtQdJ4W5UrWuLHCck
2026-07-16 12:47:13 -04:00

22 lines
1.1 KiB
Docker

# Firecracker single infra-VM image (PRD 0070 Stage B).
#
# The per-host infra VM runs BOTH the orchestrator control plane and the
# gateway data plane in one microVM (see backend/firecracker/infra_vm.py).
# It layers the stdlib-only control-plane source onto the gateway
# data-plane image, so the single VM has mitmproxy / git / gitleaks /
# supervise (gateway) AND `bot_bottle.orchestrator` (control plane) —
# reusing the gateway payload rather than copying it into a third image.
#
# The docker backend keeps the two images separate (a lean orchestrator
# container + a gateway container); this combined image exists only for
# the Firecracker single-VM cut. If the egress blast radius ever warrants
# it, splitting egress back into its own VM is a routing change, not a
# repackaging (see PRD 0070's "secret concentration").
FROM bot-bottle-gateway:latest
# The gateway image copies only its daemon modules flat under /app; the
# control plane needs the whole (stdlib-only) package. Both coexist:
# `/app/gateway_init.py` keeps its flat-sibling imports, and
# `python3 -m bot_bottle.orchestrator` resolves /app/bot_bottle.
COPY bot_bottle /app/bot_bottle