systemd և առողջության ստուգումներ
AiHummer-ը host-native է. այն տեղակայվում է որպես release tarball, որն աշխատում է systemd-ի տակ, ոչ թե կոնտեյներներում։ Այս էջն ընդգրկում է, թե որտեղ է այն ապրում սկավառակի վրա, ինչպես ստուգել նրա առողջությունը, և ինչ կողպել, նախքան այն օգտատերերի առջև դնելը։
Install root և systemd միավորներ
Ամեն ինչ ապրում է մեկ install root-ի տակ, /home/.aihummer, որը դասավորված է
bin/ etc/ share/ sidecars/ plugins/ systemd/ state/ data/ logs/-ի։ Gateway-ի
config ֆայլն է /home/.aihummer/etc/gateway.env։
systemd միավորի ֆայլերը պահվում են install root-ի տակ և symlink-վում
/etc/systemd/system/-ի մեջ, այնպես որ gateway-ը և յուրաքանչյուր sidecar սովորական ծառայություններ են,
որոնք կարող եք start, stop և inspect անել systemctl-ով և journalctl-ով։ Յուրաքանչյուր sidecar
աշխատում է իր սեփական միավորի տակ — տես Sidecar-ներ։
Health & readiness probe-ներ
Gateway-ը բացահայտում է երկու հստակ probe.
| Probe | Endpoint | Իմաստ |
|---|---|---|
| Liveness | GET /healthz |
Պրոցեսը կենդանի է. վերադարձնում է version-ը |
| Readiness | GET /readyz |
Ստուգում է PostgreSQL-ը. վերադարձնում է 503, եթե DB-ն անջատ է |
Օգտագործեք /healthz-ը «արդյո՞ք պրոցեսն աշխատում է»-ի համար, և /readyz-ը «արդյո՞ք այն իրականում կարող է սպասարկել
turn»-ի համար։ Reverse proxy-ի կամ load balancer-ի հետևում ուղղորդեք readiness ստուգումը
/readyz-ին, որպեսզի առանց տվյալների բազայի gateway-ը հանվի ռոտացիայից։
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-ը միակ կոշտ կախվածությունն է։ Առանց հասանելի տվյալների բազայի gateway-ը աշխատում է degraded health-only ռեժիմում, և
/readyz-ը հաղորդում է 503։
Smoke test
Տեղադրումից կամ թարմացումից հետո աշխատեցրեք ներառված smoke test-ը՝ հաստատելու համար, որ տեղակայումը ճիշտ է պատասխանում սկզբից մինչև վերջ.
deploy/host/smoke.sh
Ծառայությունների կառավարում CLI-ով
aihummer CLI-ն ամենօրյա գործառնությունների գլխավոր մուտքն է — այն կառավարում է
gateway-ն ու 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։
Արտադրության pre-flight ստուգաթերթ
Նախքան AiHummer-ը իրական տրաֆիկի առջև դնելը, անցեք այս ցանկի միջով.
- Սահմանեք master key-ը։ Տրամադրեք
AIHUMMER_MASTER_KEY(base64, 32 բայթ), որպեսզի secret-ների vault-ը և BYOK-ն ծածկագրված լինեն at rest։ - Կարգավորեք enterprise auth-ը։ Միացրեք OIDC, LDAP և/կամ SAML, որպեսզի
/v1/admin/*-ը պաշտպանված լինի։ Առանց auth issuer-ի ադմին մակերեսը վստահում է development header-ներին։ - Սահմանեք inbound secret-ը։ Տրամադրեք
AIHUMMER_INBOUND_SECRET, որպեսզի կոնեկտորները նույնականանան/v1/inbound/*-ի համար։ - Կողպեք ռիսկային գործիքները։ Սահմանափակեք կամ անջատեք
code_exec-ը, սեղմեք egress-ը, և scope արեքdb_query-ն read-only DSN-ի։ - Ավարտեք TLS-ը reverse proxy-ի վրա։ Աշխատեցրեք gateway-ն proxy-ի հետևում, որը կարգավորում է HTTPS-ը. gateway-ն ինքն սպասարկում է plain HTTP։
[!WARNING] Առանց OIDC/LDAP/SAML issuer-ի կարգավորման ադմին API-ն վերադառնում է development header-ներին վստահելուն։ Երբեք մի բացահայտեք այդպիսի instance անվստահելի ցանցին — նախ կարգավորեք enterprise auth-ը։
Ո՞ւր հաջորդիվ
- Խոսքի և գործիքների ծառայությունների transport մոդելը. Sidecar-ներ։
- Կրկնօրինակումներ, master key-ը և աղետից վերականգնում. Կրկնօրինակումներ և աղետից վերականգնում։
- Metrics, trace-ներ և ինչին հետևել. Observability։