AiHummer
Svenska▾
Logga inKonto
v1.0.x▾
v1.2.xstablev1.1.xstablev1.0.xstable
{ }Swagger
Operationer/Uppgraderingspolicy

Uppgraderingspolicy

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

Stabilitet är en produktprincip, inte en eftertanke. AiHummer följer SemVer, gäller framåt-säkra databas-migreringar automatiskt, och kan självuppdatering från ett CDN — så uppgraderingar är rutinmässiga snarare än riskfyllda.

Versionering (SemVer)

Utgåvor följer semantisk versionering. Versionen rapporteras av /healthz och av aihummer version, så att du alltid kan bekräfta exakt vad som körs före och efter en uppgradering.

Migrationer är framåtsäkra och automatiska

Vid start tillämpar gatewayen automatiskt väntande databasuppdateringar. Två egenskaper håller detta säkert:

  • Framåt-säker. Migrationer skrivs så att en nyare binär fungerar mot schemat det migrerar till, vilket är vad som gör automatisk tillämpning och rullande uppgraderingar säkra.
  • Endast en ansökan åt gången via rådgivande lås. Migreringar körs under en PostgreSQL rådgivande lås, så när flera gateways startar samtidigt tillämpas bara en av dem och resten väntar — aldrig en dubbel migration.

[!NOTE] Migrationer körs alltid på ägardatabaspoolen. Den begränsade RLS-rollen (AIHUMMER_DB_APP_URL) är för att hantera trafik, inte för schemaväxlingar.

Uppdatering

Nya versioner hämtas från leverantörens release-CDN. Det som stöds är ett enda kommando på servern:

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

--check skriver ingenting och behöver därför inte root. Att faktiskt tillämpa en uppdatering skriver om installationsroten och startar om tjänsten, så den körningen görs med sudo.

Förväntat resultat: --check skriver ut nuvarande och tillgänglig version och avslutas utan att ändra något. aihummer update hämtar artefakten, kontrollerar dess sha256-summa och dess cosign-signatur, byter binären och startar om tjänsten — därefter visar aihummer version den nya versionen. Stämmer kontrollen inte avbryts uppdateringen innan bytet: versionen som körs lämnas orörd.

[!NOTE] Automatisk uppdatering slås på av leverantören, inte av dig. Läge och tidsschema för automatisk uppdatering hör till underhållet av utgåvan och sätts genom ett signerat direktiv från leverantören. Reglage för detta finns varken i webbgränssnittet eller i aihummer settings, och variabler för automatisk uppdatering som skrivits in i gateway.env läses inte av gatewayen — ser du dem där påverkar de ingenting. Vill du uppdatera enligt ditt eget schema använder du kommandot aihummer update ovan.

Återställning

Vad som går att rulla tillbaka, punkt för punkt:

  • Binären — kan återställas till föregående version (artefakter från tidigare utgåvor ligger kvar på CDN; installera om den version du vill ha).
  • Databasschemat — migrationerna är framåtsäkra, så den föregående binären fungerar mot det nyare schemat; någon separat återställning av schemat behövs inte.
  • Insticksmoduler — versionerna hanteras per installation; rulla tillbaka en insticksmodul från katalogen om du behöver.
  • Konfigurationen — rörs inte av en uppdatering; återställ den från en säkerhetskopia vid behov.

Utrullningar utan driftstopp

AiHummer är byggd för att uppgradera utan avbrott:

  • Kör 2+ gateways bakom en proxy. Rulla dem en i taget; beredskapsproben (/readyz) håller en omstartande nod utanför rotation tills den tjänstgör.
  • Schemaläggaren är en ensam ledare. Bakgrundsschemaläggning väljer en enda ledare via ett PostgreSQL-rådgivningslås, så att körning av flera gateways inte dupliceras schemalagt arbete.
  • Leverans är idempotent. Tillförlitlig leverans plus idempotensnycklar betyder en svar skickas aldrig två gånger över en omstart, vilket är det som gör en rullande starta om säkert över dina gateways.

Vart härnäst