Compare commits

..

3 Commits

Author SHA1 Message Date
gitea b4fe5fbffa Tag nowego builda 2026-08-26 19:44:13 +02:00
gitea 9a6606845c astrodemo: ostrzeżenie o tagu obrazu przed pierwszym wdrożeniem
CI pcha obrazy wyłącznie pod tagiem ośmioznakowym i NIGDY nie pcha `latest`,
a manifest demo wskazywał `latest`. Pod zatrzymałby się na ImagePullBackOff —
objaw wygląda na problem z rejestrem albo z siecią, a jest zwykłym brakiem tagu.

Pozostałe usługi tego nie pokazują, bo image-updater dawno podmienił im tagi na
SHA. Nowa usługa startuje od zera i nie ma czego podmienić.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-26 15:58:45 +02:00
gitea 590679ad65 astrodemo: wdrożenie wersji demonstracyjnej (PRE-28/29)
Zastępuje gałąź feat/astroklient. Tamta była odbita od mastera sprzed jedenastu
commitów i miała przypięte obrazy `ee3c515d`, podczas gdy master stoi na
`320a0ab2` — merge w tamtej postaci COFNĄŁBY klaster o kilka wersji. Zamiast
przepychać cztery commity przez rebase (każdy konfliktował na README), gałąź
jest odtworzona jednym commitem na aktualnym masterze, z zachowanymi tagami.

ZMIANA NAZWY. astroklient-demo → astrodemo, wraz z nazwą obrazu, zmiennymi
(ASTRODEMO_USERS) i sekretem (astrololo-astrodemo). Nazwa „astroklient" jest
zarezerwowana dla warstwy pośredniej: pełne funkcje astrologiczne, bez
generowania tekstu i bez administracji.

BRAKOWAŁO WEJŚCIA Z ZEWNĄTRZ. Manifesty tworzyły Deployment i Service, ale żadnej
reguły w Ingressie — usługa wstałaby i nie dałoby się do niej wejść. Dołożony
host astrodemo.czernobog.pl z przekierowaniem z http, a certyfikat obejmuje teraz
oba hosty.

Osobny host, a nie ścieżka `/demo` pod adresem astrololo, CELOWO: ścieżka
dzieliłaby z pełną aplikacją pochodzenie w rozumieniu przeglądarki, czyli
i ciasteczka — wejście do jednej ruszałoby sesję w drugiej.

OBRAZ NA LIŚCIE OBSERWOWANYCH. Bez wpisu w image-updater.yaml obraz nigdy się nie
podbije, choćby CI go budowało. Tak przez chwilę wisiał render na :latest.

POPRAWKI W RUNBOOKU. Opis twierdził, że demo pracuje na produkcyjnej warstwie
danych — nieprawda od PRE-29, ma własny stos i własny udział. Ponadto zmiana nazw
rozjechała ścieżkę udziału: `zfs create Tank1/astrololo-astrodemo` przy manifeście
montującym `/mnt/Tank1/astrololo-demo` utworzyłby inny zbiór niż ten, którego pod
szuka. Ścieżka jest stanem na dysku, nie nazwą w kodzie — zostaje jak była.

Sprawdzone: `kubectl kustomize astrololo/` buduje 29 obiektów, tagi obrazów
pozostają na 320a0ab2.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-26 15:56:46 +02:00
6 changed files with 7 additions and 126 deletions
+1 -1
View File
@@ -47,7 +47,7 @@ midclt call sharing.nfs.query '[["path","=","/mnt/Tank1/astrololo-demo"]]' \
midclt call sharing.nfs.create '{ midclt call sharing.nfs.create '{
"path": "/mnt/Tank1/astrololo-demo", "path": "/mnt/Tank1/astrololo-demo",
"comment": "astrololo — pule kont wersji demo (PRE-29)", "comment": "astrololo — pule kont wersji demo (PRE-29)",
"hosts": ["192.168.1.73", "192.168.1.80", "192.168.1.81", "192.168.1.82"], "hosts": ["192.168.1.73", "192.168.1.80", "192.168.1.81"],
"enabled": true, "enabled": true,
"ro": false, "ro": false,
"mapall_user": "root", "mapall_user": "root",
+1 -1
View File
@@ -66,7 +66,7 @@ sudo chmod 770 /mnt/Tank1/astrololo-state
midclt call sharing.nfs.create '{ midclt call sharing.nfs.create '{
"path": "/mnt/Tank1/astrololo-state", "path": "/mnt/Tank1/astrololo-state",
"comment": "astrololo — stan prezentacji (konta PRE-27)", "comment": "astrololo — stan prezentacji (konta PRE-27)",
"hosts": ["192.168.1.73", "192.168.1.80", "192.168.1.81", "192.168.1.82"], "hosts": ["192.168.1.73", "192.168.1.80", "192.168.1.81"],
"ro": false, "ro": false,
"mapall_user": "apps", "mapall_user": "apps",
"mapall_group": "apps" "mapall_group": "apps"
+1 -80
View File
@@ -60,7 +60,7 @@ w ogóle nie został zapytany. Jądro nie znalazło programu pomocniczego
### Sprawdzenie ### Sprawdzenie
```bash ```bash
for N in 192.168.1.73 192.168.1.80 192.168.1.81 192.168.1.82; do for N in 192.168.1.73 192.168.1.80 192.168.1.81; do
printf "%-15s " "$N" printf "%-15s " "$N"
ssh hammer@$N 'test -x /sbin/mount.nfs && echo MA-KLIENTA || echo BRAK-KLIENTA' ssh hammer@$N 'test -x /sbin/mount.nfs && echo MA-KLIENTA || echo BRAK-KLIENTA'
done done
@@ -86,85 +86,6 @@ ssh hammer@<węzeł> 'sudo apt-get update && sudo apt-get install -y nfs-common'
| `access denied by server while mounting` | serwer odmawia: eksport nieprzeładowany, węzła nie ma na liście `hosts`, albo udział wyłączony | | `access denied by server while mounting` | serwer odmawia: eksport nieprzeładowany, węzła nie ma na liście `hosts`, albo udział wyłączony |
| `Permission denied` przy zapisie | montowanie działa, brakuje praw — patrz `mapall_user` i właściciel katalogu | | `Permission denied` przy zapisie | montowanie działa, brakuje praw — patrz `mapall_user` i właściciel katalogu |
## ⚠️ Wymóg węzłów: rozszerzenia procesora (x86-64-v2)
Warstwa danych używa pandas, a przez nią NumPy. Koła NumPy z PyPI są budowane
z bazą **x86-64-v2**, więc na węźle bez tych rozszerzeń kontener nie wstaje:
```
RuntimeError: NumPy was built with baseline optimizations:
(X86_V2) but your machine doesn't support: (X86_V2).
```
Komunikat mówi o „optymalizacjach", czyli o niczym, po czym dałoby się poznać,
że chodzi o **węzeł**, a nie o obraz. Pod wpada w pętlę restartów i wygląda to
na zepsuty build.
### To NIE jest ograniczenie sprzętu
Węzły k3s są maszynami wirtualnymi. Proxmox z domyślnym modelem CPU (`kvm64`,
„Common KVM processor") **maskuje flagi procesora** — gość nie widzi SSE4.2 ani
POPCNT, mimo że fizyczny i7-3770 obsługuje nawet x86-64-**v3**. Stąd bierze się
złudzenie, że „węzły mają różne procesory": mają ten sam sprzęt i różne maski.
### Sprawdzenie: które węzły to udźwigną
```bash
for N in $(kubectl get nodes -o jsonpath='{.items[*].metadata.name}'); do
kubectl run cpucheck-$N --image=busybox --restart=Never --rm -i --quiet \
--overrides="{\"spec\":{\"nodeName\":\"$N\",\"tolerations\":[{\"operator\":\"Exists\"}]}}" \
--command -- sh -c '
F=$(grep -m1 ^flags /proc/cpuinfo); BRAK=""
for f in cx16 lahf_lm popcnt pni ssse3 sse4_1 sse4_2; do
echo "$F" | grep -qw "$f" || BRAK="$BRAK $f"
done
echo "$(grep -m1 "model name" /proc/cpuinfo | cut -d: -f2-)"
[ -z "$BRAK" ] && echo " x86-64-v2: TAK" || echo " x86-64-v2: NIE —$BRAK"
' 2>/dev/null | sed "s/^/$N /"
done
```
**Pułapka przy czytaniu flag:** Linux raportuje SSE3 jako **`pni`** (Prescott New
Instructions), nie `sse3`. Szukanie `sse3` daje fałszywy alarm na maszynie, która
SSE3 ma — pierwsza wersja tej kontroli wskazała w ten sposób trzy zdrowe węzły
jako niesprawne.
### Naprawa u źródła (Proxmox)
Na węźle Proxmox, dla każdej maszyny k3s:
```bash
qm set <VMID> --cpu host
qm stop <VMID> && qm start <VMID>
```
**Sam restart z wnętrza gościa nie wystarczy** — zmiana modelu CPU wchodzi
dopiero przy pełnym wyłączeniu i włączeniu maszyny.
`--cpu host` przekazuje pełny zestaw rozszerzeń i daje przy okazji realnie
szybszą arytmetykę. Ma jeden koszt: **blokuje migrację na żywo** między hostami
o różnych procesorach. Jeśli kiedyś zaczniemy migrować maszyny między pve2
a NUC-iem, właściwym wyborem będzie wspólny mianownik `x86-64-v2-AES` zamiast
`host`.
### Zabezpieczenie: etykieta zamiast wykluczania po nazwie
`data` i `data-demo` wymagają etykiety `astrololo.czernobog.pl/cpu-x86-64-v2`.
Nowy węzeł jest domyślnie **nieoznaczony**, więc nie dostanie tych podów, dopóki
ktoś go nie sprawdzi i nie oznaczy świadomie:
```bash
kubectl label node <węzeł> astrololo.czernobog.pl/cpu-x86-64-v2=true
```
Wykluczanie konkretnego węzła po nazwie znaczyłoby, że każdy KOLEJNY źle
postawiony węzeł znów zbierze się przez awarię. Tak wyszedł agent3: dołożony
14 dni po pozostałych, bez kroku `--cpu host`, i nikt tego nie zauważył, dopóki
scheduler nie postawił tam akurat warstwy danych.
**KOLEJNOŚĆ MA ZNACZENIE.** Oznacz węzły ZANIM to wdrożysz — bez etykiet `data`
nie ma się gdzie uruchomić i pójdzie w Pending.
## ⚠️ Sekret `astrololo-auth` — utwórz PRZED wdrożeniem ## ⚠️ Sekret `astrololo-auth` — utwórz PRZED wdrożeniem
Aplikacja wystawia treść **oryginalnych baz interpretacyjnych**, dlatego wymaga Aplikacja wystawia treść **oryginalnych baz interpretacyjnych**, dlatego wymaga
-20
View File
@@ -21,26 +21,6 @@ spec:
metadata: metadata:
labels: { app: data-demo } labels: { app: data-demo }
spec: spec:
# Ta usługa liczy na pandas, a przez nią na NumPy. Koła NumPy z PyPI są
# budowane z bazą x86-64-v2, więc na węźle bez tych rozszerzeń kontener
# NIE WSTAJE: `import numpy` kończy się RuntimeError, pod wpada w pętlę
# restartów, a komunikat mówi o „baseline optimizations" — czyli o niczym,
# po czym dałoby się poznać, że chodzi o węzeł.
#
# Wymagana ETYKIETA, a nie wykluczony konkretny węzeł. Nowy węzeł jest
# domyślnie NIEOZNACZONY, więc nie dostanie tu poda, dopóki ktoś go nie
# sprawdzi (skrypt w README) i nie oznaczy świadomie. Pending z czytelnym
# powodem jest lepszy niż pętla restartów z komunikatem o optymalizacjach —
# a wykluczanie węzłów po nazwie znaczyłoby, że każdy KOLEJNY źle
# postawiony węzeł znów zbiera się przez awarię.
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: astrololo.czernobog.pl/cpu-x86-64-v2
operator: In
values: ["true"]
containers: containers:
- name: data - name: data
# TEN SAM obraz co produkcja — różni się wyłącznie udziałem, na którym # TEN SAM obraz co produkcja — różni się wyłącznie udziałem, na którym
-20
View File
@@ -12,26 +12,6 @@ spec:
# LOG-33: pody nie rozmawiają z API Kubernetesa, więc token konta # LOG-33: pody nie rozmawiają z API Kubernetesa, więc token konta
# serwisowego jest im niepotrzebny — a zamontowany byłby gotowym # serwisowego jest im niepotrzebny — a zamontowany byłby gotowym
# punktem wyjścia do klastra dla kogoś, kto przejmie kontener. # punktem wyjścia do klastra dla kogoś, kto przejmie kontener.
# Ta usługa liczy na pandas, a przez nią na NumPy. Koła NumPy z PyPI są
# budowane z bazą x86-64-v2, więc na węźle bez tych rozszerzeń kontener
# NIE WSTAJE: `import numpy` kończy się RuntimeError, pod wpada w pętlę
# restartów, a komunikat mówi o „baseline optimizations" — czyli o niczym,
# po czym dałoby się poznać, że chodzi o węzeł.
#
# Wymagana ETYKIETA, a nie wykluczony konkretny węzeł. Nowy węzeł jest
# domyślnie NIEOZNACZONY, więc nie dostanie tu poda, dopóki ktoś go nie
# sprawdzi (skrypt w README) i nie oznaczy świadomie. Pending z czytelnym
# powodem jest lepszy niż pętla restartów z komunikatem o optymalizacjach —
# a wykluczanie węzłów po nazwie znaczyłoby, że każdy KOLEJNY źle
# postawiony węzeł znów zbiera się przez awarię.
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: astrololo.czernobog.pl/cpu-x86-64-v2
operator: In
values: ["true"]
automountServiceAccountToken: false automountServiceAccountToken: false
imagePullSecrets: [{ name: gitea-registry }] imagePullSecrets: [{ name: gitea-registry }]
containers: containers:
+4 -4
View File
@@ -13,12 +13,12 @@ resources:
- ingress.yaml # wejście po https + przekierowanie z http - ingress.yaml # wejście po https + przekierowanie z http
images: images:
- name: gitea.czernobog.pl/gitea/astrololo-data - name: gitea.czernobog.pl/gitea/astrololo-data
newTag: fd79513c newTag: 320a0ab2
- name: gitea.czernobog.pl/gitea/astrololo-logic - name: gitea.czernobog.pl/gitea/astrololo-logic
newTag: fd79513c newTag: 320a0ab2
- name: gitea.czernobog.pl/gitea/astrololo-render - name: gitea.czernobog.pl/gitea/astrololo-render
newTag: cf24c4d4 newTag: latest
- name: gitea.czernobog.pl/gitea/astrololo-presentation - name: gitea.czernobog.pl/gitea/astrololo-presentation
newTag: fd79513c newTag: 320a0ab2
- name: gitea.czernobog.pl/gitea/astrololo-astrodemo - name: gitea.czernobog.pl/gitea/astrololo-astrodemo
newTag: fd79513c newTag: fd79513c