Closes #121. The Quick Deploy file was missing NETFLOW_BIND_PORT and the 2055/udp mapping, so the collector bound inside the container and nothing reached it. NetFlow did nothing, silently, with an empty traffic page and no error — for everyone following the path the README tells new users to take. The report was accurate and understated. docker-compose.ghcr.yml had drifted for seven weeks, and three closed issues had never reached it: * NETFLOW_BIND_PORT and the UDP port — as reported * all five POLLER_* tunables — #114, whose fix was "pass the tunables through" * the Redis memory ceiling and eviction policy — #116 * TZ on the postgres service, which nobody had noticed at all The middle one is the uncomfortable part. Four days ago #114 was closed by forwarding poller settings that were documented but inert, with a comment saying setting them "did precisely nothing". On Quick Deploy that remained true, because one compose file was fixed and the other was not — including the advice given to that reporter about which knob to turn. So patching the four gaps would have been treating the symptom. The two files describe the same system and differ only in where images come from; maintaining both by hand meant remembering every change twice, and the one forgotten was always the file no maintainer runs. docker-compose.ghcr.yml is now generated from docker-compose.yml by scripts/generate-ghcr-compose.mjs, which performs the two build-to-image swaps and nothing else. Substitution is textual rather than parse-and-reserialise so comments survive — the reasoning about Redis eviction is worth more than the two lines it explains. The file stays committed and browsable, because the README tells people to curl it directly. A --check mode runs as the first preflight gate and as its own CI job, both of which fail when the committed file does not match what the generator produces. Verified by deleting the NetFlow line and watching the guard reject it, with the reason and the fix in the failure message. Reported by @mamb1329, on their first issue. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
160 lines
5.5 KiB
YAML
160 lines
5.5 KiB
YAML
version: '3.8'
|
|
|
|
# ─────────────────────────────────────────────────────────────────────────────
|
|
# GENERATED FILE — DO NOT EDIT.
|
|
#
|
|
# Produced from docker-compose.yml by scripts/generate-ghcr-compose.mjs.
|
|
# Edit that file and run `npm run compose:generate`; CI fails if this one is
|
|
# out of date.
|
|
#
|
|
# Pre-built image deployment — no source code or build toolchain required.
|
|
# For development or building from source, use docker-compose.yml instead.
|
|
# ─────────────────────────────────────────────────────────────────────────────
|
|
|
|
services:
|
|
nginx:
|
|
image: ghcr.io/2gt-media-group-llc/mikrotik-manager-nginx:latest
|
|
ports:
|
|
- "${HTTP_PORT:-80}:80"
|
|
- "${HTTPS_PORT:-443}:443"
|
|
volumes:
|
|
- certs_data:/certs
|
|
depends_on:
|
|
backend:
|
|
condition: service_healthy
|
|
restart: unless-stopped
|
|
networks:
|
|
- app-network
|
|
|
|
backend:
|
|
image: ghcr.io/2gt-media-group-llc/mikrotik-manager-backend:latest
|
|
environment:
|
|
NODE_ENV: production
|
|
TZ: ${TZ:-UTC}
|
|
DATABASE_URL: postgresql://mikrotik:${DB_PASSWORD:-mikrotik_secure_pw}@postgres:5432/mikrotik_manager
|
|
REDIS_URL: redis://redis:6379
|
|
INFLUXDB_URL: http://influxdb:8086
|
|
INFLUXDB_TOKEN: ${INFLUXDB_TOKEN:-mytoken123456789}
|
|
INFLUXDB_ORG: ${INFLUXDB_ORG:-mikrotik-manager}
|
|
INFLUXDB_BUCKET: ${INFLUXDB_BUCKET:-metrics}
|
|
# Leave unset to auto-generate & persist strong secrets on first boot
|
|
# (stored in the app_data volume). Set them to pin your own values.
|
|
JWT_SECRET: ${JWT_SECRET:-}
|
|
ENCRYPTION_KEY: ${ENCRYPTION_KEY:-}
|
|
CORS_ORIGIN: ${CORS_ORIGIN:-https://localhost,http://localhost,https://127.0.0.1,http://127.0.0.1}
|
|
PORT: 3001
|
|
NETFLOW_BIND_PORT: 2055
|
|
# Poller tuning. These were documented in .env.example but never passed
|
|
# through, so setting them had no effect on the container at all.
|
|
POLLER_CONCURRENCY: ${POLLER_CONCURRENCY:-12}
|
|
POLLER_JOB_TIMEOUT_MS: ${POLLER_JOB_TIMEOUT_MS:-45000}
|
|
POLLER_INTERVAL_MS: ${POLLER_INTERVAL_MS:-30000}
|
|
POLLER_JOB_RETENTION_SEC: ${POLLER_JOB_RETENTION_SEC:-3600}
|
|
POLLER_JOB_RETENTION_COUNT: ${POLLER_JOB_RETENTION_COUNT:-5000}
|
|
ports:
|
|
# NetFlow/IPFIX collector — UDP goes straight to the backend (nginx not involved).
|
|
# Host port must match the netflow_collector_port app setting (default 2055).
|
|
- "${NETFLOW_PORT:-2055}:2055/udp"
|
|
depends_on:
|
|
postgres:
|
|
condition: service_healthy
|
|
redis:
|
|
condition: service_healthy
|
|
influxdb:
|
|
condition: service_healthy
|
|
volumes:
|
|
- backups_data:/app/backups
|
|
- certs_data:/certs
|
|
- app_data:/app/data
|
|
cap_add:
|
|
- NET_RAW
|
|
restart: unless-stopped
|
|
networks:
|
|
- app-network
|
|
healthcheck:
|
|
test: ["CMD", "wget", "-qO-", "http://127.0.0.1:3001/api/health"]
|
|
interval: 15s
|
|
timeout: 10s
|
|
retries: 5
|
|
start_period: 30s
|
|
|
|
postgres:
|
|
image: postgres:15-alpine
|
|
environment:
|
|
TZ: ${TZ:-UTC}
|
|
POSTGRES_DB: mikrotik_manager
|
|
POSTGRES_USER: mikrotik
|
|
POSTGRES_PASSWORD: ${DB_PASSWORD:-mikrotik_secure_pw}
|
|
volumes:
|
|
- postgres_data:/var/lib/postgresql/data
|
|
restart: unless-stopped
|
|
networks:
|
|
- app-network
|
|
healthcheck:
|
|
test: ["CMD-SHELL", "pg_isready -U mikrotik -d mikrotik_manager"]
|
|
interval: 10s
|
|
timeout: 5s
|
|
retries: 5
|
|
start_period: 10s
|
|
|
|
redis:
|
|
image: redis:7-alpine
|
|
# A memory ceiling so a runaway producer can never take the host down, with
|
|
# eviction disabled.
|
|
#
|
|
# volatile-lru looks tempting — it would evict only keys with an expiry, and
|
|
# BullMQ's job hashes have none. But its *control* keys do: job locks and
|
|
# per-queue stalled-check markers both carry TTLs, and losing one causes
|
|
# duplicate processing or a stalled-job storm. BullMQ warns about this on
|
|
# connect, and it is right. noeviction means Redis refuses writes when full
|
|
# rather than quietly corrupting queue state: the host stays up, and the
|
|
# failure is loud. Retention limits and the stale-pending sweep are what keep
|
|
# us away from the ceiling in the first place.
|
|
command: >
|
|
redis-server --appendonly yes
|
|
--maxmemory ${REDIS_MAXMEMORY:-512mb}
|
|
--maxmemory-policy noeviction
|
|
volumes:
|
|
- redis_data:/data
|
|
restart: unless-stopped
|
|
networks:
|
|
- app-network
|
|
healthcheck:
|
|
test: ["CMD", "redis-cli", "ping"]
|
|
interval: 10s
|
|
timeout: 5s
|
|
retries: 5
|
|
|
|
influxdb:
|
|
image: influxdb:2.7
|
|
environment:
|
|
DOCKER_INFLUXDB_INIT_MODE: setup
|
|
DOCKER_INFLUXDB_INIT_USERNAME: admin
|
|
DOCKER_INFLUXDB_INIT_PASSWORD: ${INFLUXDB_ADMIN_PASSWORD:-admin_password_123}
|
|
DOCKER_INFLUXDB_INIT_ORG: ${INFLUXDB_ORG:-mikrotik-manager}
|
|
DOCKER_INFLUXDB_INIT_BUCKET: ${INFLUXDB_BUCKET:-metrics}
|
|
DOCKER_INFLUXDB_INIT_ADMIN_TOKEN: ${INFLUXDB_TOKEN:-mytoken123456789}
|
|
volumes:
|
|
- influxdb_data:/var/lib/influxdb2
|
|
restart: unless-stopped
|
|
networks:
|
|
- app-network
|
|
healthcheck:
|
|
test: ["CMD", "influx", "ping"]
|
|
interval: 15s
|
|
timeout: 10s
|
|
retries: 10
|
|
start_period: 30s
|
|
|
|
volumes:
|
|
postgres_data:
|
|
redis_data:
|
|
influxdb_data:
|
|
backups_data:
|
|
certs_data:
|
|
app_data:
|
|
|
|
networks:
|
|
app-network:
|
|
driver: bridge
|