AiHummer
Dansk▾
Log indKonto
v1.0.x▾
v1.2.xstablev1.1.xstablev1.0.xstable
{ }Swagger
Operationer/Opgraderingspolitik

Opgraderingspolitik

v1.0.x · opdateret 2026-08-04

Stabilitet er et produktprincip, ikke en eftertanke. AiHummer følger SemVer, gælder fremad-sikre database-migrationer automatisk, og kan selvopdatering fra en CDN — så opgraderinger er rutinemæssige snarere end risikable.

Versionering (SemVer)

Udgivelser følger semantisk versionering. Versionen rapporteres af /healthz og ved aihummer version, så du altid kan bekræfte præcist, hvad der kører før og efter en opgradering.

Migrationer er fremadkompatible og automatiske

Ved opstart anvender gatewayen automatisk ventende database-migrationer. To egenskaber holder dette sikkert:

  • Fremad-sikker. Migrationer er skrevet, så en nyere binær fungerer mod skemaet det migrerer til, hvilket er det, der gør automatisk anvendelse og løbende opgraderinger sikre.
  • Enkeltansøger via rådgivende lås. Migrationer kører under en PostgreSQL vejledende lås, så når flere gateways starter på samme tid, gælder kun én dem og resten venter — aldrig en dobbelt migration.

[!NOTE] Migrationer kører altid på ejer-databasepuljen. Den begrænsede RLS-rolle (AIHUMMER_DB_APP_URL) er til at håndtere trafik, ikke til skemændringer.

Opdatering

Nye versioner hentes fra leverandørens release-CDN. Den understøttede måde er én enkelt kommando på serveren:

aihummer update --check   # only report whether a newer version exists
aihummer update           # download and apply it

--check skriver ingenting og kræver derfor ikke root. At tage en opdatering i brug omskriver installationsroden og genstarter tjenesten, så den kørsel foretages med sudo.

Forventet resultat: --check udskriver den nuværende og den tilgængelige version og afslutter uden at ændre noget. aihummer update henter artefakten, kontrollerer dens sha256-sum og dens cosign-signatur, skifter binærfilen og genstarter tjenesten — hvorefter aihummer version viser den nye version. Passer kontrollen ikke, afbrydes opdateringen før skiftet: den kørende version efterlades urørt.

[!NOTE] Automatisk opdatering slås til af leverandøren, ikke af dig. Tilstand og tidsplan for automatisk opdatering hører til vedligeholdelsen af udgivelsen og sættes gennem et signeret direktiv fra leverandøren. Knapper til det findes hverken i webgrænsefladen eller i aihummer settings, og variabler til automatisk opdatering skrevet ind i gateway.env læses ikke af gatewayen — ser du dem der, har de ingen virkning. Vil du opdatere efter din egen plan, bruger du kommandoen aihummer update ovenfor.

Tilbagerulning

Hvad der kan rulles tilbage, punkt for punkt:

  • Binærfilen — kan sættes tilbage til den forrige version (artefakter fra tidligere udgivelser bliver liggende på CDN’en; geninstaller den version, du vil have).
  • Databaseskemaet — migrationerne er fremad-sikre, så den forrige binærfil fungerer mod det nyere skema; en særskilt tilbagerulning af skemaet er ikke nødvendig.
  • Udvidelser — versionerne styres pr. installation; rul en udvidelse tilbage fra kataloget, hvis du har brug for det.
  • Konfigurationen — røres ikke af en opdatering; gendan den fra en sikkerhedskopi efter behov.

Udrulninger uden nedetid

AiHummer er bygget til at opgradere uden nedetid:

  • Kør 2+ gateways bag en proxy. Rul dem en ad gangen; readiness-proben (/readyz) holder en genstartende node ude af rotation, indtil den er i drift.
  • Planlæggeren er enkeltleder. Baggrundsplanlægning vælger en enkelt leder via en PostgreSQL rådgivningslås, så kørsel af flere gateways ikke fordobler planlagt arbejde.
  • Levering er idempotent. Pålidelig levering plus idempotensnøgler betyder en svaret sendes aldrig to gange på tværs af en genstart, hvilket er det, der gør en rullende genstart sikkert på tværs af dine gateways.

Hvor til næste