Sidecar container support: deploy a second container per app with ingress (traefik) labels on the sidecar #206

New Issue

2026-09-22T15:47:22+02:00

clawbot commented

2026-09-22 15:47:22 +02:00

Split from #205.

Problem

A deploy today produces exactly one long-lived container per app, and every
label the app defines — including any traefik.* routing labels — is hardcoded
onto that one container. There is no way to place a second container beside the
app and move the ingress labels onto it, which is what the smallwebwaf sidecar
WAF requires (proxy in front carrying the traefik labels, app off the ingress
network). Current code:

One container per deploy: internal/service/deploy/deploy.go:565
(deployContainerWithTimeout) removes the single old container
(removeOldContainer, deploy.go:1034) then calls createAndStartContainer
(deploy.go:1061) once, which calls CreateContainer + StartContainer a
single time. Container name is "upaas-" + app.Name (deploy.go:1156).
One label set on that one container: buildContainerOptions
(deploy.go:1108) / buildLabelMap (deploy.go:1168) attach all app labels
plus upaas.id to the sole container; CreateContainer sets them at
internal/docker/client.go:258.
Single-container assumption in lookup/replace: FindContainerByAppID returns
containers[0] (client.go:431).

Minimal feature

Allow an app to optionally declare one extra "sidecar" container and control
which container receives the ingress labels. High level:

Data model (internal/models/app.go plus a new child table, mirroring the
existing env/label/volume/port tables): store an optional sidecar spec (image
reference, its own env/ports, internal network name) and a marker for which
labels are "ingress" labels that belong on the front container.
Deploy orchestration (deploy.go:565 deployContainerWithTimeout,
deploy.go:1061 createAndStartContainer): create/start the set of
containers (app + sidecar) instead of one; put the app on an internal-only
network and the sidecar on both the ingress network and the internal network
so it can forward to the app (app already has a single docker_network,
app.go:48).
Label routing (deploy.go:1108 / :1168): send the ingress/traefik labels
to the sidecar and keep upaas.id on every container in the set.
Multi-container lifecycle (client.go:431 FindContainerByAppID,
deploy.go:1034 removeOldContainer): find and remove all containers for an
app id (they already share the upaas.id label; add a role label to
disambiguate) rather than assuming exactly one.

Note this crosses the current README "Non-Goals: Multiple container
orchestration"; treat that line as an owner decision to reconcile.

Definition of done

An app can be configured to deploy with a sidecar container, and the app's
ingress (traefik) labels are applied to the sidecar, not the app container.
On redeploy and rollback, the whole container set for the app is replaced
cleanly.
Docs updated to describe the sidecar option and reconcile the Non-Goals line.

Model: opus-4-8

Split from https://git.eeqj.de/sneak/upaas/issues/205. ## Problem A deploy today produces exactly one long-lived container per app, and every label the app defines — including any `traefik.*` routing labels — is hardcoded onto that one container. There is no way to place a second container beside the app and move the ingress labels onto it, which is what the smallwebwaf sidecar WAF requires (proxy in front carrying the traefik labels, app off the ingress network). Current code: - One container per deploy: `internal/service/deploy/deploy.go:565` (`deployContainerWithTimeout`) removes the single old container (`removeOldContainer`, `deploy.go:1034`) then calls `createAndStartContainer` (`deploy.go:1061`) once, which calls `CreateContainer` + `StartContainer` a single time. Container name is `"upaas-" + app.Name` (`deploy.go:1156`). - One label set on that one container: `buildContainerOptions` (`deploy.go:1108`) / `buildLabelMap` (`deploy.go:1168`) attach all app labels plus `upaas.id` to the sole container; `CreateContainer` sets them at `internal/docker/client.go:258`. - Single-container assumption in lookup/replace: `FindContainerByAppID` returns `containers[0]` (`client.go:431`). ## Minimal feature Allow an app to optionally declare one extra "sidecar" container and control which container receives the ingress labels. High level: 1. Data model (`internal/models/app.go` plus a new child table, mirroring the existing env/label/volume/port tables): store an optional sidecar spec (image reference, its own env/ports, internal network name) and a marker for which labels are "ingress" labels that belong on the front container. 2. Deploy orchestration (`deploy.go:565` `deployContainerWithTimeout`, `deploy.go:1061` `createAndStartContainer`): create/start the set of containers (app + sidecar) instead of one; put the app on an internal-only network and the sidecar on both the ingress network and the internal network so it can forward to the app (app already has a single `docker_network`, `app.go:48`). 3. Label routing (`deploy.go:1108` / `:1168`): send the ingress/traefik labels to the sidecar and keep `upaas.id` on every container in the set. 4. Multi-container lifecycle (`client.go:431` `FindContainerByAppID`, `deploy.go:1034` `removeOldContainer`): find and remove all containers for an app id (they already share the `upaas.id` label; add a role label to disambiguate) rather than assuming exactly one. Note this crosses the current README "Non-Goals: Multiple container orchestration"; treat that line as an owner decision to reconcile. ## Definition of done - An app can be configured to deploy with a sidecar container, and the app's ingress (traefik) labels are applied to the sidecar, not the app container. - On redeploy and rollback, the whole container set for the app is replaced cleanly. - Docs updated to describe the sidecar option and reconcile the Non-Goals line. Model: opus-4-8

clawbot referenced this issue

2026-09-22 15:47:41 +02:00

Determine whether upaas can deploy a second container beside an app with the traefik labels moved onto it #205

clawbot referenced this issue from sneak/smallwebwaf

2026-09-22 15:56:17 +02:00

SPEC update: fold the seven resolutions, issues 2 to 5 and the internet-ready directive (issue 7) into SPEC.md #6

sneak commented

2026-09-22 16:04:14 +02:00

let's not put this functionality into upaas. we can simply decline to put the traefik labels on the upaas-deployed app and docker-compose can put them onto the sidecar, and the sidecar can point at the app's hostname. upaas doesn't need to know about the sidecar.

clawbot commented

2026-09-22 16:11:35 +02:00

Ruling (sneak, 2026-09-22, above): feature REJECTED — upaas stays single-container and never learns about sidecars. The deployment shape instead: the app is deployed by upaas with no traefik labels configured; the sidecar runs beside it under docker-compose, carries the traefik labels, and points at the app's hostname. No upaas change is needed for that shape. Closing as declined; consequence recorded for smallwebwaf on sneak/smallwebwaf#6. (model: claude-fable-5)

Ruling (sneak, 2026-09-22, above): feature REJECTED — upaas stays single-container and never learns about sidecars. The deployment shape instead: the app is deployed by upaas with no traefik labels configured; the sidecar runs beside it under docker-compose, carries the traefik labels, and points at the app's hostname. No upaas change is needed for that shape. Closing as declined; consequence recorded for smallwebwaf on https://git.eeqj.de/sneak/smallwebwaf/issues/6. (model: claude-fable-5)

clawbot referenced this issue from sneak/smallwebwaf

2026-09-22 16:11:37 +02:00

SPEC update: fold the seven resolutions, issues 2 to 5 and the internet-ready directive (issue 7) into SPEC.md #6

clawbot closed this issue

2026-09-22 16:11:40 +02:00

clawbot referenced this issue from sneak/smallwebwaf

2026-09-24 12:09:15 +02:00

Deploy model: apps build FROM the smallwebwaf image, with smallwebwaf on :8080 in front of the app on 127.0.0.1:8081 #12

Sign in to join this conversation.