Ansible 인벤토리·Playbook과 멱등성

01inventory에서 연결 플러그인과 모듈 실행까지

• inventoryControl Node는 inventory에서 호스트·그룹과 연결 변수를 읽고 play의 hosts 패턴으로 대상을 고른다.
• SSH연결 플러그인이 SSH·WinRM·PSRP·네트워크 CLI 등 적절한 경로를 준비한다.
• 대상별 실행 환경일반 Linux 모듈은 대상에서 Python 코드로 실행되어 결과 자료를 반환할 수 있지만 네트워크 장비·Windows에 같은 Python 조건을 무조건 적용하지 않는다.
• agentlessagentless는 상주 전용 에이전트를 요구하지 않는 일반 구조를 말한다.

  • inventory의 별칭과 실제 접속 주소는 다를 수 있다.
• play그룹 변수와 호스트 변수, play 변수 등은 정해진 우선순위로 합쳐지므로 CLI의 -u가 모든 ansible_user 설정보다 항상 우선한다고 가정하지 않는다.
• AnsibleAnsible ping 모듈은 ICMP ping이 아니라 연결·인증·필요 런타임에서 모듈 실행과 반환이 가능한지 보는 기능이다.
• SSH·inventory라우팅과 SSH 키 배포가 inventory 한 줄로 자동 생성되지는 않는다.

[web]
web1 ansible_host=192.0.2.11
web2 ansible_host=192.0.2.12

[web:vars]
ansible_user=automation

교육용 예시. 실제 원격 접속·설정 변경·배포는 실행하지 않았다.

02play·task·module·facts의 YAML 계층

• playplay는 대상과 공통 실행 조건을 선언하고 tasks는 순서대로 실행할 작업 목록이다.
• task각 task는 이름과 모듈, 모듈 인자를 가진다.
• YAML 구조·자료형들여쓰기와 자료형이 계층을 결정하며 설명용 name 문자열이 조금 다르다고 동작 의미가 바뀌는 것은 아니다.
• 기본 fact 수집기본 fact 수집은 배포판·인터페이스 같은 정보를 가져와 조건과 템플릿에 사용할 수 있게 한다.

  • gather_facts: false는 그 자동 단계를 생략한다.
• registerregister는 태스크 결과를 해당 호스트의 변수에 저장한다.
• 결과 객체의 필드command 결과에서 stdout은 문자열, stdout_lines는 줄 목록이며 rc와 stderr는 별도 필드다.
• 결과 변수 전달아래 조회는 df의 출력을 저장하고 다음 태스크가 그 자료를 표시한다.
• changed_when: falsechanged_when: false는 읽기 동작을 변경으로 집계하지 않게 할 뿐 명령 실행을 생략하거나 실패를 성공으로 바꾸지 않는다.
• collectioncollection까지 포함한 FQCN을 사용하면 어떤 모듈을 쓰는지 더 명확해진다.

- name: Inspect filesystem
  hosts: web
  gather_facts: false
  tasks:
    - name: Read filesystem usage
      ansible.builtin.command:
        argv: [df, -h, --, /]
      register: disk_result
      changed_when: false
    - name: Show lines
      ansible.builtin.debug:
        var: disk_result.stdout_lines

교육용 예시. 실제 원격 접속·설정 변경·배포는 실행하지 않았다.

03멱등 모듈이 현재 상태와 원하는 상태를 비교한다

• 디렉터리 상태 선언file 모듈의 state: directory는 해당 디렉터리가 존재하고 지정한 소유권·권한을 갖도록 요구한다.

  • 없다면 만들고 다르면 바꾸며 이미 맞으면 변경 없음으로 보고한다.
• 현재 상태의 재검사이전 실행 이력을 기억해서 두 번째부터 전체 태스크를 건너뛰는 방식이 아니다.

  • 같은 코드라도 외부에서 권한이 바뀌면 다음 실행에서 다시 교정할 수 있다.
• playbookcommand와 shell은 임의 프로그램을 실행하므로 명령 자체가 반복 안전하지 않으면 전체 playbook도 그렇지 않다.
• creates·removescreates·removes는 경로 존재 조건으로 실행을 제한하는 보조 수단이고 changed_when은 보고를 바꾸는 조건이다.
• 멱등성단순 mkdir가 이미 존재한다고 실패한 결과를 멱등성 성공이라고 부르지 않는다.
• 멱등 적용 예제아래는 전용 실습 경로와 관리 계정의 파일 권한 변경을 가정한 선언이다.

- name: Maintain study directory
  ansible.builtin.file:
    path: /srv/study
    state: directory
    owner: automation
    group: automation
    mode: "0750"

교육용 예시. 실제 원격 접속·설정 변경·배포는 실행하지 않았다.

04template·notify·handler가 설정 변경을 재시작과 연결한다

• templatecopy는 준비된 파일을 배포하고 template은 Jinja 변수를 평가한 결과를 파일로 만든다.
• Changed와 알림 예약파일이 실제로 달라져 changed가 되면 notify가 handler 실행을 예약할 수 있다.
• 중복 알림의 병합여러 태스크가 같은 handler를 알리더라도 일반적인 handler 처리 구간에서 한 번만 실행하도록 중복을 모은다.

  • 이미 같은 설정이면 매번 서비스를 재시작하지 않는 이유가 여기 있다.
• Handler 선택·실행 시점handler는 이름 또는 listen 관계로 알림을 받고 보통 태스크 구간 끝에 처리된다.

  • 실패 경로와 force_handlers, flush_handlers 사용 여부에 따라 실행 시점이 달라질 수 있다.
• 템플릿 문법템플릿 문법이 맞아도 생성된 애플리케이션 설정이 유효한지는 프로그램의 검사 기능으로 확인해야 한다.
• 사용자 입력사용자 입력을 그대로 임의 설정 구문으로 섞기보다 변수의 허용 범위와 인용을 정한다.
• 첫 적용과 재적용다음 도식의 첫 적용은 내용이 달라 changed와 notify가 생기고, 같은 내용을 재적용하면 ok가 되어 이 작업의 새 알림이 생기지 않는 사례다.
• Changed_when의 영향changed_when을 잘못 지정하면 실제 변경을 숨기거나 불필요한 handler를 실행시킬 수 있으므로 보고 상태와 실제 부작용을 함께 해석한다.

1. 원하는 내용 비교대상 변수로 계산한 설정과 현재 파일을 비교한다.
2. changed 결과파일을 갱신했다는 모듈 결과를 돌려준다.
3. notify 등록변경 결과에 따라 실행할 handler를 알린다.
4. 서비스 반영지원되는 재읽기 등의 작업을 실행한다.
5. 재적용 비교다음 실행에서는 같은 내용이면 파일을 바꾸지 않는다.

tasks:
  - name: Deploy nginx configuration
    ansible.builtin.template:
      src: study.conf.j2
      dest: /etc/nginx/conf.d/study.conf
      mode: "0644"
    notify: Reload nginx
handlers:
  - name: Reload nginx
    ansible.builtin.service:
      name: nginx
      state: reloaded

교육용 예시. 실제 원격 접속·설정 변경·배포는 실행하지 않았다.

05SSH 인증과 become, 조건·반복·배치

• SSH·become-k는 SSH 비밀번호를 묻고 -K는 become 비밀번호를 묻는다.
• become실제 권한 상승은 -b나 become: true로 켜며 sudo 정책이 해당 실행을 허용해야 한다.

  • 정확한 암호를 입력하는 것과 실행 권한을 부여받는 것은 다르다.
• 일반 모듈일반 모듈은 임시 모듈과 인터프리터를 실행하므로 sudoers에 마지막 명령 하나만 열어 둔 방식과 호환되지 않을 수 있다.
• whenwhen은 조건에 따라 태스크를 건너뛰고 loop는 여러 항목에 같은 모듈을 적용한다.
• serialforks는 여러 호스트 작업의 병렬 실행 자원, serial은 호스트를 배치로 나누는 단위, throttle은 특정 작업의 동시 실행 제한이다.
• 순차 배포와 가용성모든 노드의 웹 서비스를 한꺼번에 재시작하는 대신 작은 배치로 진행하는 구조를 표현할 수 있지만 실제 가용성은 백엔드 상태와 연결 배제까지 함께 설계해야 한다.

09check·diff·recap이 말해 주는 것과 말하지 않는 것

• check·YAML--syntax-check는 YAML·playbook의 해석을 검사하며 대상 연결과 프로그램 정상 응답을 보장하지 않는다.
• Check mode 지원 범위--check는 지원 모듈의 변경 예측을 제공하지만 모든 작업을 완전하게 모의 실행하지 않는다.

  • 지원하지 않는 작업이나 이전 태스크 결과에 의존하는 조건은 실제 실행과 다를 수 있다.
• 실제 실행되는 예외check_mode: false인 태스크는 check 실행에서도 실제 실행될 수 있다.
• diff--diff는 변경 내용을 드러내므로 비밀 파일의 내용도 출력될 수 있고 no_log 같은 제한 역시 의도에 맞게 구성한다.
• ok·changed태스크의 ok는 성공·변경 없음, changed는 성공·변경 보고, failed는 실행 실패, unreachable은 연결 불가, skipped는 조건 등에 따른 생략이다.
• recap·ok마지막 recap의 ok에는 changed 성공도 포함되어 ok=3 changed=1은 네 개가 아니라 성공한 세 작업 중 한 작업이 변경됐다는 뜻이다.
• failedignored·rescued가 있으면 failed=0만으로 문제가 해결됐다고 단정할 수 없다.

  • 결과 집계와 실제 서비스 동작을 분리해서 읽는다.

ansible-playbook -i inventory.ini study.yml --syntax-check
ansible-playbook -i inventory.ini study.yml --list-hosts
ansible-playbook -i inventory.ini study.yml --limit web1 --check
# 실제 실행 전 모듈의 check_mode 지원과 예외 태스크를 읽는다.

교육용 예시. 실제 원격 접속·설정 변경·배포는 실행하지 않았다.

10재사용과 운영 통제

• handler·role변수·템플릿·handler·role을 이용하면 반복 구성을 구조화할 수 있다.
• 비밀값비밀값은 일반 인벤토리와 코드에서 분리하며, Vault로 암호화했더라도 복호화 비밀과 실행 로그 관리가 필요하다.
• 대상·변수 우선순위대상 그룹과 변수 우선순위를 이해하지 못하면 의도하지 않은 설정이 적용될 수 있다.
• 변경 범위변경 범위를 작은 그룹으로 나누고 연결 장애나 중간 실패에 대한 중단·복구 기준을 정한다.
• 예상 차이와 서비스 검증실행 전 예상 차이와 실행 후 서비스 상태를 함께 남겨야 재현 가능한 운영 기록이 된다.