Ansible 팩트 캐싱 설정 종합 가이드

Ansible 팩트 캐싱은 플레이북이 실행될 때마다 동일한 호스트 팩트를 수집하는 데 너무 많은 시간을 소비할 때 유용합니다. 수백 대의 호스트를 관리하는 경우, 실제 작업이 시작되기 전에 반복적인 setup 모듈 호출로 인해 SSH 오버헤드가 눈에 띄게 증가할 수 있습니다.

팩트 캐싱은 성공적인 실행 후 수집된 팩트를 저장하고, 캐시가 유효한 동안 이를 재사용합니다. 결과적으로 약간 오래된 팩트를 허용할 수 있는 워크플로우의 경우 플레이북 시작 속도가 빨라집니다.

Ansible 팩트와 성능 영향 이해

Ansible은 명시적으로 또는 기본 gather_facts: true 동작을 통해 setup 모듈로 팩트를 수집합니다. 팩트에는 OS 계열, 커널, IP 주소, 마운트, CPU, 메모리 및 Python 인터프리터 정보와 같은 세부 정보가 포함됩니다.

성능 향상은 캐시된 데이터가 최신 상태일 때 원격 수집을 반복하지 않음으로써 얻을 수 있습니다. 이는 분 단위로 변경되지 않는 팩트에 의존하는 보고, 템플릿 작성 및 조건부 로직에 유용합니다.

팩트 캐싱 구성 방법

Ansible은 ansible.cfg에서 팩트 캐싱을 구성합니다. 실용적인 두 가지 선택은 로컬 JSON 파일과 Redis입니다. 정확한 플러그인 이름이 중요합니다.

1. JSON 파일 캐싱 (로컬 저장소)

JSON 파일 캐시는 제어 머신에 팩트를 저장합니다. 간단하며 외부 서비스가 필요하지 않습니다.

`ansible.cfg`에서 JSON 캐싱 구성

jsonfile 캐시 플러그인을 사용합니다:

[defaults]
fact_caching = jsonfile
fact_caching_connection = /path/to/ansible_facts_cache
fact_caching_timeout = 600

fact_caching_connection은 Ansible이 캐시 파일을 쓰는 디렉토리입니다. 먼저 생성하고 Ansible을 실행하는 사용자가 쓸 수 있는지 확인하십시오:

mkdir -p /path/to/ansible_facts_cache

fact_caching_timeout은 초 단위로 측정됩니다. 타임아웃이 지나면 Ansible은 플레이에서 필요할 때 새로운 팩트를 다시 수집합니다.

2. Redis 캐싱 (공유, 고성능 저장소)

Redis는 여러 제어 노드, 사용자 또는 CI 작업이 동일한 팩트 캐시를 공유해야 할 때 더 잘 작동합니다.

Redis 캐싱을 위한 전제 조건

연결 가능한 Redis 서버와 Ansible이 사용하는 Python 환경에서 사용 가능한 Python Redis 클라이언트가 필요합니다:

python -m pip install redis

`ansible.cfg`에서 Redis 캐싱 구성

Redis 연결 문자열을 사용합니다:

[defaults]
fact_caching = redis
fact_caching_connection = 127.0.0.1:6379/0
fact_caching_timeout = 3600

/0은 Redis 데이터베이스 0을 선택합니다. 다른 애플리케이션도 Redis를 사용하는 경우 전용 데이터베이스 또는 Redis 인스턴스를 사용하고, 다른 인프라 서비스와 마찬가지로 Redis 엔드포인트를 보호하십시오.

플레이북에 캐싱 통합

플레이가 팩트를 수집할 때 캐시가 채워집니다:

- name: 팩트 수집 및 사용
  hosts: webservers
  gather_facts: true
  tasks:
    - name: OS 계열 표시
      debug:
        msg: "OS 계열은 {{ ansible_os_family }}입니다"

팩트 캐싱이 활성화되면 Ansible은 캐시된 팩트가 유효한 동안 재사용할 수 있습니다. 팩트가 없거나 만료되었고 gather_facts: true인 경우 Ansible이 다시 수집합니다.

gather_facts: false로 설정하면 Ansible은 해당 플레이에 대해 팩트 수집을 실행하지 않습니다. 캐시된 팩트가 이미 캐시된 경우 호스트 변수를 통해 계속 사용할 수 있지만, 중요한 로직에 대해 맹목적으로 의존하지 마십시오. 캐시가 없으면 변수가 정의되지 않을 수 있습니다.

안전한 패턴은 예약된 플레이나 초기 플레이에서 팩트를 수집한 다음, 오래된 데이터가 허용되는 후속 보고 또는 오케스트레이션 플레이북에서 캐시된 팩트를 사용하는 것입니다.

팩트 캐시 관리

호스트 팩트가 변경되었고 타임아웃을 기다리고 싶지 않을 때 캐시를 지우십시오.

JSON 캐시 지우기

구성된 캐시 디렉토리의 파일을 삭제합니다:

rm -rf /path/to/ansible_facts_cache/*

Redis 캐시 지우기

Redis 데이터베이스가 Ansible 팩트 전용인 경우 해당 데이터베이스를 플러시할 수 있습니다:

redis-cli -n 0 FLUSHDB

FLUSHDB는 선택한 Redis 데이터베이스의 모든 키를 삭제합니다. 공유 데이터베이스에서 실행하지 마십시오. 모든 키를 삭제해도 안전한 경우에만 실행하십시오.

모범 사례

단일 제어 머신과 간단한 로컬 워크플로우에는 jsonfile을 사용하십시오.
여러 실행자가 동일한 캐시를 필요로 할 때 Redis를 사용하십시오.
빠르게 변경되는 인프라에는 짧은 타임아웃을, 안정적인 플릿에는 긴 타임아웃을 유지하십시오.
다른 사용자가 읽을 수 있는 위치에 민감한 사용자 정의 팩트를 캐시하지 마십시오.
ansible --version으로 Ansible이 사용하는 구성 파일을 확인하십시오.
대규모 플릿에서 캐싱을 활성화하기 전에 하나의 인벤토리 그룹으로 테스트하십시오.

실용적인 요점

반복적인 팩트 수집이 측정 가능한 비용이고 플레이북이 캐시된 데이터를 허용할 수 있을 때 Ansible 팩트 캐싱을 활성화하십시오. jsonfile로 시작하고, 캐시 공유가 실제 워크플로우 문제를 해결할 때만 Redis로 전환하며, 호스트 팩트가 변경되는 빈도에 맞는 타임아웃을 설정하십시오.