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>
This commit is contained in:
@@ -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 astrodemo 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-astrodemo` 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 }]
|
||||
Reference in New Issue
Block a user