systemd et contrôles de santé

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

deploy/host/smoke.sh

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

AiHummer est **hôte-natif**: il se déploie en tant que tarball de version fonctionnant sous **systemd**, pas dans des conteneurs. Cette page explique où il se trouve sur le disque, comment vérifier son état et ce qu'il faut sécuriser avant de le mettre devant les utilisateurs. ## Installer les unités root et systemd Tout vit sous une seule racine d'installation, **`/home/.aihummer`**, disposé en `bin/ etc/ share/ sidecars/ plugins/ systemd/ state/ data/ logs/`. Le fichier de configuration de la passerelle est `/home/.aihummer/etc/gateway.env`. Les fichiers d'unité systemd sont conservés sous la racine d'installation et **liée par un lien symbolique à `/etc/systemd/system/`**, donc la passerelle et chaque sidecar sont des services ordinaires que vous pouvez démarrer, arrêter et inspecter avec `systemctl` et `journalctl`. Chaque sidecar fonctionne sous sa propre unité — voir [Side-cars](/fr/v1.0/architecture/sidecars). ## Sondes de santé et de préparation La passerelle expose deux sondes distinctes : | Sonde | Point de terminaison | Sens | |---|---|---| | Vivacité | `GET /healthz` | Le processus est actif ; renvoie la version | | Préparation | `GET /readyz` | Vérifie PostgreSQL ; retourne **503** si la base de données est en panne | Utiliser `/healthz` pour "est le processus en cours" et `/readyz` pour "peut-il réellement être utile". Derrière un proxy inverse ou un équilibreur de charge, pointez le contrôle de disponibilité vers `/readyz` donc une passerelle sans base de données est retirée de la rotation. ```bash 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 est la seule dépendance stricte. Sans une base de données accessible, la passerelle > fonctionne en mode santé dégradé uniquement et `/readyz` rapports 503. ## Test de fumée Après une installation ou une mise à niveau, exécutez le test de fumée fourni pour confirmer que le déploiement répond correctement de bout en bout : ```bash deploy/host/smoke.sh ``` ## Gérer les services avec l'interface en ligne de commande Le `aihummer` CLI est la porte d'entrée des opérations quotidiennes — il gère la passerelle et les sidecars plutôt que de les piloter `systemctl` à la main : ```bash 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 ``` Voir le [Référence CLI](/fr/v1.0/reference/cli) pour l'ensemble complet des commandes, y compris `backup`, `restore`, `update` et `uninstall`. ## Liste de vérification avant le vol de production Avant d'exposer AiHummer à la circulation réelle, parcourez cette liste : - **Définissez la clé maîtresse.** Fournir `AIHUMMER_MASTER_KEY` (base64, 32 octets) donc le le coffre-fort des secrets et BYOK sont chiffrés au repos. - **Configurer l'authentification d'entreprise.** Connecter OIDC, LDAP et/ou SAML ainsi `/v1/admin/*` est protégé. Sans un émetteur d'authentification, l'interface d'administration fait confiance aux en-têtes de développement. - **Définissez le secret entrant.** Fournir `AIHUMMER_INBOUND_SECRET` donc des connecteurs s'authentifier à `/v1/inbound/*`. - **Verrouillez les outils à risque.** Restreindre ou désactiver `code_exec`, resserrer la sortie, et portée `db_query` à un DSN en lecture seule. - **Terminer TLS à un proxy inverse.** Exécutez la passerelle derrière un proxy qui gère le HTTPS ; la passerelle elle-même sert du HTTP simple. > [!WARNING] > Sans un émetteur OIDC/LDAP/SAML configuré, l'API d'administration revient à > faire confiance aux en-têtes de développement. Ne jamais exposer une telle instance à un utilisateur non fiable > réseau — configurez d'abord l'authentification d'entreprise. ## Où aller ensuite - Le modèle de transport pour les services de parole et d'outils : [Side-cars](/fr/v1.0/architecture/sidecars). - Sauvegardes, la clé maîtresse et la reprise après sinistre : [Sauvegardes et reprise après sinistre](/fr/v1.0/operations/backups-dr). - Métriques, traces et à surveiller : [Observabilité](/fr/v1.0/operations/observability).