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