dodox
69ecc7fc67
The reasoning for --workers 1 was already there; adding an upfront note that this app doesn't support multi-process/multi-replica deployment as-is, since Login Flow v2's in-flight state is in-process memory - not just a gunicorn flag choice, a structural constraint until that state moves somewhere shared.
38 lines
1.5 KiB
Docker
38 lines
1.5 KiB
Docker
FROM python:3.12-slim
|
|
|
|
WORKDIR /app
|
|
|
|
# Pillow needs these to build/run; python:3.12-slim's manylinux wheels cover
|
|
# most of it, but libjpeg/zlib runtime libs are still needed at import time.
|
|
RUN apt-get update && apt-get install -y --no-install-recommends \
|
|
libjpeg62-turbo \
|
|
zlib1g \
|
|
&& rm -rf /var/lib/apt/lists/*
|
|
|
|
COPY requirements.txt .
|
|
RUN pip install --no-cache-dir -r requirements.txt
|
|
|
|
COPY . .
|
|
|
|
RUN mkdir -p instance uploads
|
|
|
|
EXPOSE 5000
|
|
|
|
# instance/ (sqlite db) and uploads/ (receipt photos) should be mounted as
|
|
# volumes - see docker-compose.yml - so they survive a container rebuild.
|
|
#
|
|
# NOTE: this app does not support running as multiple processes. Login Flow
|
|
# v2's in-flight state (app/auth.py _pending_flows) is a plain in-memory
|
|
# dict, not shared across processes/machines - it only works because every
|
|
# request within a login attempt is guaranteed to hit the same process.
|
|
# Scaling this out (more gunicorn workers, multiple replicas, etc.) would
|
|
# need that state moved to somewhere shared (the sqlite db, redis, ...)
|
|
# first.
|
|
#
|
|
# --workers 1: with >1 worker, /auth/login/start and the follow-up
|
|
# /auth/login/poll calls can land on different worker processes, which
|
|
# never see each other's flow_id, so login intermittently/always times out.
|
|
# Single worker (+ threads for concurrency) keeps that state actually
|
|
# shared. Fine for this scale (household tool, already SQLite-backed).
|
|
CMD ["gunicorn", "--bind", "0.0.0.0:5000", "--workers", "1", "--threads", "4", "--timeout", "60", "run:app"]
|