feat(prezentacja): wolumen na konta zakładane z aplikacji (PRE-27)

Ekran „Konta" zapisuje konta do pliku, więc prezentacja potrzebuje trwałego
miejsca — inaczej wszystkie konta znikałyby przy restarcie poda.

subPath, NIE cały udział: prezentacja dostaje wyłącznie własny podkatalog
`presentation-state` i nie widzi baz interpretacyjnych. Zamontowanie tu całego
/mnt/Tank1/astrololo dałoby jej wgląd w bazy i obeszłoby bokiem zamknięcie
dostępu z DAN-25.

Konto administracyjne zostaje w APP_USER/APP_PASSWORD z sekretu — celowo poza
plikiem, żeby nie dało się go skasować ani ograniczyć z aplikacji.

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

astrololo/data.yaml

@@ -9,6 +9,10 @@ spec:
   template:
     metadata: { labels: { app: data } }
     spec:
+      # LOG-33: pody nie rozmawiają z API Kubernetesa, więc token konta
+      # serwisowego jest im niepotrzebny — a zamontowany byłby gotowym
+      # punktem wyjścia do klastra dla kogoś, kto przejmie kontener.
+      automountServiceAccountToken: false
       imagePullSecrets: [{ name: gitea-registry }]
       containers:
         - name: data

astrololo/kustomization.yaml

@@ -10,10 +10,10 @@ resources:
   - ingress.yaml # wejście po https + przekierowanie z http
 images:
   - name: gitea.czernobog.pl/gitea/astrololo-data
-    newTag: b36b3bee
+    newTag: 70c83cfc
   - name: gitea.czernobog.pl/gitea/astrololo-logic
-    newTag: b36b3bee
+    newTag: 70c83cfc
   - name: gitea.czernobog.pl/gitea/astrololo-render
     newTag: latest
   - name: gitea.czernobog.pl/gitea/astrololo-presentation
-    newTag: a9f2a038
+    newTag: 70c83cfc

astrololo/logic.yaml

@@ -9,6 +9,10 @@ spec:
   template:
     metadata: { labels: { app: logic } }
     spec:
+      # LOG-33: pody nie rozmawiają z API Kubernetesa, więc token konta
+      # serwisowego jest im niepotrzebny — a zamontowany byłby gotowym
+      # punktem wyjścia do klastra dla kogoś, kto przejmie kontener.
+      automountServiceAccountToken: false
       imagePullSecrets: [{ name: gitea-registry }]
       containers:
         - name: logic

astrololo/presentation.yaml

@@ -9,6 +9,10 @@ spec:
   template:
     metadata: { labels: { app: presentation } }
     spec:
+      # LOG-33: pody nie rozmawiają z API Kubernetesa, więc token konta
+      # serwisowego jest im niepotrzebny — a zamontowany byłby gotowym
+      # punktem wyjścia do klastra dla kogoś, kto przejmie kontener.
+      automountServiceAccountToken: false
       imagePullSecrets: [{ name: gitea-registry }]
       containers:
         - name: presentation
@@ -56,9 +60,26 @@ spec:
                 secretKeyRef: { name: astrololo-link, key: LINK_KEY_PRESENTATION_RENDER }
             - name: LINK_ENCRYPTION_REQUIRED
               value: "true"
+            # Konta zakładane z ekranu „Konta" (PRE-26). Konto administracyjne
+            # zostaje w APP_USER/APP_PASSWORD powyżej — celowo, bo dzięki temu
+            # NIE DA SIĘ go skasować ani ograniczyć z aplikacji.
+            - name: ACCOUNTS_FILE
+              value: "/app/state/accounts.json"
+          volumeMounts:
+            # subPath, NIE cały udział: prezentacja dostaje wyłącznie własny
+            # podkatalog i nie widzi baz interpretacyjnych. Zamontowanie tu całego
+            # /mnt/Tank1/astrololo obeszłoby bokiem zamknięcie dostępu z DAN-25.
+            - name: state
+              mountPath: /app/state
+              subPath: presentation-state
           resources:
             requests: { cpu: "100m", memory: "128Mi" }
             limits:   { cpu: "300m", memory: "256Mi" }
+      volumes:
+        - name: state
+          nfs:
+            server: 192.168.1.34
+            path: /mnt/Tank1/astrololo
 ---
 apiVersion: v1
 kind: Service

astrololo/render.yaml

@@ -19,6 +19,10 @@ spec:
   template:
     metadata: { labels: { app: render } }
     spec:
+      # LOG-33: pody nie rozmawiają z API Kubernetesa, więc token konta
+      # serwisowego jest im niepotrzebny — a zamontowany byłby gotowym
+      # punktem wyjścia do klastra dla kogoś, kto przejmie kontener.
+      automountServiceAccountToken: false
       imagePullSecrets: [{ name: gitea-registry }]
       containers:
         - name: render

conjurer/DEPLOY-BOT.md

@@ -12,6 +12,31 @@ namespace, sharing the same librarian / musician / radio and the shared
 Files: `deploy-bot.yaml` (Deployment + Service), `deploy-bot-backup.yaml`
 (daily backup CronJob). Both are wired into `kustomization.yaml`.
 
+## Update channel — only on `[deploy]`
+
+Unlike the test bot (which tracks every build), the production bot updates **only
+when you promote a version**. It runs a **separate image**,
+`conjurer-bot-deploy`, which the conjurer CI tags **only when the commit message
+contains `[deploy]`** (it re-tags the already-built `conjurer-bot:<sha>` — same
+bytes). The image-updater's `deploy-bot` alias then bumps this bot's tag.
+
+So: normal commits update the test bot + librarian; a commit with `[deploy]` in
+its message is the one that also rolls the production bot.
+
+**Already bootstrapped:** the channel was seeded by the first `[deploy]` commit
+(the merge of conjurer#20), which promoted `conjurer-bot-deploy:fbd1ec9f` — the
+tag pinned in `kustomization.yaml`. From here the image-updater keeps it current
+on each future `[deploy]` commit. Note the librarian is shared and still tracks
+latest, so mind large bot⇄librarian version skews.
+
+If you ever need to seed a tag by hand:
+```bash
+docker pull gitea.czernobog.pl/gitea/conjurer-bot:<sha>
+docker tag  gitea.czernobog.pl/gitea/conjurer-bot:<sha> \
+            gitea.czernobog.pl/gitea/conjurer-bot-deploy:<sha>
+docker push gitea.czernobog.pl/gitea/conjurer-bot-deploy:<sha>
+```
+
 ## One-time setup
 
 1. **Secret** — already exists as `deploy-conjurer-netrc` (a netrc carrying the

conjurer/conjurer-imageupdater.yaml

@@ -15,5 +15,8 @@ spec:
   applicationRefs:
     - namePattern: "conjurer"
       images:
-        - { alias: "librarian", imageName: "gitea.czernobog.pl/gitea/conjurer-librarian" }
-        - { alias: "bot",       imageName: "gitea.czernobog.pl/gitea/conjurer-bot" }
+        - { alias: "librarian",  imageName: "gitea.czernobog.pl/gitea/conjurer-librarian" }
+        - { alias: "bot",        imageName: "gitea.czernobog.pl/gitea/conjurer-bot" }
+        # Production bot tracks its own image, which only gets new tags on
+        # [deploy] commits (conjurer CI) - so it updates only on promoted builds.
+        - { alias: "deploy-bot", imageName: "gitea.czernobog.pl/gitea/conjurer-bot-deploy" }

conjurer/deploy-bot.yaml

@@ -30,7 +30,11 @@ spec:
       imagePullSecrets: [{ name: gitea-registry }]
       containers:
         - name: bot
-          image: gitea.czernobog.pl/gitea/conjurer-bot:c8aae106
+          # SEPARATE image from the test bot: conjurer-bot-deploy only gets a new
+          # tag when a commit message contains [deploy] (see the conjurer CI), so
+          # this bot updates only on versions you explicitly promote. Tag is
+          # managed by the image-updater (kustomization images:).
+          image: gitea.czernobog.pl/gitea/conjurer-bot-deploy:c8aae106
           ports: [{ containerPort: 5000 }]
           env:
             - { name: CONJURER_DATA_DIR,      value: "/data" }

conjurer/kustomization.yaml

@@ -8,6 +8,12 @@ resources:
   - deploy-bot-backup.yaml
 images:
   - name: gitea.czernobog.pl/gitea/conjurer-librarian
-    newTag: f4dea535
+    newTag: ae1bd677
   - name: gitea.czernobog.pl/gitea/conjurer-bot
-    newTag: f4dea535
+    newTag: fbd1ec9f
+  # Production bot channel - only bumped when a [deploy]-tagged build appears.
+  # Bootstrapped to fbd1ec9f: that's the image the first [deploy] build (merge
+  # of conjurer#20) promoted to conjurer-bot-deploy. From here the image-updater
+  # keeps it current across future [deploy] commits.
+  - name: gitea.czernobog.pl/gitea/conjurer-bot-deploy
+    newTag: fbd1ec9f