Che cos'è un Ansible Rulebook?

Un Ansible® Rulebook è un set di regole condizionali che utilizza Event-Driven Ansible per eseguire azioni IT in un modello di automazione guidata dagli eventi. I rulebook sono lo strumento con cui gli utenti comunicano a Event-Driven Ansible quale sorgente monitorare per un evento e quali azioni intraprendere quando questo si verifica e vengono soddisfatte determinate condizioni.

Similmente agli Ansible Playbook, i rulebook sono scritti in linguaggio YAML leggibile dagli utenti, ma si avvalgono di regole condizionali if-this-then-that per stabilire quando un evento deve attivare un'azione. Seguendo le istruzioni di un rulebook, Event-Driven Ansible monitora la sorgente di destinazione dell'evento, riconosce quando si verifica ed esegue automaticamente l'azione appropriata. 

Utilizzando Ansible Rulebook, i team IT possono codificare le decisioni necessarie e progettare le azioni da intraprendere quando vengono soddisfatte determinate condizioni, in modo che vengano eseguite sempre nello stesso modo. I rulebook possono anche avviare Ansible Playbook esistenti quando le condizioni sono soddisfatte, ampliando i vantaggi offerti da playbook affidabili che i team hanno realizzato e migliorato nel tempo. 

Integrando le proprie conoscenze nei rulebook, i team possono utilizzare Event-Driven Ansible per ridurre al minimo gli errori causati spesso dalla ripetitività degli interventi manuali e creare processi IT più efficienti e coerenti.

Event-Driven Ansible offre le funzionalità di gestione degli eventi necessarie per automatizzare attività che richiedono tempo, permettendo di adattarsi ai costanti cambiamenti in qualsiasi ambito IT. Inoltre, elabora gli eventi contenenti informazioni distinte sulle condizioni dell'ambiente IT, determina la risposta più adeguata e interviene in modo automatico per risolvere l'evento. Event-Driven Ansible può essere utilizzato per automatizzare le attività di gestione dei servizi IT, come il completamento dei ticket, la risoluzione dei problemi e la gestione degli utenti, e altre svariate attività in un ambiente IT.

Ad esempio, supponiamo che lo strumento di osservabilità utilizzato, ovvero la sorgente degli eventi, esamini i router di rete e noti che uno di questi non risponde, identificando questa situazione come un evento. Event-Driven Ansible riceverà questo evento, invierà i relativi dati in base alle condizioni del rulebook e abbinerà l'evento all'azione desiderata, ad esempio applicare nuovamente una configurazione, reimpostare il router, creare un ticket di assistenza o reindirizzare il traffico. Seguendo le istruzioni del rulebook, Event-Driven Ansible può attivare l'azione per reimpostare il router, ripristinando il suo normale funzionamento. Tutto ciò può verificarsi in qualsiasi momento nell'arco delle 24 ore, anche fuori dal normale orario di lavoro, in assenza dell'ingegnere di rete.

La flessibilità di Event-Driven Ansible è resa possibile dagli Ansible Rulebook, che collegano le sorgenti di eventi con le azioni corrispondenti tramite regole.

Gli Ansible Rulebook contengono la sorgente dell'evento e le istruzioni condizionali (le regole) che specificano quali azioni eseguire quando viene soddisfatta una determinata condizione. Una regola include una singola condizione e l'azione corrispondente. Un set di regole è un gruppo di diverse regole e azioni. I rulebook possono includere più set di regole.

Inoltre, sono progettati per offrire un ampio raggio di flessibilità rispetto alle azioni da eseguire:

• Monitorare una o più sorgenti. 
• Includere una o più regole.
• Attivare una o più azioni. 

Questa flessibilità di sorgenti, regole e azioni è integrata in Event-Driven Ansible, in modo che gli utenti possano impostare le azioni desiderate quando sono presenti specifiche condizioni IT.

La prima parte di un rulebook definisce una o più sorgenti da monitorare per gli eventi. Event-Driven Ansible si affida a sorgenti di eventi intelligenti, come strumenti e applicazioni di osservazione esterni, per identificare gli eventi e acquisire dati al riguardo. I plugin per le sorgenti di eventi vengono utilizzati per collegare Event-Driven Ansible a queste sorgenti in modo da prestare attenzione al verificarsi di eventi. 

Red Hat® Ansible Certified Content Collection di ansible.eda contiene una serie di plugin predefiniti per le sorgenti di eventi che possono essere utilizzati per iniziare a utilizzare Event-Driven Ansible. Tuttavia, Red Hat invita partner e fornitori a fornire plugin personalizzati progettati appositamente per la propria tecnologia, per semplificare il processo di integrazione e sfruttare la massima fruibilità dei dati degli eventi.

Plugin di contenuti certificati ansible.eda

Utilizzando i plugin per le sorgenti di eventi della raccolta ansible.eda, gli utenti possono iniziare a elaborare gli eventi rapidamente. Questi plugin per le sorgenti consentono a Event-Driven Ansible di identificare il verificarsi degli eventi, che possono quindi essere elaborati con la logica condizionale di un rulebook per stabilire quale azione intraprendere. Se un evento non soddisfa le condizioni del rulebook, Event-Driven Ansible non attiverà alcuna azione e l'evento verrà scartato. 

Alcuni dei plugin per le sorgenti più comuni che si trovano nella raccolta ansible.eda sono webhook, Kafka e Prometheus Alertmanager. Si rivolgono a webhook generici che possono provenire da più sistemi e strumenti, code di messaggistica e avvisi derivanti da sistemi di monitoraggio degli eventi aziendali come Prometheus. 

Oltre a questi plugin, i partner Red Hat forniscono ulteriori plugin certificati per le sorgenti di eventi, personalizzati in modo specifico per le loro tecnologie e soluzioni. Questi plugin possono includere funzionalità aggiuntive per consentire a Event-Driven Ansible di integrarsi in maniera ottimale con le tecnologie dei partner. Gli utenti possono anche creare i propri plugin per le sorgenti di eventi interni.

Ad esempio, se si dispone di uno switch di rete e si desidera sapere solo quando una porta ha un malfunzionamento, un partner può creare un plugin che specifichi esattamente gli eventi a cui deve prestare attenzione Event-Driven Ansible sullo switch. Utilizzando questo plugin del partner, non si rischia di ricevere innumerevoli informazioni irrilevanti su tutti gli eventi che si verificano in relazione allo switch in qualsiasi momento nell'arco delle 24 ore. Il plugin certificato potrebbe fornire solo il nome host del dispositivo, il problema e un numero di incidente, mentre un plugin generico come un webhook potrebbe includere dettagli aggiuntivi come il nome del mittente, l'URL o altri dati che non sono rilevanti per l'azione di risoluzione dei problemi.

Dopo che il plugin per le sorgenti ha rilevato un evento e ha fornito informazioni su di esso, Event-Driven Ansible analizza tali dati filtrando attraverso le regole condizionali del rulebook per determinare quali azioni intraprendere. Le regole sono scenari flessibili if-this-then-that, che definiscono le fasi da eseguire quando i dati degli eventi soddisfano determinate condizioni. 

Ad esempio, se il plugin per le sorgenti sta monitorando le porte su un router di rete, le regole potrebbero stabilire: se la porta ha un malfunzionamento e non risponde per 5 minuti, riavvia il router. Se i dati degli eventi vengono filtrati dalle regole e non soddisfano le condizioni, non verrà intrapresa alcuna azione. 

I rulebook possono:

• Contenere una o più regole. 
• Includere una o più condizioni che devono tutte corrispondere allo stato dell'evento o più condizioni di cui solo una deve corrispondere. 
• Supportare tutti gli operatori matematici tradizionali, come =, ≠, > e <.
• Supportare numeri interi, stringhe, variabili booleane (come and, or e not), virgole mobili e tipi di dati di condizione nulla. 

Ad esempio, se stai valutando un singolo evento e vuoi far corrispondere più condizioni, è possibile utilizzare la variabile booleana and (e): ciò significa che ciascuna di queste condizioni dovrà essere soddisfatta prima che l'azione venga attivata.
 

name: Combining ‘and’ operators
condition: event.version == "2.0" and event.name == "test" and event.alert_count > 10
action:
  debug:

Se stai monitorando più eventi e vuoi far corrispondere più condizioni, è possibile utilizzare all (tutte): ciò significa che ciascuna di queste condizioni dovrà essere soddisfatta prima che la condizione sia considerata una corrispondenza. Dato che queste condizioni sono correlate a più eventi, sono elencate su righe separate.
 

name: Condition using both a fact and an event
condition:
  all:
    - fact.meta.hosts == "localhost"
    - event.target_os == "windows"
action:
  debug:

Utilizzando any (qualsiasi), se una delle condizioni è soddisfatta, viene considerata una corrispondenza e l'azione si attiva. Come nell'esempio precedente, questo codice riguarda più eventi, quindi le condizioni sono elencate su righe separate.
 

name: Any condition can match
condition:
  any:
    - event.target_os == "linux"
    - event.target_os == "windows"
action:
  debug:

Nota: negli esempi precedenti, l'azione di debug stamperebbe le informazioni sull'evento, in modo da poter visualizzare questi dati in Event-Driven Ansible.

Quando i dati degli eventi soddisfano le condizioni di un rulebook, Event-Driven Ansible attiva l'azione (o le azioni) specificata. 

Tra quelle più comuni, sono incluse:

• Run_playbook esegue un Ansible Playbook esistente che è stato già programmato per automatizzare determinate azioni, come la risoluzione dei problemi di un server. 
• Run_job_template esegue un modello dei processi tramite Automation Controller in Red Hat Ansible Automation Platform. Eseguendo il modello in Ansible Automation Platform, si ottengono i vantaggi associati come la gestione dell'inventario, i controlli degli utenti e degli accessi e analisi dell'azione completata. 
• Run_module esegue un modulo Ansible esistente, che svolge un'azione più specifica e mirata quando non si desidera eseguire un intero playbook.
• Post_event consente di pubblicare un evento in un set di regole in esecuzione. In genere viene incluso dopo l'azione run_playbook o run_job_template e fornisce la possibilità di inserire informazioni sul risultato dell'azione in Event-Driven Ansible.
• Set_Fact registra dati specifici su un evento o un'azione in modo che possano essere reinseriti in Event-Driven Ansible e utilizzati per altri interventi. I dati degli eventi sono transitori ed effimeri; impostando i fatti è possibile salvare informazioni specifiche sugli eventi e rendere tali dati permanenti.
• Debug è simile al debug che si trova in Ansible Playbook. Se non vengono forniti argomenti, verranno stampati il payload dell'evento corrispondente ed eventuali informazioni importanti aggiuntive.

Questa sezione include un paio di semplici esempi di Ansible Rulebook, pensati per descrivere a titolo esemplificativo in che modo sorgenti, regole e azioni interagiscono tra loro nell'ambito di un rulebook completo.  

Questo primo esempio illustra un'azione singola e abbastanza semplice. Seguendo il codice riportato di seguito, se si verifica un'interruzione nella sorgente dell'evento, Event-Driven Ansible eseguirà un playbook per la correzione.
 

rules:
  - name: An automatic remediation rule
    condition: event.outage == true
    action:
      run_playbook:
        name: remediate_outage.yml

Nell'esempio riportato di seguito, riferito a un rulebook leggermente più complicato, definiamo la sorgente dell'evento come il plugin per le sorgenti certificato Dynatrace. Le regole stabiliscono le condizioni che dobbiamo tenere monitorate; in questo caso, specificano alcune condizioni di utilizzo di applicazioni e hardware.
 

---
- name: Listen for events on a webhook
  hosts: all
  sources:
    - dynatrace.eda.dt_esa_api:
        dt_api_host: "https://abc.live.dynatrace.com"
        dt_api_token: "asjfsjkfjfjh"
        delay: 60 
  Rules:
    - name: Problem payload Dynatrace for CPU issue
      condition: event.payload.problemTitle contains "CPU saturation"
      action:
        run_job_template:
          name: "Remediate CPU saturation issue"
          organization: "Default"
    - name: Problem payload Dynatrace for App Failure rate increase issue
      condition: event.payload.problemTitle contains "Failure rate increase"
      action:
        run_job_template:
          name: "Remediate Application issue"
          organization: "Default"
    - name: Update comments in Dynatrace
      condition: 
        all: 
          - event.status == "OPEN"
      action:
        run_playbook:
          name: dt-update-comments.yml

Nel payload dell'evento che riceviamo, controlleremo i messaggi "CPU saturation" (saturazione della CPU) o "Failure rate increase" (aumento della frequenza di errore). Se questi messaggi si trovano nel payload, Event-Driven Ansible abbina gli eventi a playbook o modelli dei processi per risolvere il problema.

Red Hat Ansible Automation Platform utilizza un linguaggio YAML leggibile dagli utenti che consente di condividere, controllare e gestire i contenuti dell'automazione. Include tutti gli strumenti necessari per implementare l'automazione nell'intera azienda, inclusi Event-Driven Ansible, playbook e analisi. Inoltre, consente ai team di centralizzare e controllare l'infrastruttura IT tramite una dashboard grafica, il controllo degli accessi basato sui ruoli e molte altre funzionalità volte a ridurre la complessità operativa.

Le sottoscrizioni Red Hat includono i contenuti certificati creati da un consolidato ecosistema di partner, l'accesso ai servizi di gestione in hosting e il supporto tecnico per il ciclo di vita che agevolano la scalabilità dell'automazione nell'intera organizzazione. I clienti possono inoltre avvalersi delle conoscenze e delle competenze degli esperti Red Hat, acquisite attraverso collaborazioni di successo con migliaia di clienti.

Il rilascio di Red Hat Ansible LightSpeed with IBM watsonx Code Assistant rende Ansible più accessibile agli utenti meno esperti e consente a quelli più esperti di lavorare in modo più produttivo ed efficiente, riducendo gli errori. Agli sviluppatori basta inserire la richiesta di un’attività in inglese affinché Ansible Lightspeed possa interagire con i modelli fondamentali di IBM watsonx per generare il codice da utilizzare per la creazione di Ansible Playbook.