updates image gitea/astrololo-logic tag '73fd41b9' to '4ef90b30' updates image gitea/astrololo-presentation tag '752f477a' to '4ef90b30'
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 (NodePort, wejście z przeglądarki) → logic → data
(pliki Excel montowane z NFS, nie z obrazu).
⚠️ 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.
# 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
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
kubectl -n astrololo rollout status deploy/presentation deploy/logic deploy/data
NODE_PORT=$(kubectl -n astrololo get svc presentation -o jsonpath='{.spec.ports[0].nodePort}')
curl -s -o /dev/null -w "bez hasła: %{http_code}\n" http://<adres-noda>:$NODE_PORT/
curl -s -o /dev/null -w "z hasłem: %{http_code}\n" -u astrololo:'<hasło>' http://<adres-noda>:$NODE_PORT/
Oczekiwane: 401 bez hasła, 200 z hasłem. /health zostaje publiczny (sondy k8s).
Czego to nie załatwia
- Brak TLS — Basic Auth idzie po sieci w postaci łatwej do podsłuchania. Przy niezaufanej sieci potrzebny ingress z certyfikatem.
- 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/.
Dziedziczy powyższe zmienne z tej bazy, więc też wymaga sekretu astrololo-auth.