<aside>
☁️ 클라우드웨이브 · W06 · 3/5 · 예상 읽기 6~8분
</aside>
플레이북이 짧을 때는 작업을 위에서 아래로 읽는 것만으로도 흐름을 파악할 수 있다. 그러나 환경별 포트, 패키지 이름, 운영체제 차이, 작업 결과에 따른 분기까지 들어오면 고정된 값과 단순한 순서만으로는 부족하다. 3일차에는 플레이북을 실제 운영에 가까운 자동화로 발전시키는 제어 수단을 정리했다.
변수는 같은 작업을 여러 환경에 적용할 때 바뀌는 값을 분리한다. 플레이북, 인벤토리의 그룹·호스트, 실행 시 전달되는 값처럼 여러 출처가 있을 수 있으므로 우선순위와 이름 규칙을 정해야 한다. 값의 출처가 불분명하면 자동화가 실행되더라도 결과를 설명하기 어려워진다.
팩트는 대상 호스트에서 수집한 운영체제나 네트워크 같은 정보다. 팩트를 이용하면 호스트별 조건에 맞춰 패키지나 경로를 선택할 수 있다. 다만 필요하지 않은 정보를 모두 수집하면 실행 시간이 늘 수 있으므로 목적을 확인해야 한다. 작업 결과를 register에 저장하면 성공 여부, 변경 여부, 출력 등을 다음 조건에서 사용할 수 있다.
- name: 결과에 따라 다음 작업 결정
hosts: all
tasks:
- name: 상태 확인
command: example-check
register: check_result
changed_when: false
- name: 조건이 맞을 때만 보정
command: example-fix
when: check_result.rc != 0
같은 모듈을 여러 값에 적용할 때 loop를 사용하면 작업의 의도를 한 곳에 모을 수 있다. when은 팩트나 register 결과에 따라 작업을 건너뛸 수 있게 한다. 조건은 짧고 읽기 쉽게 유지해야 하며, 복잡한 판단은 변수나 별도 작업으로 나누는 편이 안전하다.
서비스 설정 파일이 변경됐을 때만 재시작해야 한다면 handler가 적합하다. 일반 작업에서 notify로 변경 사실을 알리고, 실제 handler는 플레이가 끝날 때 실행되도록 구성한다. 매번 재시작하지 않으므로 불필요한 중단을 줄이고, 변경과 후속 작업의 관계도 문서화할 수 있다.
실행 전 syntax-check는 YAML 구조와 플레이북 문법의 기본 오류를 빠르게 찾는다. check 모드는 실제 변경 없이 예상 결과를 살펴보는 데 유용하지만, 모든 모듈이 완벽한 예측을 제공하는 것은 아니므로 최종 확인을 대신하지 않는다.
실패를 무시하는 것과 실패를 설계하는 것은 다르다. block 안에 위험도가 있는 작업을 묶고 rescue에서 복구나 안내를 수행하며, always에서 정리 작업을 실행할 수 있다. failed_when으로 성공 기준을 명시할 수도 있다. Vault는 민감한 변수의 평문 노출을 줄이는 수단이지만, 비밀값을 로그나 예제에 넣지 않는 기본 원칙이 먼저다.
작업을 추가할 때 입력 변수, 관찰할 팩트, 성공 판정, 변경 시 후속 작업, 실패 시 복구를 한 세트로 적는다. 실행 전 문법 검사와 예측 실행을 거치고, 변경이 발생한 작업과 실제 서비스 영향이 일치하는지 로그로 확인한다. 오류를 숨기기보다 어떤 실패를 허용하고 어떤 실패에서 중단할지 정하는 것이 운영 자동화의 품질을 높인다.
검증은 한 번의 실행으로 끝나지 않는다. 작은 대상 그룹에서 먼저 실행하고, 재실행 결과가 안정적인지 확인한 다음 범위를 넓히는 순서가 좋다. rescue가 원래 상태를 완전히 복구한다고 가정하지 말고 복구 작업 자체의 멱등성과 관찰 가능한 기록을 함께 준비해야 한다.