Ansible playbook 사용해보기! - ansible 이해하기 5편

ansible playbook은 반복, 재사용, 간단한 구성 관리 및 다중 시스템 배포, 복잡한 애플리케이션 배포 사용에 적합하다. ansible로 작업을 두 번이상 해야할 경우 playbook을 작성하고 VCS^[각주:1]로 관리를 한다. 이 playbook에 대한 예제로 ansible-examples 저장소를 참고한다.

 

플레이 북이 할 수 있는 일들:

• 구성 선언
• 여러 시스템에서 정의 된 구성을 구성한 순서대로 제어할 수 있다.
• 동기 또는 비동기식으로 task를 실행할 수 있다.

 

Playbook 구문

playbook은 yaml 형식으로 표현한다. playbook은 순서 목록에서 하나 이상의 play로 구성된다. 각 play는 playbook의 전체 목표 중 일부를 실행하여 하나 이상의 task를 실행한다. 각 task는 ansible 모듈을 호출한다.

 

Playbook 실행

playbook은 위에서 아래로 순서대로 실행한다. 여러개의 play가 설정된 playbook은 여러 시스템에 배포를 조율하여 웹 서버에서는 하나의 play를 실행, DB 서버에서 다른 play를 실행한 다음 네트워크 인프라에서 세번째 play를 실행하는 등의 작업을 수행할 수 있다. 각 play는 최소한 2가지를 정의를 해야 한다.

• 대상으로 지정할 Managed node의 이름 패턴
• 실행할 하나 이상의 task

playbook은 task를 재사용 가능한 단위로 통합하는데 사용된다. ansible 2.10 이상에서는 여러 collection에 동일한 이름(example: user)의 모듈이 포함될 수 있으므로 playbook에 정규화된 collection 이름을 사용하여 정확한 모듈이 선택되었는지 확인하는 것이 좋다. playbook에서 collection을 사용하는 방법은 해당 link를 참조한다.

아래 예제에서 첫 번째 play는 웹 서버를 대상으로 한다. 두 번째 play는 DB 서버를 대상으로 한다.

---
- name: Update web servers
  hosts: webservers
  remote_user: root

  tasks:
  - name: Ensure apache is at the latest version
    ansible.builtin.yum:
      name: httpd
      state: latest
  - name: Write the apache config file
    ansible.builtin.template:
      src: /srv/httpd.j2
      dest: /etc/httpd.conf

- name: Update db servers
  hosts: databases
  remote_user: root

  tasks:
  - name: Ensure postgresql is at the latest version
    ansible.builtin.yum:
      name: postgresql
      state: latest
  - name: Ensure that postgresql is started
    ansible.builtin.service:
      name: postgresql
      state: started

playbook에는 host 줄과 task 뿐만 아니라 다른 것도 포함될 수 있다. 예를 들어, 위 playbook은 각 play에 대해 remote_user를 설정한다. 이 설정은 ssh 연결을 위한 사용자 계정이다. playbook, play 또는 task 수준에서 다른 playbook 키워드를 추가하여 ansible 동작 방식에 영향을 줄 수 있다. playbook 키워드는 연결 플러그인, 권한 에스컬레이션 사용 여부, 오류 처리 방법 등을 제어할 수 있다. 다양한 환경을 지원하기 위해 ansible은 이러한 파라미터 중 많은 부분을 CLI 플래그, ansible configuration, 또는 inventory에서 설정할 수 있다. 이런 데이터 소스에 대한 우선 순위 규칙을 배우면 ansible ecosystem을 확장하는데 도움이 된다.

 

Task 실행

기본적으로 ansible은 호스트 패턴과 일치하는 모든 시스템에 대해 한 번에 하나씩 각 task를 순서대로 실행한다. 각 task는 특정 인수를 사용하여 모듈을 실행한다. 모든 대상 시스템에서 task가 실행되면 ansible은 다음 task로 이동한다. 이 기본 동작을 전략을 사용하여 변경할 수 있다. 각 play 내에서 ansible은 모든 호스트에 동일한 task 지시문을 적용한다. 시스템에서 작업이 실패하면 ansible은 나머지 playbook에서 실패한 호스트를 순서에서 제외한다.

 

playbook을 실행하면 ansible은 연결에 대한 정보, 모든 play 및 task의 이름, 각 task의 성공 여부, 각 task가 각 시스템에서 변경되었는지 여부를 반환한다. playbook 실행 하단에 ansible은 대상 노드와 노드 수행 방식에 대한 요약을 제공한다. 일반적인 실패와 치명적인  unreachable 같은 에러에 대해서 각각 카운트가 저장된다.

 

원하는 상태와 멱등성

대부분의 ansible 모듈은 원하는 최종 상태가 이미 달성되었는지 확인하고, 해당 상태가 달성 된 경우 작업을 수행하지 않고 종료하므로 작업을 반복해도 최종 상태가 변경되지 않는다. 모듈을 이러한 방식으로 작동하는 데 이를 멱등성이라고 한다. playbook을 한번 실행하든 여러 번 실행하든 결과는 동일해야 한다. 그러나 모든 playbook과 모듈이 이런 방식으로 작동하는 것은 아니다. 확실하지 않은 경우 라이브 환경에서 실행하기 전에 미리 테스트 환경에서 여러 번 테스트를 해야 한다.

 

Playbook 실행

playbook을 실행하려면 ansible-playbook 명령을 사용한다.

ansible-playbook playbook.yml -f 10

playbook 실행 시 --verbose 플래그를 사용하여 성공 또는 실패한 모듈의 자세한 출력을 볼 수 있다.

 

Ansible-Pull

ansible 명령이나 ansible-playbook은 push 방식으로 Control node에서 managed node로 명령이나 모듈을 배포하는 방식을 사용한다. 즉, Control node가 각각의 노드에 명령을 내리는 방식이다. 하지만 배포해야 하는 노드의 수가 많을 경우 문제가 발생할 수도 있다. 이때는 managed node에서 control node로 필요한 정보를 역으로 가져와 실행하는 pull 방식을 사용할 수 있다.

 

이 pull 모드는 control node에서 각 managed node를 나열한 후 ansible 설치에 관련된 패키지를 패키지 매니저를 사용하여 설치하는 task와 crontab을 사용하여 특정 시간마다 git같은 vcs에서 최신 playbook을 clone을 하여 체크아웃 후 자기 자신인 localhost를 inventory에 host로 삼아 실행을 하는 방법이다. 해당 방법에 대해서는 git 저장소의 url을 참고하면 이해가 쉽게된다.

 

Playbook 확인하기

playbook을 실행하기 전에 구문 오류 및 기타 문제를 파악할 수 있다. ansible-playbook 명령은 --check, --list-hosts, --diff, --list-tasks 및 --syntax-check를 포함한 여러 확인 옵션을 제공한다. 또한 playbook 검증 및 테스트를 위한 다른 도구에 대해서도 해당 link에서 확인할 수 있다.

1. Version Control System [본문으로]