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'
updates image gitea/astrololo-data tag 'f1956a08' to 'f34016a4'
updates image gitea/astrololo-logic tag '40c9bf79' to 'f34016a4'
updates image gitea/astrololo-presentation tag '40c9bf79' to 'f34016a4'