build: automatic update of astrololo

updates image gitea/astrololo-logic tag '4ef90b30' to '64d1afc7'
updates image gitea/astrololo-presentation tag '4ef90b30' to '64d1afc7'

astrololo-swisseph/README.md

@@ -0,0 +1,70 @@
+# Profil deployu: `swisseph` (silnik B, AGPL)
+
+Drugi, **opcjonalny** wariant deployu astrololo. Ten sam stack co produkcja, ale
+warstwa logiczna liczy na **Swiss Ephemeris** (silnik B, AGPL) zamiast na własnym
+Skyfieldzie. Zbudowany jako overlay Kustomize nad bazą `../astrololo`.
+
+## Co robi
+- dokłada usługę **`engine-swisseph`** (Deployment + Service, **ClusterIP**),
+- przełącza `logic` na `EPHEMERIS_ENGINE=swisseph` i ustawia
+  `ENGINE_SWISSEPH_URL=http://engine-swisseph:8003`,
+- data / logic / presentation oraz ich tagi obrazów **dziedziczy z bazy** — profil
+  śledzi tę samą wersję co produkcja (podbija ją ten sam image-updater).
+
+Włączenie `ENGINE_SWISSEPH_URL` uruchamia też endpoint **`/chart/compare`** — czyli
+w jednej instancji logica masz porównanie own vs swisseph (LOG-25/26), bez stawiania
+drugiego równoległego stacku.
+
+## ⚠️ Licencja / izolacja
+`engine-swisseph` jest **AGPL-3.0** i dlatego:
+- to **osobny proces/obraz**, wołany przez HTTP — permisywny produkt nie jest z nim
+  linkowany,
+- Service jest **ClusterIP** (świadomie **bez** NodePort/Ingress): rozmawia z nim
+  tylko `logic`, usługa nie jest wystawiona użytkownikom końcowym.
+
+Ten profil służy do walidacji / porównań i **nie jest** dystrybucją zamkniętego
+produktu.
+
+## Aktywacja
+To profil **zastępujący** bazę w tym samym namespace `astrololo` (nie dokładający się
+obok). Wskaż kontroler GitOps (Argo CD / Flux) na katalog `astrololo-swisseph`
+**zamiast** `astrololo`:
+
+```yaml
+# np. w Argo CD Application:
+source:
+  path: astrololo-swisseph        # było: astrololo
+```
+
+Ręcznie:
+```bash
+kubectl apply -k astrololo-swisseph
+```
+
+> **Nie** trzymaj obu reconcilerów naraz na ns `astrololo` — baza (own) i ten profil
+> (swisseph) biłyby się o patch `logica`. Wybierasz jeden albo drugi.
+>
+> Powrót do własnego silnika: wskaż GitOps z powrotem na `astrololo` (albo
+> `kubectl apply -k astrololo` — usuń wtedy ręcznie Deployment/Service
+> `engine-swisseph`, bo baza go nie zna).
+
+## Wymagania wstępne
+1. **Obraz silnika B** musi istnieć w registry:
+   `gitea.czernobog.pl/gitea/astrololo-engine-swisseph`. Buduje go workflow
+   `.gitea/workflows/build-swisseph.yaml` w repo `astrololo` (odpala się przy zmianach
+   w `services/engine-swisseph/**`; można też ręcznie przez `workflow_dispatch`).
+   Overlay używa tagu `latest` — podmień w `kustomization.yaml` na przypięty SHA, gdy
+   zechcesz zamrozić wersję.
+2. Ten sam ns `astrololo` → reużywa istniejący pull-secret `gitea-registry` i montaż
+   NFS z `data.yaml`. (Gdybyś wolał postawić profil **obok** produkcji w osobnym ns,
+   odkomentuj `namespace:` w `kustomization.yaml` i utwórz w nowym ns pull-secret
+   `gitea-registry` oraz upewnij się co do dostępu do NFS.)
+
+## Weryfikacja po wdrożeniu
+```bash
+kubectl -n astrololo rollout status deploy/engine-swisseph
+kubectl -n astrololo exec deploy/logic -- \
+  sh -c 'wget -qO- http://engine-swisseph:8003/health'
+# oczekiwane: {"engine":"swisseph","status":"ok","mode":"moshier",...}
+```
+Następnie w UI/`logic` policz dowolny horoskop i porównaj przez `/chart/compare`.

astrololo-swisseph/engine-swisseph.yaml

@@ -0,0 +1,51 @@
+# Silnik B — Swiss Ephemeris (AGPL-3.0), IZOLOWANY.
+#
+# Wdrażany WYŁĄCZNIE w profilu swisseph. Usługa jest wystawiona tylko wewnątrz
+# klastra (ClusterIP — brak NodePort/Ingress): rozmawia z nią jedynie `logic`.
+# To utrzymuje granicę procesu/sieci wymaganą przez izolację AGPL — permisywny
+# produkt nie jest z nią linkowany, a usługa nie jest oferowana użytkownikom
+# końcowym bezpośrednio.
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: engine-swisseph
+  namespace: astrololo
+  labels:
+    app: engine-swisseph
+    license: AGPL-3.0
+spec:
+  replicas: 1
+  selector: { matchLabels: { app: engine-swisseph } }
+  template:
+    metadata:
+      labels:
+        app: engine-swisseph
+        license: AGPL-3.0
+    spec:
+      imagePullSecrets: [{ name: gitea-registry }]
+      containers:
+        - name: engine-swisseph
+          image: gitea.czernobog.pl/gitea/astrololo-engine-swisseph:latest
+          imagePullPolicy: Always            # tag ruchomy (latest) — dociągaj najnowszy
+          ports: [{ containerPort: 8003 }]
+          readinessProbe:
+            httpGet: { path: /health, port: 8003 }
+            initialDelaySeconds: 3
+            periodSeconds: 10
+          livenessProbe:
+            httpGet: { path: /health, port: 8003 }
+            initialDelaySeconds: 10
+            periodSeconds: 30
+          resources:
+            requests: { cpu: "50m", memory: "96Mi" }
+            limits:   { cpu: "300m", memory: "256Mi" }
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: engine-swisseph
+  namespace: astrololo
+spec:
+  selector: { app: engine-swisseph }
+  ports: [{ port: 8003, targetPort: 8003 }]
+  # ClusterIP (domyślnie) — świadomie brak type: NodePort. Tylko ruch wewnątrz klastra.

astrololo-swisseph/kustomization.yaml

@@ -0,0 +1,39 @@
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+
+# Profil "swisseph" — DRUGI, opcjonalny wariant deployu, w którym warstwa logiczna
+# liczy na silniku B (Swiss Ephemeris / AGPL) zamiast na własnym (Skyfield).
+#
+# Bierze cały bazowy stack (namespace + data + logic + presentation) i:
+#   1. dokłada usługę engine-swisseph (AGPL, izolowaną, tylko wewnątrz klastra),
+#   2. przełącza `logic` na EPHEMERIS_ENGINE=swisseph i wskazuje jej silnik B.
+#
+# Tagi obrazów data/logic/presentation dziedziczą się z bazy (../astrololo) — więc
+# ten profil śledzi tę samą wersję co produkcja; podbija je ten sam image-updater.
+#
+# AKTYWACJA: wskaż kontroler GitOps (Argo/Flux) na `astrololo-swisseph` ZAMIAST
+# `astrololo`. To profil ZASTĘPUJĄCY bazę w tym samym namespace — nie uruchamiaj
+# obu reconcilerów naraz na ns `astrololo` (biłyby się o patch logica).
+# Zobacz README.md.
+
+# Zostaje w tym samym namespace co baza (astrololo) — reużywa m.in. secret
+# gitea-registry i montaż NFS z data.yaml. Aby zamiast tego postawić profil obok
+# produkcji (A/B w osobnym ns), odkomentuj poniższe i utwórz w nim pull-secret:
+# namespace: astrololo-swisseph
+
+resources:
+  - ../astrololo
+  - engine-swisseph.yaml
+
+patches:
+  - path: logic-swisseph.patch.yaml
+    target:
+      kind: Deployment
+      name: logic
+
+images:
+  # Obraz silnika B budowany osobnym workflow (.gitea/workflows/build-swisseph.yaml
+  # w repo astrololo) — nie wchodzi do głównego pipeline'u produktu. Podmień na
+  # przypięty tag (SHA), gdy zechcesz zamrozić wersję.
+  - name: gitea.czernobog.pl/gitea/astrololo-engine-swisseph
+    newTag: latest

astrololo-swisseph/logic-swisseph.patch.yaml

@@ -0,0 +1,22 @@
+# Patch warstwy logicznej dla profilu swisseph.
+# Strategic merge po kluczu `name`: nadpisuje EPHEMERIS_ENGINE (own -> swisseph)
+# i DODAJE ENGINE_SWISSEPH_URL; DATA_URL i reszta env z bazy zostają nietknięte.
+#
+# EPHEMERIS_ENGINE=swisseph  -> silnikiem GŁÓWNYM jest RemoteEngine (Swiss Ephemeris).
+# ENGINE_SWISSEPH_URL        -> adres usługi silnika B; włącza też /chart/compare
+#                               (porównanie own vs swisseph, LOG-25/26).
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: logic
+  namespace: astrololo
+spec:
+  template:
+    spec:
+      containers:
+        - name: logic
+          env:
+            - name: EPHEMERIS_ENGINE
+              value: "swisseph"
+            - name: ENGINE_SWISSEPH_URL
+              value: "http://engine-swisseph:8003"

astrololo/README.md

@@ -0,0 +1,70 @@
+# astrololo — deploy (namespace `astrololo`)
+
+Manifesty k8s składane Kustomize. Obrazy podbija automatycznie image-updater
+(`kustomization.yaml` → `images: newTag`) po każdym buildzie z repo aplikacji.
+
+Warstwy: `presentation` (NodePort, wejście z przeglądarki) → `logic` → `data`
+(pliki Excel montowane **z NFS**, nie z obrazu).
+
+## ⚠️ Sekret `astrololo-auth` — utwórz PRZED wdrożeniem
+
+Aplikacja wystawia treść **oryginalnych baz interpretacyjnych**, dlatego wymaga
+logowania i tokenu międzywarstwowego (LOG-32). Manifesty odwołują się do sekretu
+`astrololo-auth` i **celowo nie zawierają jego wartości** — to repo GitOps, więc
+cokolwiek by tu wpadło, zostałoby w historii gita na zawsze.
+
+To ta sama konwencja co `gitea-registry`: sekret tworzymy poza repo.
+
+**Pody nie wstaną bez tego sekretu — i tak ma być.** Wolimy widoczną awarię niż
+cichy start aplikacji bez ochrony.
+
+```bash
+# hasło wczytane bez zapisu w historii powłoki
+read -rs -p "Hasło do aplikacji (APP_PASSWORD): " APP_PASSWORD; echo
+
+kubectl -n astrololo create secret generic astrololo-auth \
+  --from-literal=APP_PASSWORD="$APP_PASSWORD" \
+  --from-literal=INTERNAL_TOKEN="$(openssl rand -hex 32)"
+
+unset APP_PASSWORD
+```
+
+`INTERNAL_TOKEN` jest losowany i **nikt go nigdy nie musi oglądać** — służy tylko
+usługom do rozmowy między sobą. `APP_PASSWORD` wpisujesz w przeglądarce
+(użytkownik: `astrololo`, zmienny przez `APP_USER` w `presentation.yaml`).
+
+### Zmiana hasła
+```bash
+read -rs -p "Nowe hasło: " NEW; echo
+kubectl -n astrololo create secret generic astrololo-auth \
+  --from-literal=APP_PASSWORD="$NEW" \
+  --from-literal=INTERNAL_TOKEN="$(kubectl -n astrololo get secret astrololo-auth \
+      -o jsonpath='{.data.INTERNAL_TOKEN}' | base64 -d)" \
+  --dry-run=client -o yaml | kubectl apply -f -
+kubectl -n astrololo rollout restart deploy/presentation
+unset NEW
+```
+(Zachowujemy istniejący `INTERNAL_TOKEN`; jego zmiana wymaga restartu **wszystkich
+trzech** usług naraz, inaczej przestaną się dogadywać.)
+
+### Sprawdzenie po wdrożeniu
+```bash
+kubectl -n astrololo rollout status deploy/presentation deploy/logic deploy/data
+NODE_PORT=$(kubectl -n astrololo get svc presentation -o jsonpath='{.spec.ports[0].nodePort}')
+curl -s -o /dev/null -w "bez hasła: %{http_code}\n"  http://<adres-noda>:$NODE_PORT/
+curl -s -o /dev/null -w "z hasłem: %{http_code}\n" -u astrololo:'<hasło>' http://<adres-noda>:$NODE_PORT/
+```
+Oczekiwane: **401** bez hasła, **200** z hasłem. `/health` zostaje publiczny (sondy k8s).
+
+## Czego to nie załatwia
+- **Brak TLS** — Basic Auth idzie po sieci w postaci łatwej do podsłuchania. Przy
+  niezaufanej sieci potrzebny ingress z certyfikatem.
+- **NFS `192.168.1.34:/mnt/Tank1/astrololo`** — kto ma dostęp do share'u, bierze
+  pliki baz **z pominięciem całej aplikacji**. Do zamknięcia po stronie infrastruktury
+  (eksport tylko dla IP węzłów, `root_squash`, najlepiej read-only).
+- **Sekret w etcd** jest tylko zakodowany base64. Docelowo: szyfrowanie etcd at-rest
+  albo Sealed Secrets / SOPS, jeśli chcecie trzymać sekrety deklaratywnie w repo.
+
+## Profil ze swissephem
+Wariant z silnikiem B: [`../astrololo-swisseph/`](../astrololo-swisseph/README.md).
+Dziedziczy powyższe zmienne z tej bazy, więc też wymaga sekretu `astrololo-auth`.

astrololo/data.yaml

@@ -18,11 +18,17 @@ spec:
             - name: DATA_PROVIDER
               value: "excel"
             - name: EXCEL_DIR
-              value: "/app/data_files"          # pliki są W OBRAZIE (COPY . .)
+              value: "/app/data_files"          # montowane z NFS (patrz volumes) — NIE z obrazu
             - name: CACHE_DIR
               value: "/app/.cache"
             - name: INDEXED_KEYS
               value: "name,id,symbol"
+            # Token międzywarstwowy (LOG-32). Ta warstwa oddaje SUROWE wiersze baz —
+            # najwrażliwszy punkt systemu. Bez tokenu dałoby się ją odpytać
+            # bezpośrednio, z pominięciem i logiki, i logowania w UI.
+            - name: INTERNAL_TOKEN
+              valueFrom:
+                secretKeyRef: { name: astrololo-auth, key: INTERNAL_TOKEN }
           volumeMounts:
             - name: cache
               mountPath: /app/.cache

astrololo/kustomization.yaml

@@ -7,8 +7,8 @@ resources:
   - presentation.yaml
 images:
   - name: gitea.czernobog.pl/gitea/astrololo-data
-    newTag: c75f8377
+    newTag: 752f477a
   - name: gitea.czernobog.pl/gitea/astrololo-logic
-    newTag: c75f8377
+    newTag: 64d1afc7
   - name: gitea.czernobog.pl/gitea/astrololo-presentation
-    newTag: c75f8377
+    newTag: 64d1afc7

astrololo/logic.yaml

@@ -20,6 +20,12 @@ spec:
             - name: EPHEMERIS_ENGINE
               value: "own"                       # silnik własny; swisseph pominięty
             # ENGINE_SWISSEPH_URL celowo NIE ustawiamy — engine-swisseph nie jest wdrażany
+            # Token międzywarstwowy (LOG-32): logika oddaje treść baz, więc musi
+            # odrzucać żądania z pominięciem logowania w prezentacji. Ten sam token
+            # służy jej do uwierzytelnienia się w warstwie danych.
+            - name: INTERNAL_TOKEN
+              valueFrom:
+                secretKeyRef: { name: astrololo-auth, key: INTERNAL_TOKEN }
           resources:
             requests: { cpu: "100m", memory: "128Mi" }
             limits:   { cpu: "500m", memory: "512Mi" }

astrololo/presentation.yaml

@@ -17,6 +17,19 @@ spec:
           env:
             - name: LOGIC_URL
               value: "http://logic:8001"
+            # Logowanie do aplikacji (LOG-32). Bez tych sekretów aplikacja stoi
+            # OTWARTA — a wystawia treść baz interpretacyjnych. Sekret tworzony
+            # POZA repo (jak gitea-registry) — patrz README.md.
+            - name: APP_PASSWORD
+              valueFrom:
+                secretKeyRef: { name: astrololo-auth, key: APP_PASSWORD }
+            - name: INTERNAL_TOKEN
+              valueFrom:
+                secretKeyRef: { name: astrololo-auth, key: INTERNAL_TOKEN }
+            - name: APP_USER
+              value: "astrololo"
+            - name: RATE_LIMIT_PER_MIN
+              value: "120"                       # 0 = bez limitu
           resources:
             requests: { cpu: "100m", memory: "128Mi" }
             limits:   { cpu: "300m", memory: "256Mi" }