systemd și verificări de sănătate
AiHummer este gazdă-nativ: se desfășoară ca un fișier tarball de lansare care rulează sub systemd, nu în containere. Această pagină explică unde se află pe disc, cum să îi verifici starea de sănătate și ce să securizezi înainte de a-l pune în fața utilizatorilor.
Instalează root și unități systemd
Totul trăiește sub un singur rădăcină de instalare, /home/.aihummer, aranjat în bin/ etc/ share/ sidecars/ plugins/ systemd/ state/ data/ logs/. Fișierul de configurare al gateway-ului este /home/.aihummer/etc/gateway.env.
Fișierele unităților systemd sunt păstrate sub rădăcina de instalare și legat simbolic în /etc/systemd/system/, astfel încât gateway-ul și fiecare sidecar sunt servicii obișnuite pe care le poți porni, opri și inspecta cu systemctl și journalctl. Fiecare sidecar funcționează sub propria sa unitate — vezi Atelaje laterale.
Verificări de sănătate și pregătire
Poarta expune două sonde distincte:
| Probe | Punct final | Sens |
|---|---|---|
| Încărcare în timp real | GET /healthz |
Procesul este activ; returnează versiunea |
| Pregătire | GET /readyz |
Verifică PostgreSQL; returnează 503 dacă baza de date este căzută |
Folosește /healthz pentru „procesul este pornit” și /readyz pentru „poate de fapt să fie util”. În spatele unui proxy invers sau al unui balansator de sarcină, indicați verificarea de pregătire către /readyz așadar, un gateway fără bază de date este scos din rotație.
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 este singura dependență obligatorie. Fără o bază de date accesibilă, gateway-ul rulează în modul degradat doar pentru sănătate și
/readyzrapoarte 503.
Test de fum
După o instalare sau o actualizare, rulați testul rapid inclus pentru a confirma că implementarea răspunde corect de la un capăt la altul:
deploy/host/smoke.sh
Gestionarea serviciilor cu CLI
aihummer CLI este ușa principală pentru operațiunile de zi cu zi — gestionează gateway-ul și sidecar-urile mai degrabă decât să conducă systemctl manual:
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
Vedeți Referință CLI pentru întregul set de comenzi, inclusiv backup, restore, update și uninstall.
Lista de verificare pre-zbor pentru producție
Înainte de a expune AiHummer traficului real, parcurgeți această listă:
- Setează cheia principală. Furniza
AIHUMMER_MASTER_KEY(base64, 32 de octeți) deci secrets vault și BYOK sunt criptate în repaus. - Configurează autentificarea pentru întreprindere. Conectează OIDC, LDAP și/sau SAML astfel
/v1/admin/*este protejat. Fără un emițător de autentificare, interfața de administrare are încredere în anteturile de dezvoltare. - Setează secretul de intrare. Furniza
AIHUMMER_INBOUND_SECRETconectori deci autentifica la/v1/inbound/*. - Blocați uneltele riscante. Restricționează sau dezactivează
code_exec, strângeți evacuarea, și domeniudb_querycătre un DSN doar pentru citire. - Terminate TLS la un proxy invers. Rulați gateway-ul în spatele unui proxy care gestionază HTTPS; gateway-ul în sine servește HTTP simplu.
[!WARNING] Fără un emițător OIDC/LDAP/SAML configurat, API-ul de administrare revine la încrezându-se în headerele de dezvoltare. Nu expuneți niciodată o astfel de instanță unui necunoscut rețea — configurează mai întâi autentificarea pentru întreprindere.
Unde următor?
- Modelul de transport pentru servicii de vorbire și unelte: Atelaje laterale.
- Backup-uri, cheia principală și recuperarea în caz de dezastru: Backup-uri și recuperare în caz de dezastru.
- Metrici, urme și ce să urmărești: Observabilitate.