Files
deploy/astrololo/README-astroklient.md
T
gitea 82c73f6aa5 feat(astroklient): wdrożenie wersji demonstracyjnej (PRE-28)
Deployment + Service (ClusterIP), wpięcie w kustomization, obraz dopisany do
image-updatera i runbook.

Obraz na liście image-updatera CELOWO od razu: obraz, którego tam nie ma, nigdy
się nie podbije, choćby CI go budowało — tak przez chwilę wisiał render na :latest.

Token międzywarstwowy i klucz łącza brane z TYCH SAMYCH sekretów co prezentacja:
demo nie jest furtką omijającą ochronę warstwy logicznej. Hasło demo natomiast
z OSOBNEGO sekretu astrololo-demo — demo odcina się jego skasowaniem, bez ruszania
kont głównej aplikacji.

Limit żądań niższy niż w pełnej aplikacji (60/min): demo bywa udostępniane szerzej,
a każde zapytanie sięga do treści baz.

Runbook zaczyna się od ostrzeżenia, bo to jedyna rzecz, którą trzeba pamiętać za
każdym razem: demo pracuje na PRODUKCYJNEJ warstwie danych, więc kto dostaje adres,
czyta oryginalne bazy, a jego wgrania trafiają do produkcyjnego zbioru. Pełna
izolacja wymagałaby osobnej warstwy danych i nie jest dziś zrobiona.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-17 18:39:48 +02:00

2.5 KiB

astroklient — wdrożenie wersji demo (PRE-28)

Osobna usługa o dwóch funkcjach: dodanie pliku bazy i zapytanie o interpretację urodzeniową. Opis samej aplikacji: services/astroklient/README.md w repo aplikacji.


⚠️ Przeczytaj, zanim komuś dasz adres

Demo pracuje na produkcyjnej warstwie danych. To była świadoma decyzja, ale niesie dwie konsekwencje, o których trzeba pamiętać za każdym razem:

  • kto ma dostęp do demo, czyta Twoje oryginalne bazy interpretacyjne — czyli rdzeń produktu, którego pilnują LOG-32, DAN-25 i PRE-27,
  • pliki wgrane przez demo trafiają do produkcyjnego zbioru i od razu biorą udział w wyszukiwaniu, także w pełnej aplikacji.

Jeśli demo ma trafić do kogoś spoza kręgu zaufania, właściwą odpowiedzią jest osobna warstwa danych z pustym udziałem — nie jest to dziś zrobione.


Krok 1 — sekret z hasłem demo

Osobny sekret, nie astrololo-auth. Dzięki temu demo odcina się jedną komendą, bez ruszania kont głównej aplikacji i bez zmiany hasła komukolwiek.

read -rs -p "Hasło do demo (DEMO_PASSWORD): " DEMO; echo

kubectl -n astrololo create secret generic astrololo-demo \
  --from-literal=DEMO_PASSWORD="$DEMO"

unset DEMO

Login to demo (zmienny przez DEMO_USER w astroklient.yaml).

Hasło może być też hashem scrypt$… — wtedy nie leży nigdzie jawnie:

cd services/presentation && python scripts/make_user.py demo   # w repo aplikacji

Krok 2 — wdrożenie

kubectl apply -k astrololo
kubectl -n astrololo rollout status deploy/astroklient

Image-updater ma astroklienta na liście, więc kolejne obrazy podbiją się same.


Krok 3 — wejście z zewnątrz

Usługa jest ClusterIP; z zewnątrz wchodzi się wyłącznie przez Ingress po https, tak samo jak do prezentacji. Dopisz regułę do ingress.yaml — osobny host albo ścieżka, zależnie od tego, jak chcesz demo udostępniać.

Na czas sprawdzenia wystarczy tunel:

kubectl -n astrololo port-forward deploy/astroklient 8005:8005

i http://localhost:8005 — login demo, hasło z kroku 1.


Odcięcie demo

kubectl -n astrololo delete secret astrololo-demo
kubectl -n astrololo rollout restart deploy/astroklient

Uwaga: pod bez sekretu nie wstanie i to jest zachowanie zamierzone. Alternatywnie kubectl -n astrololo scale deploy/astroklient --replicas=0, jeśli chcesz tylko wyłączyć, zachowując konfigurację.

Konta głównej aplikacji pozostają nietknięte w obu przypadkach.