Dockerfile + deployment config #88

New issue

Closed

opened 2026-06-26 20:00:18 +00:00 by Mark · 0 comments

Mark commented

2026-06-26 20:00:18 +00:00

Owner

Phase 1: Dockerfile + deployment config

Production-ready container build and node_hub deployment manifest.

Files:

Modify: Dockerfile (add CMD for uvicorn, ensure deps are
installed in runtime stage, pin base image tag)
New: node-hub.app.yml (or whatever format node_hub expects) for
deploying easyStitch as a managed service
New: docker-compose.yml for local dev (optional, but useful for
testing the full service)
New: docs/deployment.md covering Docker, node_hub, env vars

Acceptance:

docker build -t easystitch-service . && docker run -p 8080:8080 easystitch-service starts a working service.
node-hub.app.yml registers the service, sets CORS_ALLOWED_ORIGINS
correctly, and node_hub health-checks it successfully.
docs/deployment.md covers: building, running, env vars, common
errors.
Image size is reasonable (< 2 GB; the current python:3.11-slim
base + scipy + scikit-image is ~1.5 GB; that's fine).

Depends on: P1 (skeleton) so the Dockerfile has something to run.
P2/P3/P4 not required — the image with only P1 is shippable, and the
endpoints come online as those phases land.

Cross-cutting concerns (handled across all phases, not in one phase)

CORS is configured in P1; later phases don't need to think about it.
Concurrency (queue depth, timeouts) is documented per #43; the
service implementation honors those values across all endpoints.
Logging uses structured JSON in production (LOG_LEVEL=info by
default; per-request UUID for correlation).
Error responses follow a consistent shape: {"error": "...", "stage": "...", "request_id": "..."} across all endpoints.

Decomposed from easystitch#31

Decomposed from easystitch#50

## Phase 1: Dockerfile + deployment config Production-ready container build and node_hub deployment manifest. **Files:** - Modify: `Dockerfile` (add `CMD` for uvicorn, ensure deps are installed in runtime stage, pin base image tag) - New: `node-hub.app.yml` (or whatever format node_hub expects) for deploying easyStitch as a managed service - New: `docker-compose.yml` for local dev (optional, but useful for testing the full service) - New: `docs/deployment.md` covering Docker, node_hub, env vars **Acceptance:** - `docker build -t easystitch-service . && docker run -p 8080:8080 easystitch-service` starts a working service. - `node-hub.app.yml` registers the service, sets `CORS_ALLOWED_ORIGINS` correctly, and `node_hub` health-checks it successfully. - `docs/deployment.md` covers: building, running, env vars, common errors. - Image size is reasonable (< 2 GB; the current `python:3.11-slim` base + scipy + scikit-image is ~1.5 GB; that's fine). **Depends on:** P1 (skeleton) so the Dockerfile has something to run. P2/P3/P4 not required — the image with only P1 is shippable, and the endpoints come online as those phases land. ## Cross-cutting concerns (handled across all phases, not in one phase) - **CORS** is configured in P1; later phases don't need to think about it. - **Concurrency** (queue depth, timeouts) is documented per #43; the service implementation honors those values across all endpoints. - **Logging** uses structured JSON in production (`LOG_LEVEL=info` by default; per-request UUID for correlation). - **Error responses** follow a consistent shape: `{"error": "...", "stage": "...", "request_id": "..."}` across all endpoints. --- _Decomposed from [easystitch#31](https://forgejo.tail018ac4.ts.net/Mark/easystitch/issues/31)_ --- _Decomposed from [easystitch#50](https://forgejo.tail018ac4.ts.net/Mark/easystitch/issues/50)_