Files
alva/felsokning/infra/terraform
Claude 301c477e25 Merge main: Guidad Felsökning flyttar ur roten till felsokning/
Main är sedan den här grenen skapades en helt annan produkt — Semantika,
en mobilapp med egen CDK-infrastruktur. Den äger nu repots rot: en
npm-workspaces-monorepo med apps/mobile, services/api och infra.

För att båda ska rymmas i samma repo flyttar Guidad Felsökning in i en
egen katalog i stället för att göra anspråk på roten:

  felsokning/app        webbklienten (Vite, egen package.json och
                        eslint-/vitest-konfiguration)
  felsokning/services   plattformstjänsten och AI-orkestern
  felsokning/infra      Terraform och databasschemat
  felsokning/docs       vision, moduler, drift
  felsokning/supabase   edge-funktion och migrationer

Merge:n hade tagit bort 128 filer som Guidad Felsökning bygger på —
värdapplikationens komponenter, Supabase-klienten, tillgångar — eftersom
main raderat dem och den här grenen inte råkat ändra just dem. De är
återställda på sin nya plats. Utan dem gick varken bygget eller
testerna: ai.ts och synk.ts importerar Supabase-klienten.

Semantikas rotfiler är orörda: package.json, eslint.config.js och
.github/workflows/ är deras. Guidad Felsökning har egna motsvarigheter i
sin katalog.

CI flyttar samtidigt från GitHub Actions till .gitea/workflows — samma
syntax, egna runners. .github/workflows/ tillhör Semantika härefter.

Verifierat på den nya platsen: 96 vitest-tester, typkontroll, eslint på
både klient och tjänster, bygge, och integrationstest mot riktig Postgres.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt
2026-08-04 12:22:49 +00:00
..

Infrastrukturen

Hela systemet i Terraform. Filerna är numrerade i den ordning de är begripliga att läsa:

Fil Vad
versions.tf Leverantörer och tillståndsbackend
variables.tf Allt som skiljer en installation från en annan
karta.tf Systemet som data — tjänster, portar, routing, hemligheter, dataflöden, gränser
10-namnrymd.tf Namnrymd, hemligheten, databasschemat
20-databas.tf Händelseloggen — tre lägen, se nedan
30-plattform.tf Backend: auth, händelse-API, delning, integrationer
40-orkester.tf AI-orkestern
50-web.tf Klienten
60-ingress.tf Trafiken utifrån
70-natverk.tf Nätverkspolicyer — vem får prata med vem
outputs.tf Kartan utskriven

Börja i karta.tf. Den beskriver systemet en gång, som data; resten av filerna läser därifrån i stället för att upprepa portar och namn.

Kom igång

cp terraform.tfvars.exempel terraform.tfvars   # fyll i domän, register, nycklar
terraform init
terraform plan
terraform apply
terraform output karta                         # hela systemet i klartext

terraform output karta svarar på frågorna "vad kör var", "vem ser vilken hemlighet", "vad pratar med vad" och "vad ingår inte" — utan att någon behöver läsa .tf-filerna.

Kontroll utan kluster

terraform fmt -check -diff        # formatering
terraform init -backend=false     # hämtar leverantörer
terraform validate                # typer och referenser

terraform validate kräver att leverantörerna hämtats från registry.terraform.io.

Databasen: tre lägen

var.databas_lage saknar standardvärde med flit. Valet avgör om det finns säkerhetskopiering, och det ska inte kunna bli fel av slentrian.

Läge Backup Failover Använd när
extern Leverantörens, med PITR Leverantörens Produktion. Cloud SQL, RDS, Neon, Azure Flexible Server
cnpg Basbackup 02:30 + WAL-arkiv → objektlagring, PITR Ja, databas_instanser styr Produktion när databasen måste ligga i klustret
inbyggd Ingen Nej Prov och demo. Blockeras av en precondition när miljo = "produktion"

Går händelseloggen förlorad är det inte "data" som försvinner utan varje ärendes bevisvärde: vad som kontrollerades, av vem, när, med vilken evidens. Det går inte att återskapa i efterhand.

cnpg kräver att CloudNativePG-operatorn redan är installerad — Terraform slår upp dess CRD vid plan:

kubectl apply --server-side -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.25/releases/cnpg-1.25.0.yaml

I extern läge ansvarar ni själva för att köra infra/postgres-init.sql mot databasen. Det är samma fil som integrationstestet kör, så schemat kan inte glida isär från det som testas.

Driftsättning

Bilderna byggs av publicera.yml vid varje push till main och taggas med git-SHA:t. Driftsättningen är ett eget flöde, driftsatt.yml, som startas för hand med en tagg och kör mot GitHub-miljön produktion — den kan kräva godkännande. Rollback är att köra flödet igen med en tidigare tagg.

Kustomize- och Argo CD-vägen är borttagen. Den beskrev samma system en gång till och kunde inte köras samtidigt som Terraform utan att de motarbetade varandra (selfHeal återställde det Terraform ändrade, prune tog bort det Terraform skapade).

Det som medvetet inte ingår

Står också i terraform output karta under avgränsningar:

  • Objektlagring. Foton och video ligger som data-URL:er i händelseloggen. Det gör loggen till systemets enda sanningskälla, men också stor och tung att säkerhetskopiera.
  • Observability. Ingen metrikexport, ingen tracing.
  • Takt-begränsning på inloggning. Bara den publika beslutsvägen är begränsad, och bara per pod.
  • Återkallelse av JWT. En utfärdad token gäller sina 12 timmar ut även om användaren tagits bort.

Krav på klustret

  • En CNI som tillämpar NetworkPolicy (Cilium, Calico, Antrea). Utan det är 70-natverk.tf dokumentation, inte skydd.
  • ingress-nginx, med kontrollern i namnrymden var.ingress_namnrymd.
  • cert-manager med en ClusterIssuer.
  • En metrics-server för autoskalningen.
  • En StorageClass som klarar ReadWriteOnce.