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

systemd і праверкі здароўя

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

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

Усталяваць адзінкі root і systemd

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

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

Даследаванні здароўя і гатоўнасці

Шлюз адкрывае два розныя даследчыя прыстасаванні:

Даследаванне Канчатковая кропка Сэнс
Жыўнасць 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

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

aihummer up         # install / bring services up
aihummer restart    # restart the gateway
aihummer stop       # stop services
aihummer status     # show service status
aihummer logs --no-follow   # tail logs and exit (without the flag it follows; optionally: aihummer logs <unit>)
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 пераходзіць на давярацца загалоўкам развіцця. Ніколі не падстаўляйце такі выпадак пад недаверныя сетку — спачатку наладзьце карпаратыўную аўтэнтыфікацыю.

Куды далей