# The webserver and runner on zeus, in containers.
#
#   docker compose -f docker-compose.services.yml up -d
#   docker compose -f docker-compose.services.yml logs -f
#
# The database is NOT here - it has its own compose file next to this one and
# its own lifecycle. These two only talk to it.
#
# Build the image first (from the repo root):
#   REPO_PASS=$(grep -oP 'RepoPass:\s*\K.*' /data/smartbotics-deb-repo/.env)
#   docker buildx build -f packaging/Dockerfile.build \
#     --build-arg BASE_IMAGE=smartbotic-automation-build-base:debian13 \
#     --build-arg REPO_PASS="$REPO_PASS" \
#     --target runtime -t smartbotic-automation:current .

name: smartbotic

services:
  smartbotic-webserver:
    image: smartbotic-automation:current
    container_name: smartbotic-webserver
    command: ["/usr/bin/smartbotic-webserver"]
    restart: unless-stopped
    networks: [smartbotic]
    ports:
      - "8090:8090"   # HTTP + WebUI
      - "8091:8091"   # WebSocket, derived as http_port + 1
    # The database container publishes 9004 on the host and sits on the default
    # bridge. Rather than move it onto this network - which would mean
    # recreating a running database - these services reach it back through the
    # host gateway.
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      TZ: Europe/Budapest
      LOG_LEVEL: info
      DATABASE_ADDRESS: host.docker.internal:9004
      DATABASE_PROJECT: smartbotic-automation
      # For anything that talks to OpenSSL directly. libcurl ignores it, which
      # is why the bundle is also mounted over curl's default CA path below -
      # see the volume comment.
      SSL_CERT_FILE: /etc/ssl/certs/ca-certificates.crt
    volumes:
      # Read-only: it carries the credentials master key and the JWT secret,
      # and nothing should be rewriting it from inside a container.
      - /data/dev/smartbotics/smartbotic/config:/var/lib/smartbotic/config:ro
      # Bind-mounted rather than used from the image so a node can be edited and
      # re-migrated without a rebuild, which is how they are worked on today.
      - /data/dev/smartbotics/smartbotic/nodes:/usr/share/smartbotic-automation/nodes:ro
      # Debian's CA set plus the extra certificates in ca/ - currently mulan's
      # self-signed SD.cpp cert. Regenerate with ca/build-bundle.sh.
      #
      # Mounted OVER curl's default CA file rather than beside it. The runner
      # never sets CURLOPT_CAINFO, so libcurl uses its compiled-in default,
      # which on Debian is exactly this path - and libcurl reads neither
      # SSL_CERT_FILE (that is OpenSSL's) nor CURL_CA_BUNDLE (that is the curl
      # command-line tool's). Pointing an environment variable at a bundle
      # somewhere else looks like it should work and silently does nothing.
      - /data/dev/smartbotics/smartbotic/deploy/zeus/ca/bundle.crt:/etc/ssl/certs/ca-certificates.crt:ro
    healthcheck:
      # bash's /dev/tcp, because a slim image carries no curl or wget.
      #
      # It must be CMD + bash, NOT CMD-SHELL: CMD-SHELL runs /bin/sh, which on
      # Debian is dash, and dash has no /dev/tcp - it fails with "cannot create
      # /dev/tcp/...: Directory nonexistent" on a webserver that is serving
      # perfectly well. The runner depends_on this being healthy, so getting it
      # wrong stops the runner from ever starting.
      test: ["CMD", "bash", "-c", "exec 3<>/dev/tcp/127.0.0.1/8090"]
      interval: 15s
      timeout: 5s
      retries: 5
      start_period: 20s

  smartbotic-runner:
    image: smartbotic-automation:current
    container_name: smartbotic-runner
    command: ["/usr/bin/smartbotic-runner"]
    restart: unless-stopped
    networks: [smartbotic]
    depends_on:
      smartbotic-webserver:
        condition: service_healthy
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      TZ: Europe/Budapest
      LOG_LEVEL: info
      RUNNER_ID: runner-1
      DATABASE_ADDRESS: host.docker.internal:9004
      DATABASE_PROJECT: smartbotic-automation
      # Service names, not localhost: the two are separate containers even when
      # they share a host, so every one of these has to be stated.
      WEBSERVER_ADDRESS: smartbotic-webserver:8090
      NODE_SYNC_ADDRESS: smartbotic-webserver:9012
      CREDENTIAL_SERVICE_ADDRESS: smartbotic-webserver:9013
      # What the runner tells the webserver to reach it on. Left unset it says
      # "localhost:9011", which inside a container means the webserver's own
      # container - it registers, reports online, and every dispatch vanishes.
      ADVERTISE_ADDRESS: smartbotic-runner:9011
      # For anything that talks to OpenSSL directly. libcurl ignores it, which
      # is why the bundle is also mounted over curl's default CA path below -
      # see the volume comment.
      SSL_CERT_FILE: /etc/ssl/certs/ca-certificates.crt
    volumes:
      - /data/dev/smartbotics/smartbotic/config:/var/lib/smartbotic/config:ro
      - /data/dev/smartbotics/smartbotic/nodes:/usr/share/smartbotic-automation/nodes:ro
      # Written by imap-extract-attachments. A bind mount, so the 230 files
      # carried over from mulan stay where the host can see them.
      - /data/dev/smartbotics/smartbotic/data:/var/lib/smartbotic/data
      # Debian's CA set plus the extra certificates in ca/ - currently mulan's
      # self-signed SD.cpp cert. Regenerate with ca/build-bundle.sh.
      #
      # Mounted OVER curl's default CA file rather than beside it. The runner
      # never sets CURLOPT_CAINFO, so libcurl uses its compiled-in default,
      # which on Debian is exactly this path - and libcurl reads neither
      # SSL_CERT_FILE (that is OpenSSL's) nor CURL_CA_BUNDLE (that is the curl
      # command-line tool's). Pointing an environment variable at a bundle
      # somewhere else looks like it should work and silently does nothing.
      - /data/dev/smartbotics/smartbotic/deploy/zeus/ca/bundle.crt:/etc/ssl/certs/ca-certificates.crt:ro

networks:
  smartbotic:
    name: smartbotic