Deployment + Service (ClusterIP), wpięcie w kustomization, obraz dopisany do
image-updatera i runbook.
Obraz na liście image-updatera CELOWO od razu: obraz, którego tam nie ma, nigdy
się nie podbije, choćby CI go budowało — tak przez chwilę wisiał render na :latest.
Token międzywarstwowy i klucz łącza brane z TYCH SAMYCH sekretów co prezentacja:
demo nie jest furtką omijającą ochronę warstwy logicznej. Hasło demo natomiast
z OSOBNEGO sekretu astrololo-demo — demo odcina się jego skasowaniem, bez ruszania
kont głównej aplikacji.
Limit żądań niższy niż w pełnej aplikacji (60/min): demo bywa udostępniane szerzej,
a każde zapytanie sięga do treści baz.
Runbook zaczyna się od ostrzeżenia, bo to jedyna rzecz, którą trzeba pamiętać za
każdym razem: demo pracuje na PRODUKCYJNEJ warstwie danych, więc kto dostaje adres,
czyta oryginalne bazy, a jego wgrania trafiają do produkcyjnego zbioru. Pełna
izolacja wymagałaby osobnej warstwy danych i nie jest dziś zrobiona.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
gitea