image-updater: definicja wdrażana przez ArgoCD zamiast wklepywanej ręcznie

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 <noreply@anthropic.com>
This commit was merged in pull request #27.
This commit is contained in:
2026-08-27 21:18:45 +02:00
parent c1a88ef573
commit f2ea8e26c0
2 changed files with 31 additions and 8 deletions
+26 -8
View File
@@ -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` 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 (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 go budowało — tak przez chwilę wisiał `render` na `:latest`.
listy. Dodając nową usługę, dopisz jej wpis w `image-updater.yaml` i nałóż:
```bash Dodając nową usługę, dopisz jej wpis w `image-updater.yaml`. **Nic więcej nie
kubectl apply -f astrololo/image-updater.yaml 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` ### Dlaczego jest w kustomization, skoro kiedyś celowo nie był
(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. 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) ## Pliki baz — udział otwarty na zapis (DAN-27)
+5
View File
@@ -13,6 +13,11 @@ resources:
- render.yaml # składanie raportu PDF (PRE-24), osobny obraz z TeX Live - render.yaml # składanie raportu PDF (PRE-24), osobny obraz z TeX Live
- tls.yaml # certyfikat z własnego CA (wymaga cert-managera) - tls.yaml # certyfikat z własnego CA (wymaga cert-managera)
- ingress.yaml # wejście po https + przekierowanie z http - 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: images:
- name: gitea.czernobog.pl/gitea/astrololo-data - name: gitea.czernobog.pl/gitea/astrololo-data
newTag: fd79513c newTag: fd79513c