1. Playbook 확장

제어 구조

Ansible Playbook에 선택문/반복문은 Attribute 형태를 사용하여 적용
(他 프로그래밍 언어와 다른 특성)

순차 구조

명령이 기술된 순서로 순차적으로 수행하는 구조

선택 구조

조건에 따라 명령의 실행 순서를 변경할 수 있는 구조 -> 선택문

반복 구조

특정 명령을 일정 횟수 동안 반복해서 수행하는 구조 -> 반복문

반복문

• task를 반복해서 동작시킬 때 사용
• 모듈의 키워드(keyword, Attribute 성격)로 사용
• with_* 키워드와 loop 키워드 사용
  • with_item
  • with_nested
  • with_sequence
• 패키지 관련 모듈은 반복문 사용 X 권장
• 반복문에서 제공되는 목록을 참조하는 변수명은 항상 item 사용

예시 1) loop.yml
---
- name: loop
  hosts: private
  gather_facts: False

  tasks:
    - name: loop basic
      debug:
        msg: "{{ item }}"
      loop:
        - a
        - b
        - c

    - name: loop basic 2
      debug:
        msg: "{{ item.user }} [ {{ item.group }} ]"
      loop:
        - user: user1
          group: group1
        - user: user2
          group: group2

    - name: non loop 1
      debug:
        msg: "user1 [ group1 ]"

    - name: non loop 2
      debug:
        msg: "user2 [ group2 ]"     
        
        
        
예시 2) create_file.yml
---
- name: create file
  hosts: private
  gather_facts: False

  vars:
    file_path: /home/ec2-user/work_touch
    id: ansible

  tasks:
    - name: create directory
      file:
        path: "{{ file_path }}"  
        state: directory

    - name: confirm file
      stat:
        path: "{{ file_path }}/{{ id }}.txt"   
      register: result  

    - name: create file
      file:
        path: "{{ file_path }}/{{ item }}.txt"
        state: touch 
      loop:
        - "{{ id }}1"
        - "{{ id }}2"
        - "{{ id }}3"   

조건문 (선택문)

• task가 특정 조건에만 작업을 수행하도록 구성할 때 사용
• when 키워드 사용
• 조건에 대한 표현식을 테스트문 또는 필터 사용
• 조건문에 변수를 참조할 때 "{{ 변수명 }}" 사용 X, 바로 변수명 사용
• 조건 결과가 True 인 경우에 task 실행

테스트문

테스트는 표현식 평가 및 True / False 반환

when: 변수 연산

변수를 테스트하기 위한 테스트문

<변수> is failed : 작업 실패
<변수> is changed : 작업 성공적 실행 및 변경 수행
<변수> is succeeded : 작업 성공적 실행
<변수> is skipped : 조건문에 의해 실행되지 X

필터

when: <변수 [ | (자료형) ]> <조건 연산자> 값

<변수 | (자료형) > 표현은 변수형 변환 의미, | 다음에 형변환을 원하는 자료형 기입, 숫자형으로 변환할 때 사용

• 조건 연산자 : > , < , >= , <= , == , !=

include (포함)

• Playbook의 내용이 많아지거나 복잡한 경우 더 작은 단위로 나누면 관리 편의성 ↑
• 모듈식으로 여러개의 Playbook을 main Playbook에 결합 or 파일의 task를 play에 포함
• 이와 같은 방식으로 Playbook을 모듈로 나누면 재사용성 ↑ (모듈화)
  
  
• Ansible에서 파일이나 role을 특정 Playbook에 읽어들일 때 import / include 2가지 방법 中 1 사용 가능

import

static (정적, 고정적) re-use

• role, task, Playbook 등을 Playbook에 정적으로 포함
• Ansible은 읽어들인 파일이나 role 등을 최상위 플레이북에서 작업 실행 전 사전 처리
• import된 Playbook은 최상위 Playbook 化, 他 task 영향 X
• import 사용 : import_playbook

include

dynamic (동적, 유동적) re-use

• role, task, Playbook 등을 Playbook에 동적으로 포함
• include된 콘텐츠는 최상위 Playbook의 이전 작업의 결과에 영향 받음
• 최상위 Playbook의 실행 결과에 따라 실행 될수도 안될수도
• include 사용 : include <playbook 파일명>

예시 3) install_pack_web.yml
---
- include: webserver.yml

Handler

함수 (function)와 비슷한 성격; 단위 기능 실행 (참고)

• task가 하는 일 똑같이 가능
• Playbook의 task에서 handler 호출시 해당 handler가 호출되어 실행되는 방식으로 동작
• 반복되는 동작(task)에 대해 별도의 handler로 정의

Handler 정의

정의

Handlers 섹션에 task 정의, task 섹션과 같은 level

호출

Handler 호출은 notify: 키워드에 해당 Handler 이름 명시, 모듈과 같은 level

• Handler는 이름으로 호출 -> notify에 기술된 Handler 이름이 실제 Handlers 섹션에 정의된 Handler 이름과 동일해야!
• 동일한 Handler에 대해 여러번 호출되어도 한번만 실행
• 변수 사용시에는 include_vars 모듈 사용
• listen key를 handler task에 부여하면 notify시 listen에 부여한 이름으로 호출할 때 listen key가 정의된 handler가 모두 동작

Roles

include(포함)의 확장 개념, 역할에 따라 roles 폴더에 필요한 파일들을 별도로 생성하여 사용

• role에서 다른 role 포함 및 변수 전달 가능
• 역할에 따른 role을 작성해서 관리함으로써 관리의 편의성 및 재사용성을 높일 수 있는 프로젝트 관리 방법

role 관리 방법

• roles 이름의 폴더(디렉토리) 생성
• roles 폴더 아래에 필요한 폴더 추가 생성
  • files, handlers, tasks, templates, vars, meta ...

    tasks/main.yml : 역할 실행 task 저장
    handlers/main.yml : handler 저장
    vars/main.yml : 변수 저장

• Playbook에는 적용하고 싶은 role을 roles 섹션에 추가

2.TIF

드디어 오늘로 Ansible이 끝이 났다.
늘 그렇듯 막판가서 진도와 난이도가 와다다다 하면서 급상승해서 따라가기 힘든 경향이 있었지만, 최소한 이번만큼은 어떻게든 이해하고 따라가보려 노력했던 것 같다. 적어도 나로써는.

드디어 다음주부터는 본격적으로 도커에 들어간다. 난 이번주 내내 다뤘던 앤서블의 응용이 도커다, 정도로만 이해하고 있었는데 알고보니 그래도 앤서블 정도면 전통적인 방식의 수동적인(?) 배포법이라는데서 적잖은 충격을 받았었다. 내 입장에서는 앤서블도 충분히 혁신이었는데 말이지. 도커와 쿠버네티스 정도면 대체 얼마나 혁신적으로 자동화가 이뤄지는건지 이제 다음주면 알 수 있겠지?

갈수록 머리가 조금씩 IT에 맞춰서 변해져가는게 느껴지는데 나쁘진 않다.