Ansible 핸들러 이해하기: 멱등성 있는 서비스 재시작 보장
Ansible 핸들러가 작업이 변경될 때만 서비스를 재시작하거나 리로드하는 방법을 플레이북, 역할, 플러시 핸들러 예제와 함께 알아보세요.
Ansible 핸들러 이해하기: 멱등적인 서비스 재시작 보장
Ansible 핸들러는 일반적인 배포 문제를 해결합니다: 설정 파일은 매 실행마다 확인될 수 있지만, 서비스는 해당 파일이 실제로 변경될 때만 재시작되어야 합니다. 핸들러가 없으면 플레이북이 정상 서비스를 이유 없이 재시작할 수 있습니다.
이 가이드는 핸들러의 작동 방식, 정의 위치, 그리고 조기에 플러시해야 하는 시점을 설명합니다. 예제는 웹 서비스를 사용하지만, 동일한 패턴이 앱 워커, 스케줄러, 시스템 데몬에도 적용됩니다.
Ansible 핸들러란?
Ansible에서 핸들러는 다른 작업이 알림을 보낸 후에만 실행되는 작업입니다. 작업이 무언가를 변경하고 notify를 포함하면, Ansible은 일치하는 핸들러를 대기열에 추가합니다.
핸들러의 주요 특징:
- 알림에 의해 트리거됨: 변경된 작업이
notify를 사용할 때 핸들러가 실행됩니다. - 플레이당 한 번 실행: 다섯 개의 작업이 동일한 핸들러에 알리더라도, Ansible은 플레이 끝에 한 번만 실행합니다.
- 재시작 및 리로드에 최적: 핸들러는 설정 변경 후에만 수행되어야 하는 서비스 작업에 이상적입니다.
서비스 재시작에 핸들러를 사용하는 이유
Ansible 핸들러의 주요 사용 사례는 서비스 관리입니다. Apache, Nginx 또는 애플리케이션 설정 파일을 업데이트할 때 서비스는 종종 재시작 또는 리로드가 필요합니다. 배포된 파일이 현재 파일과 다를 때만 해당 작업을 원합니다.
대안을 고려해보세요:
- 핸들러 없음: 추가 조건이 없으면 플레이북이 해당 지점에 도달할 때마다 직접 재시작 작업이 실행됩니다.
- 핸들러 사용: 템플릿 또는 복사 작업은
changed를 보고할 때만 재시작을 알립니다.
예를 들어, 프로덕션 Nginx 플레이북은 설정 드리프트를 강제하기 위해 매시간 실행될 수 있습니다. 핸들러를 사용하면 변경되지 않은 설정 파일이 시간별 리로드를 유발하지 않습니다.
Ansible 핸들러 구현 방법
핸들러는 플레이북의 handlers 섹션이나 역할 내의 handlers/main.yml에 위치합니다. 핸들러 이름은 notify에서 사용하는 이름과 일치해야 합니다.
기본 핸들러 구문
핸들러는 플레이북 수준 또는 역할 내에서 handlers 블록에 선언됩니다.
---
- name: 웹 서버 구성 및 재시작
hosts: webservers
become: yes
tasks:
- name: Apache 설정 파일이 있는지 확인
template:
src: templates/httpd.conf.j2
dest: /etc/httpd/conf/httpd.conf
notify:
- Apache 재시작
handlers:
- name: Apache 재시작
service:
name: httpd
state: restarted
이 예제에서:
template작업을 사용하여 새 Apache 설정 파일(httpd.conf)을 배포합니다.notify키워드가Apache 재시작으로 설정됩니다. 즉,template작업이httpd.conf파일을 성공적으로 변경하면 Ansible이Apache 재시작이라는 핸들러에 신호를 보냅니다.handlers섹션은service모듈을 사용하여httpd서비스를 재시작하는Apache 재시작핸들러를 정의합니다.
여러 핸들러에 알림 보내기
단일 작업이 여러 핸들러에 알릴 수 있습니다. 이는 하나의 구성을 변경하기 위해 여러 서비스를 재시작하거나 여러 정리 작업을 수행해야 하는 경우 유용합니다.
---
- name: 데이터베이스 및 웹 서버 업데이트로 애플리케이션 배포
hosts: app_servers
become: yes
tasks:
- name: 애플리케이션 설정 업데이트
copy:
src: files/app.conf
dest: /etc/app/app.conf
notify:
- 애플리케이션 서비스 재시작
- Nginx 리로드
handlers:
- name: 애플리케이션 서비스 재시작
service:
name: myapp
state: restarted
- name: Nginx 리로드
service:
name: nginx
state: reloaded
이 시나리오에서 app.conf가 업데이트되면 애플리케이션 서비스 재시작과 Nginx 리로드 핸들러가 모두 트리거됩니다.
역할에서 핸들러 사용
핸들러는 일반적으로 Ansible 역할 내에서 사용됩니다. 역할의 handlers/main.yml 파일에 정의됩니다. 역할 내의 작업(또는 역할을 포함하는 플레이북의 작업)이 역할에 정의된 핸들러에 알리면 Ansible이 이를 실행합니다.
apache라는 역할이 다음과 같은 구조를 가지고 있다고 가정해보겠습니다:
apache/
├── handlers/
│ └── main.yml
└── tasks/
└── main.yml
apache/tasks/main.yml:
---
- name: Apache 설정 배포
template:
src: httpd.conf.j2
dest: /etc/httpd/conf/httpd.conf
notify:
- Apache 재시작
apache/handlers/main.yml:
---
- name: Apache 재시작
service:
name: httpd
state: restarted
그런 다음 플레이북에서 역할을 포함합니다:
---
- name: Apache 역할을 사용하여 웹 서버 구성
hosts: webservers
become: yes
roles:
- apache
apache 역할의 Apache 설정 배포 작업이 실행되어 구성을 수정하면, apache/handlers/main.yml에 정의된 Apache 재시작 핸들러가 트리거됩니다.
핸들러 사용 모범 사례
- 각 핸들러를 하나의 작업에 집중시키세요.
Nginx 리로드와 같이 작업과 일치하는 이름을 사용하세요.- 서비스가 리로드를 지원하고 전체 재시작이 필요하지 않은 경우
state: reloaded를 선호하세요. - 구성 작업 후 직접 재시작 작업을 피하세요.
- 알림을 받은 핸들러는 플러시하지 않는 한 플레이 끝에 실행된다는 점을 기억하세요.
고급 개념: 핸들러 플러시
기본적으로 핸들러는 플레이 끝에 한 번 실행됩니다. 때로는 이후 작업을 계속하기 전에 재시작이 필요할 수 있습니다. 예를 들어, 헬스 체크나 마이그레이션을 실행하기 전에 기본 구성을 작성한 후 앱을 재시작해야 할 수 있습니다.
---
- name: 즉각적인 서비스 재시작이 필요한 순차적 설정 업데이트 수행
hosts: servers
become: yes
tasks:
- name: 기본 설정 파일 업데이트
copy:
src: files/primary.conf
dest: /etc/myapp/primary.conf
notify:
- Myapp 재시작
- name: 즉시 재시작을 적용하기 위해 핸들러 플러시
meta: flush_handlers
- name: 보조 설정 파일 업데이트
copy:
src: files/secondary.conf
dest: /etc/myapp/secondary.conf
notify:
- Myapp 재시작
handlers:
- name: Myapp 재시작
service:
name: myapp
state: restarted
여기서 첫 번째 구성 변경이 Myapp 재시작을 트리거하고, meta: flush_handlers가 즉시 실행합니다. 이후 작업이 다른 파일을 변경하면 동일한 핸들러에 다시 알릴 수 있습니다.
전문가에게 문의해야 할 때
핸들러가 프로덕션 데이터베이스, 로드 밸런서 또는 클러스터형 서비스를 재시작하는 경우 검토를 요청하세요. 일부 시스템은 간단한 핸들러 뒤에 숨겨서는 안 되는 롤링 재시작, 쿼럼 확인 또는 드레인 단계가 필요합니다.
결론
변경된 작업이 서비스 재시작, 리로드 또는 데몬 리로드를 트리거해야 할 때마다 Ansible 핸들러를 사용하세요. 핸들러는 플레이북을 멱등적으로 유지하고, 불필요한 재시작을 줄이며, 서비스 변경 사항을 더 쉽게 추론할 수 있게 합니다.