소개
서로 관련된 여러 일회성 명령을 플레이북에 저장하면 반복 실행과 검토가 쉬워집니다. 유용한 플레이북은 안정적인 원하는 상태를 설명하며 의도한 모든 대상에서 관찰 가능한 결과를 만듭니다.
file과 copy 모듈을 사용하는 작은 YAML 플레이북을 작성하고 두 SSH 노드에 적용한 다음 생성된 파일과 변경이 없는 반복 실행을 검증합니다. 이 실습은 변수, 반복문, 역할 없이 플레이, 태스크, 멱등성을 소개합니다.
YAML로 플레이북 작성하기
이 단계에서는 이미 연습한 file과 copy 모듈을 재사용 가능한 플레이북으로 결합합니다.
Terminal에서 프로젝트로 이동합니다.
cd /home/labex/project
플레이북은 플레이의 YAML 목록입니다. 각 플레이는 호스트 패턴을 순서가 있는 태스크 목록과 연결합니다. 각 태스크는 모듈과 인수를 지정합니다. name 표시는 사람이 출력을 읽는 데 도움을 주지만 그 자체로 구성을 만들지는 않습니다.
YAML은 들여쓰기로 데이터를 중첩합니다. 탭 대신 공백을 사용하세요. 앞의 -는 목록 항목을 시작하고 콜론은 키의 값을 도입합니다. 여기서 tasks는 두 모듈 태스크를 포함합니다. "0750"처럼 따옴표로 감싼 mode는 권한 문자열로 유지됩니다. gather_facts: false는 이 고정 상태 태스크들이 팩트를 사용하지 않으므로 자동 팩트 수집을 생략합니다.
앞서 연습한 대로 따옴표로 감싼 히어 도큐먼트로 파일을 만듭니다. 마지막 EOF 줄까지 복사하세요.
cat > workspace.yml <<'EOF'
- name: Prepare managed workspaces
hosts: all
gather_facts: false
tasks:
- name: Create the workspace directory
ansible.builtin.file:
path: /home/automation/workspace
state: directory
mode: "0750"
- name: Write the workspace notice
ansible.builtin.copy:
dest: /home/automation/workspace/README.txt
content: "Workspace managed by Ansible\n"
mode: "0640"
EOF
첫 번째 태스크는 디렉터리를 선언합니다. 두 번째는 컨트롤러 src 파일을 읽는 대신 copy의 content 인수로 리터럴 텍스트를 직접 제공합니다. 큰따옴표로 감싼 YAML 문자열은 \n을 마지막 줄바꿈으로 해석합니다. 고정된 콘텐츠는 반복 실행을 안정적으로 만듭니다. 바뀌는 타임스탬프를 추가하지 마세요.
플레이는 hosts: all을 사용하며 이는 제공된 두 SSH 노드를 뜻합니다. 일반 태스크는 automation으로 실행되므로 become 없이 해당 홈 디렉터리에 쓸 수 있습니다.
ansible-playbook은 플레이북 파일을 실행합니다. 먼저 --syntax-check로 태스크를 적용하지 않고 구조를 검증합니다.
ansible-playbook workspace.yml --syntax-check
플레이북 식별 줄이 표시되고 파서 오류는 없어야 합니다. 구문 검증만으로는 원격 연결이나 올바른 최종 파일을 증명할 수 없습니다.
--list-hosts로 플레이의 호스트 선택을 미리 확인합니다.
ansible-playbook workspace.yml --list-hosts
플레이에는 web1과 web2가 나열되어야 합니다. 빈 목록은 사용할 수 있는 두 호스트 플레이북이 아닙니다.
원하는 상태 적용하기
이 단계에서는 플레이북을 실행하고 실제 원격 결과를 확인합니다.
프로젝트의 구성과 인벤토리가 선택되도록 프로젝트에서 파일을 실행합니다.
ansible-playbook workspace.yml
Ansible은 각 플레이와 태스크 이름을 출력한 다음 PLAY RECAP을 표시합니다. 새로운 환경에서는 두 태스크가 각 호스트를 변경해야 합니다.
web1 : ok=2 changed=2 unreachable=0 failed=0 ...
web2 : ok=2 changed=2 unreachable=0 failed=0 ...
공백과 호스트 순서는 다를 수 있습니다. ok는 성공한 태스크 수, changed는 변경이 필요했던 태스크 수를 나타내며 unreachable/failed는 모두 0이어야 합니다. 성공한 태스크 이름만으로는 필요한 파일 바이트나 권한을 증명할 수 없습니다.
애드혹 command 모듈로 각 원격 안내문을 읽습니다.
ansible all -m ansible.builtin.command -a 'cat /home/automation/workspace/README.txt'
두 stdout 값 모두 Workspace managed by Ansible을 보여야 합니다. 읽기 전용 command 조회도 CHANGED를 보고할 수 있습니다. 플레이북의 file/copy 결과가 선언된 상태를 설명합니다. 관리 디렉터리 권한은 0750, 안내문 권한은 0640이며 둘 다 automation 소유입니다.
멱등적 수렴 검증하기
이 단계에서는 플레이북을 반복 실행하여 일치하는 상태에 추가 변경이 필요하지 않음을 확인합니다.
멱등성은 같은 원하는 상태를 반복 적용해도 수렴 후에는 불필요한 변경이 발생하지 않는다는 뜻입니다. 같은 플레이북을 다시 실행합니다.
ansible-playbook workspace.yml
각 대상의 요약에서 ok=2, changed=0, unreachable=0, failed=0이 나와야 합니다. 두 파일은 계속 존재하며 올바른 상태입니다. 바뀌는 타임스탬프나 무조건 실행되는 일반 명령은 이러한 안정된 결과를 해칩니다.
--check는 미리 보기를 요청합니다. 이를 지원하는 모듈은 변경을 적용하지 않고 예측합니다. file과 copy 모두 이 작업 흐름을 지원합니다. 수렴된 플레이북을 미리 확인합니다.
ansible-playbook workspace.yml --check
다시 두 호스트 모두 변경이 0이어야 합니다. 미리 보기는 최초 실제 실행이나 실제 상태 점검을 대체하지 않습니다. 여기서는 이미 생성된 작업 공간이 선언과 일치함을 확인합니다.
나중에 재사용할 수 있도록 플레이북을 보관하세요. 깨끗한 요약을 꾸며 내기 위해 changed_when으로 변경을 숨기거나 태스크를 check mode 밖에서 강제로 실행하지 마세요. 결과는 실제로 일치하는 상태를 반영해야 합니다.
요약
YAML로 호스트 선택과 순서가 있는 모듈 태스크를 표현하고 구문 및 대상 범위를 확인한 다음 실제 두 관리 노드에 플레이북을 적용했습니다. 실제 파일 상태가 요구 사항과 일치했고 두 번째 실제 실행은 추가 변경을 하지 않았으며 읽기 전용 check mode에서도 대기 중인 변경이 발견되지 않았습니다.
