astroklient: wdrożenie warstwy pośredniej z własnym stosem danych (5/5) #26

2026-08-27T14:10:36Z

gitea commented

2026-08-27 14:10:36 +00:00

Domyka drabinę produktów: astrodemo (dwie funkcje) → astroklient → astrololo.

Host astroklient.czernobog.pl · obraz astrololo-astroklient · port 8006.

⚠️ ZANIM ZMERGUJESZ

Dwie rzeczy muszą istnieć wcześniej, inaczej pody nie wstaną:

1. Udział NFS — ze wszystkimi czterema węzłami:

midclt call sharing.nfs.create '{
  "path": "/mnt/Tank1/astrololo-klient",
  "hosts": ["192.168.1.73", "192.168.1.80", "192.168.1.81", "192.168.1.82"],
  "maproot_user": "root", "maproot_group": "root", "enabled": true
}'
midclt call service.restart nfs

2. Sekret z kontami — pod bez SESSION_SECRET celowo nie wstanie:

kubectl -n astrololo create secret generic astrololo-astroklient \
  --from-literal=ASTROKLIENT_USERS='klientA:scrypt$…' \
  --from-literal=SESSION_SECRET="$(openssl rand -hex 32)"

Hashe: python services/presentation/scripts/make_user.py klientA w repo aplikacji.

Własny stos, nie wspólny

Zgodnie z Twoją decyzją: nowa para data-astroklient + logic-astroklient i nowy udział /mnt/Tank1/astrololo-klient.

Pule kont izolują klientów od siebie w każdym wariancie, ale to izolacja programowa — opiera się na poprawności mechanizmu pul. Granica na poziomie systemu plików nie zależy od tego, czy w kodzie niczego nie przeoczono. Przy sprzątaniu demo nie da się przez pomyłkę skasować cudzych danych, bo leżą gdzie indziej.

Klaster ma zapas (węzły na 24–38% pamięci), więc koszt dwóch podów nie był argumentem przeciw.

Silnik własny, permisywny — silnik B (AGPL) nie wchodzi do produktu oddawanego klientom.

data-astroklient dostaje nodeAffinity na etykietę zdolności procesora, jak pozostałe warstwy danych: ciąga pandas, a przez nią NumPy z bazą x86-64-v2.

Wpis w liście obserwowanych obrazów — od razu

Bez niego usługa nie deployuje się sama: obraz powstaje w rejestrze, kustomization zostaje na starym tagu, i wygląda to na zepsute CI. Tak zawisł kiedyś render. Wpis ma komentarz mówiący dlaczego tam jest.

Poprawka w sprawdzeniu, którą najpierw napisałem błędnie

Bez sesji każdy adres oddaje 303 — także nieistniejący, bo bramka logowania działa przed trasowaniem. Moja pierwsza wersja runbooka kazała sprawdzać nieobecne ekrany curlem bez ciasteczka; pokazywałaby 303 dla wszystkiego i sugerowała, że te ekrany „są".

Sprawdzenie ma sens dopiero z sesją — i wtedy nieobecne ekrany dają 404, nie 403. Zweryfikowane na złożonym drzewie:

adres	bez sesji	z sesją
`/`	303	200
`/compile` `/settings` `/accounts` `/files`	303	404

Przy okazji to dobra własność sama w sobie: niezalogowany nie wyczyta z kodów odpowiedzi, które ekrany istnieją.

Zweryfikowane

kustomize build — 37 obiektów · dry-run serwerowy przyjmuje wszystkie osiem nowych obiektów · certyfikat obejmuje trzeci host · DNS już wskazuje (wildcard).

Domyka drabinę produktów: **astrodemo** (dwie funkcje) → **astroklient** → **astrololo**. Host `astroklient.czernobog.pl` · obraz `astrololo-astroklient` · port 8006. ## ⚠️ ZANIM ZMERGUJESZ Dwie rzeczy muszą istnieć wcześniej, inaczej pody nie wstaną: **1. Udział NFS** — ze wszystkimi **czterema** węzłami: ```bash midclt call sharing.nfs.create '{ "path": "/mnt/Tank1/astrololo-klient", "hosts": ["192.168.1.73", "192.168.1.80", "192.168.1.81", "192.168.1.82"], "maproot_user": "root", "maproot_group": "root", "enabled": true }' midclt call service.restart nfs ``` **2. Sekret z kontami** — pod bez `SESSION_SECRET` celowo nie wstanie: ```bash kubectl -n astrololo create secret generic astrololo-astroklient \ --from-literal=ASTROKLIENT_USERS='klientA:scrypt$…' \ --from-literal=SESSION_SECRET="$(openssl rand -hex 32)" ``` Hashe: `python services/presentation/scripts/make_user.py klientA` w repo aplikacji. ## Własny stos, nie wspólny Zgodnie z Twoją decyzją: nowa para `data-astroklient` + `logic-astroklient` i nowy udział `/mnt/Tank1/astrololo-klient`. Pule kont izolują klientów od siebie w każdym wariancie, ale to izolacja **programowa** — opiera się na poprawności mechanizmu pul. Granica na poziomie systemu plików nie zależy od tego, czy w kodzie niczego nie przeoczono. Przy sprzątaniu demo nie da się przez pomyłkę skasować cudzych danych, bo leżą gdzie indziej. Klaster ma zapas (węzły na 24–38% pamięci), więc koszt dwóch podów nie był argumentem przeciw. Silnik **własny, permisywny** — silnik B (AGPL) nie wchodzi do produktu oddawanego klientom. `data-astroklient` dostaje nodeAffinity na etykietę zdolności procesora, jak pozostałe warstwy danych: ciąga pandas, a przez nią NumPy z bazą x86-64-v2. ## Wpis w liście obserwowanych obrazów — od razu Bez niego usługa **nie deployuje się sama**: obraz powstaje w rejestrze, kustomization zostaje na starym tagu, i wygląda to na zepsute CI. Tak zawisł kiedyś render. Wpis ma komentarz mówiący dlaczego tam jest. ## Poprawka w sprawdzeniu, którą najpierw napisałem błędnie **Bez sesji każdy adres oddaje 303** — także nieistniejący, bo bramka logowania działa przed trasowaniem. Moja pierwsza wersja runbooka kazała sprawdzać nieobecne ekrany curlem bez ciasteczka; pokazywałaby 303 dla wszystkiego i sugerowała, że te ekrany „są". Sprawdzenie ma sens dopiero **z sesją** — i wtedy nieobecne ekrany dają **404, nie 403**. Zweryfikowane na złożonym drzewie: | adres | bez sesji | z sesją | |---|---|---| | `/` | 303 | **200** | | `/compile` `/settings` `/accounts` `/files` | 303 | **404** | Przy okazji to dobra własność sama w sobie: niezalogowany nie wyczyta z kodów odpowiedzi, które ekrany istnieją. ## Zweryfikowane `kustomize build` — 37 obiektów · dry-run serwerowy przyjmuje wszystkie osiem nowych obiektów · certyfikat obejmuje trzeci host · DNS już wskazuje (wildcard).

gitea added 1 commit 2026-08-27 14:10:36 +00:00

astroklient: wdrożenie warstwy pośredniej z własnym stosem danych (5/5) 16240466ec

Domyka drabinę produktów: astrodemo (dwie funkcje) → astroklient → astrololo.
Host astroklient.czernobog.pl, obraz astrololo-astroklient, port 8006.

WŁASNY STOS, NIE WSPÓLNY. Nowa para data-astroklient + logic-astroklient
i nowy udział /mnt/Tank1/astrololo-klient. Pule kont izolują klientów od siebie
w każdym wariancie, ale to izolacja PROGRAMOWA — opiera się na poprawności
mechanizmu pul. Granica na poziomie systemu plików nie zależy od tego, czy
w kodzie niczego nie przeoczono, a przy sprzątaniu demo nie da się przez pomyłkę
skasować cudzych danych, bo leżą gdzie indziej.

Klaster ma zapas (węzły na 24–38% pamięci), więc koszt dwóch podów nie był
argumentem przeciw.

Silnik własny (permisywny) — silnik B (AGPL) nie wchodzi do produktu
oddawanego klientom.

data-astroklient dostaje nodeAffinity na etykietę zdolności procesora, jak
pozostałe warstwy danych: ciągnie pandas, a przez nią NumPy z bazą x86-64-v2.

WPIS W LIŚCIE OBSERWOWANYCH OBRAZÓW od razu, z komentarzem dlaczego. Bez niego
usługa nie deployuje się sama: obraz powstaje w rejestrze, kustomization zostaje
na starym tagu, i wygląda to na zepsute CI. Tak zawisł kiedyś render.

Certyfikat obejmuje trzeci host; DNS już wskazuje (wildcard).

RUNBOOK: udział NFS ze WSZYSTKIMI CZTEREMA węzłami, konta jako hashe scrypt,
własny SESSION_SECRET i własna nazwa ciasteczka (trzy produkty nie mają powodu
uznawać nawzajem swoich sesji), unieważnianie dostępu bez wolumenu stanu, oraz
sprawdzenie po wdrożeniu.

W sprawdzeniu poprawiona rzecz, którą najpierw napisałem błędnie: BEZ SESJI
każdy adres oddaje 303, także nieistniejący, bo bramka logowania działa przed
trasowaniem. Pętla curl bez ciasteczka pokazywałaby 303 dla wszystkiego
i sugerowała, że nieobecne ekrany „są". Sprawdzenie ma sens dopiero z sesją —
i wtedy dają 404, nie 403.

Zweryfikowane: kustomize build (37 obiektów), dry-run serwerowy przyjmuje
wszystkie osiem nowych obiektów, kody odpowiedzi sprawdzone na złożonym drzewie.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

gitea merged commit 16240466ec into master

2026-08-27 14:26:14 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gitea/deploy#26