Domyslnie dziala model LOKALNY i nic nie opuszcza sieci. Zeby dalo sie wybrac
w UI OpenAI albo Anthropic, logika potrzebuje ich kluczy.
- LLM_PROVIDER=local, LOCAL_BASE_URL, LOCAL_MODEL, LLM_TIMEOUT, LLM_MAX_TOKENS
jawnie (nie sa tajne),
- OPENAI_API_KEY i ANTHROPIC_API_KEY z osobnego sekretu `astrololo-llm`.
Sekret jest OPCJONALNY (optional: true) — inaczej niz `astrololo-auth`. Auth to
zabezpieczenie i ma zatrzymac pody, gdy go brak; klucze do chmury to funkcja,
wiec ich brak nie moze wywracac wdrozenia. Bez nich pody startuja normalnie,
tylko chmura jest niedostepna.
Osobny sekret, a nie doklejenie do astrololo-auth, zeby klucze LLM dalo sie
wymieniac bez dotykania hasla i tokenu miedzywarstwowego.
Zwalidowane kubectl kustomize; w wyniku nadal zadnego `kind: Secret`.
Instrukcja tworzenia i podmiany kluczy w astrololo/README.md.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
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'
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>
updates image gitea/astrololo-data tag '9323803c' to 'c75f8377'
updates image gitea/astrololo-logic tag '9323803c' to 'c75f8377'
updates image gitea/astrololo-presentation tag '9323803c' to 'c75f8377'
gitea
argocd-image-updater