Ansible 은 시스템 관리자와 개발자가 인프라를 효율적으로 관리할 수 있도록 돕는 강력한 IT 자동화 도구입니다. Ansible 의 주요 기능 중 하나는 "fact"라고 하는 대상 시스템에 대한 정보를 수집하는 능력입니다. Ansible 의 gather_facts 옵션은 플레이북 실행 중에 이 정보가 수집되는지 여부와 방법을 결정합니다.
이 실습에서는 Ansible 플레이북에서 gather_facts 옵션을 구성하는 방법을 배우게 됩니다. 다양한 설정을 살펴보고, fact 수집을 활성화하거나 비활성화해야 하는 경우를 이해하며, 수집된 fact 를 사용하여 플레이북을 더욱 동적이고 효율적으로 만드는 방법을 배우게 됩니다. 이 실습을 마치면 특정 요구 사항에 따라 fact 수집 프로세스를 제어하여 Ansible 워크플로우를 최적화할 수 있습니다.
Ansible 을 설치하고 gather_facts 옵션이 무엇을 하는지 살펴보겠습니다. 이 단계에서는 Ansible 을 설치하고, 간단한 인벤토리를 생성한 다음, 명령을 실행하여 어떤 fact 가 수집되는지 확인합니다.
먼저, 시스템에 Ansible 을 설치해 보겠습니다.
sudo apt update
sudo apt install -y ansible설치가 완료되면 Ansible 이 올바르게 설치되었는지 확인합니다.
ansible --version다음과 유사한 출력을 볼 수 있습니다.
ansible [core 2.12.x]
config file = /etc/ansible/ansible.cfg
configured module search path = ['/home/labex/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python3/dist-packages/ansible
ansible collection location = /home/labex/.ansible/collections:/usr/share/ansible/collections
executable location = /usr/bin/ansible
python version = 3.10.x (default, Aug 14 2022, 00:00:00) [GCC 11.2.0]
jinja version = 3.0.3
libyaml = True이제 작업할 간단한 인벤토리 파일을 만들어 보겠습니다. 인벤토리 파일은 Ansible 이 관리할 호스트를 정의합니다. 이 실습에서는 로컬 인벤토리를 생성합니다.
mkdir -p ~/project/ansible
cd ~/project/ansible편집기를 사용하여 hosts라는 이름의 인벤토리 파일을 생성합니다.
/home/labex/project/ansible 디렉토리로 이동합니다.hosts로 지정합니다.[local]
localhost ansible_connection=local이 인벤토리는 local이라는 그룹을 설정하며, 호스트는 localhost 하나만 포함합니다. ansible_connection=local 매개변수는 Ansible 에게 SSH 를 사용하지 않고 로컬 머신에서 직접 명령을 실행하도록 지시합니다.
기본적으로 어떤 fact 가 수집되는지 확인하기 위해 간단한 Ansible 명령을 실행해 보겠습니다.
cd ~/project/ansible
ansible local -i hosts -m setup위 명령은 다음을 사용합니다.
local: 인벤토리의 그룹-i hosts: 인벤토리 파일 지정-m setup: fact 를 수집하는 setup 모듈 실행다음과 같은 시스템에 대한 자세한 정보가 포함된 큰 JSON 출력을 볼 수 있습니다.
이 정보는 gather_facts가 활성화된 경우 (기본 동작) Ansible 이 수집하는 정보입니다. 이러한 fact 는 플레이북에서 대상 시스템의 특성에 따라 결정을 내리거나 작업을 사용자 정의하는 데 사용할 수 있습니다.
이 단계에서는 기본 fact 수집 동작을 사용하고 수집된 일부 정보를 표시하는 기본 Ansible 플레이북을 생성합니다.
Ansible 플레이북은 관리되는 호스트에서 실행할 작업 목록이 포함된 YAML 파일입니다. 플레이북은 구성, 배포 및 오케스트레이션 단계를 간단하고 사람이 읽을 수 있는 형식으로 정의하는 방법을 제공합니다.
Ansible 이 기본적으로 수집하는 일부 fact 를 표시하는 간단한 플레이북을 만들어 보겠습니다.
/home/labex/project/ansible 디렉토리로 이동합니다.facts_playbook.yml이라는 새 파일을 생성합니다.---
- name: Show System Facts
hosts: local
## By default, gather_facts is set to 'true'
tasks:
- name: Display operating system
debug:
msg: "Operating System: {{ ansible_distribution }} {{ ansible_distribution_version }}"
- name: Display CPU information
debug:
msg: "CPU: {{ ansible_processor[1] }} with {{ ansible_processor_cores }} cores"
- name: Display memory information
debug:
msg: "Total Memory: {{ ansible_memtotal_mb }} MB"
- name: Display Python version
debug:
msg: "Python version: {{ ansible_python_version }}"이 플레이북은 다음과 같습니다.
local 그룹을 대상으로 합니다.이제 플레이북을 실행하여 수집된 fact 가 작동하는 것을 확인해 보겠습니다.
cd ~/project/ansible
ansible-playbook -i hosts facts_playbook.yml다음과 유사한 출력을 볼 수 있습니다.
PLAY [Show System Facts] *****************************************************
TASK [Gathering Facts] *******************************************************
ok: [localhost]
TASK [Display operating system] **********************************************
ok: [localhost] => {
"msg": "Operating System: Ubuntu 22.04"
}
TASK [Display CPU information] ***********************************************
ok: [localhost] => {
"msg": "CPU: Intel(R) Xeon(R) CPU with 2 cores"
}
TASK [Display memory information] ********************************************
ok: [localhost] => {
"msg": "Total Memory: 3907 MB"
}
TASK [Display Python version] ************************************************
ok: [localhost] => {
"msg": "Python version: 3.10.6"
}
PLAY RECAP *******************************************************************
localhost : ok=5 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0출력의 첫 번째 작업인 TASK [Gathering Facts]에 주목하십시오. 이는 gather_facts의 기본값이 true이므로 Ansible 이 정의된 작업을 실행하기 전에 자동으로 fact 를 수집하는 것입니다.
그런 다음 플레이북은 수집된 fact 를 사용하여 시스템에 대한 정보를 성공적으로 표시합니다. 각 fact 는 ansible_ 접두사가 있는 변수를 사용하여 참조됩니다.
이 단계에서는 fact 가 필요하지 않은 상황에서 플레이북 성능을 향상시키기 위해 fact 수집을 비활성화하는 방법을 배웁니다.
fact 수집은 유용하지만 특정 시나리오에서는 불필요한 오버헤드를 추가할 수 있습니다.
fact 수집을 비활성화하면 특히 여러 호스트를 관리할 때 플레이북 실행 속도를 크게 향상시킬 수 있습니다.
fact 수집이 비활성화된 새 플레이북을 만들어 보겠습니다.
/home/labex/project/ansible 디렉토리로 이동합니다.no_facts_playbook.yml이라는 새 파일을 생성합니다.---
- name: Playbook with Disabled Fact Gathering
hosts: local
gather_facts: false
tasks:
- name: Display current time
command: date
register: current_time
- name: Show the current time
debug:
msg: "Current time is: {{ current_time.stdout }}"
- name: List files in the project directory
command: ls -la ~/project
register: file_list
- name: Show file list
debug:
msg: "Project directory contents:\n{{ file_list.stdout }}"이 플레이북은 다음과 같습니다.
gather_facts: false를 사용하여 fact 수집을 명시적으로 비활성화합니다.register 키워드를 사용하여 명령 출력을 캡처합니다.debug 모듈을 사용하여 캡처된 정보를 표시합니다.플레이북을 실행하고 차이점을 관찰해 보겠습니다.
cd ~/project/ansible
ansible-playbook -i hosts no_facts_playbook.yml다음과 유사한 출력을 볼 수 있습니다.
PLAY [Playbook with Disabled Fact Gathering] *********************************
TASK [Display current time] **************************************************
changed: [localhost]
TASK [Show the current time] *************************************************
ok: [localhost] => {
"msg": "Current time is: Wed May 17 15:30:45 UTC 2023"
}
TASK [List files in the project directory] ***********************************
changed: [localhost]
TASK [Show file list] ********************************************************
ok: [localhost] => {
"msg": "Project directory contents:\ntotal 20\ndrwxr-xr-x 3 labex labex 4096 May 17 15:25 .\ndrwxr-xr-x 4 labex labex 4096 May 17 15:20 ..\ndrwxr-xr-x 2 labex labex 4096 May 17 15:25 ansible\n"
}
PLAY RECAP *******************************************************************
localhost : ok=4 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0이번에는 출력에 Gathering Facts 작업이 없다는 것을 알 수 있습니다. 플레이북은 정의된 첫 번째 작업부터 바로 시작합니다.
성능 차이를 확인하기 위해 간단한 타이밍 스크립트를 만들어 보겠습니다.
/home/labex/project/ansible 디렉토리로 이동합니다.compare_timing.sh라는 새 파일을 생성합니다.#!/bin/bash
echo "Running playbook with fact gathering enabled..."
time ansible-playbook -i hosts facts_playbook.yml > /dev/null
echo -e "\nRunning playbook with fact gathering disabled..."
time ansible-playbook -i hosts no_facts_playbook.yml > /dev/nullchmod +x compare_timing.sh./compare_timing.shfact 수집이 비활성화된 플레이북이 fact 수집이 활성화된 플레이북보다 더 빠르게 실행되는 것을 보여주는 출력을 볼 수 있습니다. 이 간단한 예제에서는 차이가 작을 수 있지만, 여러 원격 호스트에서 복잡한 플레이북을 실행할 때는 상당할 수 있습니다.
경우에 따라 모든 시스템 정보가 아닌 특정 fact 만 필요할 수 있습니다. Ansible 은 필요한 정보를 계속 수집하면서 성능을 최적화하기 위해 선택적 fact 수집을 허용합니다.
Ansible 은 fact 를 다음과 같은 하위 집합으로 구성합니다.
all: 모든 fact (기본값)min / minimal: 최소한의 fact 집합hardware: CPU, 메모리 및 장치 정보network: 네트워크 인터페이스 및 라우팅 정보virtual: 가상화 세부 정보ohai: Ohai 의 fact (사용 가능한 경우)facter: Facter 의 fact (사용 가능한 경우)필요한 fact 만 선택하면 필요한 정보에 계속 액세스하면서 플레이북 성능을 향상시킬 수 있습니다.
하드웨어 관련 fact 만 수집하는 플레이북을 만들어 보겠습니다.
/home/labex/project/ansible 디렉토리로 이동합니다.selective_facts_playbook.yml이라는 새 파일을 생성합니다.---
- name: Selective Fact Gathering
hosts: local
gather_facts: true
gather_subset:
- "!all" ## Exclude all facts by default
- "hardware" ## Then include only hardware facts
tasks:
- name: Display CPU information
debug:
msg: "CPU: {{ ansible_processor[1] }} with {{ ansible_processor_cores }} cores"
- name: Display memory information
debug:
msg: "Total Memory: {{ ansible_memtotal_mb }} MB"
- name: Try to access network facts (should fail)
debug:
msg: "Default IPv4 Address: {{ ansible_default_ipv4.address }}"
ignore_errors: true이 플레이북은 다음과 같습니다.
gather_facts: true를 사용하여 fact 수집을 활성화합니다.gather_subset을 사용하여 수집할 fact 를 제한합니다.!all로 모든 fact 를 제외합니다.hardware로 하드웨어 fact 만 포함합니다.플레이북을 실행하여 선택적 fact 수집이 작동하는 것을 확인해 보겠습니다.
cd ~/project/ansible
ansible-playbook -i hosts selective_facts_playbook.yml다음과 유사한 출력을 볼 수 있습니다.
PLAY [Selective Fact Gathering] **********************************************
TASK [Gathering Facts] *******************************************************
ok: [localhost]
TASK [Display CPU information] ***********************************************
ok: [localhost] => {
"msg": "CPU: Intel(R) Xeon(R) CPU with 2 cores"
}
TASK [Display memory information] ********************************************
ok: [localhost] => {
"msg": "Total Memory: 3907 MB"
}
TASK [Try to access network facts (should fail)] *****************************
fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'address'..."}
...ignoring
PLAY RECAP *******************************************************************
localhost : ok=4 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=1처음 두 작업은 수집된 하드웨어 fact 에 액세스하므로 성공하지만, 세 번째 작업은 네트워크 fact 가 수집되지 않았기 때문에 실패합니다. 이 오류에도 불구하고 플레이북 실행을 계속하기 위해 ignore_errors: true를 사용했습니다.
이제 하드웨어 및 네트워크 fact 를 모두 수집하는 플레이북을 만들어 보겠습니다.
multiple_subsets_playbook.yml이라는 새 파일을 생성합니다.---
- name: Multiple Fact Subsets
hosts: local
gather_facts: true
gather_subset:
- "!all" ## Exclude all facts by default
- "hardware" ## Include hardware facts
- "network" ## Include network facts
tasks:
- name: Display CPU information
debug:
msg: "CPU: {{ ansible_processor[1] }} with {{ ansible_processor_cores }} cores"
- name: Display memory information
debug:
msg: "Total Memory: {{ ansible_memtotal_mb }} MB"
- name: Display network information
debug:
msg: "Default IPv4 Address: {{ ansible_default_ipv4.address }}"이 플레이북을 실행합니다.
ansible-playbook -i hosts multiple_subsets_playbook.yml이번에는 하드웨어 및 네트워크 fact 를 모두 수집했으므로 모든 작업이 성공해야 합니다.
수집된 fact 의 가장 강력한 사용 사례 중 하나는 플레이북에서 조건부 로직을 구현하는 것입니다. 이 단계에서는 실행할 작업을 결정하기 위해 fact 를 사용하는 플레이북을 만들 것입니다.
Ansible 을 사용하면 when 키워드를 사용하여 변수, fact 또는 작업 결과에 따라 작업을 조건부로 실행할 수 있습니다. 이를 통해 더 동적이고 적응 가능한 플레이북을 만들 수 있습니다.
운영 체제에 따라 다른 작업을 수행하는 플레이북을 만들어 보겠습니다.
/home/labex/project/ansible 디렉토리로 이동합니다.conditional_facts_playbook.yml이라는 새 파일을 생성합니다.---
- name: Conditional Tasks Based on Facts
hosts: local
gather_facts: true
tasks:
- name: Display OS information
debug:
msg: "Running on {{ ansible_distribution }} {{ ansible_distribution_version }}"
- name: Task for Ubuntu systems
debug:
msg: "This is an Ubuntu system. Would run apt commands here."
when: ansible_distribution == "Ubuntu"
- name: Task for CentOS systems
debug:
msg: "This is a CentOS system. Would run yum commands here."
when: ansible_distribution == "CentOS"
- name: Task for systems with at least 2GB RAM
debug:
msg: "This system has {{ ansible_memtotal_mb }} MB RAM, which is sufficient for our application."
when: ansible_memtotal_mb >= 2048
- name: Task for systems with less than 2GB RAM
debug:
msg: "This system has only {{ ansible_memtotal_mb }} MB RAM, which may not be sufficient."
when: ansible_memtotal_mb < 2048이 플레이북은 다음과 같습니다.
플레이북을 실행하여 조건부 작업이 작동하는 것을 확인해 보겠습니다.
cd ~/project/ansible
ansible-playbook -i hosts conditional_facts_playbook.ymlUbuntu 에서 실행 중이므로 다음과 유사한 출력을 볼 수 있습니다.
PLAY [Conditional Tasks Based on Facts] **************************************
TASK [Gathering Facts] *******************************************************
ok: [localhost]
TASK [Display OS information] ************************************************
ok: [localhost] => {
"msg": "Running on Ubuntu 22.04"
}
TASK [Task for Ubuntu systems] ***********************************************
ok: [localhost] => {
"msg": "This is an Ubuntu system. Would run apt commands here."
}
TASK [Task for CentOS systems] ***********************************************
skipping: [localhost]
TASK [Task for systems with at least 2GB RAM] ********************************
ok: [localhost] => {
"msg": "This system has 3907 MB RAM, which is sufficient for our application."
}
TASK [Task for systems with less than 2GB RAM] *******************************
skipping: [localhost]
PLAY RECAP *******************************************************************
localhost : ok=4 changed=0 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0일부 작업은 실행되고 다른 작업은 조건에 따라 건너뛰는 것을 알 수 있습니다. CentOS 작업은 Ubuntu 에서 실행 중이므로 건너뛰고, "2GB RAM 미만" 작업은 시스템에 2GB RAM 이상이 있으므로 건너뜁니다.
이제 실제 환경에서 사용할 수 있는 더 실용적인 예제를 만들어 보겠습니다.
practical_conditional_playbook.yml이라는 새 파일을 생성합니다.---
- name: Practical Conditional Playbook
hosts: local
gather_facts: true
vars:
app_dir: "/home/labex/project/app"
tasks:
- name: Create application directory
file:
path: "{{ app_dir }}"
state: directory
mode: "0755"
- name: Configure for production environment
copy:
dest: "{{ app_dir }}/config.yml"
content: |
environment: production
memory_limit: high
debug: false
when: ansible_memtotal_mb >= 4096
- name: Configure for development environment
copy:
dest: "{{ app_dir }}/config.yml"
content: |
environment: development
memory_limit: low
debug: true
when: ansible_memtotal_mb < 4096
- name: Display configuration
command: cat {{ app_dir }}/config.yml
register: config_content
- name: Show configuration
debug:
msg: "{{ config_content.stdout_lines }}"이 플레이북은 다음과 같습니다.
실용적인 플레이북을 실행합니다.
ansible-playbook -i hosts practical_conditional_playbook.yml이 예제는 수집된 fact 를 사용하여 시스템 특성에 따라 구성을 자동으로 조정하는 방법을 보여줍니다.
이 Lab 에서는 Ansible 플레이북에서 gather_facts 옵션을 효과적으로 구성하고 사용하는 방법을 배웠습니다. 다음은 수행한 작업에 대한 요약입니다.
기본 fact 수집: Ansible 을 설치하고 기본 fact 수집 동작을 탐색하여 Ansible 이 수집하는 광범위한 시스템 정보를 확인했습니다.
fact 수집 비활성화: fact 가 필요하지 않을 때 플레이북 성능을 향상시키기 위해 fact 수집을 비활성화하는 방법을 배웠습니다.
선택적 fact 수집: 성능과 필요한 정보 확보 사이의 균형을 맞추기 위해 특정 하위 집합의 fact 만 수집하는 방법을 배웠습니다.
조건부 작업: 수집된 fact 를 기반으로 플레이북에서 조건부 로직을 구현하여 시스템 특성에 따라 동적 동작을 허용했습니다.
실용적인 응용 프로그램: 실제 시나리오에서 수집된 fact 를 사용하는 방법을 보여주는 실용적인 예제를 만들었습니다.
gather_facts 옵션을 마스터하면 필요한 시스템 정보에 계속 액세스하면서 더 나은 성능을 위해 Ansible 플레이북을 최적화할 수 있습니다. 이 지식은 더 효율적이고 유연하며 강력한 자동화 워크플로우를 만드는 데 도움이 됩니다.
기억해야 할 몇 가지 모범 사례는 다음과 같습니다.
이러한 기술을 통해 인프라 관리 요구 사항에 맞는 더 정교하고 효율적인 Ansible 자동화를 만들 수 있습니다.
