Ansible을 이용하여 Linux 업데이트 자동화 (2편)에서 이어지는 글이다.
3편에서는 인벤토리 확인 > 접속 테스트 > 예행연습 > 실제 적용을 다룬다.
1) Inventory 확인 (Tree 형태로 출력)
# 현재 Ansible이 읽고 있는 inventory 구조를 트리 형태로 출력
ansible-inventory --graph
현재 Ansible이 읽고 있는 inventory 구조를 트리 형태로 출력한다.
어떤 그룹 아래에 어떤 호스트가 들어 있는지 한눈에 확인할 수 있어서, hosts.yml 문법이나 그룹 구성이 의도대로 잡혔는지 점검할 때 유용하다. 이 명령은 실제 서버에 접속해 작업을 수행하는 것이 아니라, inventory가 어떻게 해석되는지 확인하는 용도에 가깝다.
2) inventory에 있는 모든 호스트(all)에 대해 ping 모듈을 실행 (ad-hoc 명령)
# inventory에 있는 모든 호스트(all)에 대해 ping 모듈을 실행하는 ad-hoc 명령
ansible all -m ping
inventory에 있는 모든 호스트(all)에 대해 ping 모듈을 실행하는 ad-hoc 명령이다.
여기서 말하는 ping은 네트워크의 ICMP ping이 아니라, SSH로 로그인할 수 있는지와 원격 서버에 사용 가능한 Python이 있는지를 확인한 뒤 성공하면 pong을 반환하는 간단한 테스트다. 따라서 이 명령은 “서버가 실제로 관리 가능한 상태인지”를 빠르게 확인하는 데 쓰인다.
3) playbook을 실제로 적용하지 않고 미리 검토
# playbook을 실제로 적용하지 않고 미리 검토
ansible-playbook playbooks/update_all.yml --check --diff
playbook을 실제로 적용하지 않고 미리 검토하는 명령이다.
--check는 변경을 가하지 않고 어떤 변경이 일어날지 예측하는 옵션이고, --diff는 diff mode를 지원하는 모듈에 대해 변경 전후 차이 또는 변경 예정 내용을 보여준다. 따라서 이 명령은 운영 서버에 적용하기 전에 "이 playbook이 어떤 영향을 줄지"를 확인하는 예행연습 단계라고 보면 된다. 다만 --check는 어디까지나 시뮬레이션이므로, 실제 패키지 업데이트가 적용되지는 않는다.
4) playbook을 실제로 실행해서 Managed node에 업데이트 적용
# playbook을 실제로 실행해서 변경을 적용
ansible-playbook playbooks/update_all.yml
playbook을 실제로 실행해서 변경을 적용하는 명령이다.
즉, update_all.yml에 정의한 대로 Debian 계열 서버에는 apt, RHEL 계열 서버에는 dnf 작업을 수행해 실제 패키지 업데이트와 정리 작업을 진행한다. 앞선 --check --diff가 점검 단계였다면, 이 명령은 실제 운영 반영 단계라고 이해하면 된다.
5) Managed node 업데이트 완료 확인
ansible-playbook playbooks/update_all.yml을 다시 한번 실행했을 때 changed=0으로 떠야 정상적으로 작동된 것이다.
이제 Ubuntu 24.04, Debian 13, AlmaLinux 10에 직접 SSH로 접속하여 apt update, dnf update를 실행시켜보면 된다.
모두 정상적으로 업데이트된 것을 확인할 수 있다.
Ansible 초기 구성 과정이 조금 번거로울 수는 있지만, 한 번만 제대로 세팅해 두면 그 이후부터는 명령어 한 줄로 전체 Linux 업데이트를 간편하고 안전하게 자동으로 수행할 수 있다.
아직도 수동으로 일일이 SSH로 접속하여 Linux를 업데이트하고 있었다면, 이번 기회에 Ansible 도입을 적극 권장한다.
4편에서는 Managed node 업데이트 후 필요에 따라 자동 재부팅 등을 다룰 예정이다.