인벤토리 — 자동화의 주소록

한 줄 요약

Ansible 은 "무엇을 할지"보다 "누구에게 할지"를 먼저 묻는다. 그 답이 인벤토리다.

왜 이게 필요했나

서버가 세 대일 때는 터미널 세 개를 열면 된다. 일곱 대가 되면 창을 잘못 고르는 사고가 난다. 홈랩을 3노드에서 7노드로 늘린 기록을 보면, 노드를 붙이는 절차 자체는 어렵지 않은데 "어느 노드에 무엇을 했는지"를 사람이 기억하는 순간부터 실수가 시작된다. 실제로 새로 붙인 두 노드에는 예전 클러스터의 잔재(구버전 kubelet, 옛 인증서)가 남아 있었고, 그걸 정리하는 절차를 손으로 하다 보면 한 대는 빠뜨린다.

인벤토리는 이 문제를 "목록을 파일로 만든다"로 뒤집는다. 파일에 적혀 있지 않은 서버는 자동화 대상이 아니고, 파일에 적힌 서버는 전부 같은 대접을 받는다. 이 단순한 규칙이 "한 대만 설정이 다른" 상황을 구조적으로 없앤다.

어떻게 동작하나

인벤토리에는 세 가지가 들어간다.

| 요소 | 무엇인가 | 예 |
| --- | --- | --- |
| 호스트 | 접속할 대상 하나 | web1 |
| 그룹 | 호스트의 묶음 | [web], [db] |
| 변수 | 호스트/그룹에 딸린 값 | ansible_port=2222, app_port=8080 |

핵심은 그룹이 계층을 이룬다는 점이다. [prod:children] 아래에 web 과 db 를 넣으면 prod 는 두 그룹의 모든 호스트를 포함한다. 그리고 모든 호스트는 자동으로 all 그룹에 속한다. 변수는 위에서 아래로 흐르되, 더 좁은 범위가 이긴다 — all 의 값보다 그룹의 값이, 그룹의 값보다 호스트의 값이 우선한다.

형식은 INI 와 YAML 두 가지다. INI 는 짧아서 손으로 쓰기 좋고, YAML 은 중첩 구조와 복잡한 변수를 담기 좋다. 둘 중 무엇을 쓰든 ansible-inventory --list 로 뽑아 보면 결국 같은 JSON 이 된다. 인벤토리를 의심할 때는 파일을 노려보지 말고 이 명령으로 실제 해석 결과를 봐라. 오타 하나로 그룹이 통째로 비어 있는 것을 3초 만에 알 수 있다.

현장에서 만나는 모습

첫째, "왜 한 대만 안 됐지". 대상을 좁힐 때 --limit 를 쓰지 않고 인벤토리에서 호스트를 잠시 지우는 사람이 있다. 그러면 그 파일이 그대로 커밋되어 며칠 뒤 그 서버만 패치에서 빠진다. 대상 축소는 인벤토리가 아니라 실행 옵션으로 한다.

둘째, 접속 정보도 변수다. ansible_host, ansible_port, ansible_user 는 특별한 변수처럼 보이지만 그냥 변수다. 그래서 점프 호스트나 비표준 포트 같은 환경 차이를 코드 수정 없이 인벤토리에서 흡수할 수 있다. 이 실습 환경도 sshd 가 127.0.0.1:2222 에 떠 있어서 ansible_port 로 그 차이를 다룬다.

셋째, 동적 인벤토리. 클라우드에서는 서버 목록이 매일 바뀌므로 파일 대신 스크립트가 목록을 만든다. 그래도 개념은 같다 — 그룹과 변수를 담은 JSON 을 만들어 주는 것뿐이다. 정적 인벤토리를 제대로 이해하면 동적 인벤토리는 출력 형식만 다른 같은 물건이다.

다음 실습에서 할 것

/root/ans/inventory/hosts.ini 에 web·db 그룹과 prod 상위 그룹을 만들고, 같은 구조를 YAML 로도 표현한다. 그다음 애드혹 명령으로 세 호스트에 한 번에 접속하고, --limit 로 대상을 좁혀 본다. 마지막에는 인벤토리를 JSON 으로 뽑아 그룹별 호스트 보고서를 만든다.