测验：剧本慢下来的真正原因

대상 200대에 배포하는 플레이북이 느리다. 가장 먼저 해야 할 일은?

• profile_tasks 같은 콜백을 켜고 한 번 돌려 어느 태스크가 시간을 쓰는지 기록으로 남긴다
• forks 를 기본값 5 에서 50 으로 올려 동시에 붙잡는 대상 수부터 늘린다
• strategy 를 free 로 바꿔 느린 호스트가 나머지를 붙잡지 못하게 한다
• 팩트 캐시를 켜서 두 번째 실행부터 팩트 수집을 건너뛰게 한다

gathering = smart 와 jsonfile 팩트 캐시를 켠 뒤 대상의 커널을 올렸다. 플레이북을 그냥 다시 돌리면?

• setup 이 다시 돌아 새 커널 판을 가져오고, 캐시는 그 값으로 갱신된다
• 캐시에 있는 옛 커널 판이 그대로 쓰이고, 그 값을 보는 조건문도 옛 사실로 갈린다
• 캐시와 실제 값이 달라 앤서블이 경고를 내고 그 호스트를 건너뛴다
• 캐시는 팩트 이름만 담고 값은 담지 않으므로 값은 언제나 새로 가져온다

SSH 파이프라이닝의 기본값이 꺼짐인 이유는?

• 켜면 모듈이 대상 디스크에 남아 보안 감사에서 지적되기 때문이다
• 제어 지속(ControlPersist)과 함께 쓸 수 없어 둘 중 하나만 고를 수 있기 때문이다
• 대상의 sudoers 에 requiretty 가 켜져 있으면 동작하지 않아, 되는 곳에서만 켜게 두었기 때문이다
• 파이썬 3 대상에서는 표준 입력으로 모듈을 넘길 수 없어 호환이 깨지기 때문이다

forks 와 strategy 의 관계를 옳게 설명한 것은?

• strategy 가 free 이면 forks 값은 무시되고 모든 호스트가 한꺼번에 시작된다
• forks 는 linear 에서만 쓰이고 free 에서는 호스트마다 하나씩 프로세스가 뜬다
• 둘 다 같은 것을 다르게 적는 방법이라 한쪽만 설정하면 된다
• forks 는 동시에 붙잡는 대상 수를, strategy 는 호스트들이 태스크마다 서로를 기다리는지를 정한다

30분쯤 걸리는 재색인 작업을 플레이북 중간에 넣어야 한다. 어떻게 쓰는 것이 적절한가?

• async 를 작업이 걸리는 시간보다 넉넉히 잡고 poll 을 0 으로 두어 던져 놓은 뒤, 뒤에서 async_status 로 거둔다
• async 를 30 으로 두고 poll 을 1 로 두어 1초마다 확인하며 앤서블이 그 자리에서 기다리게 한다
• 그 태스크만 strategy 를 free 로 바꿔 그 호스트가 먼저 끝까지 가게 한다
• forks 를 1 로 낮춰 컨트롤러가 그 작업에 자원을 몰아 주게 한다

ansible.cfg 에 pipelining = True 를 적었는데 정말 적용됐는지 확인하려 한다. 가장 확실한 방법은?

• 플레이북을 두 번 돌려 두 번째가 더 빠른지 시간을 재어 본다
• -vvv 로 실행해 SSH 명령줄에 pipelining 이라는 낱말이 찍히는지 본다
• ansible-config dump --only-changed -t all 의 pipelining 줄과 그 값이 어느 파일에서 왔는지 확인한다
• ansible --version 의 config file 줄이 그 파일을 가리키는지만 확인한다