Dockerfile + node_hub deployment configuration #2

New issue

Closed

opened 2026-06-23 21:20:11 +00:00 by Mark · 0 comments

Mark commented

2026-06-23 21:20:11 +00:00

Owner

Goal

Containerize the FastAPI app from the previous issue and deploy it via the existing node_hub infrastructure. Service should be reachable from ThreadCraft over the tailnet at a stable URL.

Implementation

Dockerfile — extend the existing Mark/easystitch Dockerfile or build a thin one here that FROM mark/easystitch:latest and copies the FastAPI layer. Final image runs uvicorn app:app --host 0.0.0.0 --port 8080. Multi-stage build to keep image size reasonable (the easystitch base is ~1.5GB; the service layer should add <100MB).
Build + push — Dockerfile builds cleanly with docker build -t mark/easystitch-service:latest .. Push to the registry node_hub reads from (local registry on the tailnet, or whatever nodehub.tail018ac4.ts.net is configured for).
node_hub registration — easystitch-service registered as a managed app on node_hub. Required config:
- Port: 8080
- Healthcheck: GET /healthz
- Env vars: LOG_LEVEL=info, MAX_UPLOAD_MB=4, THREAD_PALETTE_PATH=/data/brother_pr10.json
- Replicas: 1 (start single; scale if queue depth exceeds threshold — see observability note below)
Reverse proxy — node_hub's existing /proxy/:instanceId reverse proxy exposes the service. Final URL: http://easystitch-service.tail018ac4.ts.net (or whatever the project's node_hub naming convention produces — verify against existing deployed apps).
CORS at the proxy — node_hub is configured to forward Origin headers. The FastAPI app's CORS middleware handles allow-listing; nothing extra needed here.
Observability — log aggregation via the existing node_hub pattern (likely stdout → whatever). Per-request processingMs already logged in the FastAPI wrapper.

Files to create

Dockerfile — multi-stage build
.dockerignore — exclude .git, tests/, __pycache__, *.pyc, .venv/
node_hub_config.json (or whatever format node_hub expects — check existing apps) — service registration manifest
README.md — deployment instructions, how to update the running service

Acceptance

docker build produces an image that runs locally (docker run -p 8080:8080 mark/easystitch-service).
node_hub launches the service; GET http://easystitch-service.tail018ac4.ts.net/healthz returns 200.
POST http://easystitch-service.tail018ac4.ts.net/v1/digitize with a test PNG returns a valid response.
Restart loop works: kill the container, node_hub restarts it within 30s, healthcheck recovers.

Dependencies

FastAPI wrapper issue must be complete first.
Coordination with Mark/infrastructure may be needed if node_hub needs new config (DNS, registry, etc.).

## Goal Containerize the FastAPI app from the previous issue and deploy it via the existing node_hub infrastructure. Service should be reachable from ThreadCraft over the tailnet at a stable URL. ## Implementation 1. **Dockerfile** — extend the existing `Mark/easystitch` Dockerfile or build a thin one here that `FROM mark/easystitch:latest` and copies the FastAPI layer. Final image runs `uvicorn app:app --host 0.0.0.0 --port 8080`. Multi-stage build to keep image size reasonable (the easystitch base is ~1.5GB; the service layer should add <100MB). 2. **Build + push** — `Dockerfile` builds cleanly with `docker build -t mark/easystitch-service:latest .`. Push to the registry node_hub reads from (local registry on the tailnet, or whatever `nodehub.tail018ac4.ts.net` is configured for). 3. **node_hub registration** — `easystitch-service` registered as a managed app on node_hub. Required config: - Port: 8080 - Healthcheck: `GET /healthz` - Env vars: `LOG_LEVEL=info`, `MAX_UPLOAD_MB=4`, `THREAD_PALETTE_PATH=/data/brother_pr10.json` - Replicas: 1 (start single; scale if queue depth exceeds threshold — see observability note below) 4. **Reverse proxy** — node_hub's existing `/proxy/:instanceId` reverse proxy exposes the service. Final URL: `http://easystitch-service.tail018ac4.ts.net` (or whatever the project's node_hub naming convention produces — verify against existing deployed apps). 5. **CORS at the proxy** — node_hub is configured to forward Origin headers. The FastAPI app's CORS middleware handles allow-listing; nothing extra needed here. 6. **Observability** — log aggregation via the existing node_hub pattern (likely stdout → whatever). Per-request `processingMs` already logged in the FastAPI wrapper. ## Files to create - `Dockerfile` — multi-stage build - `.dockerignore` — exclude `.git`, `tests/`, `__pycache__`, `*.pyc`, `.venv/` - `node_hub_config.json` (or whatever format node_hub expects — check existing apps) — service registration manifest - `README.md` — deployment instructions, how to update the running service ## Acceptance - `docker build` produces an image that runs locally (`docker run -p 8080:8080 mark/easystitch-service`). - node_hub launches the service; `GET http://easystitch-service.tail018ac4.ts.net/healthz` returns 200. - `POST http://easystitch-service.tail018ac4.ts.net/v1/digitize` with a test PNG returns a valid response. - Restart loop works: kill the container, node_hub restarts it within 30s, healthcheck recovers. ## Dependencies - FastAPI wrapper issue must be complete first. - Coordination with `Mark/infrastructure` may be needed if node_hub needs new config (DNS, registry, etc.).