1d5bd27cdc
Zastępuje gałąź feat/astroklient. Tamta była odbita od mastera sprzed jedenastu commitów i miała przypięte obrazy `ee3c515d`, podczas gdy master stoi na `320a0ab2` — merge w tamtej postaci COFNĄŁBY klaster o kilka wersji. Zamiast przepychać cztery commity przez rebase (każdy konfliktował na README), gałąź jest odtworzona jednym commitem na aktualnym masterze, z zachowanymi tagami. ZMIANA NAZWY. astroklient-demo → astrodemo, wraz z nazwą obrazu, zmiennymi (ASTRODEMO_USERS) i sekretem (astrololo-astrodemo). Nazwa „astroklient" jest zarezerwowana dla warstwy pośredniej: pełne funkcje astrologiczne, bez generowania tekstu i bez administracji. BRAKOWAŁO WEJŚCIA Z ZEWNĄTRZ. Manifesty tworzyły Deployment i Service, ale żadnej reguły w Ingressie — usługa wstałaby i nie dałoby się do niej wejść. Dołożony host astrodemo.czernobog.pl z przekierowaniem z http, a certyfikat obejmuje teraz oba hosty. Osobny host, a nie ścieżka `/demo` pod adresem astrololo, CELOWO: ścieżka dzieliłaby z pełną aplikacją pochodzenie w rozumieniu przeglądarki, czyli i ciasteczka — wejście do jednej ruszałoby sesję w drugiej. OBRAZ NA LIŚCIE OBSERWOWANYCH. Bez wpisu w image-updater.yaml obraz nigdy się nie podbije, choćby CI go budowało. Tak przez chwilę wisiał render na :latest. POPRAWKI W RUNBOOKU. Opis twierdził, że demo pracuje na produkcyjnej warstwie danych — nieprawda od PRE-29, ma własny stos i własny udział. Ponadto zmiana nazw rozjechała ścieżkę udziału: `zfs create Tank1/astrololo-astrodemo` przy manifeście montującym `/mnt/Tank1/astrololo-demo` utworzyłby inny zbiór niż ten, którego pod szuka. Ścieżka jest stanem na dysku, nie nazwą w kodzie — zostaje jak była. Sprawdzone: `kubectl kustomize astrololo/` buduje 29 obiektów, tagi obrazów pozostają na 320a0ab2. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
198 lines
6.4 KiB
Markdown
198 lines
6.4 KiB
Markdown
# astrodemo — wdrożenie wersji demo (PRE-28/29)
|
|
|
|
Osobna usługa o dwóch funkcjach: **dodanie pliku bazy** i **zapytanie o
|
|
interpretację urodzeniową**. Opis aplikacji: `services/astrodemo/README.md`
|
|
w repo aplikacji.
|
|
|
|
---
|
|
|
|
## Jak to jest odizolowane
|
|
|
|
```
|
|
astrodemo → logic-demo → data-demo → /mnt/Tank1/astrololo-demo
|
|
└── klientA/ ← pula konta
|
|
└── klientB/ ← pula konta
|
|
```
|
|
|
|
**Oryginalne bazy są dla demo nieosiągalne.** Nie chodzi o uprawnienia: demo ma
|
|
własną warstwę danych, pracującą na osobnym udziale, pustym na starcie.
|
|
|
|
Dlaczego osobna jest też **warstwa logiczna**: zna ona jeden adres warstwy danych,
|
|
więc astrodemo korzystający z produkcyjnej logiki i tak trafiłby na produkcyjne
|
|
bazy. Izolacja musi sięgnąć obu warstw naraz, inaczej nie ma jej wcale.
|
|
|
|
**Każde konto ma własną pulę** — swój podkatalog na tym udziale. Konta nie widzą
|
|
swoich plików nawzajem ani w liście, ani w wynikach wyszukiwania. Pula bierze się
|
|
z **loginu zalogowanej osoby**, nigdy z pola formularza.
|
|
|
|
---
|
|
|
|
## Krok 1 — udział `astrololo-demo` na TrueNAS
|
|
|
|
Ta sama procedura co przy `astrololo-state`, więc jeśli tamten działa, ten też
|
|
zadziała. Po SSH na NAS:
|
|
|
|
```bash
|
|
sudo zfs create Tank1/astrololo-demo # albo: sudo mkdir -p /mnt/Tank1/astrololo-demo
|
|
```
|
|
|
|
```bash
|
|
midclt call sharing.nfs.query '[["path","=","/mnt/Tank1/astrololo-demo"]]' \
|
|
| python3 -m json.tool
|
|
```
|
|
|
|
**Pusta lista `[]`** — twórz:
|
|
|
|
```bash
|
|
midclt call sharing.nfs.create '{
|
|
"path": "/mnt/Tank1/astrololo-demo",
|
|
"comment": "astrololo — pule kont wersji demo (PRE-29)",
|
|
"hosts": ["192.168.1.73", "192.168.1.80", "192.168.1.81"],
|
|
"enabled": true,
|
|
"ro": false,
|
|
"mapall_user": "root",
|
|
"mapall_group": "root"
|
|
}'
|
|
```
|
|
|
|
**Coś zwróciło** — weź `id` i użyj `sharing.nfs.update <ID>` z tą samą treścią.
|
|
|
|
```bash
|
|
midclt call service.restart nfs
|
|
sudo exportfs -v | grep astrololo-demo
|
|
```
|
|
|
|
Musi tam być `rw`. Sprawdź jeszcze zapis z węzła — to jest ten test, którego
|
|
zabrakło przy poprzednim udziale:
|
|
|
|
```bash
|
|
ssh <węzeł> 'sudo mkdir -p /mnt/t && sudo mount -t nfs 192.168.1.34:/mnt/Tank1/astrololo-demo /mnt/t \
|
|
&& sudo touch /mnt/t/proba && echo ZAPIS-OK || echo ZAPIS-NIE; sudo rm -f /mnt/t/proba; sudo umount /mnt/t'
|
|
```
|
|
|
|
---
|
|
|
|
## Krok 2 — konta demo
|
|
|
|
Każde konto to osobna pula, więc **rozdajesz konta, nie jedno hasło**.
|
|
|
|
Hasła najlepiej jako hash — wtedy nie leżą nigdzie jawnie (skrypt jest w repo
|
|
aplikacji, `services/presentation/scripts/make_user.py`):
|
|
|
|
```bash
|
|
python scripts/make_user.py klientA # wypisze: scrypt$…
|
|
python scripts/make_user.py klientB
|
|
```
|
|
|
|
```bash
|
|
kubectl -n astrololo create secret generic astrololo-astrodemo \
|
|
--from-literal=ASTRODEMO_USERS='klientA:scrypt$…,klientB:scrypt$…' \
|
|
--from-literal=SESSION_SECRET="$(openssl rand -hex 32)"
|
|
```
|
|
|
|
`SESSION_SECRET` podpisuje ciasteczka sesji (LOG-34). **Pod bez niego celowo nie
|
|
wstanie.** Jest WŁASNY, nie ten z pełnej aplikacji: demo i produkcja nie mają
|
|
powodu uznawać nawzajem swoich sesji.
|
|
|
|
> **Zdalne unieważnienie w demo działa inaczej niż w pełnej wersji.** Demo nie ma
|
|
> własnego wolumenu, więc nie ma gdzie trzymać licznika sesji. Zamiast tego:
|
|
> usunięcie konta z `ASTRODEMO_USERS` albo zmiana jego hasła **natychmiast ubija jego
|
|
> otwarte sesje** — bo odcisk poświadczenia wpisany w ciasteczko przestaje pasować.
|
|
> Rotacja `SESSION_SECRET` wylogowuje wszystkich naraz.
|
|
|
|
### Dodanie konta później
|
|
|
|
```bash
|
|
STARE=$(kubectl -n astrololo get secret astrololo-astrodemo -o jsonpath='{.data.ASTRODEMO_USERS}' | base64 -d)
|
|
|
|
kubectl -n astrololo create secret generic astrololo-astrodemo \
|
|
--from-literal=ASTRODEMO_USERS="${STARE},klientC:scrypt\$…" \
|
|
--dry-run=client -o yaml | kubectl apply -f -
|
|
|
|
kubectl -n astrololo rollout restart deploy/astrodemo
|
|
```
|
|
|
|
### Odebranie dostępu
|
|
|
|
Usuń wpis z `ASTRODEMO_USERS` tą samą drogą. **Pula zostaje na udziale** — pliki
|
|
klienta nie znikają, tylko przestaje być komu je pokazywać.
|
|
|
|
---
|
|
|
|
## Krok 3 — wdrożenie
|
|
|
|
```bash
|
|
kubectl apply -k astrololo
|
|
kubectl -n astrololo rollout status deploy/data-demo deploy/logic-demo deploy/astrodemo
|
|
```
|
|
|
|
Sprawdzenie na czas jednej sesji, bez wystawiania na świat:
|
|
|
|
```bash
|
|
kubectl -n astrololo port-forward deploy/astrodemo 8005:8005
|
|
```
|
|
|
|
Wejście z zewnątrz jest już w `ingress.yaml`: host **astrodemo.czernobog.pl**,
|
|
z przekierowaniem z http na https i tym samym certyfikatem co astrololo
|
|
(`tls.yaml` obejmuje oba hosty).
|
|
|
|
Osobny host, a nie ścieżka `/demo` pod adresem astrololo — CELOWO. Ścieżka
|
|
dzieliłaby z pełną aplikacją pochodzenie w rozumieniu przeglądarki, czyli
|
|
i ciasteczka: wejście do jednej ruszałoby sesję w drugiej.
|
|
|
|
Pozostaje wpis DNS: **astrodemo.czernobog.pl musi wskazywać na ten sam adres co
|
|
astrololo.czernobog.pl**. Bez tego Traefik nigdy nie zobaczy żądania.
|
|
**Celowo nie zakładam tego za Ciebie**: to decyzja, pod jakim adresem świat
|
|
zobaczy demo.
|
|
|
|
---
|
|
|
|
## Import puli klienta do pełnej aplikacji
|
|
|
|
Sedno całego układu: klient, który przechodzi na pełną wersję, **nie traci
|
|
dotychczasowych wgrań**. Jego pula to jeden katalog.
|
|
|
|
**1. Zobacz, co tam jest** (na NAS):
|
|
|
|
```bash
|
|
LOGIN=klientA
|
|
sudo ls -la /mnt/Tank1/astrololo-demo/$LOGIN/
|
|
```
|
|
|
|
**2. Sprawdź kolizje nazw** z bazami produkcyjnymi:
|
|
|
|
```bash
|
|
comm -12 \
|
|
<(cd /mnt/Tank1/astrololo-demo/$LOGIN && ls *.xlsx 2>/dev/null | sort) \
|
|
<(cd /mnt/Tank1/astrololo && ls *.xlsx 2>/dev/null | sort)
|
|
```
|
|
|
|
Pusto = brak kolizji. Cokolwiek się wypisze, przenieś ręcznie pod inną nazwą —
|
|
**nie nadpisuj bazy produkcyjnej**.
|
|
|
|
**3. Skopiuj** (`-n` = nie nadpisuj niczego, co już jest):
|
|
|
|
```bash
|
|
sudo cp -n /mnt/Tank1/astrololo-demo/$LOGIN/*.xlsx /mnt/Tank1/astrololo/
|
|
```
|
|
|
|
> Kopiujemy **tylko pliki `.xlsx`**. Plik `.files-state.json` zostaje — opisuje
|
|
> stan wewnątrz puli demo i w produkcji nie ma sensu; produkcja ma własny.
|
|
|
|
**4. Włącz je w pełnej aplikacji**: zakładka **Pliki**, nowe bazy pojawią się jako
|
|
„gotowa, odstawiona". Klikasz przełącznik przy tych, które mają wejść do użytku.
|
|
|
|
To, że nie włączają się same, jest zamierzone: przeniesienie plików jest czynnością
|
|
techniczną, a decyzja, które bazy biorą udział w interpretacji, należy do Ciebie.
|
|
|
|
---
|
|
|
|
## Odcięcie całego demo
|
|
|
|
```bash
|
|
kubectl -n astrololo scale deploy/astrodemo --replicas=0
|
|
```
|
|
|
|
Pule i dane zostają. Skasowanie sekretu `astrololo-astrodemo` zatrzyma pod (nie wstanie
|
|
bez niego) i to też jest zachowanie zamierzone.
|