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>
3.1 KiB
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
logicnaEPHEMERIS_ENGINE=swissephi ustawiaENGINE_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:
# np. w Argo CD Application:
source:
path: astrololo-swisseph # było: astrololo
Ręcznie:
kubectl apply -k astrololo-swisseph
Nie trzymaj obu reconcilerów naraz na ns
astrololo— baza (own) i ten profil (swisseph) biłyby się o patchlogica. Wybierasz jeden albo drugi.Powrót do własnego silnika: wskaż GitOps z powrotem na
astrololo(albokubectl apply -k astrololo— usuń wtedy ręcznie Deployment/Serviceengine-swisseph, bo baza go nie zna).
Wymagania wstępne
- Obraz silnika B musi istnieć w registry:
gitea.czernobog.pl/gitea/astrololo-engine-swisseph. Buduje go workflow.gitea/workflows/build-swisseph.yamlw repoastrololo(odpala się przy zmianach wservices/engine-swisseph/**; można też ręcznie przezworkflow_dispatch). Overlay używa tagulatest— podmień wkustomization.yamlna przypięty SHA, gdy zechcesz zamrozić wersję. - Ten sam ns
astrololo→ reużywa istniejący pull-secretgitea-registryi montaż NFS zdata.yaml. (Gdybyś wolał postawić profil obok produkcji w osobnym ns, odkomentujnamespace:wkustomization.yamli utwórz w nowym ns pull-secretgitea-registryoraz upewnij się co do dostępu do NFS.)
Weryfikacja po wdrożeniu
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.