Nel corso del recente Red Hat Summit, Red Hat ha annunciato la disponibilità generale di Event-Driven Ansible, una soluzione scalabile e resiliente che offre alle aziende più modalità con cui attivare in modo efficace l’automazione nell’ambito delle proprie strategie hybrid cloud. Disponibile nella Red Hat Ansible Automation Platform 2.4, Event-Driven Ansible estende il valore degli investimenti IT esistenti in tutta l’azienda, consentendo ai team IT di innovare maggiormente senza compromettere la qualità del servizio o i tempi di risposta necessari negli ambienti IT moderni.
Event-Driven Ansible è composto da tre componenti principali:
Sources: definiscono i plugin delle sorgenti di eventi da utilizzare.
In genere si tratta di strumenti di monitoraggio, ma possono anche essere integrazioni personalizzate create per qualsiasi fonte di eventi importante per l’utente. Questi plugin di origine sono creati da partner, dalla comunità di Ansible, da Red Hat o da un utente. Sono già disponibili alcuni plugin di origine comune, tra cui: webhook, Kafka – la piattaforma open source di event streaming, Azure service bus, il message broker enterprise di Microsoft, file watch, che osserva il file system e invia eventi quando lo stato di un file cambia, url_check, che effettua il polling di un insieme di Url e invia eventi con i loro stati, Prometheus alertmanager e altri, tra cui plugin specifici dei partner attualmente in fase di creazione.
Rules: definiscono le condizioni che saranno soddisfatte dalla fonte dell’evento. Se la condizione è soddisfatta, può essere attivata un’azione.
Actions: un’azione determina ciò che deve accadere se una condizione è soddisfatta. Alcune delle azioni correnti sono: l’esecuzione di un playbook, l’esecuzione di un modulo, l’impostazione di un fatto, la pubblicazione di un evento o il debug. Le regole cercano determinate situazioni in cui sono soddisfatte condizioni specifiche e quindi avviano un’azione per affrontare l’”evento” per il quale il sistema decisionale ha identificato un’azione necessaria.
I casi d’uso dell’automazione guidata dagli eventi
L’inizio dell’automazione guidata dagli eventi inizia con l’identificazione delle attività ripetitive e banali che i team IT completano manualmente e frequentemente. Alcuni casi d’uso comuni includono:
- Correzione automatizzata: la soluzione a un tipo specifico di problema è spesso una sequenza di passaggi ripetibile. L’automazione event-driven può collegare le analisi o i ticket che segnalano un problema ai passaggi automatizzati che lo risolveranno. Ciò significa che i team possono automatizzare la risoluzione dei ticket, la correzione dei problemi in base a modelli noti di comportamento del sistema o la risposta agli eventi monitorati, come ad esempio l’avviso che un sistema necessita di maggiore capacità.
- Arricchimento dei ticket: un problema comune nella gestione dei ticket è che questi ultimi non contengono informazioni sufficienti per consentire un’efficace RCA (root cause analysis). L’automazione event-driven può essere utilizzata per raggiungere i sistemi pertinenti, raccogliere dati e aggiornare i ticket corrispondenti con i dettagli necessari per un processo di RCA più approfondito.
- Scalabilità automatizzata della piattaforma: i carichi di lavoro e le piattaforme applicative si affidano al provisioning automatico per garantire la continuità operativa e ridurre il potenziale impatto sui clienti. Invece di attendere il provisioning manuale, i team IT possono combinare le metriche di capacità e prestazioni con l’automazione basata sugli eventi per eseguire automaticamente il provisioning di container, infrastrutture cloud, macchine virtuali e altre tecnologie. Oltre allo scaling automatico, gli eventi dei carichi di lavoro delle applicazioni possono anche attivare il provisioning degli ambienti di sviluppo e di test per accelerare il processo di innovazione.
- Mitigazione dei rischi: Con l’automazione guidata dagli eventi, le risposte di sicurezza possono essere lanciate non appena viene identificato un rischio. Ad esempio, se viene identificato un rischio su un firewall, una soluzione event-driven può chiudere immediatamente il firewall e creare un ticket di servizio, riducendo l’opportunità di esposizione a una violazione della sicurezza. L’automazione basata sugli eventi può aiutare a garantire che le interruzioni vengano affrontate rapidamente, ma può anche osservare in modo proattivo i segnali che portano alle interruzioni, prevenendo ulteriori problemi in futuro e garantendo la stabilità dell’IT.
- Tuning e gestione della capacità automatizzati: il tuning continuo e la gestione della capacità sono necessari per molte funzioni IT, come la gestione delle applicazioni web e il monitoraggio degli storage pool. Per alcuni team, il tuning avviene migliaia o decine di migliaia di volte al mese, il che rende l’operazione manualmente dispendiosa in termini di tempo. L’automazione guidata dagli eventi è in grado di rispondere a questo tipo di eventi in base a regole predeterminate, come ad esempio la scarsa capacità di storage, e di attivare regolazioni automatiche. Eliminando le fasi manuali di questo processo di regolazione, i team possono essere più efficienti, economici e disponibili a rispondere ad altre esigenze aziendali critiche.
- Scalare l’automazione: come per la messa a punto, può essere oneroso scalare manualmente lo storage, l’elaborazione e la larghezza di banda di rete delle applicazioni per soddisfare la domanda degli utenti. Ad esempio, una soluzione di automazione guidata dagli eventi può monitorare i buffer pool, regolando automaticamente le dimensioni quando vengono raggiunti i limiti.
Un semplice esempio: gestione di eventi su webhook
Event-Driven Ansible contiene un decision framework che è stato realizzato utilizzando Drools, un Business Rule Management System (BRMS) che fornisce un motore di regole che elabora fatti e produce output come risultato dell’elaborazione delle regole e dei fatti. Per ogni insieme di eventi da gestire occorre un rulebook per dire al sistema quali eventi segnalare e come rispondere a tali eventi. Come i tradizionali Playbook di Ansible, anche questi rulebook sono creati in YAML; la differenza fondamentale tra playbook e rulebook è la codifica If-this-then-that che è necessaria in un rulebook per far funzionare un approccio all’automazione basato sugli eventi.
Il rulebook è così definito:
--- - name: Listen for events on a webhook hosts: all ## Define our source for events sources: - ansible.eda.webhook: host: 0.0.0.0 port: 5000 ## Define the conditions we are looking for rules: - name: Say Hello condition: event.payload.message == "Ansible is super cool" ## Define the action we should take should the condition be met action: run_playbook: name: say-what.yml
Nella sezione sources viene indicato quale plugin di origine si sta utilizzando, in questo esempio il plugin ansible.eda.webhook:
sources: - ansible.eda.webhook: host: 0.0.0.0 porta: 5000
Nella sezione rules è specificata la regola che fornisce una condizione e che in questo esempio è alla ricerca di un messaggio:
rules: - nome: Say Hello condition: event.payload.message == "Ansible is super cool!"
Infine, nel rulebook abbiamo un’azione, per cui se la condizione della regola è soddisfatta, l’azione si attiverà.
action: run_playbook: name: say-what.yml
Il playbook say-what.yml in questo esempio elementare non va oltre la produzione di un messaggio di ringraziamento indirizzato a chi ha scatenato l’evento, senza modificare lo stato del sistema, ma la sequenza di azioni potrebbe essere molto più complessa.
---
- name: say thanks
hosts: localhost
gather_facts: false
tasks:
- debug:
msg: "Thank you, {{ ansible_eda.event.sender | default('my friend') }}!"
Le integrazioni
Event-Driven Ansible si integra, inoltre, con le “event source” di strumenti di monitoraggio, osservabilità e analisi IT di terze parti già in uso presso i clienti, con risorse sviluppate da partner quali Cisco ThousandEyes, CyberArk, Dynatrace, F5, IBM Instana, IBM Turbonomic, Palo Alto Networks e Zabbix – ne arriveranno a breve di nuovi – per aiutare i clienti a iniziare più rapidamente. Contenuti supplementari sviluppati da Red Hat sono disponibili per Red Hat OpenShift, Red Hat Insights, AWS, Microsoft Azure, Google Cloud Platform e ServiceNow per offrire un’esperienza di automazione cloud end-to-end coerente. Event-Driven Ansible supporta anche lo sviluppo di integrazioni personalizzate, in modo che i clienti possano integrare gli eventi dai loro strumenti di monitoraggio preferiti, compresi quelli creati in-house. Per aiutarli a iniziare sono disponibili anche le competenze di system integrator partner come Kyndryl, World Wide Technology e altri.
