クイズ: 変数の優先順位

한 플레이에 vars: 로 svc_tier 를 적고, 같은 플레이의 vars_files: 로 읽는 파일에도 svc_tier 가 있다. 태스크에서 보이는 값은?

• vars_files 쪽 값 - 파일에서 읽어 들인 값이 플레이에 직접 적은 값보다 높다
• 플레이 vars 쪽 값 - 플레이북에 직접 적은 값이 밖에서 읽어 온 값보다 높다
• 먼저 적은 쪽 값 - 두 자리는 같은 순위라 YAML 에서 먼저 나온 것이 남는다
• 정의되지 않음 - 같은 순위의 두 자리가 겹치면 ansible 이 오류로 멈춘다

남이 만든 롤의 값을 플레이 vars_files 로 덮어썼는데 전혀 바뀌지 않는다. 가장 먼저 열어 볼 파일은?

• 롤의 defaults/main.yml - 기본값이 밖에서 준 값을 이기고 있을 가능성이 크다
• 롤의 vars/main.yml - 이 자리의 값은 플레이의 vars_files 보다 높다
• 롤의 meta/main.yml - 의존 롤이 같은 이름을 다시 세우고 있을 가능성이 크다
• 롤의 handlers/main.yml - 핸들러가 값을 되돌려 놓고 있을 가능성이 크다

낮은 자리에 svc_limits: {cpu: "1", memory: 1Gi} 가 있고 높은 자리에서 svc_limits: {memory: 2Gi} 를 줬다. 결과는?

• {cpu: "1", memory: 2Gi} - 같은 이름의 딕셔너리는 키 단위로 합쳐진다
• {cpu: "1", memory: 1Gi} - 딕셔너리는 통째 교체가 막혀 있어 낮은 자리가 남는다
• {memory: 2Gi} - 높은 자리의 딕셔너리가 낮은 자리를 통째로 갈아 치운다
• 오류 - 같은 이름이 서로 다른 키 집합을 가지면 템플릿 평가에서 멈춘다

인벤토리를 디렉터리로 주었더니 ansible-inventory --graph 에 호스트가 하나도 안 나온다. 디렉터리 안에는 hosts.ini 와 group_vars/ 가 있다. 원인으로 가장 그럴듯한 것은?

• group_vars 는 디렉터리 인벤토리에서 지원되지 않아 전체 파싱이 중단됐다
• 디렉터리 인벤토리는 파일이 두 개 이상이면 -i 를 두 번 주어야 한다
• INI 형식은 디렉터리 안에서 YAML 로 자동 변환되는데 변환에 실패했다
• 기본 설정이 무시하는 확장자에 .ini 가 들어 있어 hosts.ini 가 읽히지 않았다

블록 vars 와 태스크 vars 에 같은 이름이 있다. 그 태스크에서 이기는 쪽과 그 이유는?

• 블록 vars - 블록이 태스크를 감싸므로 바깥쪽이 안쪽을 덮는다
• 태스크 vars - 범위가 좁을수록 높다는 규칙이 블록과 태스크 사이에도 그대로 적용된다
• 블록 vars - 태스크 vars 는 loop 안에서만 쓰이고 일반 태스크에서는 무시된다
• 둘 다 무시 - 같은 이름이 중첩되면 플레이 vars 로 되돌아간다

운영 사고 중에 -e svc_tier=emergency 로 플레이북을 돌렸다. 이 방식의 가장 큰 문제는?

• 명령줄 값은 첫 플레이에만 적용되어 뒤 플레이에서 조용히 사라진다
• 명령줄 값은 set_fact 보다 낮아 실행 중에 쉽게 덮어써진다
• 명령줄 값은 문자열로만 넘어가 숫자나 불리언을 요구하는 자리에서 반드시 실패한다
• 명령줄 값은 어느 자리보다 높아 플레이북 안에서 덮을 수 없고, 쓴 사실이 저장소에 남지 않는다