37 lines
1.2 KiB
Markdown
37 lines
1.2 KiB
Markdown
# FR24 ingest compose skeleton
|
|
|
|
## Goals
|
|
- PostgreSQL + PostGIS as the single database
|
|
- separate ingest placeholder service
|
|
- healthcheck/status scaffolding
|
|
- predictable volume layout
|
|
- environment-driven configuration
|
|
|
|
## Proposed runtime layout
|
|
- `compose/` — Docker Compose manifests and env examples
|
|
- `db/postgres/` — persistent PostgreSQL data
|
|
- `db/init/` — bootstrap SQL for extensions and initial schema
|
|
- `ingest/` — capture/preprocess implementation lives here later
|
|
- `logs/ingest/` — service logs
|
|
- `logs/status/` — heartbeat/status artifacts
|
|
- `backup/` — pg_dump and restore artifacts
|
|
|
|
## Environment variables
|
|
- `POSTGRES_DB`
|
|
- `POSTGRES_USER`
|
|
- `POSTGRES_PASSWORD`
|
|
- `POSTGRES_PUBLISHED_PORT`
|
|
- `RAW_RETENTION_DAYS`
|
|
- `OVERLAP_MINUTES`
|
|
- `CAPTURE_SOURCE`
|
|
- `TZ`
|
|
- `APP_ENV`
|
|
|
|
## Status scaffolding
|
|
The current skeleton includes a minimal `status` container that writes a heartbeat file. This is only a placeholder and should be replaced or extended by a real monitoring endpoint later.
|
|
|
|
## Open questions
|
|
- whether capture and preprocess should become separate services immediately
|
|
- whether API/viewer belongs in the first compose cut or later
|
|
- whether a dedicated monitoring container is needed before hardware verification
|