Cheng Zhou
28 lines
1.8 KiB
Markdown
28 lines
1.8 KiB
Markdown
# Production Compose Design
|
|
|
|
**Goal:** Convert the current single-host `docker-compose` deployment from a development-oriented stack into a production-oriented stack while keeping the existing `docker-compose.yaml` as the only deployment entrypoint.
|
|
|
|
**Decisions**
|
|
- Keep single-host `docker-compose` deployment.
|
|
- Convert the frontend to a static build served directly by Nginx.
|
|
- Keep PostgreSQL and the existing `pg_data` persistence model.
|
|
- Keep one backend container and remove development-only runtime behavior.
|
|
- Update the existing `docker-compose.yaml` in place instead of introducing a separate production file.
|
|
|
|
**Architecture**
|
|
- `db` remains a long-lived PostgreSQL service with the existing bind-mounted data directory.
|
|
- `backend` runs from the backend image default command and exposes only the application port needed inside the compose network.
|
|
- `nginx` becomes the public entrypoint. It serves the built frontend assets and proxies `/api/` and `/health` to the backend service.
|
|
- The frontend is no longer a long-running service in production. Its build artifacts are produced during the image build and copied into the Nginx image.
|
|
|
|
**Cleanup Scope**
|
|
- Remove development-only compose services such as toolbox/init containers.
|
|
- Remove development-only backend startup overrides such as `debugpy` and `uvicorn --reload`.
|
|
- Remove development-only frontend runtime behavior such as `npm run dev`, bind mounts, and exposed Vite ports.
|
|
- Keep data persistence and core service names stable where practical to limit operational change.
|
|
|
|
**Operational Notes**
|
|
- Updating `docker-compose.yaml` in place means local development will no longer use the previous hot-reload setup by default.
|
|
- Frontend SPA routing must be handled by Nginx with `try_files`.
|
|
- Verification is done through `docker compose config`, image builds, container startup, and HTTP health checks.
|