Ansible Rulebook이란?

Ansible® Rulebook은 Event-Driven Ansible이 이벤트 기반 자동화 모델에서 IT 작업을 수행하기 위해 따르는 조건부 규칙 세트입니다. Rulebook은 사용자가 Event-Driven Ansible에 이벤트에 대해 모니터링할 소스와 해당 이벤트가 발생할 때 특정 조건이 충족되면 어떤 작업을 수행해야 할지를 지시하기 위해 사용하는 수단입니다.

Rulebook은 Ansible Playbook과 같이 사람이 읽을 수 있는 YAML로 작성되지만 IFTTT(if-this-then-that) 조건부 규칙을 사용하여 이벤트가 작업을 트리거할 시점을 정의합니다. Event-Driven Ansible은 Rulebook의 명령에 따라 이벤트에 대한 타겟 소스를 모니터링하고, 이벤트가 언제 발생할지 파악하고, 적절한 조치를 자동으로 시행합니다. 

Ansible Rulebook을 사용하면 IT 팀은 원하는 의사결정을 코드화하고 특정 조건이 충족될 때 수행할 작업을 설계하여 매번 동일한 방식으로 작업이 수행되도록 할 수 있습니다. 또한 Rulebook은 조건이 충족될 때 기존의 Ansible Playbook을 시작하므로, 팀이 오랜 시간 구축하고 향상해 온 신뢰할 수 있는 플레이북의 가치를 더욱 확장합니다. 

팀은 보유하고 있는 지식을 Rulebook에 통합하여 Event-Driven Ansible을 사용해 반복적인 태스크로 지친 직원으로 인해 발생할 수 있는 오류를 최소화하고 더욱 효율적이며 일관된 IT 프로세스를 구축할 수 있습니다.

Event-Driven Ansible은 시간이 오래 걸리는 태스크를 자동화하고 모든 IT 도메인에서 상황 변화에 대응하는 데 필요한 이벤트 처리 기능을 제공합니다. Event-Driven Ansible은 IT 환경의 상태에 대한 개별 인텔리전스가 포함된 이벤트를 처리하고, 해당 이벤트에 대한 적절한 대응을 결정한 다음, 이벤트를 처리하거나 해결하기 위한 자동화된 작업을 실행할 수 있습니다. Event-Driven Ansible은 티켓 향상, 문제 해결, 사용자 관리와 같은 IT 서비스 관리 태스크와 IT 환경 전반의 기타 다양한 태스크를 자동화하는 데 사용할 수 있습니다.

예를 들어, 관찰 툴(이벤트 소스)이 네트워크 라우터를 감시하고 라우터가 응답하지 않음을 발견하여 이를 이벤트로 인식한다고 하겠습니다. Event-Driven Ansible은 이 이벤트를 수신하고 해당 Rulebook의 조건을 통해 이벤트 데이터를 제공하고 원하는 작업(구성 재적용, 라우터 재설정, 서비스 티켓 생성 또는 트래픽 리라우팅)과 이벤트를 일치시킵니다. Rulebook의 명령에 따라 Event-Driven Ansible은 라우터를 재설정하는 작업을 트리거하고 이를 정상 기능으로 복원합니다. 네트워크 엔지니어가 잠을 자는 새벽 2시에도 언제든지 이런 작업이 이루어질 수 있습니다.

Ansible Rulebook이 지원하는 Event-Driven Ansible의 유연성은 룰을 통해 이벤트 소스를 해당 작업과 연결합니다.

Ansible Rulebook은 이벤트 소스와 조건부 명령, 즉 특정 조건이 충족될 때 어떤 작업을 수행해야 할지 명시하는 룰을 포함합니다. 룰은 단일 조건과 해당 작업으로 이루어져 있습니다. 룰셋은 다수의 룰과 작업으로 이루어진 그룹입니다. Rulebook은 다수의 룰셋을 포함할 수 있습니다.

Rulebook은 유연성을 갖추도록 설계되었으며, 다음과 같은 기능을 수행할 수 있습니다.

• 하나 또는 다수의 소스 모니터링 
• 하나 또는 다수의 룰 포함
• 하나 또는 다수의 작업 트리거 

이와 같은 소스, 룰, 작업의 유연성은 Event-Driven Ansible에 내장되어 사용자가 특정 IT 조건이 존재할 때 원하는 작업을 설정할 수 있도록 합니다.

Rulebook의 첫 번째 부분은 소스 또는 이벤트에 대해 모니터링하고자 하는 소스를 정의합니다. Event-Driven Ansible은 외부 관찰 툴이나 애플리케이션과 같은 지능형 이벤트 소스에 의존하여 이벤트를 식별하고 이에 대한 데이터를 수집합니다. 이벤트 소스 플러그인을 사용하여 Event-Driven Ansible과 이러한 소스를 연결하여 이벤트를 수신할 수 있습니다. 

ansible.eda Red Hat® Ansible Certified Content Collection은 Event-Driven Ansible을 시작하는 데 사용할 수 있는 사전 구축된 이벤트 소스 플러그인을 포함하고 있습니다. 하지만 Red Hat은 파트너와 벤더가 보유한 기술을 위해 특별히 설계된 사용자 정의 플러그인을 제공하여 통합 프로세스를 간소화하고 이벤트 데이터로부터 더욱 쉽게 가치를 창출할 수 있도록 독려하고 있습니다.

Ansible.eda 인증 콘텐츠 플러그인

사용자는 ansible.eda 컬렉션에서 이벤트 소스 플러그인을 사용하여 이벤트 처리를 빠르게 시작할 수 있습니다. 이러한 소스 플러그인을 통해 Event-Driven Ansible은 이벤트를 수신할 수 있으며, 이후 Rulebook의 조건부 로직을 사용하여 이벤트를 처리하고 어떤 조치를 취할지 결정할 수 있습니다. 이벤트가 Rulebook의 조건을 충족하지 못하는 경우, Event-Driven Ansible은 작업을 트리거하지 않으며 이벤트는 폐기됩니다. 

ansible.eda 컬렉션에서 일반적으로 볼 수 있는 소스 플러그인으로는 웹후크, Kafka, Prometheus Alertmanager가 있습니다. 이들은 다수의 시스템 및 툴, 메시지 큐, Prometheus와 같은 엔터프라이즈 이벤트 모니터링 시스템의 경고에서 올 수 있는 일반 웹후크를 처리합니다. 

이러한 플러그인과 더불어 Red Hat 파트너는 파트너가 보유한 기술과 솔루션에 맞춰 최적화된 추가 인증 이벤트 소스 플러그인을 제공합니다. 이러한 플러그인은 이와 같은 파트너 기술과 더욱 원활하게 연동되도록 Event-Driven Ansible을 위한 추가 기능을 포함할 수 있습니다. 또한 사용자는 자체 개발한 이벤트 소스를 위한 자체 소스 플러그인을 제작할 수 있습니다.

예를 들어, 네트워크 스위치를 보유하고 있으며 포트가 다운될 때만 알고 싶은 경우, 파트너는 스위치에서 Event-Driven Ansible이 무엇을 수신해야 하는지 정확히 명시하는 플러그인을 구축할 수 있습니다. 이러한 파트너 플러그인을 사용하면 스위치에 발생하는 모든 사항에 대한 불필요한 정보를 종일 받지 않아도 됩니다. 인증 플러그인은 장치 호스트 이름, 문제, 인시던트 번호만을 제공하는 반면, 웹후크와 같은 일반 플러그인은 발신자 이름, URL 또는 트러블슈팅 작업과는 관련 없는 기타 데이터와 같은 추가 세부 정보를 포함할 수 있습니다.

소스 플러그인이 이벤트를 감지하여 이에 대한 정보를 제공하면, Event-Driven Ansible은 이러한 데이터를 Rulebook의 조건부 룰을 통해 필터링하여 어떤 조치를 취할지 결정합니다. 룰은 이벤트 데이터가 특정 조건을 충족할 때 수행해야 할 단계를 정의하는 유연한 IFTTT(if-this-then-that) 시나리오입니다. 

예를 들어, 소스 플러그인이 네트워크 라우터에서 포트를 모니터링하는 경우, 룰에 따라 포트가 다운되고 5분간 응답이 없는 경우 라우터를 재시작하도록 지시할 수 있습니다. 이벤트 데이터는 룰을 통해 필터링되며 조건을 충족하지 않으면 어떠한 조치도 시행되지 않습니다. 

Rulebook은 다음과 같은 기능을 수행할 수 있습니다.

• 하나 또는 다수의 룰 포함 
• 하나의 조건, 이벤트 상태와 모두 일치해야 하는 다수의 조건, 또는 여러 조건 중 하나만 이벤트 상태와 일치해야 하는 다수의 조건 포함 
• =, ≠, >, <와 같은 기존의 모든 수학적 연산자 지원
• 정수, 스트링, 부울(예: and, or, not), 부동소수점 및 null 조건 데이터 유형 지원 

예를 들어, 단일 이벤트를 평가하고 다수의 조건을 일치시키려는 경우, 부울 and를 사용할 수 있으며, 이는 각 조건이 충족되어야 작업이 트리거된다는 것을 의미합니다.
 

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

다수의 이벤트를 모니터링하고 다수의 조건을 일치시키려는 경우, all을 사용할 수 있으며, 이는 각 조건이 충족되어야 조건이 일치하는 것으로 간주된다는 것을 의미합니다. 이러한 조건은 다수의 이벤트와 관련이 있으므로, 조건은 별도의 줄에 나열됩니다.
 

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

any를 사용하면 조건 중 하나라도 충족되는 경우, 해당 조건이 일치하는 것으로 간주되며 작업이 트리거됩니다. 위의 예시와 마찬가지로 해당 코드가 다수의 이벤트를 살펴보고 있으므로, 조건은 별도의 줄에 나열됩니다.
 

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

참고: 위 예시에서 debug 작업은 이벤트 정보를 출력하므로 이 데이터를 Event-Driven Ansible에서 확인할 수 있습니다.

이벤트 데이터가 Rulebook의 조건을 충족하는 경우, Event-Driven Ansible은 특정 작업 또는 여러 작업을 트리거합니다. 

다음은 몇 가지 일반적인 작업의 예시입니다.

• Run_playbook은 서버 트러블슈팅과 같은 특정 작업을 자동화하도록 설계해 둔 기존 Ansible Playbook을 실행합니다. 
• Run_job_template은 Red Hat Ansible Automation Platform의 오토메이션 컨트롤러를 통해 작업 템플릿을 실행합니다. Ansible Automation Platform 내에서 템플릿을 실행하기 때문에 인벤토리 관리, 사용자 및 액세스 제어, 완료된 작업에 대한 분석과 같은 관련 장점을 경험할 수 있습니다. 
• Run_module은 플레이북 전체를 실행하지 않으려는 경우 기존 Ansible 모듈을 실행하여 특정 작업을 실행합니다.
• Post_event를 사용하면 실행 중인 룰셋에 이벤트를 게시할 수 있습니다. 이는 보통 run_playbook 또는 run_job_template 작업 이후에 포함되며, 작업의 결과에 관한 정보를 Event-Driven Ansible에 다시 보내는 기능을 제공합니다.
• Set_fact는 이벤트 또는 작업에 관한 특정 데이터를 기록하여 Event-Driven Ansible에 다시 보내 다른 작업에 사용할 수 있도록 합니다. 이벤트 데이터는 일시적인 데이터로, 팩트를 설정하여 이벤트에 관한 특정 정보를 저장하고 해당 데이터를 퍼시스턴트로 유지할 수 있습니다.
• Debug는 Ansible Playbook에서 볼 수 있는 debug와 유사합니다. 인수가 제공되지 않으면, 일치하는 이벤트 페이로드와 중요한 추가 정보를 출력합니다.

이 섹션에는 몇 가지 간단한 Ansible Rulebook 예시가 나와 있습니다. 일부 세부 사항이 잘 이해되지 않더라도 괜찮습니다. 이 예시는 소스, 룰, 작업이 완전한 Rulebook 맥락에서 어떻게 함께 작동하는지에 관해 기본적인 아이디어를 제공하기 위한 것입니다. 

첫 번째 예시는 상당히 간단한 단일 작업입니다. 아래 코드에 따라 이벤트 소스에 중단이 발생하는 경우 Event-Driven Ansible이 문제 해결 플레이북을 실행합니다.
 

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

좀 더 복잡한 Rulebook을 보여주는 아래 예시에서는 이벤트 소스를 Dynatrace 인증 소스 플러그인으로 정의합니다. 룰은 수신하고 있는 조건을 정의하며, 이 예시에서는 일부 애플리케이션 및 하드웨어 활용 조건을 명시합니다.
 

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

수신한 이벤트 페이로드에서 'CPU saturation' 또는 'Failure rate increase' 메시지를 확인합니다. 이러한 메시지가 페이로드에 있는 경우, Event-Driven Ansible은 이러한 이벤트를 문제 해결 플레이북 또는 작업 템플릿과 일치시켜 문제를 해결합니다.

Red Hat Ansible Automation Platform은 사람이 읽을 수 있는 YAML 언어를 사용하므로 사용자가 오토메이션 콘텐츠를 공유, 검사, 관리할 수 있습니다. 여기에는 Event-Driven Ansible, 플레이북, 분석 등 전사적 자동화를 구현하는 데 필요한 모든 툴이 포함되어 있습니다. 팀은 시각적 대시보드, 역할 기반 액세스 제어, 그 외 많은 기능을 통해 IT 인프라를 중앙화하고 제어하여 운영의 복잡성을 줄일 수 있습니다.

Red Hat 서브스크립션을 활용하면 강력한 파트너 에코시스템의 인증 콘텐츠, 호스팅된 관리 서비스에 대한 액세스, 그리고 조직 전반에서 자동화를 확장하기 위한 라이프사이클 기술 지원을 받을 수 있습니다. 또한 수천 곳의 고객 성공 사례를 통해 쌓은 전문 지식을 활용할 수 있습니다.

Red Hat Ansible Lightspeed with IBM watsonx Code Assistant의 도입으로, Ansible 초보자들도 더욱 쉽게 Ansible을 사용할 수 있고, Ansible 사용 경험자들은 더욱 생산적이고 효율적으로 오류 없이 작업할 수 있습니다. 개발자가 태스크 요청을 영어로 입력하면, Ansible Lightspeed가 IBM Watson 파운데이션 모델과 상호 작용하여 코드 권장 사항을 생성하고 이를 사용하여 Ansible Playbook을 생성합니다.