Gå till innehållet

Drift och skalning

Hodor är en fristående .NET 10-webbapplikation som själv-hostar via Kestrel på port 5200 och serverar den färdigbyggda Angular-appen från samma process. Den kan därför köras i container (OpenShift/Kubernetes), som en Linux-tjänst eller på en Windows-server — utan att koden ändras. Metadatabasen är alltid en extern SQL Server eller PostgreSQL.

Bara tre saker utgör körningens tillstånd:

Tillstånd Var det ligger Måste överleva omstart
Scheman, körhistorik, körlås Metadatabasen (SQL Server / Postgres) Ja — extern databas
Pipelines (.hodor) Hodor:PipelinesFolder (volym /data) Ja
Data Protection-nycklar Hodor:KeysPath (volym /data) Ja — annars går krypterade hemligheter förlorade

Vad händer om processen/podden dör?

Ingenting går förlorat, och en orkestrerare (OpenShift, systemd, Windows) startar om den automatiskt.

  • Schemana överlever. Databasen är sanningskällan. Vid start läser Hodor tillbaka alla aktiverade cron-scheman från databasen och registrerar om dem.
  • Missade körningar tas igen. Var processen nere när en nattladdning skulle köra, triggas en igenkörning vid uppstart (jämför senaste körning mot cron). Stäng av med Hodor:Scheduler:CatchUpMissedRuns=false.
  • Avbrutna körningar städas. En körning som stod på Running när processen dog markeras som Interrupted och dess körlås rensas, så pipelinen går att köra igen direkt. Laddningarna körs i transaktion med rollback — ingen halvladdad data, bara en avbruten körning som kan startas om.
  • Hälsoprobar. /healthz (liveness) och /readyz (readiness, kontrollerar databasanslutningen). Använd dem som probar så att trafik inte dirigeras in förrän appen är redo.

Skala i OpenShift / Kubernetes

Ett komplett Helm-chart finns under charts/hodor.

En replika (standard)

Standardvärdena kör en replika med en ReadWriteOnce-PVC för /data och deploy-strategin Recreate.

Recreate-strategin ger kort nertid vid deploy

Eftersom /data-volymen är ReadWriteOnce måste den gamla podden avslutas innan den nya kan montera volymen. En uppdatering innebär därför en kort paus — priset för en single-writer-volym.

Flera repliker

Applikationen är byggd för flera repliker: en RunLocks-tabell med heartbeats i databasen ser till att två pods aldrig dubbelkör samma pipeline (den ena tar låset, den andra hoppar över körningen). Ett dött låst rensas efter att dess heartbeat gått ut, så en pipeline aldrig fastnar låst.

För att faktiskt köra fler än en replika måste /data (pipelines + Data Protection-nycklar) flyttas till en ReadWriteMany-volym så att alla pods kan montera den samtidigt:

# values.yaml
replicaCount: 2
persistence:
  accessModes:
    - ReadWriteMany
  storageClassName: <en RWX-klass, t.ex. NFS/CephFS>

Hälsoprobarna (/healthz, /readyz) och en RollingUpdate-strategi ger då noll-nertids-deploy, eftersom flera pods kan mounta volymen samtidigt.


Drift utan container (Linux, systemd)

Ingen Docker behövs — publicera och kör som en vanlig tjänst:

# på byggmaskinen
dotnet publish Hodor.Api -c Release -o ./publish

Kopiera ./publish till servern och kör den som en systemd-tjänst:

# /etc/systemd/system/hodor.service
[Unit]
Description=Hodor ETL
After=network.target

[Service]
WorkingDirectory=/opt/hodor
ExecStart=/usr/bin/dotnet /opt/hodor/Hodor.Api.dll
Restart=always
RestartSec=5
User=hodor
Environment=ASPNETCORE_URLS=http://127.0.0.1:5200
Environment=Database__Provider=Postgres
Environment=Database__ConnectionString=Host=...;Database=hodor;Username=hodor;Password=...
Environment=Jwt__Key=minst-32-tecken-lång-hemlig-nyckel
Environment=Hodor__KeysPath=/var/lib/hodor/keys

[Install]
WantedBy=multi-user.target
sudo systemctl enable --now hodor

Sätt en omvänd proxy (nginx, Traefik) framför port 5200 för HTTPS/TLS. systemd startar om tjänsten automatiskt om den dör (Restart=always).

Slipp installera .NET-runtime på servern

Publicera self-contained så bakas runtime in i mappen: dotnet publish Hodor.Api -c Release --self-contained -r linux-x64 -o ./publish


Windows Server

En av Hodors bästa passformar, eftersom den redan rekommenderar Windows- autentisering mot SQL Server (Trusted_Connection=True) — då innehåller .hodor-filerna inga hemligheter alls. Två standardvägar:

IIS (rekommenderat på Windows)

  1. Installera ASP.NET Core Hosting Bundle (.NET 10) på servern.
  2. dotnet publish Hodor.Api -c Release -o C:\inetpub\hodor.
  3. Skapa en IIS-sajt som pekar på publish-mappen. IIS blir omvänd proxy mot Kestrel (via AspNetCoreModuleV2) och sköter TLS/certifikat i Windows.
  4. Sätt konfiguration (databas, Jwt:Key, Hodor:KeysPath) via miljövariabler på apppoolen eller i appsettings.Production.json.

Windows-tjänst

dotnet publish Hodor.Api -c Release -o C:\hodor
New-Service -Name Hodor -BinaryPathName "C:\Program Files\dotnet\dotnet.exe C:\hodor\Hodor.Api.dll" -StartupType Automatic
Start-Service Hodor

Kestrel lyssnar på port 5200; sätt IIS/ARR eller brandväggen framför för TLS.

SQL Server på samma box

En SQL Server på samma Windows-server (eller domän) är en naturlig kombination — kör Hodor-tjänsten under ett tjänstekonto med åtkomst till databasen och använd Trusted_Connection=True i connection-stringen.