Ansible 실습

플레이북

• Ansible 플레이북은 반복 가능하고 재사용 가능하며 간단한 구성 관리부터 여러 호스트에 복잡한 애플리케이션을 배포하는데 매우 적합
• 작업을 두 번 이상 실행해야하는 경우 Ad-hoc 명령을 사용하지 않고, 플레이북을 작성하고 Git과 같은 소스 제어를 사용하는 것을 권장

YAML 기본

• Ansible 플레이북의 YAML 파일은 항상 목록(List)으로 시작되며, 목록의 각 항목은 해시(Hash) 또는 사전(Dictionary)이라는 키/값 쌍을 가지고 있음
• 선택적으로 YAML 파일의 시작은 ---로, 파일의 끝은 ...으로 끝을 나타내고 들여쓰기 수준은 동일해야 하며, 공백문자로 만 사용
• 탭은 구문 오류를 발생함으로 일반적으로 공백 2칸을 사용
• yaml 문서의 원활한 작성 위해 vim 설정

  1. vi ~/.vimrc

  2. syntax on
      autocmd FileType yaml setlocal ai ts=2 sw=2 sts=2 et autoindent
      set cursorcolumn

     -> yaml 문서는 들여쓰기에 민감하므로 vim설정을 통해 들여쓰기를 맞추기 쉽게 설정한다
• YAML에서 리스트
  • 일반적인 리스트 : [1,2,3,4,5]
  • YAML에서 리스트
    
• YAML에서 딕셔너리
  • 반드시 key와 value사이에 공백이 있어야 함
    
• 리스트와 딕셔너리 사용 예시
  
• 위의 예시를 json으로 축약한 예시
  
  -> 리스트 : [] , 딕셔너리 : {}
• 플레이북 구문 예시
  

<yaml 파일 작성시 주의 사항>

1. 들여쓰기 맞춤 매우 중요
2. 콜론(:) 이후에 띄어쓰기 필수
3. 사전(딕셔너리), 목록(리스트) 적용 숙지
4. 모듈별 항목 숙지 필수

• 
• 
• 
• 
• 

플레이북 기본

• 플레이북은 하나 이상의 플레이를 가지고 있으며, 플레이는 작업을 실행하기 위한 특정 관리 노드 또는 그룹을 지정

• 플레이에는 작업을 선언하며, 작업은 모듈을 호출

• 플레이북은 위에서 아래 순서대로 실행

• YAML의 목록은 위에서 아래로 순서를 가짐

  • 플레이북: 하나 이상의 플레이를 가짐
  • 플레이: 하나 이상의 작업을 가짐
  • 작업: 하나의 모듈과 모듈의 옵션/아규먼트를 지정

• 플레이북 기본 구조
  

• 작업 실행 순서
  ① Ansible은 기본적으로 호스트의 패턴과 일치하는 모든 시스템에 대해 각 작업을 순서대로 실행
  ② 각 작업은 지정한 모듈 옵션을 사용하여 모듈을 실행
  ③ 하나의 작업이 호스트 패턴과 일치하는 모든 시스템에서 완료되면 다음 작업으로 이동
  ④ 특정 호스트에서 작업이 실패하면 해당 호스트는 작업이 더 남아 있더라도 제외
  📒 1->2->3->4의 작업 순서에서 3이 실패하면 4로 가지 않고 제외된다

• 작업 실행 멱등성

  • 수학이나 IT에서 연산의 한 성질을 나타내며, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미
  • Ansible의 대부분 모듈은 원하는 최종 상태가 달성 되었는지 확인하고, 이미 원하는 최종 상태를 달성했다면 작업을 실행하지 않게 되는데 몇 번이고 작업을 반복 실행 하더라도 최종 상태가 변경되지 않기 때문에 멱등성을 가진다고 함
  • 모듈의 옵션에 따라 이러한 멱등성을 제공하지 않는 것도 있음.
  • 예를 들어, apache2를 설치하고나서 다시 apache2를 설치한다면 이미 설치되어 있기 때문에 최종결과에 도달한 상태이다. 따라서 그 이후에 작업은 결과가 달라지지 않는다
    -> 처음 설치작업 명령어를 입력하면
    
    -> 다시 설치작업 명령어를 입력하면
    

플레이북 실습

• ansible-playbook playbook.yml

  플레이북 실행

• ansible-playbook playbook.yml --syntax-check

  구문 체크

• ansible-playbook playbook.yml --check

  체크 모드
  -> 체크 모드는 모의 테스트(dry run)로 시뮬레이션을 진행
  -> 체크 모드는 관리 노드를 변경하지 않고 실행하고 모듈은 변경 사항을 보고함
  -> 검사모드를 지원하지 않는 모듈은 아무것도 보고하지 않으며 실행하지도 않음
• 플레이북 작성요령
  
  플레이북은 플레이의 이름, 대상, 작업을 기본적으로 작성해야 함

1 . 간단한 디버깅 및 메세지 출력하는 플레이북

vi test1.yml # test1.yml파일 생성후 접속 

---
- name: play1
  hosts: AA
  tasks:
  - name: 1st task
    debug:
      msg: "1st task"
...

2 . 위의 플레이북에서 gathering fact 사용 안하는 플레이북

vi test2.yml # test2.yml파일 생성 후 접속

---
- name: play1
  hosts: AA
  gather_facts: no #0 false False FALSE
  tasks:
  - name: 1st task
    debug:
      msg: "1st task"
...

📒 Gathering Facts : Fact 라는 변수는 관리하는 대상의 기본 정보들을 담고 있는 변수

3 . 다중 모듈 : 작업에 대해서 여러 모듈을 실행

 - name: 1st play
   hosts: AA
   gather_facts: 0
   tasks:
   - name: 1st task
     command: id
     register: result

   - name: 2nd task
     debug:
     msg: "{{ result.stdout }}"

-> 첫번째 사진은 id의 결과를 "{{ result }}"로 다 출력한 것
-> 두번째 사진은 "{{ result.stdout }}"로 stdout만 뽑아내서 출력한 결과이다

4 . 다중 작업 : 플레이를 설정함으로써 여러 작업을 실행

- name: 1st play
  hosts: ansi-node1
  gather_facts: no
  tasks:
  - name: 1st play - lst task
    command: id
    register: result1

  - name: 1st play - 2nd task
    debug:
      msg: "{{ result1.stdout }}"

- name: 2nd play
  hosts: ansi-node2
  gather_facts: no
  tasks:
  - name: 2nd play - 1st task
    command: hostname
    register: result2
    
  - name: 2nd play - 2nd task
    debug:
      msg: "{{ result2.stdout }}"
      

-> ansi-node1에 대한 작업 결과

-> ansi-node2에 대한 작업 결과

Ansible의 변수 사용

• Ansible을 이용하여 시스템의 구성 관리를 자동화 할 수 있지만, 모든 시스템이 항상 같은 구성을 가지지 않고 경우에 따라 다른 구성을 가져야 할 수 있음.
• Ansible은 변수를 사용해 시스템 간 차이를 처리

1 . 변수 사용

 - name: vars test
   hosts: ansi-node1
   vars:
     var1: abc
     var2: 123
   tasks:
   - name: string print
     debug:
       msg: "문자 출력 결과 {{ var1 }} \n 숫자 출력 결과 {{ var2 }} "

2 . 따옴표와 변수

- name: vars use syntax
  hosts: ansi-node1
  vars:
    str1: "var test"
  tasks:
  - name: vars print1
    debug:
      msg: "{{ str1 }}---------" #변수를 문장의 앞에 오는 경우에는 반드시 따옴표로 쌓여 있어야함

  - name: vars print2
    debug:
      msg: "-----{{ str1 }}----" #변수 참조가 문자의 중간이나 끝에 오는 경우에는 따옴표를 사용하지 않아도 사용 가능

  - name: vars print3
    debug:
      msg: "----{{ str1 }}"

📗 왠만하면 따옴표로 변수를 감싸자

3 . 리스트 변수 사용

- name: list vars
  hosts: ansi-node1
  gather_facts: 0
  vars:
    list1:
    - 1
    - 2
    - 3
  tasks:
  - debug:
      msg: "{{ list1 }}"
  - debug:
      msg: "{{ list1[0] }}"
  - debug:
      msg: "{{ list1[1] }} {{ list1[2] }}"

4 . 딕셔너리 변수 사용

- name: dict vars
  hosts: AA
  gather_facts: 0
  vars:
    info:
      name: Lee
      age: 47
      area: seoul
  tasks:
  - debug:
      msg: "{{ info }}"
  - debug:
      msg: "{{ info.name }} , {{ info.age }} , {{ info.area }}"
  - debug:
      msg: "{{ info['age'] }} , {{ info.area }}"

📗 info.name = info['name']

• 점 표기법 사용시 모듈에 따라 일부 키가 Python 사전의 속성 및 메서드와 충돌할 수 있음
• 딕셔너리 변수의 값은 항상 키 값으로 접근한다

5 . 등록 변수 사용

- name: register vars
  hosts: ansi-node1
  gather_facts: 0
  tasks:
  - name: Input register vars
    command: "ls -la /home/vagrant"
    register: result

  - name: Output register vars
    debug:
      msg: "{{ result }}"

• "{{ result }}"로 result 등록 변수의 ls -la에 대한 결과값을 다 출력
  
  -> result변수에는 ls -la에 대한 결과로 stdout_lines라는 리스트가 존재한다.

5-1 . 위의 플레이북 마지막줄에 추가

- name: register vars stdout_lines
   debug:
     msg: "{{ result.stdout_lines[0:-1] }}"   

-> 인덱스 슬라이싱을 통해 stdout_lines의 마지막줄을 제외한 나머지 줄이 출력되는 것을 확인

6 . 인벤토리 호스트 변수 사용

cp inventory inventory_vars # 기본인벤토리 복사본 생성

vi inventory_vars # 복사본에 접속 후 아래처럼 수정

[all]
ansi-master1

[AA]
ansi-node1   port=80
ansi-node2   port=8080

[BB]
ansi-node2
ansi-node3

[CC]
ansi-node1
ansi-node3

[ABC:children]
AA
BB

vi inven_host_vars1.yml # 플레이북 생성후 아래 처럼 작성

- name: inven host vars
  hosts: AA
  tasks:
  - debug:
      msg: "{{ port }}"

• ansible-playbook inven_host_vars1.yml -i inventory_vars

  
  플레이북 실행시 위의 사진처럼 호스트변수의 port가 출력됨을 확인
  📗 기본 인벤토리가 아닌 복사본 인벤토리이므로 -i 옵션으로 인벤토리를 지정해줘야한다

• 인벤토리에 그룹변수로 port를 정의해도 호스트변수가 있다면 호스트변수에 정의된 port가 출력된다. 마찬가지로 /group_vars에 정의된 port보다 /host_vars에 정의된 port가 우선적으로 출력된다. 여기에 플레이북에 port가 정의되어 있다면 우선적으로 출력된다. 이처럼 변수에는 우선순위가 존재한다
  

# inventory 파일 수정 
[AA]
ansi-node1  var1=1000
ansi-node2

[AA:vars]
var1=2000

# yml파일 작성 
- name: vars
  gather_facts: 0
  hosts: AA
  tasks:
  - debug:
      msg: "{{ var1 }}"

-> ansi-node1은 inventory에서 var1이 호스트변수, 그룹변수로 정의되었고, ansi-node2는 그룹변수로 var1이 정의되었다.
따라서 yml 파일에서 그룹 AA를 대상으로 변수를 출력했을 때
ansi-node1의 호스트변수가 우선이 되어 1000이 출력되고 ansi-node2는 그룹변수만 정의되어있기 때문에 2000이 출력됨을 알 수 있다.

<변수 정의 위치에 대한 팁>

• group_vars/all: 모든 호스트에 공통적으로 적용할 변수 설정
• group_vars/<specific_group>: 특정 호스트 그룹에 공통적으로 적용할 변수 설정
• host_vars/< host >: 특정 호스트에만 적용할 변수 설정
• 플레이 또는 역할에서 만 적용할 변수 설정
• 특정 작업에만 적용할 변수 설정