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

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 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:

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

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.