Files
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

71 lines
3.1 KiB
Markdown

# 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`.