From f2ea8e26c0530509f81337e585caf1740a31ed4d Mon Sep 17 00:00:00 2001 From: migatu Date: Thu, 27 Aug 2026 21:18:45 +0200 Subject: [PATCH] =?UTF-8?q?image-updater:=20definicja=20wdra=C5=BCana=20pr?= =?UTF-8?q?zez=20ArgoCD=20zamiast=20wklepywanej=20r=C4=99cznie?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Astroklient zbudował się poprawnie, ale jego obraz nie schodził do klastra. Przyczyna nie leżała ani w CI, ani w rejestrze: CRD ImageUpdater w klastrze miał CZTERY obrazy (data, logic, presentation, render), a plik w gicie sześć. Brakowało astrodemo I astroklienta. `image-updater.yaml` nie był w kustomization.yaml, więc ArgoCD go nie nakładał. Dopisanie usługi do pliku nie robiło zatem nic — listy nikt nie stosował. ODWRACAM DECYZJĘ UDOKUMENTOWANĄ W TYM REPO. README twierdziło, że wyłączenie jest celowe: resource stoi w ns argocd, poza namespace docelowym aplikacji, i jest konfiguracją kontrolera, a nie aplikacji. Rozumowanie nie było głupie, ale nie wytrzymało praktyki — ręczny krok zapomniano dwa razy w ciągu dwóch tygodni, najpierw dla astrodemo, potem dla astroklienta. Najgorsza była CICHOŚĆ rozjazdu. Plik w gicie wyglądał poprawnie, git log pokazywał dopisanie usługi, a objawem był obraz, który „się nie deployuje" — co kieruje podejrzenia na CI albo na rejestr, czyli wszędzie poza właściwe miejsce. Diagnoza wymaga porównania pliku ze stanem klastra, a nikt nie porównuje rzeczy, o której nie wie, że mogą się różnić. Przeszkody technicznej nie było: projekt ArgoCD dopuszcza dowolną przestrzeń nazw (destinations: '*'), a dry-run serwerowy przyjmuje resource bez zastrzeżeń. W README zostaje wyjaśnienie, dlaczego jest w kustomization mimo wcześniejszego uzasadnienia — razem z prośbą, żeby przy ewentualnym wyjmowaniu usunąć też ten akapit. Inaczej następna osoba przeczyta powód, którego już nie ma. Zweryfikowane: kustomize build 38 obiektów (było 37), dry-run serwerowy aktualizuje istniejący CRD. Co-Authored-By: Claude Opus 5 --- astrololo/README.md | 34 ++++++++++++++++++++++++++-------- astrololo/kustomization.yaml | 5 +++++ 2 files changed, 31 insertions(+), 8 deletions(-) diff --git a/astrololo/README.md b/astrololo/README.md index 61e3780..34f30f8 100644 --- a/astrololo/README.md +++ b/astrololo/README.md @@ -12,16 +12,34 @@ Adres aplikacji: **https://astrololo.czernobog.pl** — patrz [TLS](#-tls--wymag Lista obrazów podbijanych automatycznie jest **jawna** i żyje w CRD `ImageUpdater` (ns `argocd`). Obraz, którego na niej nie ma, **nigdy się nie podbije**, choćby CI -go budowało — tak przez chwilę wisiał `render` na `:latest`, zanim dopisaliśmy go do -listy. Dodając nową usługę, dopisz jej wpis w `image-updater.yaml` i nałóż: +go budowało — tak przez chwilę wisiał `render` na `:latest`. -```bash -kubectl apply -f astrololo/image-updater.yaml -``` +Dodając nową usługę, dopisz jej wpis w `image-updater.yaml`. **Nic więcej nie +trzeba**: plik jest w `kustomization.yaml`, więc ArgoCD nakłada go razem z resztą. -Ten plik **celowo nie jest w `kustomization.yaml`**: resource stoi w ns `argocd` -(poza namespace docelowym aplikacji), a to konfiguracja kontrolera, który wdraża tę -aplikację — nakładamy go ręcznie, w repo trzymamy dla odtwarzalności i historii. +### Dlaczego jest w kustomization, skoro kiedyś celowo nie był + +Wcześniej ten plik był z niej wyłączony z uzasadnieniem, że resource stoi w ns +`argocd`, poza namespace docelowym aplikacji, i że to konfiguracja kontrolera, +a nie samej aplikacji — więc nakłada się go ręcznie. + +Rozumowanie nie było głupie, ale **nie wytrzymało praktyki**. Ręczny krok +zapomniano dwa razy w ciągu dwóch tygodni: najpierw dla `astrodemo`, potem dla +`astroklient`. Obie usługi miały wpis w pliku i obu brakowało w klastrze, więc +ich obrazy stały w miejscu mimo poprawnie działającego CI. + +Najgorsza w tym była **cichość rozjazdu**: plik w gicie wyglądał poprawnie, +`git log` pokazywał dopisanie usługi, a objawem był obraz, który „się nie +deployuje" — co kieruje podejrzenia na CI albo na rejestr, czyli wszędzie poza +właściwe miejsce. Diagnoza wymaga porównania pliku ze stanem klastra, a nikt nie +porównuje rzeczy, o której nie wie, że mogą się różnić. + +Przeszkody technicznej nie było: projekt ArgoCD dopuszcza dowolną przestrzeń +nazw (`destinations: [{namespace: "*", server: "*"}]`), więc resource w ns +`argocd` nakłada się bez zastrzeżeń. + +Jeśli kiedyś trzeba będzie go stamtąd wyjąć, **wyjmij razem z tym akapitem** — +inaczej następna osoba przeczyta uzasadnienie, którego już nie ma. ## Pliki baz — udział otwarty na zapis (DAN-27) diff --git a/astrololo/kustomization.yaml b/astrololo/kustomization.yaml index 7d45a6c..cb012d4 100644 --- a/astrololo/kustomization.yaml +++ b/astrololo/kustomization.yaml @@ -13,6 +13,11 @@ resources: - render.yaml # składanie raportu PDF (PRE-24), osobny obraz z TeX Live - tls.yaml # certyfikat z własnego CA (wymaga cert-managera) - ingress.yaml # wejście po https + przekierowanie z http + # Definicja obserwatora obrazów — WDRAŻANA, a nie wklepywana ręcznie. + # Póki jej tu nie było, plik w gicie i stan klastra rozjeżdżały się w ciszy: + # dopisanie usługi do listy nie robiło nic, bo listy nikt nie stosował. + # Mieszka w przestrzeni argocd — projekt to dopuszcza (destinations: '*'). + - image-updater.yaml images: - name: gitea.czernobog.pl/gitea/astrololo-data newTag: fd79513c