8 Commits

Author SHA1 Message Date
gitea 0509ebd597 feat(astrololo): sekrety logowania i tokenu miedzywarstwowego (LOG-32)
Domyka od strony wdrozenia ochrone dodana w aplikacji (PR #10 w repo astrololo).
Bez tych zmiennych aplikacja startuje OTWARTA, a wystawia tresc oryginalnych
baz interpretacyjnych.

- presentation: APP_PASSWORD + INTERNAL_TOKEN z sekretu, APP_USER i
  RATE_LIMIT_PER_MIN jawnie (nie sa tajne).
- logic, data: INTERNAL_TOKEN z sekretu — bez niego da sie ominac logowanie,
  uderzajac wprost w warstwe nizej. Warstwa danych oddaje SUROWE wiersze,
  wiec to najwrazliwszy punkt.

WARTOSCI SEKRETOW CELOWO NIE TRAFIAJA DO REPO — to GitOps, wiec zostalyby
w historii gita na zawsze i przekreslily caly sens tej zmiany. Manifesty
tylko odwoluja sie do sekretu `astrololo-auth`, tworzonego poza repo — ta sama
konwencja co istniejacy `gitea-registry`.

UWAGA: sekret jest WYMAGANY (bez `optional: true`), wiec pody nie wstana,
dopoki go nie utworzysz. To swiadome: lepsza widoczna awaria niz cichy start
bez ochrony. Instrukcja tworzenia i zmiany hasla w astrololo/README.md.

Przy okazji: poprawiony mylacy komentarz przy EXCEL_DIR — pliki baz ida
z NFS, nie z obrazu (montaz je nadpisuje).

Zwalidowane `kubectl kustomize` dla bazy i profilu swisseph: sekrety trafiaja
do wlasciwych uslug, a w wyniku nie ma zadnego `kind: Secret`.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-21 18:53:12 +02:00
argocd-image-updater b686837d19 build: automatic update of astrololo
updates image gitea/astrololo-logic tag 'de5d5895' to '6f87b2b3'
updates image gitea/astrololo-presentation tag 'a2aabd37' to '6f87b2b3'
2026-07-21 14:35:50 +00:00
argocd-image-updater fb332c4e75 build: automatic update of astrololo
updates image gitea/astrololo-logic tag 'de5d5895' to '6f87b2b3'
2026-07-21 14:33:47 +00:00
argocd-image-updater 69ac1aa90b build: automatic update of astrololo
updates image gitea/astrololo-presentation tag 'de5d5895' to 'a2aabd37'
2026-07-21 01:57:20 +00:00
argocd-image-updater 6405a2544c build: automatic update of astrololo
updates image gitea/astrololo-data tag 'c75f8377' to 'de5d5895'
updates image gitea/astrololo-logic tag 'ab6fc072' to 'de5d5895'
updates image gitea/astrololo-presentation tag 'ab6fc072' to 'de5d5895'
2026-07-21 01:18:43 +00:00
gitea d3b518273a feat(astrololo): profil deployu swisseph (silnik B, AGPL)
Drugi, opcjonalny wariant deployu: ten sam stack co produkcja, ale logic
liczy na Swiss Ephemeris zamiast na wlasnym Skyfieldzie.

Overlay Kustomize nad ../astrololo:
- dokłada usluge engine-swisseph (Deployment + Service, ClusterIP — bez
  wejscia z zewnatrz, izolacja AGPL: rozmawia z nia tylko logic),
- patchuje logic: EPHEMERIS_ENGINE=swisseph + ENGINE_SWISSEPH_URL (wlacza
  tez /chart/compare, LOG-25/26),
- tagi data/logic/presentation dziedziczy z bazy (sledzi wersje produkcji).

Aktywacja przez wskazanie GitOps na katalog astrololo-swisseph zamiast
astrololo (profil zastepujacy baze w tym samym ns). Szczegoly w README.
Zwalidowane `kubectl kustomize` (9 obiektow, env logica i ClusterIP OK).

Wymaga obrazu astrololo-engine-swisseph w registry — buduje go osobny
workflow w repo astrololo (PR rownolegly).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-21 01:02:28 +00:00
argocd-image-updater b8c9d96edf build: automatic update of astrololo
updates image gitea/astrololo-logic tag '6ced2ddd' to 'ab6fc072'
updates image gitea/astrololo-presentation tag '6ced2ddd' to 'ab6fc072'
2026-07-21 00:18:13 +00:00
argocd-image-updater cfeb47020d build: automatic update of astrololo
updates image gitea/astrololo-logic tag 'c75f8377' to '6ced2ddd'
updates image gitea/astrololo-presentation tag 'c75f8377' to '6ced2ddd'
2026-07-20 18:52:05 +00:00
9 changed files with 281 additions and 4 deletions
+70
View File
@@ -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`.
+51
View File
@@ -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.
+39
View File
@@ -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
@@ -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"
+70
View File
@@ -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`.
+7 -1
View File
@@ -18,11 +18,17 @@ spec:
- name: DATA_PROVIDER - name: DATA_PROVIDER
value: "excel" value: "excel"
- name: EXCEL_DIR - 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 - name: CACHE_DIR
value: "/app/.cache" value: "/app/.cache"
- name: INDEXED_KEYS - name: INDEXED_KEYS
value: "name,id,symbol" 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: volumeMounts:
- name: cache - name: cache
mountPath: /app/.cache mountPath: /app/.cache
+3 -3
View File
@@ -7,8 +7,8 @@ resources:
- presentation.yaml - presentation.yaml
images: images:
- name: gitea.czernobog.pl/gitea/astrololo-data - name: gitea.czernobog.pl/gitea/astrololo-data
newTag: c75f8377 newTag: de5d5895
- name: gitea.czernobog.pl/gitea/astrololo-logic - name: gitea.czernobog.pl/gitea/astrololo-logic
newTag: c75f8377 newTag: 6f87b2b3
- name: gitea.czernobog.pl/gitea/astrololo-presentation - name: gitea.czernobog.pl/gitea/astrololo-presentation
newTag: c75f8377 newTag: 6f87b2b3
+6
View File
@@ -20,6 +20,12 @@ spec:
- name: EPHEMERIS_ENGINE - name: EPHEMERIS_ENGINE
value: "own" # silnik własny; swisseph pominięty value: "own" # silnik własny; swisseph pominięty
# ENGINE_SWISSEPH_URL celowo NIE ustawiamy — engine-swisseph nie jest wdrażany # 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: resources:
requests: { cpu: "100m", memory: "128Mi" } requests: { cpu: "100m", memory: "128Mi" }
limits: { cpu: "500m", memory: "512Mi" } limits: { cpu: "500m", memory: "512Mi" }
+13
View File
@@ -17,6 +17,19 @@ spec:
env: env:
- name: LOGIC_URL - name: LOGIC_URL
value: "http://logic:8001" 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: resources:
requests: { cpu: "100m", memory: "128Mi" } requests: { cpu: "100m", memory: "128Mi" }
limits: { cpu: "300m", memory: "256Mi" } limits: { cpu: "300m", memory: "256Mi" }