AiHummer
Español▾
Iniciar sesiónCuenta
v1.0.x▾
v1.2.xstablev1.1.xstablev1.0.xstable
{ }Swagger
Operaciones/systemd y controles de salud

systemd y controles de salud

v1.0.x · actualizada 2026-06-26

AiHummer es anfitrión-nativo: se despliega como un archivo tarball de lanzamiento ejecutándose bajo systemd, no en contenedores. Esta página cubre dónde se encuentra en el disco, cómo verificar su estado y qué asegurar antes de ponerlo frente a los usuarios.

Instalar root y unidades systemd

Todo vive bajo una única raíz de instalación, /home/.aihummer, dispuesto en bin/ etc/ share/ sidecars/ plugins/ systemd/ state/ data/ logs/. El archivo de configuración de la puerta de enlace es /home/.aihummer/etc/gateway.env.

Los archivos de unidad systemd se mantienen bajo la raíz de instalación y vinculado simbólicamente en /etc/systemd/system/, por lo que la puerta de enlace y cada sidecar son servicios ordinarios que puedes iniciar, detener e inspeccionar con systemctl y journalctl. Cada sidecar se ejecuta bajo su propia unidad — ver Sidecares.

Sondas de salud y preparación

La puerta de enlace expone dos sondas distintas:

Sonda Punto final Significado
Vitalidad GET /healthz El proceso está activo; devuelve la versión
Preparación GET /readyz Verifica PostgreSQL; devuelve 503 si la base de datos está caída

Usar /healthz para “está el proceso en marcha” y /readyz para “¿realmente puede ser útil?” Detrás de un proxy inverso o balanceador de carga, apunta la verificación de disponibilidad a /readyz así que un gateway sin base de datos se retira de la rotación.

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 es la única dependencia rígida. Sin una base de datos accesible, la puerta de enlace se ejecuta en un modo de solo salud degradado y /readyz informa 503.

Prueba de humo

Después de una instalación o actualización, ejecute la prueba de humo incluida para confirmar que la implementación responde correctamente de extremo a extremo:

deploy/host/smoke.sh

Administrar servicios con la CLI

la aihummer CLI es la puerta de entrada para las operaciones diarias: gestiona la puerta de enlace y los sidecars en lugar de conducir systemctl a mano:

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

Ver el Referencia de CLI para el conjunto completo de comandos, incluyendo backup, restore, update y uninstall.

Lista de verificación previa a la producción

Antes de exponer a AiHummer al tráfico real, repasa esta lista:

  • Establece la clave maestra. Proporcionar AIHUMMER_MASTER_KEY (base64, 32 bytes) así que la El bóveda de secretos y BYOK están encriptados en reposo.
  • Configurar la autenticación empresarial. Conectar OIDC, LDAP y/o SAML de manera que /v1/admin/* es protegido. Sin un emisor de autenticación, la superficie de administración confía en los encabezados de desarrollo.
  • Establece el secreto de entrada. Proporcionar AIHUMMER_INBOUND_SECRET así que conectores autenticar en /v1/inbound/*.
  • Bloquea las herramientas riesgosas. Restringir o desactivar code_exec, ajustar la salida, y alcance db_query a un DSN de solo lectura.
  • Finalizar TLS en un proxy inverso. Ejecute la pasarela detrás de un proxy que maneja HTTPS; la propia puerta de enlace sirve HTTP simple.

[!WARNING] Sin un emisor OIDC/LDAP/SAML configurado, la API de administración vuelve a confiar en los encabezados de desarrollo. Nunca exponga dicha instancia a un no confiable red — configure primero la autenticación empresarial.

¿A dónde vamos ahora?