2025-08-24_k8s_infra_refaktorering#

2025-08-24 — Konsoliderad konfiguration & secrets, härdad runtime och standardiserade app-inställningar

Sammanfattning#

Vi har omarbetat projektet så att .env i repots root nu är den enda sanningskällan för konfiguration i alla miljöer:

  • Lokal utveckling (Docker Compose) läser .env direkt via env_file. DATABASE_URL sätts ihop från .env-variabler och är inte hårdkodad.

  • Kubernetes använder inte längre någon Secret-fil i repository. Istället läser Kustomize secretGenerator från ../.env vid build och skapar Secret-dokumentet dynamiskt. Inga secrets lagras i repo.

  • Applikationskoden (FastAPI, bakgrundsjobb, workers) läser konfigurationen uteslutande via app.config.settings (Pydantic Settings). Alla utspridda os.getenv(...) har tagits bort.

  • Makefile / arbetsflöden: Kubernetes deploy är en explicit och valfri operation (kustomize build k8s | kubectl apply -f - alternativt make k8s-apply). Lokal utveckling fungerar som tidigare med docker compose up --build.

Detta minskar spridningen av secrets, eliminerar oklarheter om var konfigurationen bor och gör misstag svårare att begå.

Syfte & Avgränsningar#

Syfte#

  • Centralisera all konfiguration i .env för både lokal och deployment-flöde.

  • Ta bort all hårdkodad eller duplicerad secrets och gamla YAML-filer.

  • Standardisera åtkomst till konfiguration via ett Python-inställningsobjekt.

  • Behåll enkel lokal utveckling—docker compose up --build ska alltid fungera.

Ej Syfte#

  • Ingen MkDocs-anpassning i denna journal (hanteras separat).

  • Ingen förändring av runtime-arkitekturen utöver config/secrets-hantering.

  • Inga ändringar i containerimages utöver config/env-paritet.

Implementerade ändringar#

1) Docker Compose (lokalt)#

Compose-tjänster använder nu env_file: .env.

DATABASE_URL sätts ihop från variabler (POSTGRES_DB, POSTGRES_USER, POSTGRES_PASSWORD, DATABASE_HOST, DATABASE_PORT) istället för hårdkodad eller duplicerad text.

Motivering: Undviker dubbla sanningar och håller miljöändringar på ett ställe.

Acceptanskriterier#

  • Ändringar i .env (DB, användare, lösenord, host, port) och sedan docker compose up --build uppdaterar hela stacken utan kod- eller YAML-patchning.

  • Inga plaintext credentials checkas in.

2) Kubernetes via Kustomize#

Ny k8s/kustomization.yaml med:

  • secretGenerator som heter postgres-secrets och läser från envs: ["../.env"].

  • generatorOptions.disableNameSuffixHash: true för att hålla Secret-namnet stabilt.

  • resources: pekar på befintliga manifest (exempelvis postgres-deployment.yaml).

  • k8s/postgres-secret.yaml är borttagen från repo och tillagd i .gitignore.

  • k8s/postgres-deployment.yaml refererar fortsatt till envFrom: secretRef → postgres-secrets.

Operativt flöde vid K8s-deploy:

kustomize build k8s | kubectl apply -f -

eller

make k8s-apply

Varför inte auto-apply K8s vid Compose?

Compose och K8s är skilda orchestrators. Om Compose triggar kubectl innebär det skör koppling mot host kubeconfig och kan ge oväntade sidoeffekter. Branschstandard är att hålla Compose (lokalt) och K8s (cluster) separata. Lokalt behövs Kubernetes inte alls.

Acceptanskriterier#

  • Deployers som använder K8s kan applicera alla manifests med ett kommando, utan att någonsin editera YAML-secrets. .env styr hela flödet.

3) Applikationskonfiguration (Python)#

All konfiguration (DB URL, loggsökvägar, datavolymer, ML-hyperparametrar, UA, koordinater mm) hanteras nu via app.config.settings (Pydantic Settings).

Alla användningar av os.getenv(...) i koden har bytts ut mot settings.<FÄLT>, t ex:

  • Konsumtenter av DATABASE_URL i träningsjobb och triggers.

  • FASTAPI_LOG_PATH, SLURM_JOB_DATA_PATH

  • ML-parametrar: ML_NUM_EPOCHS, ML_LEARNING_RATE, ML_BATCH_SIZE, ML_TEST_SIZE, ML_MIN_DATA_POINTS

  • Optionella fält (t ex MY_LAT, MY_LONG) mappas med Field(..., env="...") där det är relevant.

Acceptanskriterier#

  • En minimal .env styr Compose och applikation utan kodändringar.

  • ML-parametrar och paths kan ändras via .env utan kod-patchning.

4) Makefile och README#

Makefile#

  • Lagt till target för k8s-apply samt k8s-dry-run.

  • K8s är inte bunden till allmänt “build”-steg för att inte tvinga K8s på lokala utvecklare. K8s är fortsatt explicit och valfritt.

README#

  • Ny sektion “Secrets & Configuration” som förklarar .env-flödet för Compose, K8s (Kustomize), och Python-settings.

Riskanalys & hantering#

  • Risk: Gamla Secrets ligger på K8s-klustret. Hantering: K8s-deploy sker i ett steg (kustomize build k8s | kubectl apply -f -) som alltid genererar secrets från .env.

  • Risk: Oavsiktlig läcka av secrets till repo. Hantering: Tog bort k8s/postgres-secret.yaml och la till motsvarande i .gitignore; README förtydligar flödet.

  • Risk: Kodvägar som kringgår settings. Hantering: Full sopning med ersättning av os.getenv(...) till settings. Framtida policy är att alltid importera från app.config.

Testplan#

Lokal Compose#

  • Redigera .env, ändra DB-kredentialer, kör docker compose up --build.

  • Verifiera att DB kopplar upp, app startar och loggar skrivs till settings.FASTAPI_LOG_PATH.

Setting-mappning#

  • Tillfälligt ändra ML-miljövariabler i .env.

  • Verifiera att träningsjobbet snappar upp värden (settings.ML_*) utan kodändring.

K8s torrkörning (valfritt)#

  • kustomize build k8s | head -n 120 för att granska Secret och env-injektion.

  • Full apply kan ske mot ett kluster när det behövs.

Återställningsplan#

  • Om en miljö slutar fungera, kan man tillfälligt ange DATABASE_URL direkt i .env och referera den explicit i settings.

  • I nödfall: återställ commiten som tog bort k8s/postgres-secret.yaml och gå tillbaka till tidigare beteende (varnas för).

Uppföljning (ej MkDocs)#

Secrets & Konfigurering#

  • Sanningskälla: .env i projektroten

  • Lokal utveckling: Compose-tjänster läser .env via env_file. DATABASE_URL sätts ihop från variabler (ingen hårdkodning).

  • Kubernetes: secrets genereras dynamiskt från .env via Kustomize:

    kustomize build k8s | kubectl apply -f -

    eller

    make k8s-apply

  • Ingen YAML med secrets committas.

  • Python-app: all konfiguration konsumeras via app.config.settings (Pydantic Settings) och läses in från .env.

Lägg till detta i dagboksfilen (Svenska)#

2025-08-24 — Konfigurationsenhetlighet & stärkt secrets-hantering (ej MkDocs)#

  • All konfiguration konsoliderad: .env är sanningskälla för både lokal och deployment.

  • Docker Compose läser .env genom env_file och skapar DATABASE_URL utifrån komponenter (ingen hårdkodning).

  • Kubernetes nyttjar Kustomize secretGenerator (läser in ../.env), med disableNameSuffixHash: true och postgres-secrets hänvisat från envFrom: secretRef. Den gamla k8s/postgres-secret.yaml är borttagen och ignoreras av git.

  • Applikationskod konsumerar inställningar uteslutande från app.config.settings (Pydantic Settings). All användning av os.getenv(...) har ersatts av settings.<FÄLT>, bl a för DB URL, logg/datasökvägar och ML-parametrar.

  • Makefile har fått mål för k8s-apply och k8s-dry-run. Kubernetes-deploy är fortsatt explicit; lokal utveckling påverkas inte (docker compose up --build).

  • README har fått en sammanfattande “Secrets & Configuration”-sektion som dokumenterar flödet.

Resultat: Inga secrets finns kvar i repo; konfigurationsändringar hanteras på ett ställe (.env); både lokal och K8s deploy är tydliga och friktionsfria.