didericis
c60e6b7e9f
Addresses the review finding that buildah lived only in the orchestrator
image, so the persistent infra VM wasn't the builder — a separate throwaway
builder VM contended with it for the orchestrator TAP. Consolidate:
- **Rebase the gateway (and thus infra) on `python:3.12-slim` = Debian
trixie**, pip-installing mitmproxy instead of `FROM mitmproxy/mitmproxy`
(Debian bookworm). trixie ships buildah 1.39, which can build agent
Dockerfiles that use heredocs; bookworm's 1.28 can't (`Unknown
instruction: "{"`). CA path is unchanged (set via `--set confdir=`).
- **buildah lives only in `Dockerfile.infra`** now (removed from the
orchestrator image, which is lean/stdlib-only again).
- **Shared orchestrator content**: `Dockerfile.orchestrator` is the single
definition of the control-plane payload; the infra image `COPY --from`s
it (same trixie base → clean copy, and future deps like iroh are added
once). The docker backend runs the orchestrator image directly.
- **`image_builder` builds inside the infra VM** (which now has buildah)
over SSH — no throwaway builder VM, so the `bborch0` contention is gone.
`ensure_built` builds orchestrator + gateway before infra (FROM gateway,
COPY --from orchestrator).
Verified on a KVM host: images build (buildah 1.39 in infra), the agent
image builds *inside* the infra VM (heredoc Dockerfile and all), the infra
VM stays healthy, the agent boots and `claude --version` = 2.1.172. The
rebased gateway still starts as a docker container and generates its CA
(docker backend unaffected).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WBMWTEtQdJ4W5UrWuLHCck
46 lines
2.5 KiB
Docker
46 lines
2.5 KiB
Docker
# Firecracker single infra-VM image (PRD 0070 Stage B).
|
|
#
|
|
# The per-host infra VM runs the orchestrator control plane, the gateway
|
|
# data plane, AND builds agent images (buildah) — all in one microVM (see
|
|
# backend/firecracker/infra_vm.py). It composes:
|
|
# * FROM the gateway image (mitmproxy / git / gitleaks / supervise + the
|
|
# flat daemon modules) — now trixie-based, so buildah 1.39 is available;
|
|
# * `COPY --from` the orchestrator image's content (the single definition
|
|
# of the control-plane payload — see Dockerfile.orchestrator), so this
|
|
# VM and the docker backend share one orchestrator definition; and
|
|
# * buildah, installed HERE only (the docker orchestrator/gateway images
|
|
# never carry it).
|
|
#
|
|
# multi-`FROM` can't union two bases (that's multi-stage, not multiple
|
|
# inheritance), so the orchestrator content is pulled in via `COPY --from`
|
|
# rather than a second base. Both images share the trixie `python:3.12-slim`
|
|
# base, so the copy is clean (same python; future installed deps copy too).
|
|
#
|
|
# The docker backend keeps orchestrator + gateway as separate images; this
|
|
# combined image exists only for the Firecracker single-VM cut. Splitting a
|
|
# service back into its own VM later is a routing change, not a repackaging
|
|
# (PRD 0070's "secret concentration"; a disposable builder can boot from
|
|
# this same image on its own TAP).
|
|
FROM bot-bottle-gateway:latest
|
|
|
|
# --- in-VM agent-image builder (PRD 0069 Stage 3) -------------------
|
|
# The Firecracker backend builds users' agent Dockerfiles *inside this VM*
|
|
# with buildah (rootless, daemonless) instead of on the host — no host
|
|
# Docker daemon, no root-equivalent `docker` group. `crun` is the OCI
|
|
# runtime; `netavark` + `aardvark-dns` are the network backend for `FROM`
|
|
# pulls + `RUN` egress. Requires the trixie base (buildah 1.39: bookworm's
|
|
# 1.28 can't parse Dockerfile heredocs that agent images use).
|
|
RUN apt-get update \
|
|
&& apt-get install -y --no-install-recommends \
|
|
buildah crun netavark aardvark-dns \
|
|
&& rm -rf /var/lib/apt/lists/*
|
|
# vfs + chroot: buildah works as root in the bare microVM (no
|
|
# fuse-overlayfs / overlay module / subuid maps). Matches image_builder.
|
|
ENV STORAGE_DRIVER=vfs \
|
|
BUILDAH_ISOLATION=chroot
|
|
|
|
# The orchestrator content, pulled from its single definition. The gateway
|
|
# image already has the flat daemon modules under /app; this adds the full
|
|
# `bot_bottle` package so `python3 -m bot_bottle.orchestrator` resolves.
|
|
COPY --from=bot-bottle-orchestrator:latest /app/bot_bottle /app/bot_bottle
|