Today I Learn - 36

-프로젝트에 본격적으로 들어가서 이제 바빠지기 시작했다.

꾸준히 써야 하는데 쉽지 않다.

Ansible 실습환경

Control Node : CentOS 7.8.ova.
IP: 192.168.100.10/24
gateway: 192.168.100.2
dns: 192.168.100.2

$ sudo -i
nmcli connection add con-name static ifname ens33 type ethernet ipv4.addresses 192.168.100.10/24 ipv4.gateway 192.168.100.2 ipv4.dns 192.168.100.2 ipv4.method manual
nmcli connection up static
nmcli connection delete ens33
hostnamectl set-hostname control.example.local

Managed hosts : CentOS 7.8.ova => multi-user.target, 메모리, CPU 확인
IP: 192.168.100.21,22/24
gateway: 192.168.100.2
dns: 192.168.100.2

$ sudo -i
nmcli connection add con-name static ifname ens33 type ethernet ipv4.addresses 192.168.100.21/24 ipv4.gateway 192.168.100.2 ipv4.dns 192.168.100.2 ipv4.method manual
nmcli connection up static
nmcli connection delete ens33
systemctl set-default multi-user.target
hostnamectl set-hostname managed1.example.local
reboot

============================================================

IaC 개요

기존 시스템 관리 방식
수동관리. 직접 콘솔을 통해서 관리, 네트워크를 통한 접근
직접 관리방식은 사용자에 의한 오류 발생 등의 가능성이 높음
수행결과에 대한 검증
각자 다른 환경에 대한 일관적인 구성이 어려움
유지관리 어려움
자동화된 관리의 필요성 : IaC

IaC (Infrastructure as Code)
코드형 인프라
코드에 의하여 자동적으로 인프라를 구성하도록 하는 방식
인프라 자체에 대한 배포
구성 설정을 관리
클라우드 등과 결합하여 더 강력한 힘을 가지게 됨

IaC 특징
시스템이 자동으로 읽어서 처리할 수 있는 언어(Code)를 사용
상태에 대해서 이해를 하고, 변경사항을 반영할 수 있도록 구성
텍스트 형태의 파일로 구성되어 버전 관리가 용이
인적 오류 완화

Ansible
오픈소스 자동화 관리도구 플랫폼
상용화된 기능도 제공됨 : Ansible Tower
구성관리의 포지션을 담당
일회성 명령, 플레이북(Playbook) 사용
플레이북은 YAML(YAML Ain't Markup Language) 문법을 사용
Agentless(에이전트가 없음) - SSH, Python
Idempotency : 멱등성. 반복적으로 작업을 실행하여도 이미 실행한 작업은 다시 수행하지 않음

Ansible 아키텍처
제어 노드 (Control Node)
Ansible을 사용하여 Managed hosts 를 관리하는 역할
Ansible이 실제 설치되어야 하는 위치
프로젝트 파일 작성, 보관
관리 호스트 (Managed host)
Ansible을 통해 관리되는 실제 인프라
인벤토리 (Inventory)
인벤토리(Inventory)를 사용하여 관리 호스트 목록을 제어
개별 호스트, 그룹 지정 가능
정적 인벤토리/동적 인벤토리 사용 가능
플레이북
YAML 형태의 언어로 구성된 텍스트 파일
플레이북은 하나 이상의 플레이로 구성
플레이는 하나 이상의 작업(Tasks)로 구성
작업
모듈(Module)을 실행
거의 대부분의 모듈은 멱등성을 지원 (command, shell, raw 등은 제외)
플레이북 내에서 작업 실행 중 실패시 나머지 작업이 중단

Ansible 권장 사용방식
복잡하지 않게
가독성을 좋게
선언적인 사고 : 모듈 내에서는 해당 모듈을 통해 갖추어야 할 상태를 정의

==============================================================

Ansible 설치 (제어 노드)
제어노드는 유닉스/리눅스만 가능 (Windows는 안됨)
파이썬 2.6 이상 또는 3버전 이상 필요
ssh 명령 사용 가능
CentOS 에서는 EPEL 레포지토리가 활성화되어 있어야 설치 가능
yum install epel-release
yum install ansible

관리노드 설정 확인
리눅스/유닉스/Windows/네트워크 장비 등을 사용가능
리눅스/유닉스/네트워크장비 : SSH 연결 + Python (2.6 이상)
Windows : WinRM (Windows Remote Management) + PowerShell
SSH 연결 : 키 기반 인증 설정

인벤토리 생성
인벤토리 파일은 INI 파일 형식 또는 YAML 형식으로 작성 (주로 INI)
[항목]
Key=Value

인벤토리에 호스트 등록시 변환 가능한 호스트의 이름, IP 사용
호스트 그룹 사용시 [그룹이름]
기본적으로 지정되어 있는 그룹
all : 인벤토리 내의 모든 호스트들을 중복을 제거하고 출력
ungrouped : 특정 그룹에 포함되어 있지 않은 호스트
인벤토리 확인 : --list-hosts
ansible -i [인벤토리] --list-hosts <대상>
인벤토리에 호스트 지정시 범위 사용가능
server1.example.local ~ server10.example.local 호스트 등록시
server[1:10].example.local

Ad-hoc 명령 실행
ansible 명령을 사용하여 단일 모듈을 대상에 대하여 실행
ansible -m [사용할 모듈] -a [모듈 사용시 필요한 argument] -i [인벤토리] <대상>

Ansible 주요 파일
/etc/ansible/hosts : 기본 Ansible 인벤토리 파일
/etc/ansible/ansible.cfg : 기본 Ansible 설정 파일
이 파일은 우선순위가 높지 않음
Ansible 설정파일 우선순위
ANSIBLE_CONFIG : 환경변수로 지정한 경로의 파일이 사용. 유연한 관리
./ansible.cfg : ansible 명령을 실행하고 있는 working directory 내 설정파일
~/.ansible.cfg : 사용자에게 적용되는 Ansible 설정 파일
/etc/ansible/ansible.cfg
사용중인 설정파일 확인방법
ansible --version : 현재 위치에서 ansible 명령 사용시 쓰는 설정파일 확인
ansible-config
view : 설정파일 내용 출력
dump : 전체 설정항목 값 출력
초록색 : 기본값
노란색 : 설정파일에 의해 변경된 값
Ansible 설정 파일 내 주요 항목
[defaults] : Ansible 동작의 기본 설정. 인벤토리 등
inventory : 인벤토리 파일/디렉토리의 경로
기본값 : /etc/ansible/hosts
remote_user : 관리 호스트 접근시 사용할 계정. root 권장하지 않음
기본값 : 사용자이름
ask_pass : ansible 실행 시 패스워드 물어볼지 여부 (yes/no/true/false)
기본값 : False
[privilege_escalation] : 권한 상승
become : 관리자 권한 상승여부 (Y/N/T/F)
기본값 : False
become_method : 관리자 권한 상승 방법 (sudo/su)
기본값 : sudo
become_user : 권한 상승시 변경할 사용자 (root)
기본값 : root
become_ask_pass : 권한 상승시 필요한 암호 입력 (Y/N/T/F)
기본값 : False

샘플
[defaults]
inventory = ./inventory
remote_user = user
ask_pass = false

[privilege_escalation]
become = true
become_method = sudo
become_user = root
become_ask_pass = true

테스트 명령
ansible -m user -a 'name=testuser state=present' all

=====================================================================

실습환경 구성 다시 한번 확인해보세요! (제공해드린 ova 이미지 사용하였을 경우)

Control node 1개, Managed host 2개를 import

기본 네트워크 및 호스트이름 설정
Control node
$ sudo -i

nmcli connection add con-name static ifname ens33 type ethernet ipv4.addresses 192.168.100.10/24 ipv4.gateway 192.168.100.2 ipv4.dns 192.168.100.2 ipv4.method manual

nmcli connection up static

nmcli connection delete ens33

hostnamectl set-hostname control.example.local

Managed host 1

$ sudo -i

nmcli connection add con-name static ifname ens33 type ethernet ipv4.addresses 192.168.100.21/24 ipv4.gateway 192.168.100.2 ipv4.dns 192.168.100.2 ipv4.method manual

#nmcli connection up static

nmcli connection delete ens33

systemctl set-default multi-user.target

hostnamectl set-hostname managed1.example.local

reboot

Managed host 2

$ sudo -i

nmcli connection add con-name static ifname ens33 type ethernet ipv4.addresses 192.168.100.22/24 ipv4.gateway 192.168.100.2 ipv4.dns 192.168.100.2 ipv4.method manual

nmcli connection up static

nmcli connection delete ens33

systemctl set-default multi-user.target

hostnamectl set-hostname managed2.example.local

reboot

Control node의 /etc/hosts 파일을 수정

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.100.21 managed1 managed1.example.local
192.168.100.22 managed2 managed2.example.local

Managed host에 SSH 키 기반인증을 하기 위하여 필요한 키 생성 (반드시 Control node에서 실행)

user@control $ ssh-keygen
입력항목은 전부 기본값으로 설정

user@control $ ssh-copy-id user@managed1.example.local

user@control $ ssh-copy-id user@managed2.example.local

각 호스트에 키 기반 인증이 연결되는지 확인

user@control $ ssh user@managed1.example.local
user@control $ ssh user@managed2.example.local

Control node에 ansible 설치 (Managed 에는 설치할 필요 없음)

user@control $ sudo yum -y install epel-release

user@control $ sudo yum -y install ansible

Ansible 설치 확인

user@control $ ansible --version

(옵션) ansible bash completion 설치

user@control $ sudo -i

root@control # cd /etc/bash_completion.d/

root@control # wget https://raw.githubusercontent.com/dysosmus/ansible-completion/master/ansible-completion.bash

root@control # exit

user@control $ exec bash

ansible 실습용 디렉토리 작성

user@control $ cd

user@control $ mkdir ansible

user@control $ cd ansible

기본 인벤토리 파일 생성

user@control $ cat > inventory
managed1.example.local
managed2.example.local

기본 환경설정 파일 생성

user@control $ cat > ansible.cfg
[defaults]
inventory = ./inventory
remote_user = user
ask_pass = false

[privilege_escalation]
become = true
become_method = sudo
become_user = root
become_ask_pass =true

ansible 명령 동작 확인

user@control $ ansible -m user -a ‘name=testuser state=present’ all

================================================================

Ansible을 통해 관리자 권한을 사용할 때, sudo 패스워드 입력 없이 sudo 사용
-> sudoers 설정의 NOPASSWD 설정
(managed host)

/etc/sudoers.d/<사용자이름>
<사용자이름> ALL=(ALL) NOPASSWD: ALL

명령어에서 become 등 ansible.cfg 파일의 설정과 다른 설정을 사용할 경우, 기존 설정파일의 설정에 override 되어 지정한 설정이 반영됨
--inventory, -i : 인벤토리 재지정
--user, -u : remote user 재지정
--ask-pass, -k : ask_pass 활성화
--become, -b : become 활성화
--become-method : become_method 재지정
--become-user : become_user 재지정
--ask-become-pass, -K : become_ask_pass 재지정

===================================================================

다양한 모듈 검색
ansible docs 검색
Ansible Documentation 내 module index 항목 참고
ansible-doc 명령 사용
ansible-doc -l : 전체 모듈 목록 확인
ansible-doc [모듈이름] : 개별 모듈 확인
options : 모듈 사용시 필요한 argument
= : 필수항목

• : 선택항목 (일부 선택항목은 기본값이 지정되어 있음, ansible-doc 내에 기본값 표기되어 있음)
  example 참고
  ansible-doc -l | grep [키워드] : 특정 키워드와 관련된 ansible 모듈 검색

==================================================================

command, shell, raw 모듈
대상 시스템에서 단순 명령 실행 형태로 동작
raw
python이 없어도 사용가능
일반적으로 사용하지 않음
python이 깔려있지 않은 managed host에 python 설치 등을 하기위한 목적 정도로만 사용
command
쉘을 실행하지 않고 명령 수행
shell
쉘을 실행하고 쉘 내에서 명령 수행
비교
파일로 존재하는 명령어 실행시는 차이가 없음
ansible -m shell -a hostname managed1.example.local
ansible -m command -a hostname managed1.example.local
쉘 내장 명령어, 또는 쉘 기능 사용시는 차이가 발생
ansible -m shell -a set managed1.example.local
ansible -m command -a set managed1.example.local

=====================================================================

Playbook

Ansible로 실행할 내용을 작성하는 문서=Code
ad-hoc 명령과 달리 여러 가지 수행할 내용을 하나의 플레이북에 저장
구조
플레이북 파일
플레이(1개 이상)
작업
모듈(1개 이상)

YAML 문법을 사용하여 작성하여야 함

확장자를 .yaml 또는 .yml
--- : 문서의 시작을 의미하는 마커
… : 문서의 마지막을 의미하는 마커
들여쓰기로 구조를 작성 : Ansible에서는 일반적으로 공백 2칸으로 한 단계를 지정
vi 편집기에서 편리하게 yaml 작성을 하기 위한 설정
~/.vimrc
syntax on
autocmd FileType yaml setlocal ts=2 sts=2 sw=2 et ai nu

et: expand tab. 탭 입력시 공백으로 변환
ai : auto indent. 자동 들여쓰기
nu : 줄 수 표시
목록 사용 가능(리스트)
목록의 아이템의 하나의 대시, 공백 뒤에 아이템 목록을 표시

• 목록의 아이템1
• 목록의 아이템2
• 목록의 아이템3
• …
  각 항목의 값을 입력할 경우 ‘:’ 뒤에 입력
  반드시 항목의 이름 뒤에 붙여서 : 작성
  : 뒤에 공백 한 칸 추가
  기본적으로 플레이북에 포함되는 항목
  play의 이름(설명): name 항목으로 플레이의 이름을 표시
  hosts: 플레이를 적용할 대상
  tasks: 이 플레이를 통해 실행할 작업의 목록
  내부에는 작업의 목록이 표시
  name으로 작업에 대한 설명 추가
  샘플

---

• name: My first play
  hosts: managed1.example.local
  tasks:
  - name: user testuser must exist
  user:
  name: testuser
  state: present
  - name: ping test
  ping:
  ...

플레이북 실행
ansible-playbook <플레이북 파일이름> [옵션]
ansible 명령과 동일한 옵션 사용가능 : --become 등
플레이북 실행 시 구체적인 실행내용 확인
-v : v의 개수를 1~4개 사용하여 구체적인 정도를 지정
Gathering Facts : 플레이북 실행 시 자동으로 처음에 실행되는 대상 시스템 정보 수집단계
Play Recap : 실행 통계. ok(정상), changed(변경), failed(실패)
--syntax-check : 플레이북 파일 내 구조적인 오류 탐지. 내용상의 결함은 찾지 못함
-C, --check : 예행연습. 실제 대상에 변경을 가하지 않으면서 동작 여부 확인

다중 플레이
하나의 플레이북 내에 두 개 이상의 플레이를 지정
각 플레이는 동일한 들여쓰기 단계를 준수하여 작성
각 플레이의 구조는 동일하며, 플레이마다 각각 대상을 지정할 수 있음 (hosts)

---

• name: My first play
  hosts: managed1.example.local
  tasks:

  • name: user testuser must exist
    user:
    name: testuser
    state: present

• name: My second play
  hosts: managed2.example.local
  tasks:
  - name: user testuser2 must exist
  user:
  name: testuser2
  state: present
  ...

플레이북 내에서 플레이 별 설정
플레이 별로 개별적인 옵션을 지정 가능 (become, become_method, become_user, remote_user…)

---

• name: My first play
  hosts: managed1.example.local
  become: true
  tasks:

  • name: user testuser must exist
    user:
    name: testuser
    state: present

• name: My second play
  hosts: managed2.example.local
  become: false
  tasks:
  - name: ping test
  ping:
  ...

---

• name: My first play
  hosts: managed1.example.local
  tasks:

  • name: user testuser must exist
    user:
    name: testuser
    state: present
    become: true
  • name: user testuser must exist
    user:
    name: testuser2
    state: present

• name: My second play
  hosts: managed2.example.local
  become: false
  tasks:
  - name: ping test
  ping:
  ...

연습
managed1, managed2 서버를 각각 웹 서버, DB 서버로 구성해 보자
각 서버에 필요한 패키지를 설치
서비스 구동
방화벽 설정

inventory 구성
[webservers]
managed1.example.local

[dbservers]
managed2.example.local

[allservers:children]
webservers
dbservers

ansible.cfg

webservice.yaml(prototype)

---

• name: webserver is ready
  hosts: webservers
  become: true
  tasks:
  • name: httpd package is installed
  • name: httpd service is enabled and started
  • name: firewall is opened
• name: dbserver is ready
  hosts: dbservers
  become: true
  tasks:
  • name: mariadb package is installed
  • name: mariadb service is enabled and started
  • name: firewall is opened

webservice.yaml

---

• name: webserver is ready
  hosts: webservers
  become: true
  tasks:

  • name: httpd package is installed
    yum:
    name: httpd
    state: latest
  • name: httpd service is enabled and started
    service:
    name: httpd
    enabled: true
    state: started
  • name: firewall is opened
    firewalld:
    service: http
    state: enabled
    permanent: true

• name: dbserver is ready
  hosts: dbservers
  become: true
  tasks:

  • name: mariadb package is installed
    yum:
    name: mariadb-server
    state: latest
  • name: mariadb service is enabled and started
    service:
    name: mariadb
    state: started
    enabled: yes
  • name: firewall is opened
    firewalld:
    service: mysql
    state: enabled
    permanent: yes

실행 전 테스트

$ ansible-playbook webservice.yaml --syntax-check
$ ansible-playbook webservice.yaml --check

실행 후 확인

$ ansible-playbook webservice.yaml

=====================================================================

변수(Variables)

재사용할 수 있는 값을 저장하기 위하여 사용
ex) 설치할 패키지의 이름, 서비스의 이름, 추가할 파일의 경로, 인터넷 경로 주소…
변수 이름 규칙
사용할 수 있는 글자: 영문자(대소문자), 숫자, 밑줄
문자로 시작

변수의 위치
전역 범위 : 명령줄, Ansible 설정에서 변수를 지정
ansible-playbook <플레이북 파일명> -e “변수이름=변수값”
플레이 : 플레이북의 구조에서 선언
플레이의 vars 예약어를 사용하여 변수를 지정

---

• name: webserver is ready
  hosts: webservers
  become: true
  vars:
  package: httpd
  service: httpd
  firewall_svc: http
  ...

별도의 파일을 사용하여 변수를 지정: YAML 포맷으로 작성

$ cat http.yml
package: httpd
service: httpd
firewall_svc: http

파일을 불러올 때는 vars_files 예약어를 사용하여 변수가 들어있는 파일을 지정

---

• name: webserver is ready
  hosts: webservers
  become: true
  vars_files:
  • http.yml

호스트/그룹 : 인벤토리 내의 특정 호스트/그룹
인벤토리 내 특정 호스트에 대한 변수 설정: 인벤토리 내 호스트 목록 뒤
[webservers]
managed1.example.local service=httpd, package=httpd, firewall_svc=http

인벤토리 내 특정 그룹에 대한 변수 설정: [그룹이름:vars] 항목으로 변수 지정
[websevers:vars]
service=httpd
package=httpd
firewall_svc=http

각 호스트에 대한 변수를 디렉토리 내 별도의 파일로 저장 : host_vars/<호스트이름>
각 그룹에 대한 변수를 인벤토리 내 별도의 파일로 저장 : group_vars/<그룹이름>

.
├── ansible.cfg
├── group_vars
│ └── webservers
├── host_vars
│ └── managed1.example.local
├── http.yml
├── inventory
├── webservice2.yaml
└── webservice.yaml

변수 호출
{{ 변수명 }}
값의 시작 부분이 변수로 시작하는 경우 반드시 “ “로 묶어줄 것
값이 목록으로 작성되는 경우와 혼동될 수 있음

변수의 우선순위
우선순위가 높은 위치와 낮은 위치에서 동일한 변수를 같이 지정할 경우, 높은 우선순위의 위치에서 선언된 변수로 지정됨
우선순위 (위쪽이 높은 우선순위)
명령줄에서 정의한 변수
플레이에서 지정한 변수
인벤토리에서 지정한 호스트변수
인벤토리에서 지정한 그룹 변수

사용예
플레이에 변수 선언

---

• name: webserver is ready
  hosts: webservers
  become: true
  vars:
  package: httpd
  service: httpd
  firewall_svc: http
  tasks:
  • name: "{{ package }} package is installed"
    yum:
    name: "{{ package }}"
    state: latest
  • name: "{{ service }} service is enabled and started"
    service:
    name: "{{ service }}"
    enabled: true
    state: started
  • name: firewall {{ firewall_svc }} service is opened
    firewalld:
    service: "{{ firewall_svc }}"
    state: enabled
    permanent: true

플레이 내에 변수 파일 포함

---

• name: webserver is ready
  hosts: webservers
  become: true
  vars_files:
  • http.yml
    tasks:
  • name: "{{ package }} package is installed"
    yum:
    name: "{{ package }}"
    state: latest
  • name: "{{ service }} service is enabled and started"
    service:
    name: "{{ service }}"
    enabled: true
    state: started
  • name: firewall {{ firewall_svc }} service is opened
    firewalld:
    service: "{{ firewall_svc }}"
    state: enabled
    permanent: true

인벤토리에 변수 선언

• name: dbserver is ready
  hosts: dbservers
  become: true
  tasks:
  - name: "{{ package }} package is installed"
  yum:
  name: "{{ package }}"
  state: latest
  - name: "{{ service }} service is enabled and started"
  service:
  name: "{{ service }}"
  state: started
  enabled: yes
  - name: firewall {{ firewall_svc }} service is opened
  firewalld:
  service: "{{ firewall_svc }}"
  state: enabled
  permanent: yes
  $ cat inventory
  [webservers]
  managed1.example.local

[dbservers]
managed2.example.local service=mariadb

[dbservers:vars]
package=mariadb-server
firewall_svc=mysql

[allservers:children]
webservers
dbservers

호스트에 대해 명령 실행 시 호스트 변수 및 그룹 변수 모두 사용 가능

별도의 파일로 호스트/그룹 변수 파일 생성

$ mkdir group_vars
$ cat > group_vars/dbservers
service: mariadb
package: mariadb-server
firewall_svc: mysql

변수를 사용하여 두 개의 플레이를 하나로 통합

---

• name: webservers and dbservers are ready
  hosts: webservers, dbservers
  become: true
  tasks:
  - name: "{{ package }} package is installed"
  yum:
  name: "{{ package }}"
  state: latest
  - name: "{{ service }} service is enabled and started"
  service:
  name: "{{ service }}"
  enabled: true
  state: started
  - name: firewall {{ firewall_svc }} service is opened
  firewalld:
  service: "{{ firewall_svc }}"
  state: enabled
  permanent: true
  ...
  $ cat group_vars/*

service: mariadb
package: mariadb-server
firewall_svc: mysql

service: httpd
package: httpd
firewall_svc: http

=============================================================

변수의 배열 사용

ex) 사용자 추가를 위한 변수 선언

단순 변수 형태
user1_id
user1_uid
user1_homedir
user1_login_shell
user2_id
user2_uid
user2_homedir
user2_login_shell

배열 형태
user1
id
uid
homedir
login_shell
user2
id
uid
homedir
login_shell

사용자들이 저장된 배열
users
user1
id
uid
homedir
login_shell
user2
id
uid
homedir
login_shell

변수 호출방식
users.user1.id
users[‘user1’][‘id’]

===========================================================

명령 출력 캡쳐

register : 모듈 실행시 실행 결과를 지정한 이름의 변수에 저장
debug : 변수의 값 등을 출력할 수 있는 모듈

테스트용 플레이북

---

• name: register and debug test
  hosts: webservers
  become: true
  tasks:
  • name: install package
    yum:
    name: tree
    state: latest
    register: result
  • name: print result
    debug:
    var: result

=============================================================

변수의 목록(배열), 사전

목록이나 사전을 사용하지 않는 유형

---

• name: variable test
  hosts: webservers
  vars:
  user1_id: alice
  user1_uid: 10000
  user1_homedir: /home/alice
  user2_id: bob
  user2_uid: 10001
  user2_homedir: /home/bob
  tasks:
  • name: print username
    debug:
    var: user1_id
  • name: print user uid
    debug:
    var: user1_uid
  • name: print user home directory
    debug:
    var: user1_homedir

목록(배열) 형태로 사용할 경우

---

• name: variable test
  hosts: webservers
  vars:
  user1:
  - alice
  - 10000
  - /home/alice
  user2:
  - bob
  - 10001
  - /home/bob
  tasks:
  • name: print username
    debug:
    var: user1[0]
  • name: print user uid
    debug:
    var: user1[1]
  • name: print user home directory
    debug:
    var: user1[2]
  • name: print user home directory
    debug:
    var: user1

사전 형태의 변수 사용

---

• name: variable test
  hosts: webservers
  vars:
  user1:
  id: alice
  uid: 10000
  homedir: /home/alice
  user2:
  id: bob
  uid: 10001
  homedir: /home/bob
  tasks:
  • name: print username
    debug:
    var: user1['id']
  • name: print user uid
    debug:
    var: user1.uid
  • name: print user home directory
    debug:
    var: user1.homedir
  • name: print user home directory
    debug:
    var: user1

---

• name: variable test
  hosts: webservers
  vars:
  users:
  user1:
  id: alice
  uid: 10000
  homedir: /home/alice
  user2:
  id: bob
  uid: 10001
  homedir: /home/bob
  tasks:
  • name: print username
    debug:
    var: users['user1']['id']
  • name: print user uid
    debug:
    var: users.user1.uid
  • name: print user home directory
    debug:
    var: users.user1.homedir
  • name: print user home directory
    debug:
    var: users

===================================================================

팩트 (Ansible Facts)

Ansible Facts
Ansible이 대상 시스템으로부터 자동으로 수집한 정보
수집한 정보를 변수 형태로 저장
대상 시스템의 상태를 확인하고 상태에 따라 조치하도록 하기 위하여 사용
플레이북을 작성하고 실행 시 기본적으로 각 플레이의 시작 단계에서 수행
필요에 따라 팩트 수집을 해제할 수 있음
gather_facts 항목을 플레이에 설정

---

• name: variable test
  hosts: webservers
  gather_facts: no
  tasks:

필요에 따라 직접 팩트 수집을 수행할 수 있음 : setup (모듈)
기본적으로 setup 모듈에 수집할 항목들이 지정되어 있음

ansible_facts
setup 모듈에 의해 수집된 팩트 정보가 저장되는 변수
ansible_facts.[팩트항목] 형태로 각 팩트에 접근
hostname : 짧은 호스트이름 (도메인이름 제외)
fqdn : 전체 호스트이름 (도메인이름 포함)
default_ipv4.address : 대상의 IP주소 정보
interfaces : 네트워크 인터페이스 정보
kernel : 커널 정보(버전)
devices.sda.partitions.sda1.size : 장치 정보

---

• name: Ansible Facts test
  hosts: webservers
  tasks:
  • name: print fact variable value
    debug:
    var: ansible_facts.hostname

ansible_facts[‘팩트항목’] 형태도 사용가능

---

• name: Ansible Facts test
  hosts: webservers
  tasks:
  • name: print fact variable value
    debug:
    var: ansible_facts['hostname']

setup 모듈을 ad-hoc 방식으로 실행할 경우, ansible_facts 변수의 하위 항목이 구식 표기방법으로 표기됨(eg. ansible_hostname, ansible_fqdn)

사용자 지정 Facts
기본 Ansible Facts 와 같이 setup에 의해서 수집되는 데이터를 사용자가 직접 지정
파일 형태로 팩트로 제공할 내용을 미리 작성해 놓아야 함
/etc/ansible/facts.d 디렉토리 내에 .fact로 끝나는 이름으로 작성
cat /etc/ansible/facts.d/test.fact
[users]
user1=alice
user2=bob

[webservice]
package=httpd
service=httpd
firewall_svc=httpd

===================================================================