Compare commits

...

12 Commits

Author SHA1 Message Date
gitea 7e0a51878e feat(astroklient-demo): własny klucz podpisu sesji (LOG-34)
SESSION_SECRET w sekrecie astrololo-demo — WŁASNY, nie ten z pełnej aplikacji:
demo i produkcja nie mają powodu uznawać nawzajem swoich sesji.

W runbooku zapisana różnica wobec pełnej wersji: demo nie ma własnego wolumenu,
więc nie ma licznika sesji. Zdalne unieważnienie robi się przez DEMO_USERS —
usunięcie konta albo zmiana hasła natychmiast ubija jego otwarte sesje.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 00:21:52 +02:00
gitea a9ff6e1f68 refactor: astroklient → astroklient-demo
Nazwa `astroklient` zostaje zarezerwowana dla przyszłej wersji produkcyjnej;
obecna, demonstracyjna nazywa się od teraz `astroklient-demo`.

Zmiana obejmuje nazwy plików (astroklient-demo.yaml, astroklient-demo-stack.yaml,
README-astroklient-demo.md), Deployment i Service, etykiety selektorów, obraz
w rejestrze, alias w image-updaterze, wpisy w kustomization i odsyłacze w README.

`data-demo` i `logic-demo` zostają bez zmian — nie niosły starej nazwy.

Sprawdzone: `kubectl kustomize astrololo` składa komplet 27 zasobów, obraz to
astrololo-astroklient-demo, żadnego zdublowanego przyrostka ani gołego
`astroklient` nie zostało.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 23:36:57 +02:00
gitea e52284c88f feat(astroklient): własna warstwa danych i pule per konto (PRE-29)
Zmiana wobec pierwszej wersji: demo NIE pracuje już na produkcyjnej warstwie
danych. Ma własną logikę i własne dane, na osobnym udziale astrololo-demo,
pustym na starcie. Oryginalne bazy są dla demo nieosiągalne — nie przez
uprawnienia, tylko dlatego, że nie ma do nich drogi.

DLACZEGO OSOBNA JEST TEŻ WARSTWA LOGICZNA. Zna ona JEDEN adres warstwy danych,
więc astroklient korzystający z produkcyjnej logiki i tak trafiłby na produkcyjne
bazy. Izolacja musi sięgnąć obu warstw naraz, inaczej nie ma jej wcale. Jedyną
różnicą logic-demo wobec produkcyjnej jest DATA_URL — i to jest cała izolacja,
więc wpisanie tam „logic" cofnęłoby ją jednym słowem. Stąd komentarz przy tej
linii i sąsiedztwo obu plików.

PULE PER KONTO. Każde konto demo dostaje własny podkatalog na tym udziale,
niewidoczny dla pozostałych — w liście plików i w wynikach wyszukiwania. Konta
są listą `login:sekret` w sekrecie, bo jedno wspólne oznaczałoby wspólną pulę,
czyli klientów oglądających nawzajem swoje wgrania.

Ten sam OBRAZ co produkcja dla data i logic — różni je wyłącznie konfiguracja.
Osobny obraz to drugi kod do utrzymania i pewność, że kiedyś się rozjadą.

Logika demo nie dostaje kluczy do modeli językowych: astroklient nie umie o nie
prosić, więc nie ma powodu, żeby leżały w tym podzie.

Runbook opisuje IMPORT PULI KLIENTA do pełnej aplikacji — sedno całego układu,
bo klient przechodzący na pełną wersję nie może stracić wgrań. Jego pula to jeden
katalog: sprawdzenie kolizji nazw, kopiowanie z -n (nigdy nadpisania bazy
produkcyjnej), bez pliku stanu (produkcja ma własny), a na końcu świadome
włączenie w zakładce Pliki. Nie włączają się same, bo przeniesienie jest
czynnością techniczną, a decyzja o użyciu należy do właściciela.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-17 18:59:20 +02:00
gitea 82c73f6aa5 feat(astroklient): wdrożenie wersji demonstracyjnej (PRE-28)
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>
2026-08-17 18:39:48 +02:00
argocd-image-updater 3ea509b13a build: automatic update of conjurer
updates image gitea/conjurer-librarian tag 'c2e6b8e6' to 'd0c7ab61'
updates image gitea/conjurer-bot tag 'c2e6b8e6' to 'd0c7ab61'
2026-08-12 15:46:05 +00:00
argocd-image-updater 70f4d298ff build: automatic update of conjurer
updates image gitea/conjurer-librarian tag 'ae1bd677' to 'c2e6b8e6'
updates image gitea/conjurer-bot tag 'fbd1ec9f' to 'c2e6b8e6'
2026-08-12 15:16:03 +00:00
argocd-image-updater 7dd32b1fd4 build: automatic update of conjurer
updates image gitea/conjurer-librarian tag 'ae1bd677' to 'c2e6b8e6'
2026-08-12 15:14:02 +00:00
argocd-image-updater 1f9ea03ca6 build: automatic update of astrololo
updates image gitea/astrololo-data tag 'ac8a0e9f' to 'ee3c515d'
updates image gitea/astrololo-logic tag 'e2b50b28' to 'ee3c515d'
updates image gitea/astrololo-presentation tag 'e2b50b28' to 'ee3c515d'
2026-08-11 14:38:44 +00:00
argocd-image-updater 466d3cb8e7 build: automatic update of astrololo
updates image gitea/astrololo-data tag 'b838cf47' to 'ac8a0e9f'
2026-08-11 13:40:38 +00:00
argocd-image-updater bd0948f7a5 build: automatic update of astrololo
updates image gitea/astrololo-data tag '003deb94' to 'b838cf47'
updates image gitea/astrololo-logic tag '003deb94' to 'e2b50b28'
updates image gitea/astrololo-presentation tag '003deb94' to 'e2b50b28'
2026-08-11 09:18:11 +00:00
argocd-image-updater ba6e3bc9ee build: automatic update of astrololo
updates image gitea/astrololo-data tag 'baf4e0e3' to '003deb94'
updates image gitea/astrololo-logic tag 'baf4e0e3' to '003deb94'
updates image gitea/astrololo-presentation tag 'a8339659' to '003deb94'
2026-08-09 15:54:27 +00:00
argocd-image-updater 02ab25e39e build: automatic update of astrololo
updates image gitea/astrololo-data tag 'baf4e0e3' to '003deb94'
updates image gitea/astrololo-logic tag 'baf4e0e3' to '003deb94'
2026-08-09 15:51:02 +00:00
7 changed files with 418 additions and 5 deletions
+188
View File
@@ -0,0 +1,188 @@
# astroklient-demo — wdrożenie wersji demo (PRE-28/29)
Osobna usługa o dwóch funkcjach: **dodanie pliku bazy** i **zapytanie o
interpretację urodzeniową**. Opis aplikacji: `services/astroklient-demo/README.md`
w repo aplikacji.
---
## Jak to jest odizolowane
```
astroklient-demo → logic-demo → data-demo → /mnt/Tank1/astrololo-demo
└── klientA/ ← pula konta
└── klientB/ ← pula konta
```
**Oryginalne bazy są dla demo nieosiągalne.** Nie chodzi o uprawnienia: demo ma
własną warstwę danych, pracującą na osobnym udziale, pustym na starcie.
Dlaczego osobna jest też **warstwa logiczna**: zna ona jeden adres warstwy danych,
więc astroklient-demo korzystający z produkcyjnej logiki i tak trafiłby na produkcyjne
bazy. Izolacja musi sięgnąć obu warstw naraz, inaczej nie ma jej wcale.
**Każde konto ma własną pulę** — swój podkatalog na tym udziale. Konta nie widzą
swoich plików nawzajem ani w liście, ani w wynikach wyszukiwania. Pula bierze się
z **loginu zalogowanej osoby**, nigdy z pola formularza.
---
## Krok 1 — udział `astrololo-demo` na TrueNAS
Ta sama procedura co przy `astrololo-state`, więc jeśli tamten działa, ten też
zadziała. Po SSH na NAS:
```bash
sudo zfs create Tank1/astrololo-demo # albo: sudo mkdir -p /mnt/Tank1/astrololo-demo
```
```bash
midclt call sharing.nfs.query '[["path","=","/mnt/Tank1/astrololo-demo"]]' \
| python3 -m json.tool
```
**Pusta lista `[]`** — twórz:
```bash
midclt call sharing.nfs.create '{
"path": "/mnt/Tank1/astrololo-demo",
"comment": "astrololo — pule kont wersji demo (PRE-29)",
"hosts": ["192.168.1.73", "192.168.1.80", "192.168.1.81"],
"enabled": true,
"ro": false,
"mapall_user": "root",
"mapall_group": "root"
}'
```
**Coś zwróciło** — weź `id` i użyj `sharing.nfs.update <ID>` z tą samą treścią.
```bash
midclt call service.restart nfs
sudo exportfs -v | grep astrololo-demo
```
Musi tam być `rw`. Sprawdź jeszcze zapis z węzła — to jest ten test, którego
zabrakło przy poprzednim udziale:
```bash
ssh <węzeł> 'sudo mkdir -p /mnt/t && sudo mount -t nfs 192.168.1.34:/mnt/Tank1/astrololo-demo /mnt/t \
&& sudo touch /mnt/t/proba && echo ZAPIS-OK || echo ZAPIS-NIE; sudo rm -f /mnt/t/proba; sudo umount /mnt/t'
```
---
## Krok 2 — konta demo
Każde konto to osobna pula, więc **rozdajesz konta, nie jedno hasło**.
Hasła najlepiej jako hash — wtedy nie leżą nigdzie jawnie (skrypt jest w repo
aplikacji, `services/presentation/scripts/make_user.py`):
```bash
python scripts/make_user.py klientA # wypisze: scrypt$…
python scripts/make_user.py klientB
```
```bash
kubectl -n astrololo create secret generic astrololo-demo \
--from-literal=DEMO_USERS='klientA:scrypt$…,klientB:scrypt$…' \
--from-literal=SESSION_SECRET="$(openssl rand -hex 32)"
```
`SESSION_SECRET` podpisuje ciasteczka sesji (LOG-34). **Pod bez niego celowo nie
wstanie.** Jest WŁASNY, nie ten z pełnej aplikacji: demo i produkcja nie mają
powodu uznawać nawzajem swoich sesji.
> **Zdalne unieważnienie w demo działa inaczej niż w pełnej wersji.** Demo nie ma
> własnego wolumenu, więc nie ma gdzie trzymać licznika sesji. Zamiast tego:
> usunięcie konta z `DEMO_USERS` albo zmiana jego hasła **natychmiast ubija jego
> otwarte sesje** — bo odcisk poświadczenia wpisany w ciasteczko przestaje pasować.
> Rotacja `SESSION_SECRET` wylogowuje wszystkich naraz.
### Dodanie konta później
```bash
STARE=$(kubectl -n astrololo get secret astrololo-demo -o jsonpath='{.data.DEMO_USERS}' | base64 -d)
kubectl -n astrololo create secret generic astrololo-demo \
--from-literal=DEMO_USERS="${STARE},klientC:scrypt\$…" \
--dry-run=client -o yaml | kubectl apply -f -
kubectl -n astrololo rollout restart deploy/astroklient-demo
```
### Odebranie dostępu
Usuń wpis z `DEMO_USERS` tą samą drogą. **Pula zostaje na udziale** — pliki
klienta nie znikają, tylko przestaje być komu je pokazywać.
---
## Krok 3 — wdrożenie
```bash
kubectl apply -k astrololo
kubectl -n astrololo rollout status deploy/data-demo deploy/logic-demo deploy/astroklient-demo
```
Sprawdzenie na czas jednej sesji, bez wystawiania na świat:
```bash
kubectl -n astrololo port-forward deploy/astroklient-demo 8005:8005
```
Wejście z zewnątrz wymaga reguły w `ingress.yaml` — osobny host albo ścieżka.
**Celowo nie zakładam tego za Ciebie**: to decyzja, pod jakim adresem świat
zobaczy demo.
---
## Import puli klienta do pełnej aplikacji
Sedno całego układu: klient, który przechodzi na pełną wersję, **nie traci
dotychczasowych wgrań**. Jego pula to jeden katalog.
**1. Zobacz, co tam jest** (na NAS):
```bash
LOGIN=klientA
sudo ls -la /mnt/Tank1/astrololo-demo/$LOGIN/
```
**2. Sprawdź kolizje nazw** z bazami produkcyjnymi:
```bash
comm -12 \
<(cd /mnt/Tank1/astrololo-demo/$LOGIN && ls *.xlsx 2>/dev/null | sort) \
<(cd /mnt/Tank1/astrololo && ls *.xlsx 2>/dev/null | sort)
```
Pusto = brak kolizji. Cokolwiek się wypisze, przenieś ręcznie pod inną nazwą —
**nie nadpisuj bazy produkcyjnej**.
**3. Skopiuj** (`-n` = nie nadpisuj niczego, co już jest):
```bash
sudo cp -n /mnt/Tank1/astrololo-demo/$LOGIN/*.xlsx /mnt/Tank1/astrololo/
```
> Kopiujemy **tylko pliki `.xlsx`**. Plik `.files-state.json` zostaje — opisuje
> stan wewnątrz puli demo i w produkcji nie ma sensu; produkcja ma własny.
**4. Włącz je w pełnej aplikacji**: zakładka **Pliki**, nowe bazy pojawią się jako
„gotowa, odstawiona". Klikasz przełącznik przy tych, które mają wejść do użytku.
To, że nie włączają się same, jest zamierzone: przeniesienie plików jest czynnością
techniczną, a decyzja, które bazy biorą udział w interpretacji, należy do Ciebie.
---
## Odcięcie całego demo
```bash
kubectl -n astrololo scale deploy/astroklient-demo --replicas=0
```
Pule i dane zostają. Skasowanie sekretu `astrololo-demo` zatrzyma pod (nie wstanie
bez niego) i to też jest zachowanie zamierzone.
+9
View File
@@ -29,6 +29,15 @@ Runbook: **[README-pliki.md](README-pliki.md)**. Ekran „Pliki" wymaga zapisu d
udziału z bazami, więc znosi gwarancję z DAN-25, że baz nie da się zmienić przez udziału z bazami, więc znosi gwarancję z DAN-25, że baz nie da się zmienić przez
NFS. Co zostaje z zabezpieczeń i jak to wdrożyć — w runbooku. NFS. Co zostaje z zabezpieczeń i jak to wdrożyć — w runbooku.
## astroklient-demo — wersja demo (PRE-28)
Osobna usługa o dwóch funkcjach. Runbook: **[README-astroklient-demo.md](README-astroklient-demo.md)**.
Ma **własną warstwę logiczną i własną warstwę danych** na osobnym udziale
`astrololo-demo` — oryginalne bazy są dla demo nieosiągalne. Każde konto demo ma
własną, niewidoczną dla pozostałych pulę plików, a jego pulę da się później
przenieść do pełnej aplikacji jako jeden katalog.
## ⚠️ 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
+122
View File
@@ -0,0 +1,122 @@
# Warstwa danych i logiki WYŁĄCZNIE dla wersji demo (PRE-29).
#
# DLACZEGO OSOBNY KOMPLET, A NIE WSPÓŁDZIELONY. Warstwa logiczna zna JEDEN adres
# warstwy danych, więc astroklient-demo korzystający z produkcyjnej logiki i tak trafiłby
# na produkcyjne bazy. Izolacja demo musi więc sięgnąć obu warstw naraz, inaczej
# nie ma jej wcale.
#
# Udział `astrololo-demo` jest PUSTY na starcie i nigdy nie zawiera oryginalnych
# baz. Każde konto demo dostaje w nim własny podkatalog (pulę) — patrz PRE-29.
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: data-demo
namespace: astrololo
spec:
replicas: 1
selector:
matchLabels: { app: data-demo }
template:
metadata:
labels: { app: data-demo }
spec:
containers:
- name: data
# TEN SAM obraz co produkcja — różni się wyłącznie udziałem, na którym
# pracuje. Osobny obraz oznaczałby drugi kod do utrzymania i pewność,
# że kiedyś się rozjadą.
image: gitea.czernobog.pl/gitea/astrololo-data:latest
ports: [{ containerPort: 8002 }]
env:
- name: DATA_PROVIDER
value: "excel"
- name: EXCEL_DIR
value: "/app/data_files"
- name: CACHE_DIR
value: "/app/.cache"
- name: INTERNAL_TOKEN
valueFrom:
secretKeyRef: { name: astrololo-auth, key: INTERNAL_TOKEN }
- name: LINK_KEY_LOGIC_DATA
valueFrom:
secretKeyRef: { name: astrololo-link, key: LINK_KEY_LOGIC_DATA }
- name: LINK_ENCRYPTION_REQUIRED
value: "true"
volumeMounts:
- name: cache
mountPath: /app/.cache
- name: demo
mountPath: /app/data_files
resources:
requests: { cpu: "100m", memory: "256Mi" }
limits: { cpu: "500m", memory: "512Mi" }
volumes:
- name: cache
emptyDir: {}
- name: demo
nfs:
server: 192.168.1.34
# OSOBNY udział, pusty na starcie. NIE /mnt/Tank1/astrololo —
# to jest cała istota izolacji demo.
path: /mnt/Tank1/astrololo-demo
---
apiVersion: v1
kind: Service
metadata:
name: data-demo
namespace: astrololo
spec:
type: ClusterIP
selector: { app: data-demo }
ports: [{ port: 8002, targetPort: 8002 }]
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: logic-demo
namespace: astrololo
spec:
replicas: 1
selector:
matchLabels: { app: logic-demo }
template:
metadata:
labels: { app: logic-demo }
spec:
containers:
- name: logic
image: gitea.czernobog.pl/gitea/astrololo-logic:latest
ports: [{ containerPort: 8001 }]
env:
# JEDYNA różnica wobec produkcyjnej logiki — i zarazem cała izolacja.
- name: DATA_URL
value: "http://data-demo:8002"
- name: EPHEMERIS_ENGINE
value: "own"
- name: INTERNAL_TOKEN
valueFrom:
secretKeyRef: { name: astrololo-auth, key: INTERNAL_TOKEN }
- name: LINK_KEY_PRESENTATION_LOGIC
valueFrom:
secretKeyRef: { name: astrololo-link, key: LINK_KEY_PRESENTATION_LOGIC }
- name: LINK_KEY_LOGIC_DATA
valueFrom:
secretKeyRef: { name: astrololo-link, key: LINK_KEY_LOGIC_DATA }
- name: LINK_ENCRYPTION_REQUIRED
value: "true"
# Bez kluczy do modeli językowych. Astroklient nie umie o nie prosić,
# więc ich tu nie ma — czego nie ma w podzie, tego nie wyniesie.
resources:
requests: { cpu: "100m", memory: "128Mi" }
limits: { cpu: "500m", memory: "512Mi" }
---
apiVersion: v1
kind: Service
metadata:
name: logic-demo
namespace: astrololo
spec:
type: ClusterIP
selector: { app: logic-demo }
ports: [{ port: 8001, targetPort: 8001 }]
+86
View File
@@ -0,0 +1,86 @@
# astroklient-demo — wersja demonstracyjna (PRE-28).
#
# Osobna usługa o DWÓCH funkcjach: dodanie pliku bazy i zapytanie o interpretację
# urodzeniową. Pozostałe funkcje nie są tu ukryte — nie ma ich w obrazie.
#
# IZOLACJA (PRE-29): astroklient-demo ma WŁASNĄ warstwę logiczną i WŁASNĄ warstwę
# danych (astroklient-demo-stack.yaml), pracujące na osobnym, pustym na starcie
# udziale. Oryginalne bazy interpretacyjne są dla demo NIEOSIĄGALNE.
#
# Wewnątrz demo każde konto ma własną pulę plików — swój podkatalog na tym
# udziale — niewidoczną dla pozostałych kont. Dzięki temu demo można rozdawać
# szeroko, a pliki jednego klienta da się później przenieść do pełnej aplikacji
# jako jeden katalog (patrz README-astroklient-demo.md).
apiVersion: apps/v1
kind: Deployment
metadata:
name: astroklient-demo
namespace: astrololo
spec:
replicas: 1
selector:
matchLabels: { app: astroklient-demo }
template:
metadata:
labels: { app: astroklient-demo }
spec:
containers:
- name: astroklient-demo
image: gitea.czernobog.pl/gitea/astrololo-astroklient-demo:latest
ports: [{ containerPort: 8005 }]
env:
# WŁASNA warstwa logiczna, wskazująca na WŁASNĄ warstwę danych.
# Wpisanie tu produkcyjnego `logic` cofnęłoby całą izolację demo
# jednym słowem — dlatego stoi to tuż obok siebie w jednym pliku.
- name: LOGIC_URL
value: "http://logic-demo:8001"
# Konto demo — WŁASNE, nie astrololo-auth. Sekret tworzony POZA repo
# (jak pozostałe), patrz README-astroklient-demo.md.
# KONTA DEMO — lista `login:sekret` po przecinku. Każde konto ma
# WŁASNĄ, niewidoczną dla pozostałych pulę baz (PRE-29), więc jedno
# wspólne konto oznaczałoby klientów oglądających swoje wgrania
# nawzajem. Sekrety najlepiej jako hash scrypt.
- name: DEMO_USERS
valueFrom:
secretKeyRef: { name: astrololo-demo, key: DEMO_USERS }
# Token międzywarstwowy i klucz łącza — TE SAME co prezentacja:
# demo nie jest furtką omijającą ochronę warstwy logicznej.
- name: INTERNAL_TOKEN
valueFrom:
secretKeyRef: { name: astrololo-auth, key: INTERNAL_TOKEN }
- name: LINK_KEY_PRESENTATION_LOGIC
valueFrom:
secretKeyRef: { name: astrololo-link, key: LINK_KEY_PRESENTATION_LOGIC }
- name: LINK_ENCRYPTION_REQUIRED
value: "true"
# Klucz podpisu ciasteczek sesji (LOG-34). WYMAGANY — pod bez niego
# celowo nie wstaje. WŁASNY, nie ten z pełnej aplikacji: demo i produkcja
# nie mają powodu uznawać nawzajem swoich sesji, a wspólny klucz
# znaczyłby, że sesja z demo bywa ważna tam, gdzie nie powinna.
- name: SESSION_SECRET
valueFrom:
secretKeyRef: { name: astrololo-demo, key: SESSION_SECRET }
# Za Ingressem bezpośrednim rozmówcą jest pod Traefika. Bez tego limit
# liczyłby WSZYSTKICH do jednego wiadra i pierwsza osoba, która go
# wyklika, odcięłaby pozostałe.
- name: TRUST_PROXY
value: "true"
# Niższy niż w pełnej aplikacji: demo bywa udostępniane szerzej,
# a każde zapytanie sięga do treści baz.
- name: RATE_LIMIT_PER_MIN
value: "60"
resources:
requests: { cpu: "50m", memory: "96Mi" }
limits: { cpu: "300m", memory: "256Mi" }
---
apiVersion: v1
kind: Service
metadata:
name: astroklient-demo
namespace: astrololo
spec:
# ClusterIP — wejście z zewnątrz wyłącznie przez Ingress po https, tak samo
# jak prezentacja. Druga, nieszyfrowana droga byłaby obejściem PRE-16.
type: ClusterIP
selector: { app: astroklient-demo }
ports: [{ port: 8005, targetPort: 8005 }]
+4
View File
@@ -34,6 +34,10 @@ spec:
imageName: gitea.czernobog.pl/gitea/astrololo-presentation imageName: gitea.czernobog.pl/gitea/astrololo-presentation
- alias: render - alias: render
imageName: gitea.czernobog.pl/gitea/astrololo-render imageName: gitea.czernobog.pl/gitea/astrololo-render
# Wersja demo (PRE-28). Obraz, którego nie ma na tej liście, NIGDY się nie
# podbije, choćby CI go budowało — tak przez chwilę wisiał render na :latest.
- alias: astroklient-demo
imageName: gitea.czernobog.pl/gitea/astrololo-astroklient-demo
commonUpdateSettings: commonUpdateSettings:
updateStrategy: newest-build updateStrategy: newest-build
writeBackConfig: writeBackConfig:
+7 -3
View File
@@ -6,15 +6,19 @@ resources:
- data.yaml - data.yaml
- logic.yaml - logic.yaml
- presentation.yaml - presentation.yaml
- astroklient-demo-stack.yaml # OSOBNA warstwa danych i logiki dla demo (PRE-29)
- astroklient-demo.yaml # wersja demo (PRE-28) — sekret astrololo-demo POZA repo
- 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
images: images:
- name: gitea.czernobog.pl/gitea/astrololo-data - name: gitea.czernobog.pl/gitea/astrololo-data
newTag: baf4e0e3 newTag: ee3c515d
- name: gitea.czernobog.pl/gitea/astrololo-logic - name: gitea.czernobog.pl/gitea/astrololo-logic
newTag: baf4e0e3 newTag: ee3c515d
- name: gitea.czernobog.pl/gitea/astrololo-render - name: gitea.czernobog.pl/gitea/astrololo-render
newTag: latest newTag: latest
- name: gitea.czernobog.pl/gitea/astrololo-astroklient-demo
newTag: latest
- name: gitea.czernobog.pl/gitea/astrololo-presentation - name: gitea.czernobog.pl/gitea/astrololo-presentation
newTag: a8339659 newTag: ee3c515d
+2 -2
View File
@@ -8,9 +8,9 @@ resources:
- deploy-bot-backup.yaml - deploy-bot-backup.yaml
images: images:
- name: gitea.czernobog.pl/gitea/conjurer-librarian - name: gitea.czernobog.pl/gitea/conjurer-librarian
newTag: ae1bd677 newTag: d0c7ab61
- name: gitea.czernobog.pl/gitea/conjurer-bot - name: gitea.czernobog.pl/gitea/conjurer-bot
newTag: fbd1ec9f newTag: d0c7ab61
# Production bot channel - only bumped when a [deploy]-tagged build appears. # Production bot channel - only bumped when a [deploy]-tagged build appears.
# Bootstrapped to fbd1ec9f: that's the image the first [deploy] build (merge # Bootstrapped to fbd1ec9f: that's the image the first [deploy] build (merge
# of conjurer#20) promoted to conjurer-bot-deploy. From here the image-updater # of conjurer#20) promoted to conjurer-bot-deploy. From here the image-updater