クイズ: 直す前に見る方法

--check 로 돌렸더니 command 모듈을 쓴 태스크가 skipping 으로 나왔다. 왜인가?

• 명령이 무엇을 할지 Ansible 이 알 수 없어 점검 모드를 지원하지 않고, 지원하지 않는 모듈은 건너뛰어진다
• 점검 모드에서는 대상에 SSH 연결 자체를 하지 않으므로 모든 원격 태스크가 건너뛰어진다
• 명령의 종료 코드를 미리 알 수 없어 Ansible 이 그 태스크만 마지막으로 미뤄 둔 것이다
• 점검 모드는 파일을 바꾸는 모듈만 평가하도록 설계되어 조회 태스크는 항상 제외된다

읽기 전용 명령 태스크에 check_mode: false 를 붙이면 무엇이 달라지는가?

• 점검 모드에서 그 태스크의 diff 출력만 숨겨지고 실행 여부는 그대로다
• 점검 모드에서도 그 태스크는 실제로 실행되어 register 변수에 값이 담긴다
• 실제 실행에서도 그 태스크가 건너뛰어져 대상 상태를 절대 읽지 않는다
• 그 태스크의 changed 보고가 항상 false 로 고정되어 요약에서 빠진다

앞 태스크가 파일을 만들고 뒤 태스크가 그 파일의 한 줄을 고치는 플레이북을 --check 로 돌리면 뒤 태스크가 실패한다. 이유는?

• 점검 모드에서는 두 태스크의 실행 순서가 뒤바뀌어 고치는 쪽이 먼저 평가되기 때문이다
• 점검 모드가 같은 파일을 두 태스크가 다루는 것을 충돌로 보고 뒤쪽을 거부하기 때문이다
• 앞 태스크가 실제로 파일을 만들지 않았으므로 뒤 태스크가 없는 파일을 고치려다 죽기 때문이다
• 점검 모드에서는 파일을 읽을 권한만 주어져 쓰기를 시도하는 태스크가 권한 오류를 내기 때문이다

정의되지 않은 변수를 쓰는 플레이북을 세 도구로 검사하면 결과가 어떻게 갈리는가?

• 세 도구 모두 같은 오류를 같은 종료 코드로 잡아낸다
• --list-tasks 만 잡아내고 --syntax-check 와 --check 는 통과시킨다
• --syntax-check 만 잡아내고 나머지 둘은 실행 단계라 그냥 지나간다
• --syntax-check 와 --list-tasks 는 0 으로 통과하고 --check 에서 처음 실패한다

check_mode: true 를 태스크에 붙였을 때의 동작으로 옳은 것은?

• 점검 모드로 돌릴 때만 그 태스크가 실행되고 평소 실행에서는 건너뛰어진다
• --check 없이 평소대로 돌려도 그 태스크는 절대 변경하지 않고 바뀔 것이라는 보고만 한다
• 그 태스크가 실패해도 플레이북이 멈추지 않고 다음 태스크로 넘어간다
• 그 태스크의 결과가 diff 로만 출력되고 PLAY RECAP 의 집계에서는 제외된다

점검 모드를 CI 의 드리프트 게이트로 쓴다는 말의 뜻은?

• 배포 전에 --syntax-check 를 걸어 문법 오류가 있으면 파이프라인을 세우는 것
• 배포할 때마다 --diff 를 걸어 바뀐 내용을 로그에 남겨 두는 것
• 플레이북을 두 번 연속 실행해 두 번째 실행의 changed 가 0 인지 보는 것
• 수렴이 끝난 뒤 점검 모드로 한 번 더 돌려, 바뀔 것이 하나라도 있으면 실패로 끝내는 것