Ansible Rulebook

O Ansible® Rulebook é um conjunto de regras condicionais que o Event-Driven Ansible usa para executar ações de TI no modelo de automação orientada por eventos. Com os rulebooks, os usuários indicam ao Event-Driven Ansible qual fonte de evento monitorar e, quando o evento ocorre, o que fazer caso determinadas condições sejam atendidas.

Os rulebooks são escritos em YAML legível por humanos, assim como os Ansible Playbooks. No entanto, eles usam regras condicionais do tipo if-this-then-that (se isso acontecer, faça aquilo) para definir quando um evento deve executar uma ação. Seguindo as instruções de um rulebook, o Event-Driven Ansible monitora o destino, reconhece quando o evento ocorre e executa automaticamente a ação apropriada. 

Com os Ansible Rulebooks, as equipes de TI podem codificar as decisões desejadas e definir as ações a serem executadas quando os critérios definidos forem atendidos. Assim, as ações sempre serão realizadas da mesma maneira. Quando as condições são atendidas, os rulebooks também podem iniciar os Ansible Playbooks existentes, ampliando o valor dos playbooks criados e aprimorados ao longo do tempo, nos quais as equipes já confiam. 

Ao integrar seu conhecimento aos rulebooks, as equipes podem usar o Event-Driven Ansible para minimizar os erros humanos causados por excesso de tarefas repetitivas, criando processos de TI mais eficazes e consistentes.

Event-Driven Ansible oferece funcionalidades de gerenciamento de eventos para automatizar tarefas demoradas e responder a condições dinâmicas em todas as áreas da TI. Ele pode processar eventos contendo informações específicas sobre as condições do ambiente de TI, determinar a resposta adequada e executar ações automatizadas para solucionar ou minimizar a situação. O Event-Driven Ansible pode ser usado para automatizar tarefas de gerenciamento de serviços de TI, como aprimoramento de tickets, correções e gerenciamento de usuários, além de outras tarefas em todo o ambiente.

Por exemplo, suponha que sua ferramenta de observabilidade (fonte de eventos) monitora roteadores de rede e descobre que um deles não está respondendo, reconhecendo isso como um evento. O Event-Driven Ansible recebe o evento, analisa os dados com base nas condições do rulebook e corresponde o evento à ação desejada, por exemplo, restaurar a configuração, redefinir o roteador, criar um ticket de serviço ou redirecionar o tráfego. Seguindo as instruções do rulebook, o Event-Driven Ansible dispara a ação para redefinir o roteador, restabelecendo seu funcionamento normal. Isso pode acontecer a qualquer momento, mesmo de madrugada, enquanto os engenheiros de rede estão dormindo.

Os Ansible Rulebooks oferecem flexibilidade ao Event-Driven Ansible, conectando as fontes de eventos às ações correspondentes por meio de regras.

Os Ansible Rulebooks contêm a fonte de eventos e instruções condicionais, regras que especificam quais ações devem ser realizadas quando determinada condição é atendida. Uma regra inclui uma condição única e uma ação correspondente. O conjunto de regras é um grupo de várias regras e ações. Os rulebooks podem ter vários conjuntos de regras.

Os rulebooks são projetados para oferecer flexibilidade. Eles podem:

• Monitorar uma ou várias fontes. 
• Conter uma ou várias regras.
• Disparar uma ou várias ações. 

A flexibilidade das fontes, regras e ações é integrada ao Event-Driven Ansible, para que os usuários configurem as ações desejadas para condições de TI específicas.

A primeira parte de um rulebook define a fonte ou fontes de eventos que você deseja monitorar. O Event-Driven Ansible conta com fontes inteligentes, como ferramentas e aplicações de observação externas, para identificar os eventos e coletar dados sobre eles. Os Event Source Plugins conectam o Event-Driven Ansible a essas fontes para monitorar os eventos. 

O Red Hat® Ansible Certified Content Collection do ansible.eda contém diversos Event Source Plugins pré-programados para você começar a usar o Event-Driven Ansible. No entanto, a Red Hat incentiva os parceiros e fornecedores a oferecer plugins desenvolvidos especificamente para sua tecnologia, o que simplifica o processo de integração e aumenta o valor dos dados coletados a partir dos eventos.

Plugins de conteúdo certificado do ansible.eda

Com os Event Source Plugins da coleção do ansible.eda, os usuários podem começar a processar eventos rapidamente. Os plugins de fonte permitem que o Event-Driven Ansible analise os eventos, processando-os com base na lógica condicional de um rulebook para determinar as ações a serem tomadas. Se um evento não atender às condições do rulebook, o Event-Driven Ansible não executará nenhuma ação, e o evento será descartado. 

Alguns dos plugins de fonte mais utilizados encontrados na coleção ansible.eda são webhooks, Kafka e Prometheus Alertmanager. Eles são compatíveis com webhooks genéricos que podem ser encontrados em vários sistemas e ferramentas, filas de sistemas de mensageria e alertas de sistemas empresariais de monitoramento de eventos, como o Prometheus. 

Além desses plugins, os parceiros da Red Hat oferecem Event Source Plugins certificados adicionais, desenvolvidos para tecnologias e soluções específicas. Eles podem incluir outras funcionalidades para que o Event-Driven Ansible funcione melhor com as tecnologias dos parceiros. Os usuários também podem criar seus próprios plugins de fonte para fontes de eventos internas.

Por exemplo, se você tem um switch de rede e quer saber quando uma porta fica inativa, o parceiro pode criar um plugin que especifica exatamente o que o Event-Driven Ansible deve monitorar em relação ao switch. Com esse plugin do parceiro, você não receberá inúmeras informações irrelevantes sobre cada atividade que ocorre no switch em tempo integral. O plugin certificado pode indicar apenas o nome do host do dispositivo, o problema ou um número de incidente. Já um plugin genérico, como um webhook, pode incluir outros detalhes, por exemplo, nome do remetente, URL ou outros dados irrelevantes para a resolução do problema.

Quando um plugin de fonte detecta um evento e envia informações sobre ele, o Event-Driven Ansible filtra esses dados usando as regras condicionais do rulebook para determinar quais ações devem ser executadas. As regras são flexíveis, usando cenários do tipo "se isto acontecer, faça aquilo" que definem as etapas a serem realizadas quando os dados do evento atendem a certas condições. 

Por exemplo, em um plugin de fonte que monitora as portas de um roteador de rede, as regras podem estabelecer que, se a porta ficar inativa e não responder por cinco minutos, o roteador deve ser reiniciado. Quando os dados do evento são filtrados com base nas regras e não atendem às condições, nenhuma ação é executada. 

Os rulebooks:

• Contêm uma ou várias regras. 
• Inclui uma condição, várias condições que precisam coincidir com o status do evento, ou várias condições das quais apenas uma precisa coincidir. 
• Aceitam todos os operadores matemáticos tradicionais, como =, ≠, > e <.
• Aceitam dados inteiros, strings, booleanos (como and, or e not), flutuantes e nulos. 

Por exemplo, ao avaliar um único evento e tentar corresponder várias condições, use o booleano and, que indica que cada condição precisará ser atendida para que a ação seja executada.
 

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

Se você estiver monitorando vários eventos e quiser corresponder diversas condições, use all. Assim, todas as condições devem ser atendidas para que uma condição seja considerada uma correspondência. Como as condições são relacionadas a vários eventos, elas são listadas em linhas separadas.
 

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

Ao usar any, se uma das condições for atendida, será considerada uma correspondência, e a ação será executada. Como no exemplo acima, o código envolve vários eventos, e as condições são listadas em linhas separadas.
 

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

Observação: nos exemplos acima, a ação debug imprime as informações do evento para que esses dados sejam exibidos no Event-Driven Ansible.

Quando os dados do evento atendem às condições do rulebook, o Event-Driven Ansible executa uma ou mais ações especificadas. 

Por exemplo:

• Run_playbook executa o Ansible Playbook existente designado para automatizar determinadas ações, como solucionar problemas em um servidor. 
• Run_job_template executa um template de tarefas por meio do automation controller no Red Hat Ansible Automation Platform. Ao executar o modelo dentro do Red Hat Ansible Automation Platform, você obtém benefícios adicionais como gerenciamento de inventário, controle de usuários e acessos, além de análises detalhadas sobre as ações concluídas. 
• Run_module executa um módulo do Ansible existente, que realiza uma ação mais específica e direcionada quando você não quer executar um playbook inteiro.
• Post_event permite publicar um evento em um conjunto de regras em execução. Isso é normalmente incluído após a ação run_playbook ou run_job_template e permite enviar informações sobre o resultado da ação para o Event-Driven Ansible
• Set_fact registra dados específicos sobre um evento ou ação para serem reenviados ao Event-Driven Ansible e usados para outras ações. Como os dados de eventos são temporários, esta ação salva informações especificas para tornar os dados persistentes.
• O debug é semelhante à depuração encontrada nos Ansible Playbooks. Se nenhum argumento for fornecido, a ação imprimirá o payload do evento correspondente e outras informações importantes.

Esta seção inclui alguns exemplos simples de Ansible Rulebooks. Não se preocupe com os detalhes. Estes exemplos são uma introdução a como as fontes, regras e ações interagem no contexto de um rulebook completo. 

Este primeiro exemplo ilustra uma ação individual simples. Seguindo o código abaixo, se houver uma interrupção na fonte de eventos, o Event-Driven Ansible executará um playbook de correção.
 

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

No exemplo abaixo, que tem um rulebook um pouco mais complexo, definimos a fonte de eventos como o plugin de fonte certificado Dynatrace. As regras definem as condições monitoradas. Neste caso, elas especificam as condições de uso da aplicação e do 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

No payload do evento recebido, serão buscadas mensagens de “saturação da CPU” ou “aumento da taxa de falhas”. Se as mensagens forem encontradas, o Event-Driven Ansible corresponderá esses eventos aos playbooks de correção ou aos templates de tarefas para resolver o problema.

O Red Hat Ansible Automation Platform usa linguagem YAML legível por humanos para os usuários compartilharem, verifiquem e gerenciem conteúdo de automação. A solução oferece todas as ferramentas necessárias para implementar a automação em toda a empresa, incluindo o Event-Driven Ansible, playbooks e analytics. Isso permite que suas equipes centralizem e controlem a infraestrutura de TI com um dashboard visual, controle de acesso baseado em função e outras funcionalidades que ajudam a reduzir a complexidade das operações.

Com uma subscrição da Red Hat, você tem acesso a conteúdo certificado do nosso ecossistema de parceiros, serviços de gerenciamento hospedados e suporte técnico de ciclo de vida para escalar a automação por toda a sua organização. Tudo isso com o conhecimento especializado que acumulamos ao trabalhar com sucesso junto a milhares de clientes.

A chegada do Ansible Lightspeed with IBM watsonx Code Assistant torna o Ansible mais acessível para iniciantes, além de ajudar os usuários mais experientes a serem ainda mais produtivos, eficientes e livres de erros. Os desenvolvedores podem fazer uma solicitação em linguagem natural e o Ansible Lightspeed interage com os modelos de base IBM watsonx para gerar recomendações de código então usadas para criar Ansible Playbooks.