gitea
16240466ec
Domyka drabinę produktów: astrodemo (dwie funkcje) → astroklient → astrololo. Host astroklient.czernobog.pl, obraz astrololo-astroklient, port 8006. WŁASNY STOS, NIE WSPÓLNY. Nowa para data-astroklient + logic-astroklient i nowy udział /mnt/Tank1/astrololo-klient. Pule kont izolują klientów od siebie w każdym wariancie, ale to izolacja PROGRAMOWA — opiera się na poprawności mechanizmu pul. Granica na poziomie systemu plików nie zależy od tego, czy w kodzie niczego nie przeoczono, a przy sprzątaniu demo nie da się przez pomyłkę skasować cudzych danych, bo leżą gdzie indziej. Klaster ma zapas (węzły na 24–38% pamięci), więc koszt dwóch podów nie był argumentem przeciw. Silnik własny (permisywny) — silnik B (AGPL) nie wchodzi do produktu oddawanego klientom. data-astroklient dostaje nodeAffinity na etykietę zdolności procesora, jak pozostałe warstwy danych: ciągnie pandas, a przez nią NumPy z bazą x86-64-v2. WPIS W LIŚCIE OBSERWOWANYCH OBRAZÓW od razu, z komentarzem dlaczego. Bez niego usługa nie deployuje się sama: obraz powstaje w rejestrze, kustomization zostaje na starym tagu, i wygląda to na zepsute CI. Tak zawisł kiedyś render. Certyfikat obejmuje trzeci host; DNS już wskazuje (wildcard). RUNBOOK: udział NFS ze WSZYSTKIMI CZTEREMA węzłami, konta jako hashe scrypt, własny SESSION_SECRET i własna nazwa ciasteczka (trzy produkty nie mają powodu uznawać nawzajem swoich sesji), unieważnianie dostępu bez wolumenu stanu, oraz sprawdzenie po wdrożeniu. W sprawdzeniu poprawiona rzecz, którą najpierw napisałem błędnie: BEZ SESJI każdy adres oddaje 303, także nieistniejący, bo bramka logowania działa przed trasowaniem. Pętla curl bez ciasteczka pokazywałaby 303 dla wszystkiego i sugerowała, że nieobecne ekrany „są". Sprawdzenie ma sens dopiero z sesją — i wtedy dają 404, nie 403. Zweryfikowane: kustomize build (37 obiektów), dry-run serwerowy przyjmuje wszystkie osiem nowych obiektów, kody odpowiedzi sprawdzone na złożonym drzewie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
70 lines
2.6 KiB
YAML
70 lines
2.6 KiB
YAML
# Certyfikat dla wejścia do aplikacji (PRE-16).
|
|
#
|
|
# Dlaczego WŁASNE CA, a nie Let's Encrypt: klaster stoi w LAN (traefik trzyma
|
|
# LoadBalancera na 192.168.1.x), więc walidacja HTTP-01 nie ma jak dojść z
|
|
# internetu, a DNS-01 wymagałby trzymania w klastrze tokena API do domeny.
|
|
# Własne CA nie potrzebuje niczego z zewnątrz, a certyfikaty odnawia samo.
|
|
#
|
|
# WYMAGANIE WSTĘPNE: cert-manager musi być w klastrze PRZED synchronizacją tego
|
|
# katalogu — inaczej API odrzuci poniższe obiekty jako nieznane rodzaje zasobów.
|
|
# Instalacja jednorazowa: patrz README.md.
|
|
#
|
|
# Wszystko jest w namespace `astrololo` (Issuer, nie ClusterIssuer) świadomie:
|
|
# ArgoCD ma tu włączone `prune`, a zasoby o zasięgu całego klastra chcemy trzymać
|
|
# poza aplikacją, która może zostać skasowana.
|
|
---
|
|
apiVersion: cert-manager.io/v1
|
|
kind: Issuer
|
|
metadata:
|
|
name: selfsigned
|
|
namespace: astrololo
|
|
spec:
|
|
selfSigned: {}
|
|
---
|
|
# Korzeń zaufania. TO JEST certyfikat, który raz importujesz do przeglądarki
|
|
# i systemu — patrz README. Stąd długi termin ważności: importu nie chcemy
|
|
# powtarzać co kwartał.
|
|
apiVersion: cert-manager.io/v1
|
|
kind: Certificate
|
|
metadata:
|
|
name: astrololo-ca
|
|
namespace: astrololo
|
|
spec:
|
|
isCA: true
|
|
commonName: astrololo internal CA
|
|
secretName: astrololo-ca # tu lądują klucz i certyfikat korzenia
|
|
duration: 87600h # 10 lat
|
|
renewBefore: 8760h # odnowienie na rok przed końcem
|
|
privateKey: { algorithm: ECDSA, size: 256 }
|
|
issuerRef: { name: selfsigned, kind: Issuer, group: cert-manager.io }
|
|
---
|
|
apiVersion: cert-manager.io/v1
|
|
kind: Issuer
|
|
metadata:
|
|
name: astrololo-ca
|
|
namespace: astrololo
|
|
spec:
|
|
ca: { secretName: astrololo-ca }
|
|
---
|
|
# Właściwy certyfikat serwera. Krótki termin CELOWO: przy 90 dniach odnawianie
|
|
# jest sprawdzane w praktyce co kwartał, więc awaria wyjdzie od razu, a nie za
|
|
# dziesięć lat, gdy nikt już nie będzie pamiętał, jak to działa.
|
|
apiVersion: cert-manager.io/v1
|
|
kind: Certificate
|
|
metadata:
|
|
name: astrololo-tls
|
|
namespace: astrololo
|
|
spec:
|
|
secretName: astrololo-tls # tego szuka Ingress
|
|
commonName: astrololo.czernobog.pl
|
|
dnsNames:
|
|
- astrololo.czernobog.pl
|
|
# Jeden certyfikat na oba hosty. Osobny wymagałby osobnego sekretu i osobnego
|
|
# odnawiania, a to ten sam klaster i ten sam wystawca.
|
|
- astrodemo.czernobog.pl
|
|
- astroklient.czernobog.pl
|
|
duration: 2160h # 90 dni
|
|
renewBefore: 720h # 30 dni zapasu
|
|
privateKey: { algorithm: ECDSA, size: 256, rotationPolicy: Always }
|
|
issuerRef: { name: astrololo-ca, kind: Issuer, group: cert-manager.io }
|