AiHummer
Polski▾
Zaloguj sięKonto
v1.1.x▾
v1.2.xstablev1.1.xstablev1.0.xstable
{ }Swagger
Operacje/Polityka aktualizacji

Polityka aktualizacji

v1.1.x · zaktualizowany 2026-08-04

Stabilność jest zasadą produktu, a nie przemyśleniem po fakcie. AiHummer stosuje się do tego SemVer, stosuje się automatyczne migracje bazy danych bezpieczne w przód, i może aktualizacja własna z CDN — więc aktualizacje są rutynowe, a nie ryzykowne.

Wersjonowanie (SemVer)

Wydania stosują wersjonowanie semantyczne. Wersja jest raportowana przez /healthz i przez aihummer version, dzięki czemu zawsze możesz dokładnie potwierdzić, co działa przed i po aktualizacji.

Migracje są bezpieczne w przód i automatyczne

Przy uruchamianiu brama automatycznie stosuje oczekujące migracje bazy danych. Dwie właściwości zapewniają bezpieczeństwo tego procesu:

  • Bezpieczny do przodu. Migracje są pisane tak, aby nowszy plik binarny działał z schemat, do którego migruje, co sprawia, że automatyczne stosowanie i stopniowe aktualizacje są bezpieczne.
  • Pojedynczy zastosowujący przez blokadę doradczą. Migracje uruchamiane są pod PostgreSQL blokada doradcza, więc kiedy kilka bramek uruchamia się jednocześnie, tylko jedna je zastosuje a reszta czeka — nigdy podwójnej migracji.

[!NOTE] Migracje zawsze działają na puli baz danych właściciela. Ograniczona rola RLS (AIHUMMER_DB_APP_URL) służy do obsługi ruchu, a nie do zmian w schemacie.

Aktualizacja

Nowe wersje pobierane są z wydaniowego CDN dostawcy. Standardowym sposobem aktualizacji jest jedno polecenie na serwerze:

aihummer update --check   # tylko sprawdź, czy jest nowsza wersja
aihummer update           # pobierz i zastosuj

--check niczego nie zapisuje, więc nie wymaga uprawnień root. Samo zastosowanie aktualizacji przepisuje katalog instalacji i restartuje usługę, dlatego uruchamia się je przez sudo.

Oczekiwany wynik: --check wypisuje wersję bieżącą i dostępną, po czym kończy pracę, niczego nie zmieniając. aihummer update pobiera artefakt, sprawdza jego sumę kontrolną sha256 i podpis cosign, podmienia plik binarny i restartuje usługę — po czym aihummer version pokazuje nową wersję. Jeśli weryfikacja się nie powiedzie, aktualizacja przerywa się przed podmianą pliku: działająca wersja pozostaje nietknięta.

[!NOTE] Automatyczną aktualizację włącza dostawca, a nie Ty. Tryb i harmonogram automatycznych aktualizacji należą do obsługi wydania i są ustawiane podpisanym poleceniem dostawcy. Odpowiednich przełączników nie ma ani w interfejsie WWW, ani w aihummer settings, a zmienne automatycznej aktualizacji wpisane do gateway.env nie są przez bramę odczytywane — jeśli je tam widzisz, nie mają żadnego wpływu. Aby aktualizować według własnego harmonogramu, użyj powyższego polecenia aihummer update.

Wycofanie zmian

Co da się wycofać, punkt po punkcie:

  • Plik binarny — można wrócić do poprzedniej wersji (artefakty wcześniejszych wydań pozostają w CDN; zainstaluj ponownie potrzebną wersję).
  • Schemat bazy danych — migracje są zgodne w przód, więc poprzedni plik binarny działa z nowszym schematem; osobnego wycofania schematu nie ma.
  • Wtyczki — wersje są zarządzane osobno dla każdej instalacji; w razie potrzeby przywróć poprzednią wersję wtyczki z katalogu.
  • Konfiguracja — nie zmienia się przy aktualizacji; w razie potrzeby przywróć ją z kopii zapasowej.

Wdrażanie bez przestojów

AiHummer jest zaprojektowany tak, aby można go było aktualizować bez przestojów:

  • Uruchom 2+ bram za proxy. Rzucaj je pojedynczo; sonda gotowości (/readyz) utrzymuje ponownie uruchamiany węzeł poza rotacją, dopóki nie zacznie obsługiwać.
  • Harmonogram jest jednostronny. Harmonogramowanie w tle wybiera jednego lidera za pomocą blokady doradczej PostgreSQL, więc uruchamianie wielu bramek nie powoduje duplikacji zaplanowana praca.
  • Dostawa jest idempotentna. Niezawodna dostawa oraz klucze idempotencji oznaczają odpowiedź nigdy nie jest wysyłana dwukrotnie po ponownym uruchomieniu, co sprawia, że jest to ciągłe bezpieczny restart na wszystkich twoich bramach.

Dokąd dalej