Ansible
앤서블
은 의 대상을 playbook의 작업으로 관리하는 구성 자동화 도구이다. 연결 플러그인과 모듈을 통해 현재 상태와 원하는 상태를 비교하고 결과·변경·실패를 호스트별로 보고한다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
로고: Ansible community 공식 자료. 제품 식별을 위해 표시하며 각 상표의 권리는 권리자에게 있습니다.
01무엇이고, 어떤 일을 하나
- 대상과 그룹·변수를 로 관리한다.
- 멱등 모듈과 템플릿으로 설정·패키지·서비스 상태를 선언한다.
- 변경 알림··배치 실행·결과 객체로 운영 절차를 구성한다.
02어떤 순서로 동작하나
- 대상 결정
와 의 hosts·변수 조건으로 실제 관리 대상을 선택한다.
- 연결·권한
SSH 등의 연결 방식으로 접속하고 필요한 경우 별도의 become 정책으로 작업 권한을 얻는다.
- 모듈 실행
현재 상태와 요구 상태를 비교하는 모듈 또는 명령을 수행하고 반환값을 등에 저장한다.
- 후속 처리
changed·failed·when 조건과 notify·를 적용하고 호스트별 recap으로 결과를 정리한다.
03먼저 알아둘 용어와 구성요소
- Control Node는 에서 호스트·그룹과 연결 변수를 읽고 의 hosts 패턴으로 대상을 고른다.
- 는 대상과 공통 실행 조건을 선언하고 tasks는 순서대로 실행할 작업 목록이다.
- 각 는 이름과 모듈, 모듈 인자를 가진다.
- 는 태스크 결과를 해당 호스트의 변수에 저장한다.
- copy는 준비된 파일을 배포하고 은 Jinja 변수를 평가한 결과를 파일로 만든다.
- 는 이름 또는 listen 관계로 알림을 받고 보통 태스크 구간 끝에 처리된다. 실패 경로와 force_handlers, flush_handlers 사용 여부에 따라 실행 시점이 달라질 수 있다.
SSH 인증 실패와 반복 mkdir 실패를 멱등 모듈로 구별하기
의 UNREACHABLE·FAILED·CHANGED가 발생한 처리 단계를 비교하고 원하는 디렉터리 상태로 작업을 표현한다.
실습 구성과 전제
- 사진은 대상에 command 모듈을 실행한 사례다. 아래에서는 대상 그룹·경로를 lab과 /tmp/-lab으로 재구성한다.
- 관리 대상에 검증한 SSH 접속과 파일 모듈 실행 환경이 준비되어 있어야 한다. 화면의 삭제 명령은 재실행하지 않는다.
원격 작업 전에 연결이 성립했는지 읽는다
- 첫 화면의 UNREACHABLE과 Permission denied는 SSH 인증 단계의 실패다. 원하는 mkdir 작업이 실행되어 실패한 것이 아니다.
- changed=false도 디렉터리 상태를 검사해 이미 정상이었다는 뜻이 아니라, 이 사례에서는 원격 작업까지 도달하지 못했다는 결과와 함께 읽어야 한다.
bashansible-inventory -i inventory --graph ansible lab -i inventory -m ansible.builtin.ping연결과 모듈 실행 준비를 확인하는 예시다. ping은 ping이 아니다.
원본 크기로 보기 ↗- inventory와 -u 사용자를 지정한 command 실행이 UNREACHABLE로 끝난다.
- 메시지는 Permission denied이며 changed=false가 함께 표시된다.
확인 기준의 주소·사용자·인증 키와 수동 SSH 접속 조건을 대조한다. module 인자를 바꿔도 앞단 인증 실패는 해결되지 않는다.
명령 실행 성공과 원하는 상태의 달성을 구별한다
- 다음 화면의 mkdir는 이미 존재하는 디렉터리 때문에 rc=1로 실패한다. 필요한 상태가 이미 있어도 명령은 매번 생성 연산을 시도한다.
- 화면의 별도 삭제 명령은 rc=0과 CHANGED로 나타난다. 이를 반복 생성 문제의 필수 해결책으로 삼지 않고, 처음부터 원하는 디렉터리 상태를 표현하는 것이 적절하다.
원본 크기로 보기 ↗- mkdir 결과에 File exists, rc=1, FAILED가 표시된다.
- 다른 삭제 작업은 rc=0과 CHANGED로 나와 상태 변경과 명령 종료 결과를 각각 보여 준다.
확인 기준command 모듈의 CHANGED는 작업이 업무적으로 올바른 상태를 만들었다는 자동 검증이 아니다. 결과의 의미를 해당 명령과 연결한다.
file 모듈로 상태를 선언하고 재실행 결과를 비교한다
- file 모듈의 state: directory는 경로가 디렉터리인지와 요청한 속성을 비교한다. 없으면 만들고, 이미 조건을 만족하면 불필요한 변경을 하지 않는 구조다.
- 재구성 playbook을 같은 대상에 두 번 적용한다면 첫 변경 이후 두 번째는 해당 의 changed가 줄어드는지 확인한다. 이는 실제 사진의 결과가 아니라 준비한 환경에서 검증할 기대 동작이다.
yaml- name: Ensure the lab directory exists hosts: lab gather_facts: false tasks: - name: Keep the directory at the desired mode ansible.builtin.file: path: /tmp/ansible-lab state: directory mode: "0750"대상과 경로를 재구성한 playbook이다. 와 접속 신뢰 설정을 먼저 준비한다.
확인 기준두 번째에도 changed가 반복되면 권한·소유자·다른 작업의 변경·경로 종류를 확인한다. check 모드와 실제 실행을 구분한다.
실습에서 확인한 동작 원리
- UNREACHABLE은 연결 경계, FAILED는 작업 실패, CHANGED는 변경 판정이므로 처리 위치를 구분한다.
- 멱등성은 같은 명령을 반복하는 것이 아니라 현재 상태와 원하는 상태를 비교하는 방식에서 얻는다.
동작·명령 참고 문서
04예제로 따라가기
- 디렉터리 존재와 모드를 선언한 멱등 모듈은 첫 적용에서 changed, 이미 조건이 맞는 재적용에서 ok를 보고할 수 있다.
- failed_when을 YAML 목록 두 조건으로 쓰면 일반적으로 AND 결합이므로 둘 중 하나만 참인 실패를 놓치지 않도록 필요한 OR를 명시한다.
- changed_when: false는 변경 보고를 바꾸는 것이며 실행한 명령 자체의 부작용을 취소하지 않는다.
05혼동하기 쉬운 점과 확인 기준
- 앞서 변경 알림을 받았더라도 뒤 태스크 실패 때문에 해당 호스트의 가 실행되지 않을 수 있다. force_handlers도 접속 불가 같은 모든 장애를 해결하는 것은 아니다.
- --check는 지원 모듈의 변경 예측을 제공하지만 모든 작업을 완전하게 모의 실행하지 않는다. 지원하지 않는 작업이나 이전 태스크 결과에 의존하는 조건은 실제 실행과 다를 수 있다.
- check_mode: false인 태스크는 check 실행에서도 실제 실행될 수 있다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
함께 보는 학습 자료
아래 공식 자료를 본문의 개념·예제와 함께 읽어 보세요. 자료별로 확인할 위치와 관찰할 내용을 적었습니다.
Ansible 실패·변경·handler의 조건
Defining failure·Defining changed와 Handlers and failure 절의 YAML을 비교한다. 명령 결과, failed 판정, changed 보고와 실제 변경이 서로 다른 층임을 읽는 자료다.
- failed_when 목록이 암묵적 AND가 되는 조건
- changed_when이 부작용을 취소하지 않는 이유
- 후속 실패가 실행에 미치는 영향
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.