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>
gitea
argocd-image-updater