gitea
82c73f6aa5
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>
87 lines
2.5 KiB
Markdown
87 lines
2.5 KiB
Markdown
# 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.
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
cd services/presentation && python scripts/make_user.py demo # w repo aplikacji
|
|
```
|
|
|
|
---
|
|
|
|
## Krok 2 — wdrożenie
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
kubectl -n astrololo port-forward deploy/astroklient 8005:8005
|
|
```
|
|
|
|
i `http://localhost:8005` — login `demo`, hasło z kroku 1.
|
|
|
|
---
|
|
|
|
## Odcięcie demo
|
|
|
|
```bash
|
|
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.
|