クイズ: 冪等性とハンドラ

플레이북의 멱등성을 판정하는 가장 실용적인 기준은?

• 두 번 연속 실행했을 때 걸린 시간이 거의 같게 나오는 것
• 연속 두 번째 실행의 changed 와 failed 가 모두 0 인 것
• 모든 태스크에 이름이 있고 전용 모듈만 써서 작성된 것
• 첫 실행이 failed 하나 없이 끝까지 완주해 목표 상태에 도달하는 것

핸들러가 실행되는 시점으로 옳은 것은?

• notify 한 태스크가 changed 로 끝난 직후
• 플레이북의 모든 플레이가 끝난 뒤 마지막에 한 번
• 다음 플레이가 시작되기 직전에 몰아서
• 기본적으로 플레이의 모든 태스크가 끝난 뒤

같은 핸들러를 세 개의 태스크가 각각 notify 했고 셋 다 changed 였습니다. 핸들러는 몇 번 실행되나요?

• 태스크 수만큼 비동기로 실행
• 중복 통지를 합쳐 마지막에 1번
• 통지만 모이고 실행은 0번
• 통지한 태스크마다 각각 3번

shell 로 파일에 한 줄을 추가하는 태스크를 멱등하게 만드는 방법으로 가장 적절한 것은?

• creates 로 이미 만들어졌는지 알려 주거나 lineinfile 같은 전용 모듈을 쓴다
• ignore_errors: true 를 붙여 줄이 중복될 때 나는 오류를 무시하게 한다
• 태스크에 태그를 달아 평소 실행에서는 건너뛰고 필요할 때만 지정해 돌린다
• changed_when: false 를 붙여 매번 changed 로 보고되지 않게 만든다

매 실행마다 서비스가 재시작되는 플레이북에서 가장 먼저 의심할 것은?

• 템플릿 렌더링 결과가 매번 달라져 설정 파일이 계속 changed 로 잡히는 것
• 핸들러 이름에 공백이 있어 notify 가 매번 새 핸들러를 만들어 내는 것
• 인벤토리에 같은 호스트가 두 번 적혀 플레이가 두 번씩 도는 것
• SSH 연결이 매번 새로 열려 서비스 상태 조회가 changed 로 잡히는 것

멱등한 플레이북이 드리프트 감지기로도 쓰일 수 있는 이유는?

• 실행할 때마다 로그를 자동으로 저장해 두어 이전 상태와 비교할 수 있기 때문
• 손으로 고쳐진 서버에서는 changed 가 나오고 그 수가 코드와 어긋난 정도이기 때문
• 팩트 수집이 대상 서버의 파일 변경 이력까지 읽어 와 차이를 알려 주기 때문
• 핸들러가 발화할 때마다 어떤 설정이 바뀌었는지 기록으로 남기기 때문