Un rulebook Ansible, c'est quoi ?

Un rulebook Ansible® est un ensemble de règles conditionnelles qu'utilise Event-Driven Ansible pour effectuer des actions dans un modèle d'automatisation orientée événements. Les rulebooks permettent aux utilisateurs d'indiquer quelle source Event-Driven Ansible doit surveiller et l'action à effectuer lorsqu'un événement se produit et que certaines conditions sont remplies.

À l'instar des playbooks Ansible, les rulebooks sont rédigés en YAML, un langage facile à lire, mais ils se basent sur des règles conditionnelles de type si ceci, alors cela pour définir le moment où un événement déclenche une action. En fonction des instructions du rulebook, Event-Driven Ansible surveille et détecte l'apparition d'un événement dans la source cible, et exécute automatiquement l'action adaptée. 

Les rulebooks Ansible permettent aux équipes informatiques de transposer sous forme de code les décisions souhaitées et les actions à effectuer lorsque des conditions sont remplies, afin que ces actions soient toujours effectuées de la même manière. Les rulebooks peuvent également amorcer des playbooks Ansible existants lorsque certaines conditions sont remplies, ce qui permet d'exploiter des playbooks fiables que les équipes ont élaborés et améliorés au fil du temps. 

En intégrant leurs connaissances dans des rulebooks, les équipes peuvent exploiter la solution Event-Driven Ansible pour réduire les erreurs causées par la fatigue liée aux tâches répétitives, et ainsi améliorer l'efficacité et la cohérence de leurs processus informatiques.

Event-Driven Ansible offre les fonctionnalités de traitement des événements nécessaires pour automatiser les tâches chronophages afin de s'adapter à l'évolution des conditions dans tous les domaines informatiques. Ce composant peut traiter des événements qui contiennent des informations particulières sur les conditions de l'environnement informatique, déterminer la réponse appropriée à un événement, puis exécuter des actions automatisées pour le traiter ou le corriger. Event-Driven Ansible permet d'automatiser les tâches de gestion des services informatiques, comme l'amélioration des tickets, la correction et la gestion des utilisateurs, ainsi que diverses autres tâches dans un environnement informatique.

Par exemple, si un outil d'observabilité (la source d'événements) surveille les routeurs du réseau et découvre qu'un routeur ne répond pas (l'événement), il reconnaît ce phénomène comme un événement. La solution Event-Driven Ansible reçoit cet événement, injecte les données associées dans les conditions du rulebook et associe l'événement à l'action souhaitée. Celle-ci peut être la réapplication d'une configuration, la réinitialisation du routeur, la création d'un ticket d'assistance ou le réacheminement du trafic. En fonction des instructions du rulebook, Event-Driven Ansible déclenche l'action pour réinitialiser le routeur, ce qui rétablit son fonctionnement normal. Cette opération peut se produire à tout moment, même à 2 heures du matin pendant que l'équipe chargée du réseau dort paisiblement.

Les rulebooks Ansible apportent une grande flexibilité à la solution Event-Driven Ansible en associant les sources d'événements aux actions correspondantes par le biais de règles.

Les rulebooks Ansible contiennent la source de l'événement et les instructions conditionnelles qui indiquent les actions à effectuer lorsque certaines conditions sont remplies. Une règle se compose d'une condition et de l'action correspondante, tandis qu'un ensemble de règles contient plusieurs règles et actions. Les rulebooks peuvent comporter plusieurs ensembles de règles.

Adaptables, les rulebooks peuvent :

• Surveiller une ou plusieurs sources 
• Inclure une ou plusieurs règles
• Déclencher une ou plusieurs actions 

C'est cette flexibilité qu'offre Event-Driven Ansible au niveau des sources, des règles et des actions qui permet aux utilisateurs de définir les actions à effectuer lorsque des conditions informatiques données sont remplies.

La première partie d'un rulebook définit la ou les sources d'événements à surveiller. Event-Driven Ansible repose sur des sources d'événements intelligentes, telles que des outils et des applications d'observation externes, pour identifier des événements et recueillir des données les concernant. La connexion entre Event-Driven Ansible et ces sources s'établit au moyen de plug-ins de sources d'événements qui permettent à la solution d'écouter des événements. 

La collection de contenus certifiés Red Hat® Ansible ansible.eda comporte plusieurs plug-ins à utiliser pour débuter avec Event-Driven Ansible. Red Hat encourage toutefois ses partenaires et fournisseurs à proposer des plug-ins spécialement adaptés à leur technologie pour faciliter le processus d'intégration et l'exploitation des données relatives aux événements.

Plug-ins de contenus certifiés ansible.eda

Les plug-ins de sources d'événements issus de la collection ansible.eda permettent un traitement rapide des événements. Grâce à ces plug-ins, Event-Driven Ansible peut écouter, puis traiter les événements sur la base de la logique conditionnelle d'un rulebook pour déterminer l'action à effectuer. Si un événement ne remplit pas les conditions du rulebook, Event-Driven Ansible ne déclenche aucune action, et l'événement est écarté. 

La collection ansible.eda comporte des plug-ins de sources courants tels que des webhooks, Kafka et Prometheus Alertmanager. Ces derniers s'adaptent à des webhooks génériques issus de divers systèmes et outils, files d'attente de messages et alertes de systèmes de surveillance d'événements d'entreprise comme Prometheus. 

En parallèle, les partenaires Red Hat proposent d'autres plug-ins certifiés de sources d'événements adaptés à leurs technologies et solutions spécifiques. Ces plug-ins peuvent également inclure d'autres fonctionnalités qui améliorent la compatibilité entre Event-Driven Ansible et ces technologies partenaires. De plus, les utilisateurs peuvent créer leurs propres plug-ins pour les sources d'événements développées en interne.

Supposons qu'un utilisateur souhaite savoir quand un port de commutateur réseau spécifique tombe en panne : un partenaire pourrait créer un plug-in indiquant exactement ce qu'Event-Driven Ansible doit écouter sur ce port. Avec ce plug-in, l'utilisateur ne serait pas submergé d'informations non pertinentes sur tous les événements de ce commutateur. Si ce plug-in certifié pouvait fournir uniquement le nom d'hôte de l'appareil, le problème et la référence de l'incident, un plug-in générique tel qu'un webhook pourrait inclure des détails supplémentaires comme le nom de l'expéditeur, l'URL ou d'autres données qui ne servent pas à la résolution du problème.

Une fois que le plug-in de sources a détecté l'événement et fourni des informations le concernant, Event-Driven Ansible filtre ces données sur la base des règles conditionnelles du rulebook pour déterminer l'action à effectuer. Les règles sont des scénarios flexibles de type si ceci, alors cela qui définissent les étapes à suivre lorsque les données d'un événement remplissent certaines conditions. 

Par exemple, si le plug-in de sources surveille les ports d'un routeur réseau, les règles pourraient être les suivantes : si le port tombe en panne et ne répond plus pendant 5 minutes, alors redémarrer le routeur. Si les données relatives à l'événement sont filtrées en fonction des règles et ne remplissent pas les conditions, aucune action n'est effectuée. 

Les rulebooks peuvent :

• Contenir une ou plusieurs règles 
• Inclure une ou plusieurs conditions qui doivent toutes correspondre à l'état de l'événement, ou plusieurs conditions dont une seule doit correspondre à l'état de l'événement 
• Prendre en charge l'ensemble des opérateurs mathématiques classiques tels que =, ≠, > et <
• Prendre en charge des entiers, des chaînes et des variables booléennes (and, or et not), des types flottants et des types de données avec une condition null 

Par exemple, pour évaluer un événement unique à associer à plusieurs conditions, il faut utiliser la variable booléenne and pour faire en sorte que toutes les conditions soient remplies afin que l'action soit déclenchée.
 

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

Si plusieurs événements à associer à plusieurs conditions sont surveillés, il faut utiliser la valeur all pour que chacune des conditions soient remplies afin que la condition soit considérée comme une correspondance. Les conditions étant liées à plusieurs événements, elles sont rédigées sur des lignes distinctes.
 

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

Lorsque la valeur any est utilisée, si l'une des conditions est remplie, elle est considérée comme une correspondance et l'action est déclenchée. Comme pour l'exemple ci-dessus, ce code prend en compte plusieurs événements. Chaque condition apparaît donc sur une ligne distincte.
 

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

Remarque : dans les exemples ci-dessus, l'action debug (débogage) permet d'imprimer les informations relatives à l'événement afin de voir ces données dans Event-Driven Ansible.

Lorsque les données d'un événement correspondent aux conditions d'un rulebook, Event-Driven Ansible déclenche une ou plusieurs actions. 

Voici quelques actions couramment utilisées :

• Run_playbook : lance l'exécution d'un playbook Ansible existant créé pour automatiser certaines actions, comme le dépannage d'un serveur. 
• Run_job_template : lance l'exécution d'un modèle de tâche par l'intermédiaire de l'outil Automation Controller intégré à la solution Red Hat Ansible Automation Platform. L'exécution du modèle dans la solution donne accès aux avantages qui y sont associés, comme la gestion d'inventaires, le contrôle des utilisateurs et des accès, ainsi que les analyses relatives à l'action effectuée. 
• Run_module : exécute un module Ansible existant qui lance l'exécution d'une action ciblée spécifique, plutôt qu'un playbook entier.
• Post_event : permet de publier un événement dans un ensemble de règles en cours d'exécution. Cette action est généralement incluse après l'action run_playbook ou run_job_template, c'est pourquoi il est possible de réinjecter des informations sur le résultat de l'action dans Event-Driven Ansible.
• Set_fact : enregistre des données spécifiques sur un événement ou une action afin qu'elles puissent être réinjectées dans Event-Driven Ansible et utilisées pour d'autres actions. Les informations sur les événements étant des données éphémères et transitoires, l'action set_fact permet d'enregistrer des informations spécifiques sur des événements et de rendre ces données persistantes.
• Debug : à l'instar de l'action debug utilisée dans les playbooks Ansible, cette action offre la possibilité d'imprimer les données sur l'événement correspondant ainsi que toute autre information importante lorsqu'aucun argument n'est fourni.

Cette section présente deux exemples simples de rulebooks Ansible. Certains détails peuvent ne pas convenir, mais l'objectif est d'illustrer globalement la façon dont les sources, les règles et les actions fonctionnent ensemble dans le contexte d'un rulebook entier. 

Le premier exemple illustre une seule action assez simple. Le code ci-dessous indique qu'en cas de panne au niveau de la source d'événements, Event-Driven Ansible exécute un playbook de correction.
 

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

L'exemple ci-après illustre un rulebook plus élaboré, où la source d'événements est le plug-in certifié de sources Dynatrace. Les règles définissent les conditions à surveiller : ici, elles précisent plusieurs conditions d'utilisation des applications et du matériel.
 

---
- 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

Les données sur l'événement reçues sont soumises à un contrôle pour détecter la présence éventuelle de messages indiquant une saturation du processeur ou une augmentation du taux d'échec. Si ces messages figurent dans les données, Event-Driven Ansible associe ces événements à des playbooks de correction ou à des modèles de tâches afin de résoudre le problème.

Parce qu'elle utilise le langage YAML facilement lisible par un humain, la solution Red Hat Ansible Automation Platform permet aux utilisateurs de partager, corriger et gérer facilement des contenus d'automatisation. Elle comprend tous les outils nécessaires à la mise en œuvre de l'automatisation à l'échelle de l'entreprise, notamment Event-Driven Ansible, des playbooks et des outils d'analyse. De plus, les équipes peuvent centraliser et contrôler l'infrastructure informatique au moyen d'un tableau de bord visuel, du contrôle d'accès basé sur les rôles et d'autres fonctions, avec à la clé une réduction de la complexité de l'exploitation.

Une souscription Red Hat donne accès à des contenus certifiés issus de notre riche écosystème de partenaires, à des services de gestion hébergés et à une assistance technique tout au long du cycle de vie, afin de faire évoluer les processus automatisés dans l'ensemble de l'entreprise. En outre, nous mettons à disposition l'expertise que nous avons acquise dans le cadre de nos collaborations réussies avec des milliers de clients.

L'outil Red Hat Ansible Lightspeed with IBM watsonx Code Assistant rend Ansible plus accessible aux débutants et permet aux utilisateurs expérimentés de travailler de manière plus productive et plus efficace, sans erreurs. Les équipes de développement peuvent saisir une demande de tâche en anglais vernaculaire : Ansible Lightspeed se charge d'interagir avec les modèles de fondation IBM watsonx pour générer des recommandations de code qui sont ensuite utilisées pour créer des playbooks Ansible.