systemd & Gesundheitsprüfungen
AiHummer ist Host-nativ: es wird als Release-Tarball bereitgestellt, der unter läuft systemd, nicht in Containern. Diese Seite behandelt, wo es auf der Festplatte lebt, wie man seinen Zustand überprüft und was abgesichert werden muss, bevor man es Benutzern zugänglich macht.
Root- und systemd-Einheiten installieren
Alles lebt unter einem einzigen Installationsstamm, /home/.aihummer, ausgebreitet in bin/ etc/ share/ sidecars/ plugins/ systemd/ state/ data/ logs/. Die Gateway-Konfigurationsdatei ist /home/.aihummer/etc/gateway.env.
Die systemd-Einheitsdateien werden unter dem Installationsstamm aufbewahrt und in einen symbolischen Link eingebunden /etc/systemd/system/, sodass das Gateway und jedes Sidecar gewöhnliche Dienste sind, die Sie starten, stoppen und überprüfen können mit systemctl und journalctl. Jeder Sidecar läuft unter seiner eigenen Einheit — siehe Sidecars.
Gesundheits- und Einsatzbereitschaftssonden
Das Gateway stellt zwei unterschiedliche Sonden bereit:
| Probe | Endpunkt | Bedeutung |
|---|---|---|
| Lebendigkeit | GET /healthz |
Prozess läuft; gibt die Version zurück |
| Bereitschaft | GET /readyz |
Überprüft PostgreSQL; gibt zurück 503 wenn die Datenbank ausgefallen ist |
Verwenden /healthz für “läuft der Prozess” und /readyz für “kann es tatsächlich einen Dienst leisten”. Hinter einem Reverse-Proxy oder Load-Balancer richten Sie die Readiness-Prüfung auf /readyz also wird ein Gateway ohne Datenbank aus dem Betrieb genommen.
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 ist die einzige harte Abhängigkeit. Ohne eine erreichbare Datenbank funktioniert das Gateway nicht. läuft im verschlechterten Nur-Gesundheits-Modus und
/readyzmeldet 503.
Rauchtest
Führen Sie nach einer Installation oder einem Upgrade den mitgelieferten Smoke-Test aus, um zu bestätigen, dass die Bereitstellung korrekt von Anfang bis Ende funktioniert:
deploy/host/smoke.sh
Verwaltung von Diensten mit der CLI
Der aihummer CLI ist die Haustür für den täglichen Betrieb – es verwaltet das Gateway und die Sidecars, anstatt sie zu steuern systemctl von Hand:
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
Siehe das CLI-Referenz für den vollständigen Befehlssatz, einschließlich backup, restore, update und uninstall.
Produktions-Checkliste vor dem Flug
Bevor Sie AiHummer echtem Verkehr aussetzen, arbeiten Sie diese Liste durch:
- Stellen Sie den Hauptschlüssel ein. Anbieten
AIHUMMER_MASTER_KEY(base64, 32 Bytes) also die Geheimnis-Tresor und BYOK sind im Ruhezustand verschlüsselt. - Unternehmensauthentifizierung konfigurieren. Verdrahten Sie OIDC, LDAP und/oder SAML so
/v1/admin/*ist geschützt. Ohne einen Auth-Aussteller vertraut die Admin-Oberfläche den Entwicklungs-Headern. - Legen Sie das eingehende Geheimnis fest. Anbieten
AIHUMMER_INBOUND_SECRETalso Verbindungswörter authentifizieren bei/v1/inbound/*. - Riskante Werkzeuge sperren. Einschränken oder deaktivieren
code_exec, Ausgang sichern, und Umfangdb_queryzu einem schreibgeschützten DSN. - Beenden Sie TLS an einem Reverse-Proxy. Führen Sie das Gateway hinter einem Proxy aus, der handhabt HTTPS; das Gateway selbst dient einfachem HTTP.
[!WARNING] Ohne einen konfigurierten OIDC/LDAP/SAML-Aussteller fällt die Admin-API zurück auf Vertrauen in Entwicklungsköpfe. Niemals eine solche Instanz einem Unvertrauenswürdigen aussetzen Netzwerk — zuerst die Unternehmensauthentifizierung konfigurieren.
Wohin als Nächstes
- Das Transportmodell für Sprach- und Tooldienste: Sidecars.
- Backups, der Hauptschlüssel und die Wiederherstellung nach Katastrophen: Backups & Katastrophenwiederherstellung.
- Metriken, Traces und worauf man achten sollte: Beobachtbarkeit.