didericis/bot-bottle
1
0
Fork 0
Code Issues 25 Pull Requests 9 Actions Packages Projects Releases Wiki Activity

Split the conflated bot-bottle-sidecars image into distinct orchestrator + gateway images #384

New Issue
Closed
opened 2026-07-14 16:12:02 -04:00 by didericis-claude · 0 comments
didericis-claude commented 2026-07-14 16:12:02 -04:00
Collaborator
Copy Link
Copy Source

Today one image — bot-bottle-sidecars:latest, built from Dockerfile.sidecars — serves two unrelated roles in the consolidated (PRD 0070) control plane:

  1. The gateway data plane — its actual purpose: mitmproxy egress + git-gate (git-daemon / smart-HTTP / gitleaks) + supervise, spawned by the stdlib PID-1 supervisor /app/sidecar_init.py. Heavy base (mitmproxy/mitmproxy:11.1.3, debian-slim + git + openssh-client + gitleaks).
  2. The orchestrator control plane — OrchestratorService runs the same image but overrides the entrypoint to python3 -m bot_bottle.orchestrator (bot_bottle/orchestrator/lifecycle.py: image: str = GATEWAY_IMAGE, and _run_orchestrator_container sets --entrypoint python3 … -m bot_bottle.orchestrator). The orchestrator is stdlib-only by design — its module docstring notes "the orchestrator is stdlib-only, so the bundle image's python is enough" — so it needs none of the gateway's mitmproxy / gitleaks / git payload.

Why split

  • Least privilege / attack surface. The control plane concentrates every bottle's secrets (PRD 0070's "secret concentration" risk). Shipping that secret-dense process inside the mitmproxy/git/gitleaks image gives it a large, unrelated dependency surface. A lean orchestrator image (python + the bot_bottle package, nothing else) shrinks it.
  • Clarity of contract. GATEWAY_IMAGE doubling as the orchestrator's image is confusing — lifecycle.py imports a gateway.py constant purely to run non-gateway code. Two purpose-named images make the roles explicit.
  • Build cost / churn. The orchestrator rebuilds/reboots on any Dockerfile.sidecars change even when only gateway daemons moved, and vice-versa.
  • Prerequisite for the Firecracker gateway VM (#348 / PRD 0070 Stage B). Virtualizing the orchestrator needs a bootable gateway rootfs distinct from the orchestrator runtime; a clean image split is the natural first step.

Proposed shape

  • Dockerfile.gateway → bot-bottle-gateway:latest — current Dockerfile.sidecars contents (the data plane).
  • Dockerfile.orchestrator → bot-bottle-orchestrator:latest — minimal python base + the bot_bottle package; ENTRYPOINT ["python3", "-m", "bot_bottle.orchestrator"].
  • Retire the bot-bottle-sidecars:latest name + Dockerfile.sidecars; update GATEWAY_IMAGE / GATEWAY_DOCKERFILE in orchestrator/gateway.py, and give OrchestratorService its own ORCHESTRATOR_IMAGE / dockerfile instead of borrowing GATEWAY_IMAGE.

Out of scope (note)

The legacy per-bottle sidecar path still names containers bot-bottle-sidecars-<slug> (backend/docker/sidecar_bundle.py, backend/docker/compose.py, the firecracker/macos launch.py, and the enumerate/cleanup prefix constants). This issue is about the consolidated shared images; the per-bottle-bundle naming can be reconciled separately and largely disappears as the consolidated path supersedes per-bottle bundles.

Prerequisite refactor split out of the PRD 0070 firecracker consolidated-launch work (PR #354).

Today one image — `bot-bottle-sidecars:latest`, built from `Dockerfile.sidecars` — serves **two unrelated roles** in the consolidated (PRD 0070) control plane: 1. **The gateway data plane** — its actual purpose: mitmproxy egress + git-gate (git-daemon / smart-HTTP / gitleaks) + supervise, spawned by the stdlib PID-1 supervisor `/app/sidecar_init.py`. Heavy base (`mitmproxy/mitmproxy:11.1.3`, debian-slim + `git` + `openssh-client` + gitleaks). 2. **The orchestrator control plane** — `OrchestratorService` runs the *same* image but overrides the entrypoint to `python3 -m bot_bottle.orchestrator` (`bot_bottle/orchestrator/lifecycle.py`: `image: str = GATEWAY_IMAGE`, and `_run_orchestrator_container` sets `--entrypoint python3 … -m bot_bottle.orchestrator`). The orchestrator is **stdlib-only** by design — its module docstring notes "the orchestrator is stdlib-only, so the bundle image's python is enough" — so it needs *none* of the gateway's mitmproxy / gitleaks / git payload. ## Why split - **Least privilege / attack surface.** The control plane concentrates every bottle's secrets (PRD 0070's "secret concentration" risk). Shipping that secret-dense process inside the mitmproxy/git/gitleaks image gives it a large, unrelated dependency surface. A lean orchestrator image (python + the `bot_bottle` package, nothing else) shrinks it. - **Clarity of contract.** `GATEWAY_IMAGE` doubling as the orchestrator's image is confusing — `lifecycle.py` imports a `gateway.py` constant purely to run *non-gateway* code. Two purpose-named images make the roles explicit. - **Build cost / churn.** The orchestrator rebuilds/reboots on any `Dockerfile.sidecars` change even when only gateway daemons moved, and vice-versa. - **Prerequisite for the Firecracker gateway VM (#348 / PRD 0070 Stage B).** Virtualizing the orchestrator needs a bootable *gateway* rootfs distinct from the *orchestrator* runtime; a clean image split is the natural first step. ## Proposed shape - `Dockerfile.gateway` → `bot-bottle-gateway:latest` — current `Dockerfile.sidecars` contents (the data plane). - `Dockerfile.orchestrator` → `bot-bottle-orchestrator:latest` — minimal python base + the `bot_bottle` package; `ENTRYPOINT ["python3", "-m", "bot_bottle.orchestrator"]`. - Retire the `bot-bottle-sidecars:latest` name + `Dockerfile.sidecars`; update `GATEWAY_IMAGE` / `GATEWAY_DOCKERFILE` in `orchestrator/gateway.py`, and give `OrchestratorService` its own `ORCHESTRATOR_IMAGE` / dockerfile instead of borrowing `GATEWAY_IMAGE`. ## Out of scope (note) The legacy **per-bottle** sidecar path still names containers `bot-bottle-sidecars-<slug>` (`backend/docker/sidecar_bundle.py`, `backend/docker/compose.py`, the firecracker/macos `launch.py`, and the enumerate/cleanup prefix constants). This issue is about the **consolidated shared images**; the per-bottle-bundle naming can be reconciled separately and largely disappears as the consolidated path supersedes per-bottle bundles. Prerequisite refactor split out of the PRD 0070 firecracker consolidated-launch work (PR #354).
didericis-claude added the Kind/Enhancement label 2026-07-14 16:12:32 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Low
4
The priority is low
Priority
Medium
3
The priority is medium
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
No Label Kind/Enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
didericis-claude (didericis (claude)) didericis-codex (didericis (codex)) didericis-gemma (gemma) didericis
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: didericis/bot-bottle#384
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?