Red Hat Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://developers.redhat.com/articles/2025/01/09/implement-remediation-strategies-event-driven-ansible
Event-Driven Ansible 은 Red Hat Ansible Automation Platform 의 강력한 확장 기능으로 , 자동화 인프라를 활용하여 변경이나 문제에 대응할 수 있는 기능을 제공합니다. 간단히 말해, 이벤트 기반 Ansible은 특정 이벤트가 감지되면 Ansible 플레이북(또는 Ansible Automation Platform의 작업 템플릿)을 트리거할 수 있습니다.
이 글에서는 이벤트 기반 Ansible을 사용하여 환경 내 활동에 기반한 여러 가지 문제 해결 전략을 구현하는 방법에 대한 일련의 예제를 제공합니다. Red Hat Runtimes 의 일부인 Red Hat JBoss Enterprise Application Platform (JBoss EAP)을 참조 구현으로 사용합니다.
환경 설정: Podman
간단하고 재현하기 쉽도록 최신 Fedora 릴리스 기반의 Podman 컨테이너에 Ansible 컨트롤러를 설정하겠습니다 . 이 인스턴스는 다른 인스턴스와 통신해야 하므로, 먼저 컨테이너들이 공존할 수 있도록 네트워크를 생성하겠습니다.
$ podman network create eda_red_hat_blog
이 네트워크가 생성되면 첫 번째 컨테이너(Ansible 제어 노드 로 사용할 인스턴스)를 설정할 수 있습니다 .
$ podman run -it --name=control_node --rm --network eda_red_hat_blog registry.fedoraproject.org/fedora:latest /bin/bash
제어 노드 준비
컨테이너가 실행되면 Ansible을 설치할 수 있습니다.
# dnf install ansible-core
EAP용 Ansible 컬렉션은 Ansible Automation Hub 에서 제공됩니다 . 콘텐츠 제공자로 사용하려면 프로젝트의 ansible.cfg를 업데이트해야 합니다. 자세한 내용은 Ansible Automation Hub 설명서를 참조하세요 .
그런 다음 필요한 Ansible 컬렉션을 설치합니다. 이벤트 기반 Ansible용 Ansible 컬렉션 과 EAP용 Ansible 컬렉션 :
$ ansible-galaxy collection install ansible.eda redhat.eap
참고 : 물론 Ansible 자동화 플랫폼을 사용할 수 있고 사용 중이라면 이 제어 노드 설정은 필요하지 않습니다. 이 문서에 설명된 방법(Podman 컨테이너와 Fedora 배포판 사용)은 이러한 인프라가 없어도 데모를 쉽게 재현할 수 있는 방법입니다.
목표
제어 노드가 설정되었으므로 대상 노드를 사용할 수 있어야 합니다. UBI9 컨테이너를 사용하여 Red Hat Enterprise Linux (RHEL) 9 로 실행되는 시스템을 에뮬레이션합니다 .
$ podman run --rm -d --network eda_red_hat_blog --systemd=true --privileged=true --name=node registry.access.redhat.com/ubi9/ubi-init:latest
이 UBI9 플레이버는 systemd와 컨테이너 내에서 실행되도록 이미 미리 구성되어 있으므로 ubi-init 이미지 를 사용한다는 점에 유의하세요 .
제어 노드가 노드를 나타내는 컨테이너에 연결할 수 있도록 SSHd를 설치하고 활성화해야 합니다.
$ podman exec -ti node /bin/bash # dnf install -y openssh-server # # for the demo, we'll authorize root login. Obviously don't do this for sensitive or production systems!!! # sed -i /etc/sshd/sshd_config -e '/^.*PermitRootLogin.*$/PermitRootLogin yes/' # systemctl start sshd
다음 단계로 넘어가기 전에, 제어 노드를 나타내는 컨테이너가 실제로 대상에 연결할 수 있는지 확인해 보겠습니다. 먼저, Ansible이 대상을 식별할 수 있도록 인벤토리 파일을 생성해야 합니다.
$ cat inventory [all] node
이제 Ansible을 실행하여 원격 호스트에 연결할 수 있는지 확인해 보겠습니다. 이 경우, 자동화 도구에 원격 시스템에 대한 사용 가능한 정보(Ansible 용어로 ‘팩트(fact)’)를 수집하도록 요청합니다.
$ ansible -m setup -i inventory all
이 명령은 YAML 콘텐츠로 구성된 대상에 대한 많은 정보를 반환합니다. 이 단계에서는 Ansible이 올바르게 구성되었고 원격 노드에 연결할 수 있다는 결론을 내리기에 충분합니다.
JBoss EAP 설정
이제 앞서 제어 노드에 설치한 Ansible Collection for EAP의 자동화 기능을 활용하여 대상 서버에 JBoss EAP를 서비스로 설정해 보겠습니다. 이를 통해 이벤트 기반 Ansible을 사용하여 모니터링하기에 적합한 서비스를 제공할 수 있습니다.
EAP 다운로드를 위한 자격 증명
JBoss EAP는 Red Hat 제품이므로 Ansible에 service account 자격 증명을 제공해야 합니다. 이를 통해 자동화 도구가 Red Hat 고객 포털 에 연결하여 적절한 아카이브를 다운로드할 수 있습니다. 이 작업을 수행하려면 필요한 정보를 YAML 파일에 저장하고 Ansible이 런타임에 참조할 수 있습니다.
---
rhn_username: <service_account_username>
rhn_password: <service_account_password>해당 자격 증명을 얻는 방법에 대한 자세한 내용은 다음 문서 를 참조하세요 .
JBoss EAP 설치
EAP용 Ansible 컬렉션 덕분에 이 제품을 배포하기 위한 플레이북은 최소화되었습니다.
---
- name: Ensure Wildfly is install and running as a service
hosts: all
collections:
- redhat.eap
roles:
- eap_install
- eap_systemd앞서 언급한 자격 증명을 Ansible에 제공하기만 하면 자동화 도구가 나머지 작업을 처리합니다.
$ ansible-playbook -i inventory playbook.yml -e @service_acount.yml
참고 : 컬렉션은 콘텐츠가 실행될 때마다 JBoss EAP 아카이브를 다운로드하지 않습니다. Red Hat 고객 포털 에서는 한 번만 다운로드하며, 이후 제어 노드의 파일 시스템에 아카이브가 존재하는 한 더 이상 다운로드되지 않습니다.
Ansible 실행이 완료되면 systemctl status eap 명령을 사용하여 서비스가 실제로 설치되고 제대로 실행되었는지 확인할 수 있습니다. 아래 플레이북을 사용하여 제어 노드에서 이 검증을 수행할 수 있습니다.
---
- name: Ensure EAP is installed and running as a service
hosts: all
gather_facts: false
tasks:
- ansible.builtin.command: "systemctl status eap"
register: status_eap
- ansible.builtin.debug:
var: status_eap
when:
- status_eap is defined and status_eap.stdout is defined이벤트 기반 Ansible을 사용한 JBoss EAP의 수정
이제 대상 노드가 프로비저닝되었으므로 이벤트 기반 Ansible을 조금 더 자세히 살펴볼 수 있습니다.
컨트롤러에 ansible-rulebook을 설치
먼저, 제어 노드에 ansible-rulebook 명령을 설치해야 합니다 . 앞서 설정한 것과 같은 Fedora 컨테이너 내에서 다음 pip 명령을 사용하여 설치해야 합니다.
# dnf install python3-pip.noarch
# pip install ansible-rulebook
# ansible-rulebook --version
# ansible-rulebook --version
1.1.1
Executable location = /usr/local/bin/ansible-rulebook
Drools_jpy version = 0.3.9
Java home = /usr/lib/jvm/java-17-openjdk-17.0.13.0.11-3.fc41.x86_64
Java version = 17.0.13
Python version = 3.13.0 (main, Oct 8 2024, 00:00:00) [GCC 14.2.1 20240912 (Red Hat 14.2.1-3)]사용자가 Ansible Automation Platform 인스턴스(이벤트 기반 Ansible이 설치됨)를 사용할 수 있는 경우 이 단계는 필요하지 않습니다.
사용 사례 1: 서비스가 중단된 경우 EAP 다시 시작
이제 제어 노드에서 이벤트 기반 Ansible을 완전히 사용할 수 있게 되었으므로, 대상 노드의 JBoss EAP 서비스가 실행 중이 아닌지 감지하는 데 사용할 수 있습니다. 이러한 이벤트가 발생하면 이벤트 기반 Ansible은 자동화를 트리거하여 서비스를 재시작합니다. 간단한 사용 사례이지만 이벤트 기반 Ansible의 기능을 알아보기 위한 훌륭한 시작점입니다. 기존 Ansible 자동화가 플레이북을 사용하여 작업을 정의하는 반면, 이벤트 기반 Ansible은 룰북을 사용하며, 둘 다 YAML 구문을 사용합니다. 두 가지의 유사성 덕분에 대부분의 Ansible 사용자에게 내용이 익숙하게 보입니다.
규칙서는 두 부분으로 나뉩니다. 첫 번째 부분은 레이블이 지정되어 있으며 sources, 이름에서 알 수 있듯이 잠재적으로 조치를 취할 수 있는 이벤트의 출처를 제공합니다. 여기서 이벤트 기반 Ansible을 이벤트를 제공하는 여러 시스템(예: Apache Kafka)과 통합할 수 있습니다. 두 번째 부분은 레이블이 지정되어 있으며 rules, 특정 이벤트가 식별될 경우 실행될 작업을 설명합니다.
이 경우에는 내장된 check_url라고 이름 붙여진 source를 사용합니다. 이름에서 알 수 있듯이 JBoss EAP의 웹 루트 컨텍스트인 URL을 모니터링합니다. 이 URL에 접근할 수 없으면 JBoss EAP가 다운되었을 가능성이 높습니다. 규칙과 관련하여, 다음 플레이북을 실행하여 서비스가 (다시) 시작되도록 합니다.
---
- name: Ensure EAP is installed and running as a service
hosts: node
gather_facts: false
tasks:
- name: Restart EAP
ansible.builtin.service:
name: eap
state: started이제 첫 번째 규칙책의 내용을 살펴보겠습니다.
---
- name: EAP remediation using EDA
hosts: all
sources:
- ansible.eda.url_check:
urls:
- "http://node:8080/"
rules:
- name: Restart EAP if url is not reachable
condition: event.url_check.status == "down"
action:
run_playbook:
name: playbooks/restart_eap.yml플레이북과 형식이 비슷해서 내용이 매우 간단하고 이해하기 쉽습니다. 룰북의 윗부분은 플레이북과 마찬가지로 룰북의 이름과 대상(호스트)이 포함되어 있습니다.
앞서 설명한 대로 소스 항목과 규칙 항목도 포함되어 있습니다. 이 규칙집에 포함된 소스는 이벤트 기반 Ansible에서 제공하며, URL에 접근 가능한지 확인하고 원격 시스템의 상태에 따라 이벤트를 생성합니다.
이 rules 속성에는 소스 목록 내에서 생성된 이벤트에 따라 동작을 트리거할 수 있는 규칙 목록이 포함됩니다. 이 규칙집에 포함된 규칙은 노출된 URL에 더 이상 접근할 수 없는 경우 JBoss EAP를 다시 시작하는 플레이북을 트리거합니다.
꽤 간단하고 깔끔하죠!
이제 다음 명령을 사용하여 이 룰북을 실행해 보겠습니다.
$ ansible-rulebook -r rulebooks/rulebook1.yml -i inventory
명령이 시작되면 정의된 조건에 따라 이벤트가 규칙 중 하나와 일치할 때까지 대기합니다. URL이 성공적인 결과를 반환하지 못하는 조건은 대상 노드에서 systemctl stop eap 명령을 실행하여 간단히 트리거할 수 있습니다.
그러면 이벤트 기반 Ansible이 이벤트를 수집하고 JBoss EAP 서비스를 다시 시작하여 상황을 해결하려고 시도하는 것을 볼 수 있습니다.
$ ansible-rulebook -r rulebooks/rulebook1.yml -i inventory PLAY [Ensure EAP is installed and running as a service] ************************** TASK [Restart EAP] ************************************************************* changed: [node]
사용 사례 2: 메모리 부족 오류 발생 시 EAP 재시작
서비스 재시작은 비교적 간단한 사용 사례입니다. 이제 더 복잡한 실제 사용 사례를 살펴보겠습니다. JBoss EAP에 호스팅된 애플리케이션 중 하나가 가끔 Out of Memory error 오류를 발생시킨다고 가정해 보겠습니다 . 개발자들은 이 문제를 데이터베이스 연결 풀과 연관시켰으며, 이 문제를 해결하는 한 가지 방법은 JBoss EAP 내에서 유휴 상태인 연결을 플러시하는 것입니다.
이제 이벤트 기반 Ansible을 사용하여 이 수정 전략을 자동화해 보겠습니다. 이벤트 기반 Ansible에서 제공하는 다른 이벤트 소스 중 하나인 journald를 사용하겠습니다. 이를 통해 대상 인스턴스 journald에 로그인된 이벤트에 대응할 수 있습니다 .
EAP용 Ansible 컬렉션은 설치 과정에서 Java 서버를 systemd 에 통합하므로 , 자체 로그 항목이 실행 중인 시스템에 전파됩니다. 따라서 이 소스를 사용하여 악명 높은 오류 메시지 java.lang.OutOfMemoryError가 나타나는 것을 감지할 수 있습니다.
이 이벤트가 식별되면 이벤트 기반 Ansible은 또 다른 flush_idle_conn.yml 플레이북을 트리거합니다 . 이 플레이북은 Ansible Collection for EAP의 기능을 활용하여 CLI 기능을 통해 Java 서버와 상호 작용합니다.
---
- name: "Flus idle connection"
hosts: all
collections:
- redhat.eap
tasks:
- name: Flush idle connection
ansible.builtin.include_role:
name: wildfly_utils
tasks_from: jboss_cli.yml
vars:
jboss_cli_query: "/subsystem=datasources/data-source=ExampleDS:flush-idle-connection-in-pool()"새로운 규칙책은 다음과 같습니다.
---
- name: Remediate Out of Memory error triggered by idle connection
hosts: all
sources:
- ansible.eda.journald:
match: ALL
rules:
- name: Match all on journald
condition: event.journald.message is search("java.lang.OutOfMemoryError", ignorecase=false)
action:
run_playbook:
name: playbooks/flush_idle_conn.yml.yml이 시나리오를 구성하는 것은 이 논의의 범위를 벗어나므로, 이 규칙서의 실행 및 관련 수정 사항은 다루지 않겠습니다. 그러나 이 개념들을 통해 이벤트 기반 Ansible에 통합될 수 있는 다양한 전략 유형을 엿볼 수 있습니다.
요약
이 문서에서 보여주듯이, 이벤트 기반 Ansible은 환경 내 활동에 대한 수정 전략(또는 기타 이벤트 기반 작업)을 구현하는 강력한 방법입니다. JBoss EAP, JWS 또는 Red Hat Build of Keycloak과 같은 Red Hat Runtimes 솔루션의 경우, Automation Hub에서 제공되는 컬렉션을 통해 Ansible 및 이벤트 기반 Ansible 모두와 손쉽게 통합할 수 있습니다.
