Decyzja właściciela: idziemy wariantem, w którym udział z bazami staje się
zapisywalny. DAN-25 dawał gwarancję, że baz nie da się zmienić przez NFS, a
DAN-27 tę gwarancję z definicji znosi — nie da się mieć obu naraz. Runbook mówi
to wprost i wylicza, co z zabezpieczeń zostaje.
mapall_user: root mimo drwxrwxrwx na katalogu. Samo ro: false wystarczyłoby do
zapisu, bo zmapowany nobody mieści się w prawach „innych" — ale nowe pliki
należałyby wtedy do nobody, a istniejące bazy do root. Mieszana własność zemści
się przy pierwszym zaostrzeniu praw.
Krok 3 z ostrzeżeniem, że rollout restart nie wystarcza: pody się na chwilę
nakładają, więc montowanie NFS nie zostaje bez użytkownika i nowy dziedziczy
uprawnienia sprzed zmiany eksportu. To kosztowało najwięcej czasu przy udziale
astrololo-state.
Krok 4 sprawdza wyszukiwanie JAKO OSTATNI I NAJWAŻNIEJSZY punkt — to jedyne
miejsce, w którym ta zmiana mogłaby przejść niezauważona: przejście na rejestr
plików mogłoby wyłączyć wszystkie bazy i wyglądałoby to jak pusta baza, a nie
jak zepsuty deploy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ekran „Pliki" pozwala wgrywać bazy, archiwizować je i (dla administratora)
kasować, a stan użycia jest klikany, więc musi przetrwać restart poda. Warstwa
danych musi zatem móc pisać na udziale — dotąd był montowany read-only.
ŚWIADOMY KOSZT: znika jedna warstwa obrony w głąb. Przejęcie warstwy danych
pozwala teraz nie tylko odczytać bazy, ale i je zmienić. Zostaje reszta: token
międzywarstwowy, szyfrowane łącze, ograniczenie eksportu NFS do konkretnych
hostów (DAN-25) oraz to, że kasować może wyłącznie konto administracyjne (PRE-27).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ekran „Konta" zapisuje konta do pliku, więc prezentacja potrzebuje trwałego
miejsca — inaczej wszystkie konta znikałyby przy restarcie poda.
subPath, NIE cały udział: prezentacja dostaje wyłącznie własny podkatalog
`presentation-state` i nie widzi baz interpretacyjnych. Zamontowanie tu całego
/mnt/Tank1/astrololo dałoby jej wgląd w bazy i obeszłoby bokiem zamknięcie
dostępu z DAN-25.
Konto administracyjne zostaje w APP_USER/APP_PASSWORD z sekretu — celowo poza
plikiem, żeby nie dało się go skasować ani ograniczyć z aplikacji.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
updates image gitea/astrololo-data tag 'aec3f843' to 'baf4e0e3'
updates image gitea/astrololo-logic tag '8b6ecc72' to 'baf4e0e3'
updates image gitea/astrololo-presentation tag '8b6ecc72' to 'baf4e0e3'
updates image gitea/astrololo-data tag '40f5e459' to 'aec3f843'
updates image gitea/astrololo-logic tag '1be57a47' to 'aec3f843'
updates image gitea/astrololo-presentation tag '40f5e459' to 'aec3f843'
updates image gitea/astrololo-render tag 'latest' to 'aec3f843'
updates image gitea/astrololo-data tag 'e3114f3e' to '40f5e459'
updates image gitea/astrololo-logic tag '86a0f16f' to '40f5e459'
updates image gitea/astrololo-presentation tag 'e3114f3e' to '40f5e459'
updates image gitea/astrololo-data tag 'bc80745a' to 'e3114f3e'
updates image gitea/astrololo-logic tag 'bc80745a' to 'e3114f3e'
updates image gitea/astrololo-presentation tag 'bc80745a' to 'e3114f3e'
updates image gitea/astrololo-data tag '70c83cfc' to 'bc80745a'
updates image gitea/astrololo-logic tag '70c83cfc' to 'bc80745a'
updates image gitea/astrololo-presentation tag '70c83cfc' to 'bc80745a'
Wszystkie cztery usługi biegły na koncie `default` z AUTOMATYCZNIE montowanym
tokenem API Kubernetesa. Żadna z nich nie rozmawia z API klastra — sekrety dostają
przez `secretKeyRef`, który wstrzykuje kubelet, nie pod. Token był więc zbędny,
a leżał w każdym kontenerze jako gotowy punkt wyjścia do klastra dla kogoś, kto
przejmie proces (np. przez lukę w zależności).
`automountServiceAccountToken: false` w szablonie poda data/logic/presentation/
render. Zweryfikowane `kubectl kustomize` — pole trafia do `.spec.template.spec`,
nie do specu Deploymentu (tam byłoby ciche i bez efektu).
Zero wpływu na działanie: nic w kodzie nie woła API Kubernetesa.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
updates image gitea/astrololo-data tag '4c1e7f88' to '70c83cfc'
updates image gitea/astrololo-logic tag '4c1e7f88' to '70c83cfc'
updates image gitea/astrololo-presentation tag '4c1e7f88' to '70c83cfc'
updates image gitea/astrololo-data tag 'dd32f7e8' to '4c1e7f88'
updates image gitea/astrololo-logic tag 'dd32f7e8' to '4c1e7f88'
updates image gitea/astrololo-presentation tag 'd3d9b365' to '4c1e7f88'
updates image gitea/astrololo-data tag '78af6d47' to 'dd32f7e8'
updates image gitea/astrololo-logic tag '7b435d42' to 'dd32f7e8'
updates image gitea/astrololo-presentation tag '7b435d42' to 'dd32f7e8'
updates image gitea/astrololo-data tag 'a0d1135d' to 'b36b3bee'
updates image gitea/astrololo-logic tag 'a0d1135d' to 'b36b3bee'
updates image gitea/astrololo-presentation tag 'a0d1135d' to 'b36b3bee'
updates image gitea/astrololo-data tag '8ebce816' to 'a0d1135d'
updates image gitea/astrololo-logic tag '8ebce816' to 'a0d1135d'
updates image gitea/astrololo-presentation tag '8ebce816' to 'a0d1135d'
updates image gitea/astrololo-data tag '52b7c20c' to '8ebce816'
updates image gitea/astrololo-logic tag '52b7c20c' to '8ebce816'
updates image gitea/astrololo-presentation tag '52b7c20c' to '8ebce816'
updates image gitea/astrololo-data tag '998c83b2' to 'f5dec15e'
updates image gitea/astrololo-logic tag '998c83b2' to 'f5dec15e'
updates image gitea/astrololo-presentation tag '495f3734' to 'f5dec15e'
updates image gitea/astrololo-render tag 'latest' to 'f5dec15e'
updates image gitea/astrololo-data tag '623603b1' to '998c83b2'
updates image gitea/astrololo-logic tag '623603b1' to '998c83b2'
updates image gitea/astrololo-presentation tag '4b17f2dd' to '998c83b2'
Konfiguracja argocd-image-updater istniała tylko w klastrze (ręczne `kubectl
apply`, brak w git). Skutkiem był PRE-24: `render` zbudował się i zdeployował raz,
ale kolejne buildy nie schodziły — bo nie było go na JAWNEJ liście obserwowanych
obrazów CRD, a nigdzie nie dało się tego podejrzeć ani odtworzyć.
Zrzucam manifest (z `render` już w środku, 4 obrazy: data/logic/presentation/
render) do `astrololo/image-updater.yaml` + opis w README.
Plik CELOWO nie jest w kustomization.yaml: resource stoi w ns `argocd` (poza
namespace docelowym aplikacji), a to konfiguracja kontrolera wdrażającego tę
aplikację — nakładany ręcznie (`kubectl apply -f astrololo/image-updater.yaml`),
w repo dla odtwarzalności i historii. Dodanie nowej usługi = dopisanie wpisu tutaj.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
updates image gitea/astrololo-data tag '171deff2' to '623603b1'
updates image gitea/astrololo-logic tag '171deff2' to '623603b1'
updates image gitea/astrololo-presentation tag '171deff2' to '623603b1'
updates image gitea/astrololo-data tag '15964dd0' to '171deff2'
updates image gitea/astrololo-logic tag '15964dd0' to '171deff2'
updates image gitea/astrololo-presentation tag '15964dd0' to '171deff2'
updates image gitea/astrololo-data tag 'f24616d3' to '15964dd0'
updates image gitea/astrololo-logic tag 'f24616d3' to '15964dd0'
updates image gitea/astrololo-presentation tag 'f24616d3' to '15964dd0'
Nowy komponent skladajacy raport PDF. Osobny obraz, bo dzwiga TeX Live (setki MB)
— ta sama zasada co przy izolacji swissepha (LOG-27): obraz produktu zostaje maly,
TeX aktualizuje sie niezaleznie, a awaria renderu nie kladzie aplikacji, tylko
przycisk „Pobierz PDF".
- render.yaml — Deployment + Service. ClusterIP, BEZ NodePortu i Ingressu: nie ma
powodu, zeby ktokolwiek siegal do tej uslugi z zewnatrz. Rozmawia wylacznie
z prezentacja.
- Szyfrowanie: wlasny, TRZECI klucz LINK_KEY_PRESENTATION_RENDER z sekretu
astrololo-link. Osobny, bo tym laczem plynie CALY raport (dane urodzeniowe
i opisy z baz) — przejecie go nie moze otwierac lacza do logiki ani danych.
LINK_ENCRYPTION_REQUIRED=true, wiec bez klucza pod NIE wstaje.
- readOnlyRootFilesystem + emptyDir na /tmp: kompilacja pisze tylko do katalogu
tymczasowego, raport nie zostawia sladu w kontenerze.
- Limity rozjechane celowo (100m/256Mi -> 1500m/1Gi): XeLaTeX na obszernym
raporcie bierze duzo, ale na krotko.
- presentation: RENDER_URL + trzeci klucz lacza.
Sekret astrololo-link trzeba UZUPELNIC o trzeci klucz PRZED wdrozeniem,
zachowujac dwa dotychczasowe — komenda w instrukcji.
Sprawdzone: kubectl kustomize + apply --dry-run=server na zywym klastrze
(service/render i deployment.apps/render created).
Pelna instrukcja: docs/wdrozenie-render-pdf.md w repo astrololo.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
updates image gitea/astrololo-data tag 'f34016a4' to 'f24616d3'
updates image gitea/astrololo-logic tag 'f34016a4' to 'f24616d3'
updates image gitea/astrololo-presentation tag '6c9029c4' to 'f24616d3'
gitea
argocd-image-updater