Files

T

gitea 24fdae4f15 conjurer: add production ('deploy') bot + data seeding/backup

A second Conjurer bot alongside the test one, sharing librarian/musician/
radio and the API key, differing only in:
 * Discord token from the deploy-conjurer-netrc secret,
 * distinct names/labels (deploy-bot) and NodePort 32443,
 * /data on an NFS export (RWX) instead of a block PVC - so config/state
   can be uploaded while it runs (copy onto the share) and backed up
   concurrently.

deploy-bot-backup: a daily CronJob that mirrors /data and keeps 30 days of
dated snapshots of the critical small state (both memories, settings,
accident log, transcripts) on NFS. Production only - the test bot's
amnesia is fine. DEPLOY-BOT.md documents seeding, backup/restore, and the
librarian/musician callback routing (they push to one bot; repoint
CONJURER_MAIN_BOT to :32443 to feed this one).

kubectl kustomize builds cleanly (10 objects).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-08-03 18:07:53 +02:00

2.9 KiB

Raw Blame History

Production ("deploy") Conjurer bot

A second Conjurer bot that runs alongside the test bot in the conjurer namespace, sharing the same librarian / musician / radio and the shared CONJURER_API_KEY. It differs from the test bot only in:

its Discord token: the deploy-conjurer-netrc secret (already created),
distinct names/labels (deploy-bot) and NodePort 32443,
/data on NFS (RWX) instead of a block PVC — so you can seed/upload files while it runs and back it up concurrently.

Files: deploy-bot.yaml (Deployment + Service), deploy-bot-backup.yaml (daily backup CronJob). Both are wired into kustomization.yaml.

One-time setup

Secret — already exists as deploy-conjurer-netrc (a netrc carrying the deploy Discord token, key .netrc). Nothing to do; the Deployment mounts it at /secrets/.netrc.
NFS export — create the data + backup dirs on the NFS server (192.168.1.34, adjust to your real export):
```
/mnt/Tank1/conjurer_swap/deploy-bot/data
/mnt/Tank1/conjurer_swap/deploy-bot/backups
```

Seeding / uploading config & state into /data

Because /data is a plain NFS export, you upload files by copying them onto the share — no kubectl cp, no scaling the bot down. From the PVE box that holds /srv/data (mount the same export there, or rsync over it):

# on a host that can see the NFS export:
rsync -a /srv/data/ 192.168.1.34:/mnt/Tank1/conjurer_swap/deploy-bot/data/

The bot roots everything under CONJURER_DATA_DIR=/data, so these land where it expects them:

accident_log.json  Conjurer_graphics/  music/  pamiec.json
pamiec_muzyki.json  settings.json  system_gpt_settings.json  transcripts/

Upload as much or as little as you like — the bot seeds any missing JSON on first run. Live-editing pamiec.json while the bot writes to it can race; prefer seeding before first start or during a brief kubectl -n conjurer scale deploy/deploy-bot --replicas=0 window.

Backups (production only)

deploy-bot-backup runs daily (04:17) and writes to the backups export:

current/ — a full rsync mirror of /data (incl. music/graphics), always the latest state,
snapshots/deploy-state-<date>.tgz — dated archives of the critical small state (both memories, settings, accident log, transcripts), kept RETENTION_DAYS (30) days.

The test bot is deliberately not backed up (amnesia there is fine).

Restore example:

tar xzf snapshots/deploy-state-2026-08-03-0417.tgz -C /mnt/.../deploy-bot/data/

Routing librarian / musician callbacks

The librarian (CONJURER_MAIN_BOT) and musician push search results and "now playing" events to one bot address — currently the test bot's 192.168.1.73:32442. To make this bot receive them, repoint those services' CONJURER_MAIN_BOT to 192.168.1.73:32443 (this bot's NodePort). Only one bot can receive them at a time.

2.9 KiB Raw Blame History