Bring the API and WebUI into Docker Compose behind a full-stack profile #122
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/compose-full-stack"
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?
Task 109.
docker compose upalone is unchanged — still Postgres only.docker compose --profile full up -d --build --waitaddsapiandwebui, built from task 108's own Dockerfiles.The trap:
Api__BaseAddressis fetched by the browser, not resolved inside the Compose network, so it's set to the API's own published host port (http://localhost:8081by default) — nothttp://api:8080, which only resolves between containers and would fail in the browser with a network error. The API's ownConnectionStrings__PlaceMarkcorrectly does use the Docker-network hostname (Host=postgres), since that connection is server-side.CORS:
Cors__AllowedOrigins__0is computed from the sameWEBUI_PORTthe WebUI is published on, so overriding one can't silently leave the other behind.ADR-0106.
Verified by running, not by
docker compose configvalidating: built and brought up an isolated instance, provisioned roles and applied the schema against it, then drove a real headless browser throughhttp://localhost:8080— registered an account, signed in, reached the authenticated map — end to end through the actual Compose-published origin. Confirmed separately that plaindocker compose up(no profile) still starts only Postgres.Environment variables documented in
.env.exampleand the README's new "Full local stack" section:API_PORT/WEBUI_PORT,PLACEMARK_APP_ROLE_PASSWORD(shared with the existing provisioning step), andJwt__SigningKey/Oidc__*(defaulted to the same published throwawaysuser-secrets.example.jsonalready documents).Full suite, architecture tests, coverage ratchet and
dotnet formatall clean on the pinned SDK.Out of scope, per the ticket: registry push, hosting, TLS, CD.
Verdict: mergeable
Verified by running, not just reading:
docker compose -p pr122review), custom.envwith non-defaultAPI_PORT=18081/WEBUI_PORT=18080.curl http://127.0.0.1:18080/appsettings.jsonon the running WebUI container returned"Api":{"BaseAddress":"http://localhost:18081"}— the published host port, neverhttp://api:8080. Registered a real account throughhttp://127.0.0.1:18081/api/auth/registerwithOrigin: http://localhost:18080(the overridden WEBUI_PORT) — 201, withAccess-Control-Allow-Origin: http://localhost:18080echoed back; the same request withOrigin: http://localhost:9999got no ACAO header. Both claims hold under an override, not just at the defaults.docker compose config(no profile) lists onlypostgres; brought the stack up with no profile and only Postgres started. Then--profile full up -d --waitbrought up all three healthy,api/webuiboth running as non-root (uid=1654(app)/uid=101(nginx)fromdocker exec ... id).Jwt__SigningKey/Oidc__*throwaway defaults indocker-compose.ymlare byte-for-byte the same values already published inuser-secrets.example.json— no new secret-shaped value introduced.docker-compose.yml(API_PORT,WEBUI_PORT,PLACEMARK_APP_ROLE_PASSWORD,Jwt__SigningKey,Oidc__Authority/ClientId/ClientSecret) is documented in.env.example;Oidc__RedirectUri/WebUiRedirectUriare deliberately not listed as independently overridable, consistent with them being computed from the two ports.1c8e176; head unchanged from the SHA given.Nothing else to flag.