Compare commits

...

42 Commits

Author SHA1 Message Date
gitea 86849c8160 Libr 2026-07-28 13:18:37 +02:00
gitea 3df1170f5d chore(astrololo): manifest CRD image-updater w repo (ślad tego, co śledzimy)
Konfiguracja argocd-image-updater istniała tylko w klastrze (ręczne `kubectl
apply`, brak w git). Skutkiem był PRE-24: `render` zbudował się i zdeployował raz,
ale kolejne buildy nie schodziły — bo nie było go na JAWNEJ liście obserwowanych
obrazów CRD, a nigdzie nie dało się tego podejrzeć ani odtworzyć.

Zrzucam manifest (z `render` już w środku, 4 obrazy: data/logic/presentation/
render) do `astrololo/image-updater.yaml` + opis w README.

Plik CELOWO nie jest w kustomization.yaml: resource stoi w ns `argocd` (poza
namespace docelowym aplikacji), a to konfiguracja kontrolera wdrażającego tę
aplikację — nakładany ręcznie (`kubectl apply -f astrololo/image-updater.yaml`),
w repo dla odtwarzalności i historii. Dodanie nowej usługi = dopisanie wpisu tutaj.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-26 00:02:53 +02:00
argocd-image-updater 39185c128b build: automatic update of astrololo
updates image gitea/astrololo-data tag '171deff2' to '623603b1'
updates image gitea/astrololo-logic tag '171deff2' to '623603b1'
updates image gitea/astrololo-presentation tag '171deff2' to '623603b1'
2026-07-25 19:08:50 +00:00
argocd-image-updater 3fe5c33366 build: automatic update of astrololo
updates image gitea/astrololo-data tag '15964dd0' to '171deff2'
updates image gitea/astrololo-logic tag '15964dd0' to '171deff2'
updates image gitea/astrololo-presentation tag '15964dd0' to '171deff2'
2026-07-25 16:33:55 +00:00
argocd-image-updater a38c6d2fc6 build: automatic update of astrololo
updates image gitea/astrololo-data tag 'f24616d3' to '15964dd0'
updates image gitea/astrololo-logic tag 'f24616d3' to '15964dd0'
updates image gitea/astrololo-presentation tag 'f24616d3' to '15964dd0'
2026-07-25 15:07:14 +00:00
gitea 57d0cca6f9 feat(astrololo): usluga render — raport PDF (PRE-24)
Nowy komponent skladajacy raport PDF. Osobny obraz, bo dzwiga TeX Live (setki MB)
— ta sama zasada co przy izolacji swissepha (LOG-27): obraz produktu zostaje maly,
TeX aktualizuje sie niezaleznie, a awaria renderu nie kladzie aplikacji, tylko
przycisk „Pobierz PDF".

- render.yaml — Deployment + Service. ClusterIP, BEZ NodePortu i Ingressu: nie ma
  powodu, zeby ktokolwiek siegal do tej uslugi z zewnatrz. Rozmawia wylacznie
  z prezentacja.
- Szyfrowanie: wlasny, TRZECI klucz LINK_KEY_PRESENTATION_RENDER z sekretu
  astrololo-link. Osobny, bo tym laczem plynie CALY raport (dane urodzeniowe
  i opisy z baz) — przejecie go nie moze otwierac lacza do logiki ani danych.
  LINK_ENCRYPTION_REQUIRED=true, wiec bez klucza pod NIE wstaje.
- readOnlyRootFilesystem + emptyDir na /tmp: kompilacja pisze tylko do katalogu
  tymczasowego, raport nie zostawia sladu w kontenerze.
- Limity rozjechane celowo (100m/256Mi -> 1500m/1Gi): XeLaTeX na obszernym
  raporcie bierze duzo, ale na krotko.
- presentation: RENDER_URL + trzeci klucz lacza.

Sekret astrololo-link trzeba UZUPELNIC o trzeci klucz PRZED wdrozeniem,
zachowujac dwa dotychczasowe — komenda w instrukcji.

Sprawdzone: kubectl kustomize + apply --dry-run=server na zywym klastrze
(service/render i deployment.apps/render created).

Pelna instrukcja: docs/wdrozenie-render-pdf.md w repo astrololo.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-25 15:09:27 +02:00
argocd-image-updater d137a49e28 build: automatic update of astrololo
updates image gitea/astrololo-data tag 'f34016a4' to 'f24616d3'
updates image gitea/astrololo-logic tag 'f34016a4' to 'f24616d3'
updates image gitea/astrololo-presentation tag '6c9029c4' to 'f24616d3'
2026-07-25 11:27:32 +00:00
argocd-image-updater e26d888c01 build: automatic update of astrololo
updates image gitea/astrololo-presentation tag '8cc329ab' to '6c9029c4'
2026-07-24 19:22:23 +00:00
argocd-image-updater db0c9b16e6 build: automatic update of astrololo
updates image gitea/astrololo-presentation tag '76fbdefe' to '8cc329ab'
2026-07-24 19:08:14 +00:00
argocd-image-updater 71dd1b24c3 build: automatic update of astrololo
updates image gitea/astrololo-presentation tag 'f34016a4' to '76fbdefe'
2026-07-24 18:21:46 +00:00
argocd-image-updater 9ced57af74 build: automatic update of astrololo
updates image gitea/astrololo-data tag 'f1956a08' to 'f34016a4'
updates image gitea/astrololo-logic tag '40c9bf79' to 'f34016a4'
updates image gitea/astrololo-presentation tag '40c9bf79' to 'f34016a4'
2026-07-24 16:28:32 +00:00
argocd-image-updater 385b675e27 build: automatic update of astrololo
updates image gitea/astrololo-logic tag '1d7f3e21' to '40c9bf79'
updates image gitea/astrololo-presentation tag '1d7f3e21' to '40c9bf79'
2026-07-24 14:37:55 +00:00
argocd-image-updater 240d79f8b2 build: automatic update of astrololo
updates image gitea/astrololo-logic tag 'ace76183' to '1d7f3e21'
updates image gitea/astrololo-presentation tag 'ace76183' to '1d7f3e21'
2026-07-24 12:34:55 +00:00
argocd-image-updater 37ea8d6997 build: automatic update of astrololo
updates image gitea/astrololo-logic tag 'f1956a08' to 'ace76183'
updates image gitea/astrololo-presentation tag 'f1956a08' to 'ace76183'
2026-07-24 11:04:20 +00:00
argocd-image-updater 86ea5b6147 build: automatic update of astrololo
updates image gitea/astrololo-data tag 'e8f868e9' to 'f1956a08'
updates image gitea/astrololo-logic tag 'e8f868e9' to 'f1956a08'
updates image gitea/astrololo-presentation tag 'e8f868e9' to 'f1956a08'
2026-07-23 21:01:53 +00:00
argocd-image-updater 9d5f318272 build: automatic update of astrololo
updates image gitea/astrololo-data tag '56fdf01d' to 'e8f868e9'
updates image gitea/astrololo-logic tag '56fdf01d' to 'e8f868e9'
updates image gitea/astrololo-presentation tag '56fdf01d' to 'e8f868e9'
2026-07-23 20:39:41 +00:00
gitea a075f9555f feat(astrololo): klucze szyfrowania lacz miedzy warstwami (PRE-16)
Domyka PRE-16 po stronie manifestow. Kod (astrololo#21) potrafi juz szyfrowac
ruch miedzy warstwami AES-256-GCM; tu dokladamy klucze i wymuszenie.

- astrololo-link: nowy sekret z dwoma kluczami (LINK_KEY_PRESENTATION_LOGIC,
  LINK_KEY_LOGIC_DATA), tworzony POZA repo jak pozostale. Osobny klucz na pare
  rozmowcow: przejecie klucza prezentacji nie otwiera warstwy danych. Logika
  bierze oba, prezentacja i dane wylacznie swoj (secretKeyRef).
- LINK_ENCRYPTION_REQUIRED=true we wszystkich trzech: bez klucza pod NIE wstaje,
  a klient nie wysyla niczego. Fail-closed w obie strony jest celowy — usluga,
  ktora wstala i po cichu nie szyfruje, jest gorsza niz CrashLoop, bo awarii
  nie widac.

README: sekcja o sekrecie astrololo-link (tworzenie, wymiana, restart calej
trojki naraz) oraz uczciwa nota, ze szyfrowane sa ciala, nie naglowki — sciezka
i token jada czytelnie, ale sam token bez klucza nic nie daje.

Sprawdzone: kubectl kustomize + apply --dry-run=server przechodza dla obu
profili. Pelna instrukcja wdrozenia: docs/wdrozenie-pre16.md w repo astrololo.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 16:40:43 +00:00
gitea 2d30d9a84d feat(astrololo): wejscie po https z wlasnym CA (PRE-16)
Do tej pory aplikacja chodzila po zwyklym http, a logowanie szlo przez HTTP
Basic — czyli haslo leciało siecia w postaci trywialnej do podsluchania.

Poza bezpieczenstwem TLS naprawia DWIE funkcje zepsute dzis z tego samego
powodu: geolokalizacja przegladarki („Tu i teraz") i kopiowanie promptu do
schowka dzialaja wylacznie w secure context, wiec po http po prostu odmawialy.

Wlasne CA, nie Let's Encrypt — klaster stoi w LAN (traefik trzyma LoadBalancera
na 192.168.1.x), wiec walidacja HTTP-01 nie ma jak dojsc z internetu, a DNS-01
wymagalby trzymania w klastrze tokena API do domeny.

Co dochodzi:
- tls.yaml — Issuer selfSigned -> korzen CA (10 lat, importowany raz do
  przegladarki) -> Issuer CA -> certyfikat serwera (90 dni, odnawiany sam).
  Krotki termin certyfikatu serwera jest CELOWY: odnawianie sprawdza sie wtedy
  co kwartal, a nie dopiero za dekade.
- ingress.yaml — wejscie po https + naglowki (HSTS rok, nosniff, frameDeny)
  oraz osobny Ingress na porcie 80 robiacy przekierowanie. Rozdzielone
  swiadomie: gdyby redirect wisial na tym samym routerze co wejscie po https,
  odsylalby sam do siebie w kolko.
- presentation: Service NodePort -> ClusterIP. NodePort byl druga,
  nieszyfrowana droga do aplikacji, czyli obejsciem calego PRE-16.

Zmiana wymagajaca uwagi: TRUST_PROXY=true. Za Ingressem bezposrednim rozmowca
jest zawsze pod Traefika, wiec bez tego limit zadan liczylby WSZYSTKICH do
jednego wiadra i pierwsza osoba, ktora go wyklika, odcielaby pozostalych.

Sprawdzone: Ingress i Middleware przechodza `kubectl apply --dry-run=server`
na zywym klastrze (CRD traefik.io/v1alpha1 sa, entrypointy web/websecure sa).
Obiekty cert-managera zwalidowane offline wobec oficjalnego schematu z CRD
v1.21.0 z additionalProperties=false — literowka w nazwie pola zostalaby
zlapana. `kubectl kustomize` przechodzi dla obu profili (bazowego i swisseph).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 16:40:43 +00:00
argocd-image-updater 6c41782b4b build: automatic update of astrololo
updates image gitea/astrololo-logic tag '473d059a' to '56fdf01d'
updates image gitea/astrololo-presentation tag '473d059a' to '56fdf01d'
2026-07-23 15:53:47 +00:00
argocd-image-updater 5096aa98c0 build: automatic update of astrololo
updates image gitea/astrololo-data tag '929b6912' to '56fdf01d'
2026-07-23 15:51:41 +00:00
argocd-image-updater d74e2af355 build: automatic update of astrololo
updates image gitea/astrololo-logic tag '929b6912' to '473d059a'
updates image gitea/astrololo-presentation tag '929b6912' to '473d059a'
2026-07-23 13:36:47 +00:00
argocd-image-updater ffa617e17b build: automatic update of astrololo
updates image gitea/astrololo-data tag '877ec91f' to '929b6912'
updates image gitea/astrololo-logic tag '114b7eeb' to '929b6912'
updates image gitea/astrololo-presentation tag '114b7eeb' to '929b6912'
2026-07-23 13:10:29 +00:00
argocd-image-updater 07a536a315 build: automatic update of astrololo
updates image gitea/astrololo-logic tag '163ace42' to '114b7eeb'
updates image gitea/astrololo-presentation tag '163ace42' to '114b7eeb'
2026-07-23 11:57:48 +00:00
argocd-image-updater affd8b60ff build: automatic update of astrololo
updates image gitea/astrololo-presentation tag '877ec91f' to '163ace42'
2026-07-22 20:31:22 +00:00
argocd-image-updater 584340b82d build: automatic update of astrololo
updates image gitea/astrololo-logic tag '877ec91f' to '163ace42'
2026-07-22 20:29:16 +00:00
argocd-image-updater 570f879c77 build: automatic update of astrololo
updates image gitea/astrololo-data tag '752f477a' to '877ec91f'
updates image gitea/astrololo-logic tag '5203ba9e' to '877ec91f'
updates image gitea/astrololo-presentation tag '64d1afc7' to '877ec91f'
2026-07-22 19:18:28 +00:00
gitea 90bfff18df feat(astrololo): klucze do modeli w chmurze + konfiguracja modelu lokalnego
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>
2026-07-22 15:34:57 +00:00
argocd-image-updater ef4ba6d83a build: automatic update of astrololo
updates image gitea/astrololo-logic tag '64d1afc7' to '5203ba9e'
2026-07-22 15:18:19 +00:00
argocd-image-updater 8af10ce98a build: automatic update of astrololo
updates image gitea/astrololo-logic tag '4ef90b30' to '64d1afc7'
updates image gitea/astrololo-presentation tag '4ef90b30' to '64d1afc7'
2026-07-21 22:15:54 +00:00
argocd-image-updater 6b98f566eb build: automatic update of astrololo
updates image gitea/astrololo-logic tag '73fd41b9' to '4ef90b30'
updates image gitea/astrololo-presentation tag '752f477a' to '4ef90b30'
2026-07-21 19:40:29 +00:00
argocd-image-updater a386674078 build: automatic update of astrololo
updates image gitea/astrololo-logic tag '04b26afa' to '73fd41b9'
updates image gitea/astrololo-presentation tag '04b26afa' to '752f477a'
2026-07-21 18:35:56 +00:00
argocd-image-updater 2594183c39 build: automatic update of astrololo
updates image gitea/astrololo-logic tag '04b26afa' to '752f477a'
updates image gitea/astrololo-presentation tag '04b26afa' to '752f477a'
2026-07-21 17:29:23 +00:00
argocd-image-updater 32b4387d5c build: automatic update of astrololo
updates image gitea/astrololo-data tag 'de5d5895' to '752f477a'
2026-07-21 17:27:21 +00:00
gitea 66d174703e 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 17:06:16 +00:00
argocd-image-updater fec8fae922 build: automatic update of astrololo
updates image gitea/astrololo-logic tag '6f87b2b3' to '04b26afa'
updates image gitea/astrololo-presentation tag '6f87b2b3' to '04b26afa'
2026-07-21 16:52:54 +00: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
16 changed files with 833 additions and 5 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"
+228
View File
@@ -0,0 +1,228 @@
# 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` (wejście z przeglądarki przez **Ingress po https**) →
`logic``data` (pliki Excel montowane **z NFS**, nie z obrazu).
Adres aplikacji: **https://astrololo.czernobog.pl** — patrz [TLS](#-tls--wymagane-kroki-przed-wdrożeniem).
## Co śledzi image-updater — [`image-updater.yaml`](image-updater.yaml)
Lista obrazów podbijanych automatycznie jest **jawna** i żyje w CRD `ImageUpdater`
(ns `argocd`). Obraz, którego na niej nie ma, **nigdy się nie podbije**, choćby CI
go budowało — tak przez chwilę wisiał `render` na `:latest`, zanim dopisaliśmy go do
listy. Dodając nową usługę, dopisz jej wpis w `image-updater.yaml` i nałóż:
```bash
kubectl apply -f astrololo/image-updater.yaml
```
Ten plik **celowo nie jest w `kustomization.yaml`**: resource stoi w ns `argocd`
(poza namespace docelowym aplikacji), a to konfiguracja kontrolera, który wdraża tę
aplikację — nakładamy go ręcznie, w repo trzymamy dla odtwarzalności i historii.
## ⚠️ 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
curl -s -o /dev/null -w "bez hasła: %{http_code}\n" https://astrololo.czernobog.pl/
curl -s -o /dev/null -w "z hasłem: %{http_code}\n" -u astrololo:'<hasło>' https://astrololo.czernobog.pl/
```
Oczekiwane: **401** bez hasła, **200** z hasłem. `/health` zostaje publiczny (sondy k8s).
## 🔒 TLS — wymagane kroki przed wdrożeniem
Do tej pory Basic Auth szedł siecią po zwykłym http, czyli **hasło dało się
podsłuchać** (base64 to nie szyfrowanie). Poza tym http blokował dwie funkcje,
bo przeglądarki udostępniają je wyłącznie w tzw. *secure context*:
**geolokalizacja** („Tu i teraz") i **kopiowanie do schowka**. Certyfikat załatwia
oba tematy naraz.
Certyfikat wystawia **własne CA** trzymane w klastrze (cert-manager). Let's Encrypt
odpada, bo klaster stoi w LAN — walidacja HTTP-01 nie ma jak do niego dojść z
internetu, a DNS-01 wymagałby trzymania tu tokena API do domeny.
**Kolejność ma znaczenie — oba kroki PRZED synchronizacją ArgoCD.**
### 1. cert-manager (jednorazowo, cały klaster)
```bash
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.21.0/cert-manager.yaml
kubectl -n cert-manager rollout status deploy/cert-manager deploy/cert-manager-webhook
```
Bez tego API odrzuci `Certificate` i `Issuer` jako nieznane rodzaje zasobów,
a ArgoCD pokaże aplikację jako niezsynchronizowaną.
### 2. DNS: `astrololo.czernobog.pl` → adres Traefika
```bash
kubectl -n kube-system get svc traefik -o jsonpath='{.status.loadBalancer.ingress[*].ip}'; echo
```
Wpis w routerze / lokalnym DNS-ie (albo doraźnie `/etc/hosts`). **Service
`presentation` jest teraz `ClusterIP`** — NodePort był drugą, nieszyfrowaną drogą
do aplikacji, więc został zdjęty. Zanim DNS zacznie odpowiadać, jedyne wejście to:
```bash
kubectl -n astrololo port-forward svc/presentation 8000:8000 # awaryjnie, http://localhost:8000
```
### 3. Zaufanie do własnego CA (raz na urządzenie)
Bez tego przeglądarka pokaże ostrzeżenie o certyfikacie. Korzeń ważny 10 lat,
więc import robisz raz:
```bash
kubectl -n astrololo get secret astrololo-ca -o jsonpath='{.data.ca\.crt}' \
| base64 -d > astrololo-ca.crt
# macOS — do systemowego zaufania (poprosi o hasło administratora)
sudo security add-trusted-cert -d -r trustRoot \
-k /Library/Keychains/System.keychain astrololo-ca.crt
# Linux (Debian/Ubuntu)
sudo cp astrololo-ca.crt /usr/local/share/ca-certificates/ && sudo update-ca-certificates
```
Firefox ma własny magazyn — tam import przez *Ustawienia → Prywatność →
Wyświetl certyfikaty → Organy certyfikacji*.
### Sprawdzenie samego TLS
```bash
# certyfikat wystawiony i gotowy
kubectl -n astrololo get certificate
# oczekiwane: astrololo-ca True, astrololo-tls True
# http odsyła na https
curl -sI http://astrololo.czernobog.pl/ | head -2 # 301 + Location: https://...
# HSTS obecny
curl -skI -u astrololo:'<hasło>' https://astrololo.czernobog.pl/ | grep -i strict-transport
```
### Odnawianie
Certyfikat serwera żyje 90 dni i odnawia się sam 30 dni przed końcem. Termin jest
krótki **celowo** — odnawianie sprawdza się wtedy w praktyce co kwartał, a nie
dopiero za dziesięć lat, gdy nikt nie będzie pamiętał, jak to było skonfigurowane.
## ⚠️ Sekret `astrololo-link` — szyfrowanie między warstwami
Token międzywarstwowy mówi **kto** pyta, ale nie ukrywa **czego dotyczy odpowiedź**
— a płyną nią surowe wiersze oryginalnych baz. Kto podsłuchał ruch wewnątrz sieci
(drugi pod, mirror portu na switchu, zrzut z węzła), miał je w całości. Łącza są
więc szyfrowane **AES-256-GCM**, osobnym kluczem na każdą parę rozmówców.
```bash
kubectl -n astrololo create secret generic astrololo-link \
--from-literal=LINK_KEY_PRESENTATION_LOGIC="$(openssl rand -hex 32)" \
--from-literal=LINK_KEY_LOGIC_DATA="$(openssl rand -hex 32)"
```
Kluczy **nikt nigdy nie musi oglądać** — służą tylko usługom. Rozdzielenie jest
celowe: przejęcie klucza prezentacji nie daje dostępu do warstwy danych, gdzie
leżą całe bazy. Logika trzyma oba, bo rozmawia w obie strony; prezentacja i dane
dostają przez `secretKeyRef` wyłącznie swój.
**Pody nie wstaną bez tych kluczy** (`LINK_ENCRYPTION_REQUIRED=true`) — i tak ma
być. Usługa, która wstała i po cichu nie szyfruje, jest gorsza niż pod w CrashLoop,
bo awarii nie widać.
### Wymiana kluczy
```bash
kubectl -n astrololo create secret generic astrololo-link \
--from-literal=LINK_KEY_PRESENTATION_LOGIC="$(openssl rand -hex 32)" \
--from-literal=LINK_KEY_LOGIC_DATA="$(openssl rand -hex 32)" \
--dry-run=client -o yaml | kubectl apply -f -
kubectl -n astrololo rollout restart deploy/presentation deploy/logic deploy/data
```
Restart **wszystkich trzech naraz** — w trakcie wymiany warstwy chwilowo się nie
dogadują (klucze muszą być zgodne po obu stronach łącza).
## Klucze do modeli w chmurze — sekret `astrololo-llm` (opcjonalny)
Domyślnie działa **model lokalny** i nic nie opuszcza sieci. Żeby móc wybrać w UI
OpenAI lub Anthropic, potrzebne są ich klucze. Ten sekret jest **opcjonalny**
(`optional: true`) — bez niego pody startują normalnie, tylko chmura jest niedostępna.
```bash
read -rs -p "OPENAI_API_KEY (Enter = pomiń): " OPENAI_KEY; echo
read -rs -p "ANTHROPIC_API_KEY (Enter = pomiń): " ANTHROPIC_KEY; echo
kubectl -n astrololo create secret generic astrololo-llm \
--from-literal=OPENAI_API_KEY="$OPENAI_KEY" \
--from-literal=ANTHROPIC_API_KEY="$ANTHROPIC_KEY"
unset OPENAI_KEY ANTHROPIC_KEY
kubectl -n astrololo rollout restart deploy/logic # klucze wstrzykują się przy starcie
```
Podmiana pojedynczego klucza (bez kasowania drugiego):
```bash
kubectl -n astrololo create secret generic astrololo-llm \
--from-literal=OPENAI_API_KEY="$(kubectl -n astrololo get secret astrololo-llm \
-o jsonpath='{.data.OPENAI_API_KEY}' | base64 -d)" \
--from-literal=ANTHROPIC_API_KEY='NOWY-KLUCZ' \
--dry-run=client -o yaml | kubectl apply -f -
kubectl -n astrololo rollout restart deploy/logic
```
**Adres modelu lokalnego** ustawia `LOCAL_BASE_URL` w `logic.yaml` — dopasuj do miejsca,
gdzie faktycznie stoi Ollama/vLLM. Konfiguracja jest **per dostawca**
(`LOCAL_*`, `OPENAI_*`, `ANTHROPIC_*`), więc ustawienia lokalnego modelu nie przejmują
żądań do chmury.
> Wybór dostawcy w chmurze oznacza, że **oryginalne opisy z baz opuszczają naszą sieć**.
> Prompt można obejrzeć przed wysłaniem. Warto zawnioskować u dostawcy o Zero Data
> Retention — patrz LOG-32.
## Czego to nie załatwia
- **Własne CA to nie to samo co publiczne zaufanie** — każde nowe urządzenie
wymaga importu korzenia (krok 3 powyżej). Gdyby aplikacja miała kiedyś wyjść
na świat, właściwą drogą jest Let's Encrypt przez DNS-01.
- **Szyfrowane są ciała żądań, nie nagłówki** — ścieżka (`/search`) i token
międzywarstwowy jadą czytelnie. Sam token nikomu nic nie daje: bez klucza łącza
każde żądanie kończy się odmową. Pełne ukrycie metadanych wymagałoby mTLS.
- **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`.
+18 -1
View File
@@ -18,11 +18,28 @@ spec:
- name: DATA_PROVIDER
value: "excel"
- 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
value: "/app/.cache"
- name: INDEXED_KEYS
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 }
# Szyfrowanie łącza między warstwami (PRE-16). OSOBNY klucz na każdą
# parę rozmówców: przejęcie klucza prezentacji nie otwiera warstwy
# danych, gdzie leżą całe bazy. Sekret tworzony POZA repo — patrz README.
- name: LINK_KEY_LOGIC_DATA
valueFrom:
secretKeyRef: { name: astrololo-link, key: LINK_KEY_LOGIC_DATA }
# Bez klucza usługa ma NIE wstać, a klient ma nie wysłać niczego.
# Sam serwer broni się fail-closed, ale to za mało: klient bez klucza
# zdążyłby wypuścić zapytanie jawnym tekstem, zanim dostanie odmowę.
- name: LINK_ENCRYPTION_REQUIRED
value: "true"
volumeMounts:
- name: cache
mountPath: /app/.cache
+44
View File
@@ -0,0 +1,44 @@
# Konfiguracja argocd-image-updater dla astrololo — ŹRÓDŁO PRAWDY tego, CO śledzimy.
#
# Model v1.x: osobny CRD `ImageUpdater` w ns `argocd` (nie adnotacje na Application).
# Lista `images` jest JAWNA — obraz, którego tu NIE MA, nigdy nie zostanie podbity,
# choćby CI go budowało. Tak przez chwilę wisiał `render` na `:latest` (PRE-24):
# usługa istniała i budowała tag SHA, ale updater jej nie znał, więc kustomization
# jej nie ruszał. Dopisanie wpisu = wejście usługi do rotacji.
#
# ⚠️ TEGO PLIKU NIE MA w astrololo/kustomization.yaml i NIE MA GO TAM MIEĆ:
# 1. resource żyje w ns `argocd`, a Application astrololo celuje w ns `astrololo`
# — auto-sync przez kustomize próbowałby zapisać poza swój namespace docelowy;
# 2. to konfiguracja kontrolera, który wdraża tę właśnie aplikację — niech app
# nie zarządza narzędziem, które ją wdraża.
# Plik jest trzymany w repo dla odtwarzalności i historii; nakłada się go RĘCZNIE:
# kubectl apply -f astrololo/image-updater.yaml
#
# Strategia `newest-build`: updater bierze obraz o NAJNOWSZYM znaczniku czasu builda
# i zapisuje jego tag SHA do kustomization (write-back git). Uwaga na reprodukowalne
# buildy — identyczny `created` na kilku tagach potrafi zablokować wybór najnowszego.
apiVersion: argocd-image-updater.argoproj.io/v1alpha1
kind: ImageUpdater
metadata:
name: astrololo
namespace: argocd
spec:
applicationRefs:
- namePattern: astrololo
images:
- alias: data
imageName: gitea.czernobog.pl/gitea/astrololo-data
- alias: logic
imageName: gitea.czernobog.pl/gitea/astrololo-logic
- alias: presentation
imageName: gitea.czernobog.pl/gitea/astrololo-presentation
- alias: render
imageName: gitea.czernobog.pl/gitea/astrololo-render
commonUpdateSettings:
updateStrategy: newest-build
writeBackConfig:
method: git:secret:argocd/git-creds
gitConfig:
repository: https://gitea.czernobog.pl/gitea/deploy.git
branch: master
writeBackTarget: kustomization:/astrololo
+75
View File
@@ -0,0 +1,75 @@
# Wejście do aplikacji po HTTPS (PRE-16).
#
# Poza bezpieczeństwem — Basic Auth po zwykłym http leci siecią czytelny dla
# każdego, kto słucha — TLS naprawia DWIE funkcje zepsute dziś z tego samego
# powodu: geolokalizacja przeglądarki („Tu i teraz") oraz kopiowanie promptu do
# schowka działają wyłącznie w tzw. secure context i po http po prostu odmawiają.
---
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
name: security-headers
namespace: astrololo
spec:
headers:
stsSeconds: 31536000 # HSTS: rok
stsIncludeSubdomains: false # dotyczy tylko tego hosta
stsPreload: false # preload to wpis na listę w przeglądarkach
# — praktycznie nieodwracalny, nie wchodzimy
forceSTSHeader: true # nagłówek także przy odpowiedziach z backendu
contentTypeNosniff: true
frameDeny: true
referrerPolicy: same-origin
---
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
name: redirect-https
namespace: astrololo
spec:
redirectScheme:
scheme: https
permanent: true
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: astrololo
namespace: astrololo
annotations:
traefik.ingress.kubernetes.io/router.entrypoints: websecure
traefik.ingress.kubernetes.io/router.middlewares: astrololo-security-headers@kubernetescrd
spec:
tls:
- hosts: [astrololo.czernobog.pl]
secretName: astrololo-tls # wypełnia cert-manager (tls.yaml)
rules:
- host: astrololo.czernobog.pl
http:
paths:
- path: /
pathType: Prefix
backend:
service: { name: presentation, port: { number: 8000 } }
---
# Osobny Ingress wyłącznie na porcie 80 — istnieje po to, żeby odesłać na https.
# Rozdzielone świadomie: gdyby przekierowanie wisiało na tym samym routerze, co
# wejście po https, odsyłałoby samo do siebie w kółko. Backend jest tu formalnością,
# bo żadne żądanie do niego nie dojdzie.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: astrololo-redirect
namespace: astrololo
annotations:
traefik.ingress.kubernetes.io/router.entrypoints: web
traefik.ingress.kubernetes.io/router.middlewares: astrololo-redirect-https@kubernetescrd
spec:
rules:
- host: astrololo.czernobog.pl
http:
paths:
- path: /
pathType: Prefix
backend:
service: { name: presentation, port: { number: 8000 } }
+8 -3
View File
@@ -5,10 +5,15 @@ resources:
- data.yaml
- logic.yaml
- presentation.yaml
- render.yaml # składanie raportu PDF (PRE-24), osobny obraz z TeX Live
- tls.yaml # certyfikat z własnego CA (wymaga cert-managera)
- ingress.yaml # wejście po https + przekierowanie z http
images:
- name: gitea.czernobog.pl/gitea/astrololo-data
newTag: c75f8377
newTag: 623603b1
- name: gitea.czernobog.pl/gitea/astrololo-logic
newTag: c75f8377
newTag: 623603b1
- name: gitea.czernobog.pl/gitea/astrololo-render
newTag: latest
- name: gitea.czernobog.pl/gitea/astrololo-presentation
newTag: c75f8377
newTag: 623603b1
+44
View File
@@ -20,6 +20,50 @@ spec:
- name: EPHEMERIS_ENGINE
value: "own" # silnik własny; swisseph pominięty
# 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 }
# Szyfrowanie łącza między warstwami (PRE-16). OSOBNY klucz na każdą
# parę rozmówców: przejęcie klucza prezentacji nie otwiera warstwy
# danych, gdzie leżą całe bazy. Sekret tworzony POZA repo — patrz README.
- name: LINK_KEY_PRESENTATION_LOGIC
valueFrom:
secretKeyRef: { name: astrololo-link, key: LINK_KEY_PRESENTATION_LOGIC }
- name: LINK_KEY_LOGIC_DATA
valueFrom:
secretKeyRef: { name: astrololo-link, key: LINK_KEY_LOGIC_DATA }
# Bez klucza usługa ma NIE wstać, a klient ma nie wysłać niczego.
# Sam serwer broni się fail-closed, ale to za mało: klient bez klucza
# zdążyłby wypuścić zapytanie jawnym tekstem, zanim dostanie odmowę.
- name: LINK_ENCRYPTION_REQUIRED
value: "true"
# --- Model językowy (LOG-31) ---
# Domyślnie LOKALNY: prompt niesie oryginalne opisy z baz, więc nic nie
# opuszcza sieci. Dostawcę można przełączyć w UI przy pojedynczym żądaniu.
- name: LLM_PROVIDER
value: "local"
- name: LOCAL_BASE_URL
value: "http://ollama.ollama.svc.cluster.local:11434/v1"
- name: LOCAL_MODEL
value: "llama3.1:8b"
- name: LLM_TIMEOUT
value: "180" # dłuższe horoskopy potrafią trwać
- name: LLM_MAX_TOKENS
value: "2000"
# Klucze do chmury — OPCJONALNE (optional: true), bo to funkcja, nie
# zabezpieczenie: bez sekretu pody startują normalnie i działa model
# lokalny. Wybór chmury w UI oznacza, że treść baz OPUSZCZA naszą sieć.
- name: OPENAI_API_KEY
valueFrom:
secretKeyRef: { name: astrololo-llm, key: OPENAI_API_KEY, optional: true }
- name: ANTHROPIC_API_KEY
valueFrom:
secretKeyRef: { name: astrololo-llm, key: ANTHROPIC_API_KEY, optional: true }
resources:
requests: { cpu: "100m", memory: "128Mi" }
limits: { cpu: "500m", memory: "512Mi" }
+43 -1
View File
@@ -17,6 +17,45 @@ spec:
env:
- name: LOGIC_URL
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
# Aplikacja stoi za Ingressem, więc bezpośrednim rozmówcą jest zawsze
# pod Traefika. Bez tego limit żądań liczyłby WSZYSTKICH do jednego
# wiadra i pierwsza osoba, która go wyklika, odcięłaby pozostałych.
# Włączać wyłącznie gdy ruch faktycznie idzie przez proxy — inaczej
# nagłówek staje się furtką do ominięcia limitu.
- name: TRUST_PROXY
value: "true"
# Szyfrowanie łącza między warstwami (PRE-16). OSOBNY klucz na każdą
# parę rozmówców: przejęcie klucza prezentacji nie otwiera warstwy
# danych, gdzie leżą całe bazy. Sekret tworzony POZA repo — patrz README.
- name: LINK_KEY_PRESENTATION_LOGIC
valueFrom:
secretKeyRef: { name: astrololo-link, key: LINK_KEY_PRESENTATION_LOGIC }
# Bez klucza usługa ma NIE wstać, a klient ma nie wysłać niczego.
# Sam serwer broni się fail-closed, ale to za mało: klient bez klucza
# zdążyłby wypuścić zapytanie jawnym tekstem, zanim dostanie odmowę.
# Usługa składająca PDF (PRE-24) — osobny komponent.
- name: RENDER_URL
value: "http://render:8004" # discovery po nazwie Service
# Trzeci klucz łącza: prezentacja ↔ render. Osobny, bo tym łączem
# idzie CAŁY raport (dane urodzeniowe + opisy z baz).
- name: LINK_KEY_PRESENTATION_RENDER
valueFrom:
secretKeyRef: { name: astrololo-link, key: LINK_KEY_PRESENTATION_RENDER }
- name: LINK_ENCRYPTION_REQUIRED
value: "true"
resources:
requests: { cpu: "100m", memory: "128Mi" }
limits: { cpu: "300m", memory: "256Mi" }
@@ -27,7 +66,10 @@ metadata:
name: presentation
namespace: astrololo
spec:
type: NodePort # wejście z przeglądarki
# Wejście z przeglądarki idzie teraz WYŁĄCZNIE przez Ingress po https
# (ingress.yaml). NodePort był drugą, nieszyfrowaną drogą do środka — czyli
# obejściem całego PRE-16 — więc znika.
type: ClusterIP
selector: { app: presentation }
ports: [{ port: 8000, targetPort: 8000 }]
+69
View File
@@ -0,0 +1,69 @@
# Usługa render — składanie raportu PDF (PRE-24).
#
# OSOBNY komponent, nie część prezentacji, z tego samego powodu co silnik
# swisseph (LOG-27): obraz dźwiga TeX Live, czyli setki megabajtów. W obrazie
# produktu spowalniałby każdy build i deploy; tak aktualizuje się niezależnie,
# a jego awaria nie kładzie aplikacji — psuje się tylko przycisk „Pobierz PDF".
#
# Rozmawia WYŁĄCZNIE z prezentacją, po szyfrowanym łączu z własnym, trzecim
# kluczem. Wystawiona jako ClusterIP — bez NodePort i bez Ingressu, bo nie ma
# powodu, żeby ktokolwiek sięgał do niej z zewnątrz.
apiVersion: apps/v1
kind: Deployment
metadata:
name: render
namespace: astrololo
spec:
replicas: 1
selector: { matchLabels: { app: render } }
template:
metadata: { labels: { app: render } }
spec:
imagePullSecrets: [{ name: gitea-registry }]
containers:
- name: render
image: gitea.czernobog.pl/gitea/astrololo-render:latest
ports: [{ containerPort: 8004 }]
env:
# Token międzywarstwowy (LOG-32) — ta usługa dostaje CAŁY raport:
# dane urodzeniowe i opisy z baz.
- name: INTERNAL_TOKEN
valueFrom:
secretKeyRef: { name: astrololo-auth, key: INTERNAL_TOKEN }
# Szyfrowanie łącza (PRE-16/PRE-24). OSOBNY klucz na parę rozmówców:
# przejęcie klucza renderu nie może otwierać łącza do logiki ani danych.
- name: LINK_KEY_PRESENTATION_RENDER
valueFrom:
secretKeyRef: { name: astrololo-link, key: LINK_KEY_PRESENTATION_RENDER }
- name: LINK_ENCRYPTION_REQUIRED
value: "true"
# XeLaTeX na obszernym raporcie potrafi zjeść sporo pamięci i CPU,
# ale tylko na chwilę — stąd wyraźna różnica między request a limit.
resources:
requests: { cpu: "100m", memory: "256Mi" }
limits: { cpu: "1500m", memory: "1Gi" }
# Kompilacja pisze wyłącznie do katalogu tymczasowego, który sprząta po
# sobie. Dajemy na to emptyDir i zamykamy resztę systemu plików —
# raport nie ma prawa zostawić śladu w kontenerze.
volumeMounts:
- { name: tmp, mountPath: /tmp }
securityContext:
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
readinessProbe:
httpGet: { path: /health, port: 8004 }
initialDelaySeconds: 5
periodSeconds: 15
volumes:
- name: tmp
emptyDir: { sizeLimit: 512Mi }
---
apiVersion: v1
kind: Service
metadata:
name: render
namespace: astrololo
spec:
type: ClusterIP # tylko dla prezentacji, bez wejścia z zewnątrz
selector: { app: render }
ports: [{ port: 8004, targetPort: 8004 }]
+65
View File
@@ -0,0 +1,65 @@
# Certyfikat dla wejścia do aplikacji (PRE-16).
#
# Dlaczego WŁASNE CA, a nie Let's Encrypt: klaster stoi w LAN (traefik trzyma
# LoadBalancera na 192.168.1.x), więc walidacja HTTP-01 nie ma jak dojść z
# internetu, a DNS-01 wymagałby trzymania w klastrze tokena API do domeny.
# Własne CA nie potrzebuje niczego z zewnątrz, a certyfikaty odnawia samo.
#
# WYMAGANIE WSTĘPNE: cert-manager musi być w klastrze PRZED synchronizacją tego
# katalogu — inaczej API odrzuci poniższe obiekty jako nieznane rodzaje zasobów.
# Instalacja jednorazowa: patrz README.md.
#
# Wszystko jest w namespace `astrololo` (Issuer, nie ClusterIssuer) świadomie:
# ArgoCD ma tu włączone `prune`, a zasoby o zasięgu całego klastra chcemy trzymać
# poza aplikacją, która może zostać skasowana.
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: selfsigned
namespace: astrololo
spec:
selfSigned: {}
---
# Korzeń zaufania. TO JEST certyfikat, który raz importujesz do przeglądarki
# i systemu — patrz README. Stąd długi termin ważności: importu nie chcemy
# powtarzać co kwartał.
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: astrololo-ca
namespace: astrololo
spec:
isCA: true
commonName: astrololo internal CA
secretName: astrololo-ca # tu lądują klucz i certyfikat korzenia
duration: 87600h # 10 lat
renewBefore: 8760h # odnowienie na rok przed końcem
privateKey: { algorithm: ECDSA, size: 256 }
issuerRef: { name: selfsigned, kind: Issuer, group: cert-manager.io }
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: astrololo-ca
namespace: astrololo
spec:
ca: { secretName: astrololo-ca }
---
# Właściwy certyfikat serwera. Krótki termin CELOWO: przy 90 dniach odnawianie
# jest sprawdzane w praktyce co kwartał, więc awaria wyjdzie od razu, a nie za
# dziesięć lat, gdy nikt już nie będzie pamiętał, jak to działa.
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: astrololo-tls
namespace: astrololo
spec:
secretName: astrololo-tls # tego szuka Ingress
commonName: astrololo.czernobog.pl
dnsNames:
- astrololo.czernobog.pl
duration: 2160h # 90 dni
renewBefore: 720h # 30 dni zapasu
privateKey: { algorithm: ECDSA, size: 256, rotationPolicy: Always }
issuerRef: { name: astrololo-ca, kind: Issuer, group: cert-manager.io }
+5
View File
@@ -0,0 +1,5 @@
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- namespace.yaml
- librarian.yaml
+48
View File
@@ -0,0 +1,48 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: librarian
namespace: conjurer
spec:
replicas: 1
selector: { matchLabels: { app: librarian } }
template:
metadata: { labels: { app: librarian } }
spec:
imagePullSecrets: [{ name: gitea-registry }]
containers:
- name: librarian
image: gitea.czernobog.pl/gitea/conjurer-librarian:v0.1.0
ports: [{ containerPort: 5001 }]
env:
- { name: CONJURER_LIBRARIAN_HOST, value: "0.0.0.0" }
- { name: CONJURER_LIBRARIAN_PORT, value: "5001" }
- { name: CONJURER_LIBRARIAN_DB_PATH, value: "/doi/" }
- { name: CONJURER_LIBRARIAN_STATE_DIR, value: "/lib_temp_files" }
volumeMounts:
- { name: doi, mountPath: /doi, readOnly: true }
- { name: state, mountPath: /lib_temp_files }
resources:
requests: { cpu: "100m", memory: "256Mi" }
limits: { cpu: "1", memory: "1Gi" }
volumes:
- name: doi
nfs:
server: 192.168.1.34
path: /mnt/Tank1/conjurer_doi
- name: state
persistentVolumeClaim: { claimName: librarian-state }
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata: { name: librarian-state, namespace: conjurer }
spec:
accessModes: [ReadWriteOnce]
resources: { requests: { storage: 1Gi } }
---
apiVersion: v1
kind: Service
metadata: { name: librarian, namespace: conjurer }
spec:
selector: { app: librarian }
ports: [{ port: 5001, targetPort: 5001 }]
+4
View File
@@ -0,0 +1,4 @@
apiVersion: v1
kind: Namespace
metadata:
name: conjurer