AiHummer
Беларуская▾
Увайсці
v1.0.x▾
v1.0.xstable
{ }Swagger
Эксплуатацыя/systemd і праверкі спраўнасці

systemd і праверкі спраўнасці

v1.0.x · абноўлена 2026-06-26

AiHummer з’яўляецца хост-натыўным: ён разгортваецца як рэлізны tarball, які працуе пад systemd, а не ў кантэйнерах. Гэтая старонка апісвае, дзе ён знаходзіцца на дыску, як праверыць яго спраўнасць і што заблакіраваць, перш чым выставіць яго перад карыстальнікамі.

Корань усталявання і юніты systemd

Усё знаходзіцца пад адзіным коранем усталявання, /home/.aihummer, размешчаным у bin/ etc/ share/ sidecars/ plugins/ systemd/ state/ data/ logs/. Файл канфігурацыі шлюза — /home/.aihummer/etc/gateway.env.

Файлы юнітаў systemd захоўваюцца пад коранем усталявання і сімвалічна звязаны з /etc/systemd/system/, таму шлюз і кожны sidecar — гэта звычайныя сэрвісы, якія вы можаце запускаць, спыняць і інспектаваць праз systemctl і journalctl. Кожны sidecar працуе пад сваім уласным юнітам — гл. Sidecars.

Пробы спраўнасці і гатоўнасці

Шлюз выстаўляе дзве асобныя пробы:

Проба Эндпойнт Значэнне
Жывучасць GET /healthz Працэс жывы; вяртае версію
Гатоўнасць GET /readyz Правярае PostgreSQL; вяртае 503, калі БД недаступная

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

curl -fsS http://127.0.0.1:8780/healthz   # 200 + version
curl -fsS http://127.0.0.1:8780/readyz    # 200 ready, 503 if Postgres is unreachable

[!NOTE] PostgreSQL — адзіная жорсткая залежнасць. Без дасягальнай базы даных шлюз працуе ў дэградаваным рэжыме толькі спраўнасці, і /readyz паведамляе 503.

Дымавы тэст

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

deploy/host/smoke.sh

Кіраванне сэрвісамі праз CLI

CLI aihummer — гэта галоўны ўваход для штодзённых аперацый — ён кіруе шлюзам і sidecar-амі, а не выклікае systemctl уручную:

aihummer up         # install / bring services up
aihummer restart    # restart the gateway
aihummer stop       # stop services
aihummer status     # show service status
aihummer logs       # tail logs (optionally: aihummer logs <svc>)
aihummer doctor     # run diagnostics

Гл. даведнік CLI для поўнага набору каманд, уключаючы backup, restore, update і uninstall.

Кантрольны спіс перад запускам у прадакшн

Перад тым як выставіць AiHummer пад рэальны трафік, прайдзіце па гэтым спісе:

  • Задайце майстар-ключ. Падайце AIHUMMER_MASTER_KEY (base64, 32 байты), каб сховішча сакрэтаў і BYOK былі зашыфраваны ў стане спакою.
  • Сканфігуруйце карпаратыўную аўтэнтыфікацыю. Падключыце OIDC, LDAP і/або SAML, каб /v1/admin/* быў абаронены. Без эмітэнта аўтэнтыфікацыі адмін-паверхня давярае загалоўкам распрацоўкі.
  • Задайце ўваходны сакрэт. Падайце AIHUMMER_INBOUND_SECRET, каб канектары аўтэнтыфікаваліся ў /v1/inbound/*.
  • Заблакіруйце рызыкоўныя інструменты. Абмяжуйце або адключыце code_exec, узмацніце выхадны трафік і абмяжуйце db_query толькі для чытання DSN.
  • Тэрмінуйце TLS на адваротным проксі. Запускайце шлюз за проксі, які апрацоўвае HTTPS; сам шлюз абслугоўвае звычайны HTTP.

[!WARNING] Без сканфігураванага эмітэнта OIDC/LDAP/SAML адмін-API адкочваецца да даверу загалоўкам распрацоўкі. Ніколі не выстаўляйце такі інстанс у недавераную сетку — спачатку сканфігуруйце карпаратыўную аўтэнтыфікацыю.

Куды далей