`db_data` was a volume and the instance directory was not, so the documented update path - `docker compose build api && up -d api` - recreated the container and discarded everything the site had written. `plugins.json` is only the loud part: maps, branding, model and application images, employee photos, warranty proofs, slides, printed-part files and the Dell OAuth token all live under instance_path too. MySQL rows survive and point at files that are gone, so the second symptom is images 404ing rather than an error anybody sees. Reported by an adopting site, which read it as having updated too fast. It had not; nothing it could have done differently would have kept those files. DEPLOY.md had been telling sites to back up `instance/` since it was written. The template never gave them anything to back up. The air-gap `migrate` service mounts the volume too, because `flask plugin upgrade-all` rewrites plugins.json and that service exits immediately after. The image now creates instance/ ITSELF, owned by the app user. Docker seeds an empty named volume from image content at the mountpoint, ownership included; with no such directory in the image the mountpoint is created root-owned 0755 and the container, which runs as shopdb, cannot write into its own instance directory. Caught by running the built image rather than by reading it: the volume mounted clean and `touch` came back Permission denied. Verified fixed the same way. A stack that predates the volume needs its files moved across ONCE, while the old container still exists - the volume is seeded from image content, and the image ships instance/ empty, so it comes up empty rather than inheriting the old container's writable layer. DEPLOY.md carries the procedure, including the chown after `docker compose cp`, which writes files under the copying user's numeric uid rather than the app user's. Also here, found while checking what an upgrade actually runs: the connected update steps ran `flask db upgrade` and stopped. Per-plugin Alembic chains (ADR-008) are not part of that, so a connected site taking an image with a bumped plugin migration ran the core chain and silently skipped every plugin chain. The air-gap stack had it right all along. Both commands are in Step 9 now, plus a `db current` check against `db heads`.
75 lines
2.9 KiB
YAML
75 lines
2.9 KiB
YAML
# shopdb-flask single-site docker-compose template.
|
|
#
|
|
# Per ADR-004, each adopting facility runs its own stack. This template
|
|
# brings up MySQL + the API container and exposes the API on port 5001.
|
|
# The Vue frontend is served separately by the API in production builds
|
|
# (see register_frontend_routes in shopdb/__init__.py); for dev, run
|
|
# `npm run dev` in frontend/ on a separate port.
|
|
#
|
|
# Usage:
|
|
# cp .env.example .env
|
|
# # edit .env with site-specific secrets and origins
|
|
# docker compose up -d
|
|
#
|
|
# Refresh after pulling new code:
|
|
# docker compose build api
|
|
# docker compose up -d api
|
|
|
|
services:
|
|
db:
|
|
image: mysql:8.0
|
|
# utf8mb4 server-wide so the auto-created MYSQL_DATABASE is utf8mb4, not the
|
|
# image default. Keeps every site's schema on the same charset/collation.
|
|
command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
|
|
restart: unless-stopped
|
|
environment:
|
|
MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD:?MYSQL_ROOT_PASSWORD must be set}
|
|
MYSQL_DATABASE: shopdb_flask
|
|
MYSQL_USER: shopdb
|
|
MYSQL_PASSWORD: ${MYSQL_PASSWORD:?MYSQL_PASSWORD must be set}
|
|
volumes:
|
|
- db_data:/var/lib/mysql
|
|
# Bind MySQL to loopback only. The api container reaches db over the
|
|
# compose network regardless of this mapping; the published port is just
|
|
# for local admin tools (mysqldump, a client on the host). Exposing 3306
|
|
# on all interfaces would put the database on the facility network.
|
|
ports:
|
|
- "127.0.0.1:${MYSQL_PORT:-3306}:3306"
|
|
healthcheck:
|
|
test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "-p${MYSQL_ROOT_PASSWORD}"]
|
|
interval: 10s
|
|
timeout: 5s
|
|
retries: 5
|
|
|
|
api:
|
|
build: .
|
|
restart: unless-stopped
|
|
depends_on:
|
|
db:
|
|
condition: service_healthy
|
|
environment:
|
|
FLASK_ENV: production
|
|
DATABASE_URL: mysql+pymysql://shopdb:${MYSQL_PASSWORD}@db:3306/shopdb_flask?charset=utf8mb4
|
|
SECRET_KEY: ${SECRET_KEY:?SECRET_KEY must be set}
|
|
JWT_SECRET_KEY: ${JWT_SECRET_KEY:?JWT_SECRET_KEY must be set}
|
|
CORS_ORIGINS: ${CORS_ORIGINS:?CORS_ORIGINS must be set}
|
|
LOG_LEVEL: ${LOG_LEVEL:-INFO}
|
|
ZABBIX_URL: ${ZABBIX_URL:-}
|
|
ZABBIX_TOKEN: ${ZABBIX_TOKEN:-}
|
|
ports:
|
|
- "${API_PORT:-5001}:5001"
|
|
volumes:
|
|
- ./plugins:/app/plugins:ro
|
|
# /app/instance is WRITTEN state, not code: plugins.json (which plugins
|
|
# this site has enabled), uploaded floor plans, branding, model and
|
|
# application images, employee photos, warranty proofs, slides,
|
|
# printed-part files, and the Dell OAuth token. Without this volume a
|
|
# `docker compose build api && up -d api` recreates the container and
|
|
# takes all of it with it, so the site comes back with its plugins
|
|
# disabled and MySQL rows pointing at files that no longer exist.
|
|
- instance_data:/app/instance
|
|
|
|
volumes:
|
|
db_data:
|
|
instance_data:
|