Палітыка абнаўлення

v1.1.x · абноўлена 2026-08-04

Стабільнасць — гэта прынцып прадукту, а не позняя думка. AiHummer прытрымліваецца гэтага SemVer, ужываецца аўтаматычныя бяспечныя міграцыі базы даных наперад, і можа саманавядзенне з CDN — таму абнаўленні з’яўляюцца руціннымі, а не рызыкоўнымі.

Версіяніраванне (SemVer)

Выпускі рэалізуюцца згодна з сэмантычным версіраваннем. Версія паведамляецца /healthz і па aihummer version, таму вы заўсёды можаце дакладна праверыць, што працуе да і пасля абнаўлення.

Міграцыі з’яўляюцца бяспечнымі і аўтаматычнымі

Пры запуску шлюз аўтаматычна прымяняе чакаючыя міграцыі базы дадзеных. Два ўласцівасці забяспечваюць бяспеку гэтага:

Бяспечна наперад. Міграцыі напісаны такім чынам, каб новая бінарная версія працавала з схема, у якую яна мігруе, што робіць аўтаматычнае прымяненне і паступовыя абнаўленні бяспечнымі.
Адзін заявнік праз саветавую блакіроўку. Міграцыі адбываюцца пад PostgreSQL рэкамендаванае блакіраванне, таму калі некалькі шлюзаў запускаюцца адначасова, толькі адзін з іх прымяняе іх а астатнія чакаюць — ніколі падвойнай міграцыі.

[!NOTE] Міграцыі заўсёды выконваюцца на пуле баз дадзеных уладальніка. Абмежаваная роля RLS (AIHUMMER_DB_APP_URL) прызначаны для абслугоўвання трафіку, а не для змены схемы.

Абнаўленне

Новыя версіі забіраюцца з рэлізнага CDN пастаўшчыка. Штатны спосаб абнавіцца — адна каманда на серверы:

aihummer update --check   # толькі паведаміць, ці ёсць навейшая версія
aihummer update           # спампаваць і прымяніць

--check нічога не піша і таму не патрабуе root. Само прымяненне змяняе корань устаноўкі і перазапускае службу, таму запускаецца праз sudo.

Чаканы вынік: --check друкуе бягучую і даступную версіі і завяршаецца, нічога не мяняючы. aihummer update спампоўвае артэфакт, правярае яго кантрольную суму sha256 і подпіс cosign, замяняе бінарны файл, перазапускае службу — пасля чаго aihummer version паказвае новую версію. Калі праверка не сышлася, абнаўленне перарываецца да замены файла: працоўная версія застаецца некранутай.

[!NOTE] Аўтаматычнае абнаўленне ўключае пастаўшчык, а не вы. Рэжым і расклад аўтаабнаўлення ўваходзяць у абслугоўванне выпуску і задаюцца падпісаным прадпісаннем ад пастаўшчыка. Адпаведных пераключальнікаў няма ні ў вэб-інтэрфейсе, ні ў aihummer settings, а зменныя аўтаабнаўлення, прапісаныя ў gateway.env, шлюз не чытае — калі вы іх там бачыце, яны ні на што не ўплываюць. Каб абнаўляцца па сваім раскладзе, карыстайцеся камандай aihummer update вышэй.

Адкат

Што адкочваецца — па пунктах:

Бінарны файл — можа быць вернуты да папярэдняй версіі (артэфакты ранейшых выпускаў застаюцца на CDN; пераўсталюйце патрэбную версію).
Схема базы даных — міграцыі сумяшчальныя наперад, таму папярэдні бінарны файл працуе з новай схемай; асобнага адкату схемы няма.
Плагіны — версіі кіруюцца асобна для кожнай устаноўкі; пры неабходнасці адкаціце плагін з каталога.
Канфігурацыя — пры абнаўленні не мяняецца; пры патрэбе аднаўляецца з рэзервовай копіі.

Разгортванне без прастою

AiHummer створаны для абнаўлення без прыпынкаў.

Запусціце 2+ шлюзы праз проксі. Катайце іх па адным; зонд гатоўнасці (/readyz) трымае вузел, які перазапускаецца, па-за ротацыяй, пакуль ён не пачне абслугоўванне.
Планавальнік мае аднаго кіраўніка. Фонавае планаванне выбірае аднаго лідара праз рэкамендацыйную блакіроўку PostgreSQL, таму запуск некалькіх шлюзаў не стварае дублікат запланаваная праца
Дастаўка ідэмпотэнтная. Надзейная дастаўка плюс ключы ідэмпотэнтнасці азначаюць Адказ ніколі не адпраўляецца двойчы пасля перазагрузкі, што і стварае эфект бесперапыннага працэсу. бяспечна перазапусціць праз вашы шлюзы

Куды далей

Зондавыя ўстаноўкі, якія рэгулююць плыўны перазапуск: systemd і праверкі здароўя.
Робіце рэзервовую копію перад вялікім абнаўленнем: Рэзервовае капіраванне і аднаўленне пасля катастроф.
Глядзіце запуск: Назіральнасць.