Automatizácia IT infraštruktúry cez GLPI API a webhooks

Automatizácia IT infraštruktúry cez GLPI API a webhooks

GLPI samé osebe nerieši automatizáciu infraštruktúry — neskenuje servery, nepatchuje kontajnery, nereštartuje služby. Jeho silou je iné: byť centrom, kam ostatné nástroje posielajú signály a odkiaľ vychádzajú akcie. Monitoring odošle alert, GLPI vytvorí incident. Zmena schválená v GLPI spustí výrobný pipeline. Ticketsystém pre zákazníkov pošle dáta do CRM. Tento článok je o troch vzorcoch, ktoré tento tok zabezpečujú: REST API (vstupné integrácie), webhooks (výstupné notifikácie) a cron tasks (plánované akcie).

Vzor 1: monitoring → GLPI cez REST API

Najčastejšia integrácia. Zabbix, Nagios, Prometheus alebo iné monitoring tools pri prekročení prahu zavolajú GLPI REST API a vytvoria tiket. Konkrétny príklad webhook actionu v Zabbix-e:

# Zabbix media type → custom webhook → GLPI
URL: https://glpi.example.com/apirest.php/Ticket
Headers:
  Content-Type: application/json
  App-Token: <app-token>
  Session-Token: <persistent-session>
Body:
{
  "input": {
    "name": "{HOST.NAME}: {EVENT.NAME}",
    "content": "Severity: {EVENT.SEVERITY}\\nTrigger: {TRIGGER.NAME}\\nValue: {ITEM.LASTVALUE}",
    "urgency": 5,
    "type": 1,
    "entities_id": 1,
    "itilcategories_id": 12
  }
}

Pre stabilný tok session token nedeklarujte z initSession pri každom volaní (zbytočné kolísanie). Vytvorte trvalý service-account session token, uložte ho do Zabbix secrets a obnovujte raz za 24 hodín cez cron na strane Zabbixu.

Ďalšie systémy, ktoré takto bežne integrujú: Grafana alerts, AlertManager, vlastné scripty cez curl, deployment pipeline-y, ktoré po neúspechu otvoria incident.

Vzor 2: GLPI → externé systémy cez webhooks

Opačný smer. Akonáhle sa v GLPI niečo stane (vytvorenie tiketu, schválenie zmeny, priradenie technika), GLPI môže poslať HTTP POST na externý endpoint. GLPI 11 zaviedol natívne webhooks — pred 11 sa to riešilo cez plugin FlyveMobile Webhooks alebo cron a custom skript.

Konfigurácia v GLPI 11:

  1. V Setup → Webhooks → Add vytvorte webhook s URL endpointu (napríklad https://hooks.slack.com/services/... alebo váš vlastný integration server).
  2. Vyberte trigger event: Ticket created, Status changed to Solved, Change approved.
  3. Definujte payload — JSON s placeholdermi pre polia objektu: {"id": "{{id}}", "title": "{{name}}", "url": "{{url}}"}.
  4. Nastavte autentifikáciu (HMAC podpis pre overenie, že volanie prišlo z GLPI).

Typické scenáre:

  • Vytvorenie P1 tiketu → POST na Slack webhook s linkom na tiket.
  • Schválenie change → POST na Jenkins, ktorý spustí deployment pipeline.
  • Vytvorenie tiketu typu "Onboarding" → POST na HR systém s úlohou pripraviť pracovnú stanicu.

Webhooks sú vždy lepšie ako polling, pokiaľ sú dostupné — menej zaťažujú server, znižujú latenciu a nepotrebujú dedikovaný cron job na strane konzumenta.

Vzor 3: cron-driven scheduled tasks

Pre periodické akcie (synchronizácie, kontroly, údržba), ktoré nie sú reaktívne na external event, použite GLPI vstavané automatické akcie alebo systémový cron volajúci API.

Príklad cron skriptu na noční synchronizáciu LDAP používateľov:

# /etc/cron.d/glpi-sync-ldap
0 2 * * * www-data php /var/www/glpi/bin/console glpi:ldap:synchronize_users \
  --ldap-filter="(memberOf=CN=GLPI-Users,OU=Groups,DC=example,DC=com)" \
  --no-interaction

Pre akcie iniciované z GLPI smerom von (napríklad export inventára do BI tool-u) využite GLPI cron framework cez Setup → General → Automatic actions → Add custom alebo plugin GenericObject s callback hookom.

Praktická architektúra: GLPI ako tickets bus

V stredne veľkej organizácii GLPI typicky stojí v strede tohto toku:

Monitoring (Zabbix/Grafana)
       │ (REST API, vytvorenie tiketu)
       ▼
   ┌───────┐    Webhooks    ┌──────────┐
   │ GLPI  │ ─────────────▶ │ Slack    │
   └───┬───┘                └──────────┘
       │                    ┌──────────┐
       ├──────────────────▶ │ Jenkins  │
       │                    └──────────┘
   Cron│                    ┌──────────┐
       └──────────────────▶ │ BI tool  │
                            └──────────┘

Vstupné integrácie (zľava) prichádzajú cez REST API. Výstupné (vpravo) odchádzajú cez webhooks alebo cron.

Bezpečnosť integrácií

  • App-Token + service-account user-token oddeľujú integráciu od ľudského účtu. Pri rotácii hesiel ľudských účtov sa integrácia neporuší.
  • HTTPS only — REST API a webhooks vždy cez TLS. Self-signed certifikát na GLPI servere odmieta väčšina monitoring nástrojov.
  • HMAC signature pre webhooks — overí, že payload prišiel z GLPI a nebol cestou zmenený.
  • Audit log integration calls — zapnite v Setup → General → API logovanie API hovorov. Pri ladení integrácie sú logy nevyhnutné.

Spojenie troch vzorcov (REST API ako vstup, webhooks ako výstup, cron pre plánované akcie) pokrýva drvivú väčšinu integračných potrieb. Zložitejšie scenáre (s vetvením, podmienkami, retries) zvyčajne vyžadujú dedikovaný integration platform — ale aj v tom prípade GLPI ostáva v strede ako zdroj pravdy o tikoch a zmenách.

Potrebujete pomôcť s touto témou?

Kontakt