멀티 play, serial, delegate_to

🔧 Ansible 실습 시리즈

• Chap1. Ansible 실습 환경 구성과 첫 Playbook

• Chap2. 변수와 조건문

• Chap3. 반복문과 핸들러

• Chap4. 템플릿과 Role

• Chap5. 멀티 play, serial, delegate_to

이전 챕터까지 하나의 play에서 모든 노드를 동시에 처리했습니다. 이번에는 play를 여러 개로 나누어 그룹별로 다른 작업을 수행하고, serial로 한 대씩 순차 처리하며, delegate_to로 특정 task만 다른 노드에서 실행하는 방법을 다룹니다.

---

사전 준비: inventory 서브그룹

실습을 위해 inventory.ini에 서브그룹을 추가합니다:

[managed]
node1 ansible_host=node1
node2 ansible_host=node2
node3 ansible_host=node3

[primary]
node1 ansible_host=node1

[secondary]
node2 ansible_host=node2
node3 ansible_host=node3

[managed:vars]
ansible_connection=ssh
ansible_user=ansible
ansible_password=ansible

[primary:vars]
ansible_connection=ssh
ansible_user=ansible
ansible_password=ansible

[secondary:vars]
ansible_connection=ssh
ansible_user=ansible
ansible_password=ansible

primary(node1)와 secondary(node2, node3)로 역할을 나눠두면, play별로 대상 그룹을 다르게 지정할 수 있습니다.

---

멀티 play — 하나의 playbook에 여러 play

play와 task의 차이

지금까지 playbook에는 항상 play가 1개였습니다. 하나의 파일에 play를 여러 개 넣으면 그룹별로 다른 작업을 순서대로 수행할 수 있습니다.

	task	play
단위	무엇을 하느냐	누구에게 무엇을 하느냐
대상 변경	불가 (play의 hosts를 따름)	play마다 hosts, become, serial 등을 다르게 설정 가능
실행 순서	play 안에서 위 → 아래 순차	playbook 안에서 위 → 아래 순차

task만으로는 중간에 대상 호스트를 바꿀 수 없습니다. 대상이 바뀌어야 하면 play를 나눠야 합니다.

playbook 작성

playbook/multi_play.yml:

---
- name: multi playbook primary
  hosts: primary
  become: true
  gather_facts: false
  vars:
    node_role: "primary"
  tasks:
    - name: "write {{ node_role }}"
      ansible.builtin.copy:
        content: "{{ node_role }}\n"
        dest: /tmp/role.txt
    - name: 파일 읽기
      command: cat /tmp/role.txt
      register: result
    - name: 결과 출력
      debug:
        msg: "{{ result.stdout }}"

- name: multi playbook secondary
  hosts: secondary
  become: true
  gather_facts: false
  vars:
    node_role: "secondary"
  tasks:
    - name: "write {{ node_role }}"
      ansible.builtin.copy:
        content: "{{ node_role }}\n"
        dest: /tmp/role.txt
    - name: 파일 읽기
      command: cat /tmp/role.txt
      register: result
    - name: 결과 출력
      debug:
        msg: "{{ result.stdout }}"

YAML 최상위가 리스트(-)이므로, play를 여러 개 나열하면 됩니다. 주의할 점은 ---(YAML 문서 구분자)는 파일 맨 위에 한 번만 쓴다는 것입니다. play 사이에 ---를 또 넣으면 별도 YAML 문서로 해석되어 에러가 발생합니다.

실행 결과

PLAY [multi playbook primary] ****************************************************

TASK [write primary] *************************************************************
changed: [node1]

TASK [파일 읽기] *****************************************************************
changed: [node1]

TASK [결과 출력] *****************************************************************
ok: [node1] => {
    "msg": "primary"
}

PLAY [multi playbook secondary] **************************************************

TASK [write secondary] ***********************************************************
changed: [node3]
changed: [node2]

TASK [파일 읽기] *****************************************************************
changed: [node3]
changed: [node2]

TASK [결과 출력] *****************************************************************
ok: [node2] => {
    "msg": "secondary"
}
ok: [node3] => {
    "msg": "secondary"
}

Play 1(primary)이 완전히 끝난 후 Play 2(secondary)가 시작됩니다. 같은 play 안의 노드들(node2, node3)은 병렬로 처리되어, 출력 순서가 node3 → node2로 뒤바뀔 수도 있습니다.

멀티 play가 아니라 변수로 해결할 수도 있다

위 예제에서 두 play는 hosts만 다르고 task 구조는 동일합니다. 이런 경우에는 inventory의 그룹 변수에 node_role을 정의하고, play 하나로 hosts: managed를 쓰는 것이 더 간결합니다:

[primary:vars]
node_role=primary

[secondary:vars]
node_role=secondary

멀티 play가 진짜 필요한 경우는 그룹별로 task 자체가 다를 때입니다.

---

serial — 한 대씩 순차 처리

serial 추가

Play 2에 serial: 1을 추가합니다:

- name: multi playbook secondary
  hosts: secondary
  become: true
  gather_facts: false
  serial: 1
  vars:
    node_role: "secondary"
  tasks:
    ...

serial 없이 vs serial: 1

serial 없이 실행:

PLAY [multi playbook secondary] **************************************************

TASK [write secondary] ***********************************************************
changed: [node3]
changed: [node2]

node2, node3이 동시에 처리됩니다. PLAY 헤더가 1번 출력됩니다.

serial: 1 추가 후:

PLAY [multi playbook secondary] **************************************************

TASK [write secondary] ***********************************************************
ok: [node2]

TASK [파일 읽기] *****************************************************************
changed: [node2]

TASK [결과 출력] *****************************************************************
ok: [node2] => {
    "msg": "secondary"
}

PLAY [multi playbook secondary] **************************************************

TASK [write secondary] ***********************************************************
ok: [node3]

TASK [파일 읽기] *****************************************************************
changed: [node3]

TASK [결과 출력] *****************************************************************
ok: [node3] => {
    "msg": "secondary"
}

PLAY [multi playbook secondary]가 두 번 나옵니다. Ansible이 내부적으로 play를 노드 수만큼 반복 실행하기 때문입니다. node2의 모든 task가 끝난 후에야 node3이 시작됩니다.

serial: 2로 하면 2대씩 묶어서 처리합니다. 업데이트 중 장애가 발생해도 나머지 노드는 아직 건드리지 않은 상태를 유지할 수 있어, 롤링 업데이트에 핵심적인 기능입니다.

---

delegate_to — 다른 노드에서 task 실행

왜 필요한가

serial: 1로 Worker 노드를 한 대씩 순회하면서 업그레이드하는 상황을 생각해봅시다. drain(kubectl drain)은 Worker 자신이 아니라 kubectl이 설치된 다른 노드에서 실행해야 합니다.

delegate_to 없이는 이것이 불가능합니다:

• 별도 play로 hosts: primary를 만들면, "지금 어떤 Worker 차례인지"라는 순회 컨텍스트가 끊깁니다. drain → 업그레이드 → uncordon을 한 노드 단위로 묶어서 처리할 수 없습니다.
• play 안의 모든 task는 hosts에 지정된 노드에서만 실행되니까요.

delegate_to를 사용하면 play의 순회 컨텍스트는 유지하면서, 특정 task만 다른 노드에서 실행할 수 있습니다:

- hosts: secondary
  serial: 1
  tasks:
    - name: drain
      command: kubectl drain {{ inventory_hostname }}
      delegate_to: node1    # node1에서 실행

    - name: 업그레이드
      apt: ...              # 현재 노드에서 실행

    - name: uncordon
      command: kubectl uncordon {{ inventory_hostname }}
      delegate_to: node1    # node1에서 실행

node2 차례일 때: drain(node1에서) → 업그레이드(node2에서) → uncordon(node1에서). node2가 완전히 끝나야 node3으로 넘어갑니다.

에러: delegate_to는 play 레벨이 아니다

처음에 delegate_to를 play 레벨에 넣으면 다음 에러가 발생합니다:

[ERROR]: 'delegate_to' is not a valid attribute for a Play
Origin: /workspace/ansible/playbook/delegate.yml:7:3

5   gather_facts: false
6   serial: 1
7   delegate_to: node1
    ^ column 3

원인: delegate_to는 task 레벨 속성입니다. hosts, become, serial처럼 play 레벨에서 쓸 수 없습니다.

해결: 개별 task에 delegate_to를 지정합니다:

tasks:
  - name: delegate_to test
    command: hostname
    delegate_to: node1    # task 레벨

playbook 작성

playbook/delegate.yml:

---
- name: delegated playbook
  hosts: secondary
  become: true
  gather_facts: false
  serial: 1
  tasks:
    - name: delegate_to test
      command: hostname
      delegate_to: node1
      register: result
    - name: 결과 출력
      debug:
        msg: "{{ result.stdout }}"

실행 결과

PLAY [delegated playbook] ********************************************************

TASK [delegate_to test] **********************************************************
changed: [node2 -> node1]

TASK [결과 출력] *****************************************************************
ok: [node2] => {
    "msg": "node1"
}

PLAY [delegated playbook] ********************************************************

TASK [delegate_to test] **********************************************************
changed: [node3 -> node1]

TASK [결과 출력] *****************************************************************
ok: [node3] => {
    "msg": "node1"
}

[node2 -> node1]이 핵심입니다. play의 대상은 node2이지만, 실제 hostname 명령은 node1에서 실행되어 결과가 node1입니다.

PLAY RECAP을 보면 node1이 아니라 node2, node3으로 집계됩니다. play의 "현재 호스트" 컨텍스트는 유지되고, 실행만 위임하는 것이기 때문입니다.

---

--check (dry-run) 모드에서의 주의점

실습 중 --check 옵션으로 dry-run을 시도했는데, command task가 skipping되었습니다:

TASK [파일 읽기] *****************************************************************
skipping: [node1]

TASK [결과 출력] *****************************************************************
ok: [node1] => {
    "msg": ""
}

--check는 실제 변경을 하지 않으므로, copy가 파일을 쓰지 않고 command 모듈도 기본적으로 skip됩니다. command, shell 같은 실행 모듈은 dry-run에서 "이걸 실제로 실행하면 어떤 결과가 나올지" 예측할 수 없기 때문입니다.

---

정리

개념	역할	레벨
멀티 play	그룹별로 다른 작업을 순서대로 수행	playbook 레벨
serial	play 대상 호스트를 N대씩 나누어 순차 처리	play 레벨
delegate_to	순회 컨텍스트는 유지하면서 특정 task만 다른 노드에서 실행	task 레벨

이 세 가지를 조합하면, "Phase 1에서는 A 그룹에서 작업하고, Phase 2에서는 B 그룹을 한 대씩 순회하되 일부 명령은 A에서 실행"하는 복잡한 오케스트레이션이 가능해집니다.