Ep.1에서 한 대 접속에 성공했다. 이제 전체로 확장하고, 더 중요한 질문에 답한다 — “이 결과는 대체 어떤 원리로 나온 건가?” 이 원리를 이해하면 Ansible이 마법에서 구조로 바뀐다.

1. 14대를 전체로 확장하기

--limit 옵션을 떼면 인벤토리의 14대 전체에 동시 실행된다. 1대로 길을 검증했으니 이제 전체로 간다.

ansible -i inventory.yml switches \
  -m cisco.ios.ios_facts \
  -e 'sw_user=admin sw_pass=P@ssw0rd!2030 sw_enable=En@bleKey'

14대가 주르륵 SUCCESS로 뜨면 “1대 → 14대”가 입증된 것이다. 일부가 실패하면 그것도 정보다 — 어느 장비가 접속 안 되는지, 계정이 다른지가 즉시 드러난다. 이 가시성은 수동 점검으로는 얻기 어렵다.

2. 그 결과는 어떤 원리로 출력됐나 — SSH의 실체

가장 중요한 이해다. 결론부터: Ansible은 별도의 마법 채널이 아니라, 당신이 손으로 show version을 칠 때 쓰던 그 SSH 접속을 자동으로 대신 한 것이다. 실제로 일어난 일을 순서대로 풀면:

즉, 당신이 본 그 깔끔한 결과는 원래 길고 지저분했던 show version 텍스트를 모듈이 받아서 가공한 것이다. 새로운 통신 프로토콜이 아니라, SSH로 명령 치고 → 받은 텍스트를 파싱한 결과다.

3. facts vs ios_command — 두 수집 방식

여기서 중요한 분기가 있다. ios_facts는 모델·버전·시리얼처럼 Ansible이 미리 파싱해주는 정형 정보만 준다. 하지만 CPU·온도·전원처럼 그 밖의 정보는 ios_command로 직접 show 명령을 쳐서 raw 출력을 받아야 한다.

- name: 점검 명령 실행
  cisco.ios.ios_command:
    commands:
      - show clock                 # 현재 시각
      - show processes cpu | include CPU   # CPU 사용률
      - show environment all       # 온도/팬/전원
  register: result                 # 결과를 result 변수에 저장

4. cliconf vs NETCONF — 데이터를 받는 두 철학

facts 결과에 "ansible_net_api": "cliconf"라고 찍혀 있었다. 이건 “CLI로 명령을 치고 텍스트를 받는다”는 뜻이다. 구형 Cisco는 이 방식이 유일하다. 하지만 현대 장비는 다른 길도 있다.

5. 핵심 멘탈 모델 한 줄