docker-compose.infrastructure.yml

x-logging: &default-logging
  driver: "local"
  options:
    max-size: "${LOG_MAX_SIZE:-150m}"
    max-file: "${LOG_MAX_FILE:-5}"

services:

  webserver:
    image: nginx:1.30.2
    restart: always
    logging: *default-logging
    env_file: ${BPP_CONFIGS_DIR}/.env
    environment:
      NGINX_ENVSUBST_FILTER: "DJANGO_BPP_"
    ports:
      - 80:80
      - 443:443
      - 443:443/udp    # HTTP/3 (QUIC)
    healthcheck:
      test: ["CMD-SHELL", "curl -f -s -o /dev/null http://127.0.0.1:80/healthz || exit 1"]
      start_period: 10s
      interval: 10s
      timeout: 5s
      retries: 3
    volumes:
      - staticfiles:/var/www/html/staticroot
      - media:/mediaroot
      - ${BPP_CONFIGS_DIR}/ssl:/etc/ssl/private:ro
      # Let's Encrypt: certyfikaty zarzadzane przez kontener certbot (bind do
      # $BPP_CONFIGS_DIR/letsencrypt). Mountowane RW - nginx czyta certy oraz
      # usuwa sentinel .reload-needed po wykonaniu reload-a. Cert-files nie sa
      # nigdy modyfikowane przez nginx, tylko sentinel. Niezaleznie od
      # DJANGO_BPP_SSL_MODE - katalog moze byc pusty w trybie manual
      # (skrypt 30-render-bpp-vhosts.sh wybiera wlasciwa sciezke).
      - ${BPP_CONFIGS_DIR}/letsencrypt:/etc/letsencrypt
      # Webroot dla HTTP-01 challenge. Wspoldzielony z kontenerem certbot
      # (RW dla certbota, RO tutaj). Pusty katalog w trybie manual = 404
      # dla zapytan ACME, co jest ok bo i tak nikt prawdziwy tam nie chodzi.
      - acme-challenge:/var/www/certbot:ro
      - ./defaults/webserver/default.conf.template:/etc/nginx/templates/default.conf.template:ro
      # log_format bpp_access (kontekst http) — laduje sie pierwszy (prefix 00-)
      # przed default.conf/vhost-*.conf, ktore go uzywaja.
      - ./defaults/webserver/00-log-format.conf:/etc/nginx/conf.d/00-log-format.conf:ro
      - ./defaults/webserver/security-headers.conf:/etc/nginx/conf.d/security-headers.conf:ro
      - ./defaults/webserver/_bpp-locations.conf:/etc/nginx/bpp-templates/_bpp-locations.conf:ro
      - ./defaults/webserver/vhost.conf.template:/etc/nginx/bpp-templates/vhost.conf.template:ro
      - ./defaults/webserver/30-render-bpp-vhosts.sh:/docker-entrypoint.d/30-render-bpp-vhosts.sh:ro
      # Let's Encrypt reload helper. NIE w /docker-entrypoint.d/ (uruchomilby
      # sie przy starcie kontenera) - tylko jako exec na zadanie z Ofelia.
      - ./scripts/letsencrypt-reload.sh:/usr/local/bin/letsencrypt-reload.sh:ro
      # Rotacja access logu czytanego przez netdata web_log (Ofelia job-exec).
      - ./scripts/nginx-access-log-rotate.sh:/usr/local/bin/nginx-access-log-rotate.sh:ro
      - ./defaults/webserver/maintenance.html:/usr/share/nginx/html/maintenance.html:ro
      # Access log dla kolektora netdata web_log. Osobny katalog (NIE
      # /var/log/nginx) zeby nie przeslonic symlinkow access.log->stdout /
      # error.log->stderr z obrazu nginx. Wspoldzielony RO z kontenerem netdata.
      - nginx_access_log:/var/log/nginx-shared
    deploy:
      resources:
        limits:
          # Obserwowane idle ~32 MiB, ale proxy_buffers 16x16k = 256 KB/connection
          # przy buforowaniu HTML-a z Django. Przy 500 concurrent requests to realnie
          # +110 MB RAM. 256m daje headroom pod burst + HTTP/3 QUIC + duze uploady.
          memory: ${WEBSERVER_MEM_LIMIT:-256m}
          cpus: "${WEBSERVER_CPU_LIMIT:-2.0}"
    labels:
      ofelia.enabled: "true"
      # Po renew certbota (job-run w docker-compose.application.yml) pojawi sie
      # sentinel /etc/letsencrypt/.reload-needed. Ten job-exec wykrywa go
      # i robi graceful reload nginx-a, zeby podniesc nowy cert. Bez sentinela
      # nginx serwuje stary cert do najblizszej restartu.
      # 5 minut po job-run renew (bezpieczny margines na wystawienie certu).
      ofelia.job-exec.letsencrypt_reload.schedule: "0 5 4 * * *"
      ofelia.job-exec.letsencrypt_reload.command: "/usr/local/bin/letsencrypt-reload.sh"
      # Codzienna rotacja access logu czytanego przez netdata web_log (04:10 —
      # po reloadzie LE 04:05, zeby nie kolidowac). `nginx -s reopen` odtwarza
      # plik; netdata wykrywa podmiane inode i czyta dalej.
      ofelia.job-exec.nginx_access_log_rotate.schedule: "0 10 4 * * *"
      ofelia.job-exec.nginx_access_log_rotate.command: "/usr/local/bin/nginx-access-log-rotate.sh"

  redis:
    image: redis:8.6.2
    restart: always
    logging: *default-logging
    # --maxmemory + allkeys-lru: Redis sam ewiktuje klucze gdy zbliza sie
    # do wlasnego limitu, zamiast czekac az Docker zabije caly kontener.
    # Wewnetrzny limit musi byc mniejszy niz zewnetrzny, zeby eviction
    # mial szanse zadzialac przed hard-OOM-kill-em.
    command:
      - redis-server
      - --maxmemory
      - ${REDIS_MAXMEMORY:-200mb}
      - --maxmemory-policy
      - allkeys-lru
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      start_period: 3s
      interval: 5s
      timeout: 3s
      retries: 3
    volumes:
      - redis:/data
    deploy:
      resources:
        limits:
          memory: ${REDIS_MEM_LIMIT:-1g}
          cpus: "${REDIS_CPU_LIMIT:-0.5}"

volumes:
  redis:
  # Webroot dla HTTP-01 challenge Let's Encrypt. Wspoldzielony miedzy
  # webserverem (czyta+rm sentinela) a kontenerem certbot z application.yml
  # (zapisuje pliki challenge przez --webroot). Ephemeral - tresc challenge
  # zyje sekundami, nic wartosciowego sie nie kumuluje.
  acme-challenge:
  # Access log nginx (format bpp_access) czytany przez kolektor netdata
  # web_log. Pisany RW przez webserver, montowany RO do netdaty
  # (docker-compose.monitoring.yml). Rotowany codziennie przez Ofelia —
  # max 2 generacje (.log + .log.1), wiec nie rosnie w nieskonczonosc.
  nginx_access_log: