クイズ: プレイブックを試験する

ansible-playbook --syntax-check가 통과시킨 플레이북에 대해 확실히 말할 수 있는 것은?

• YAML 구조와 플레이·태스크의 모양이 말이 되고 모듈 이름이 실재한다는 것까지다
• 태스크가 모두 멱등하며 두 번 돌려도 changed 가 0 이 된다는 것까지다
• 변수가 모두 정의되어 있어 실행 중에 undefined 오류가 나지 않는다는 것까지다
• 대상에 접속할 수 있고 인벤토리의 호스트가 모두 살아 있다는 것까지다

오래된 저장소에 ansible-lint 를 처음 들인다. 지적이 400개 나왔다. 적절한 첫 수는?

• skip_list 에 지적이 많이 나온 규칙 열 개를 넣어 CI 를 먼저 초록으로 만든다
• 낮은 프로파일(min 이나 basic)로 걸어 CI 를 통과시키고, 정리되는 대로 한 층씩 올린다
• 모든 파일에 # noqa 를 한 줄씩 달아 두고 시간이 날 때 하나씩 떼어 낸다
• 린트를 CI 에서만 돌리고 개발자 쪽에서는 돌리지 않게 해 마찰을 줄인다

# noqa: risky-shell-pipe 와 .ansible-lint 의 skip_list: [risky-shell-pipe] 의 차이는?

• noqa 는 경고로 낮추고 skip_list 는 완전히 끈다. 둘 다 저장소 전체에 걸린다
• noqa 는 CI 에서만 걸리고 skip_list 는 사람이 손으로 돌릴 때만 걸린다
• noqa 는 그 태스크 하나만 규칙에서 빼고, skip_list 는 저장소 전체에서 그 규칙을 끈다
• noqa 는 프로파일이 production 일 때만 유효하고 skip_list 는 모든 프로파일에서 유효하다

.ansible-lint 의 exclude_paths 에 legacy/ 를 넣었는데, ansible-lint legacy/old.yml 을 직접 실행하니 지적이 나온다. 왜인가?

• exclude_paths 는 디렉터리가 아니라 파일 이름만 받으므로 legacy/ 는 무시된 것이다
• exclude_paths 보다 우선순위가 높은 skip_list 가 비어 있어 규칙이 그대로 살아 있는 것이다
• exclude_paths 는 profile 이 production 일 때만 적용되는 항목이기 때문이다
• 제외 목록은 디렉터리를 훑을 때 걸리는 것이고, 파일 이름을 직접 주면 적용되지 않기 때문이다

assert 가 린트로는 대신할 수 없는 일을 하는 이유는?

• assert 는 대상에서 실행되어 대상의 실제 파일과 프로세스를 볼 수 있기 때문이다
• 린트는 파일을 정적으로 읽을 뿐이고, 변수에 실제로 어떤 값이 들어오는지는 실행 시점에만 알 수 있기 때문이다
• 린트는 플레이북만 보고 롤 안의 태스크는 보지 않기 때문이다
• assert 는 실패해도 플레이를 멈추지 않아 검사를 모아서 보고할 수 있기 때문이다

문법 검사·린트·전제 조건 검사를 하나로 묶는 관문 스크립트를 만들었다. 반드시 해야 할 확인은?

• 세 검사가 모두 같은 형식으로 로그를 남기는지 확인한다
• 정상적인 저장소에서 0 으로 끝나는지 확인하면 충분하다
• 세 검사를 병렬로 돌려 전체 시간이 가장 긴 검사만큼만 걸리는지 확인한다
• 일부러 나쁜 입력을 물려 0 이 아닌 값으로 끝나는지 확인한다