docker-compose.yml

# ml-worker — anomaly detection, as its own Dockge stack.
#
# Not part of the root docker-compose.yml, and not the old
# docker-compose.override.yml this replaces (that file targeted a network,
# analysis-net, that never existed anywhere in this repository -- #61).
#
# Modelled on analysis/ghidra/docker-compose.ghidra.yml's shape (own stack,
# CPU-safe base, optional GPU overlay), but NOT on its isolation model.
# Ghidra's stack is deliberately loopback-only with no honeynet access,
# because it receives samples over a file spool and must never be reachable
# from the sensor network. ml-worker's entire job is the opposite: it has to
# read Elasticsearch continuously, so it joins honeynet as an external
# network -- the same pattern arcane/home/honeypot-init/compose.yml already uses to reach
# elasticsearch from a separate stack (#111).
#
# No Redis here, unlike the old override. ml-gpu-coordinated-roadmap.md §1
# decision 1: "Elasticsearch is the initial dashboard transport. Redis/SSE is
# optional until polling cost and latency show it is needed." Adding a
# broker before that measurement exists is a new stateful service, a new
# failure mode, and a new thing to secure on the honeypot host, for a
# problem not yet shown to exist. See #64 when that measurement happens.
#
# Deploy: copy this file to /opt/stacks/ml-worker/compose.yml (Dockge's
# naming convention), and docker-compose.ml-worker.gpu.yml to
# compose.override.yml only on a host with an nvidia container runtime --
# see that file's own header for why this stack does not need it yet.
#
# #1502: migrated into arcane/home/ for Arcane directory-aware Git sync.
# Already self-contained; only the explicit name: below and the file's own
# relocation/rename to compose.yml were needed.

name: ml-worker

services:
  ml-worker:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: hp-ml-worker
    restart: unless-stopped
    networks:
      - honeynet
    environment:
      ES_HOST: http://elasticsearch:9200
      POLL_INTERVAL: "30"
      ML_ALERT_THRESHOLD: "0.75"
      # #172: worker.py reads RETRAIN_SLOTS_UTC (fixed daily HH:MM slots),
      # not RETRAIN_INTERVAL -- that was this variable's old name/shape
      # before #172's rearchitect and was never actually wired here since.
      # Defaults to the exact value worker.py itself defaults to, so
      # leaving it unset in .env changes nothing; exists so an operator can
      # override it (e.g. to force a near-term retrain for verification)
      # without editing this file, same reasoning as ML_HOME_NET below.
      RETRAIN_SLOTS_UTC: "${RETRAIN_SLOTS_UTC:-03:00,09:00,15:00,21:00}"
      # #174: our own address(es), comma-separated CIDRs, same convention
      # as vps/.env.example's SURICATA_HOME_NET -- lets models/
      # isolation_forest.py's _get_ip()/_get_port() tell Suricata netflow's
      # "reflected" direction (source.ip == us) apart from a real remote
      # scanner. Set the real value in this stack's own .env (not checked
      # in, same reasoning as SURICATA_HOME_NET staying out of the repo).
      # Empty/unset is a safe no-op, not a startup failure.
      ML_HOME_NET: "${ML_HOME_NET:-}"
      # #1959: every other address we own -- loopback, the WireGuard tunnel,
      # the home LAN -- used to read as a remote party, because ML_HOME_NET
      # carried only the public address. On the largest alert day on record,
      # loopback was the single biggest "source": 3,204 of 6,669 alerts.
      #
      # Unset uses isolation_forest.py's DEFAULT_LOCAL_NETS, which covers
      # loopback, link-local, the WireGuard /24 and RFC1918. Those are
      # properties of this deployment shape rather than of one install, which
      # is why they are a default instead of required configuration -- the
      # incident happened precisely because the safe value had to be typed in.
      #
      # Override only for a deployment whose honeypots legitimately live
      # inside RFC1918 and must still be scored.
      ML_LOCAL_NETS: "${ML_LOCAL_NETS:-}"
      MODEL_DIR: /models
      LOG_LEVEL: INFO
    volumes:
      - ml-models:/models
    security_opt:
      - no-new-privileges:true
    cap_drop: [ALL]
    read_only: true
    tmpfs:
      - /tmp
    deploy:
      resources:
        limits:
          # PyTorch + sklearn + a rolling feature DataFrame can be
          # memory-hungry; 2G is the same allotment the old override used,
          # kept until Milestone C's 24h throughput baseline says otherwise.
          cpus: "2.0"
          memory: 2g

networks:
  honeynet:
    name: honeynet
    external: true

volumes:
  ml-models: