🚀 요약
SUMMARY
쉘 스크립트로 굴리던 클러스터 구축을 Ansible 기반으로 갈아탔다. 결정적이었던 건 멱등성(Idempotency)이다. 여기에 Kubespray와 NVIDIA GPU roles를 얹어 클러스터 구축·관리를 통째로 자동화했다.
💡 개요
쿠버네티스 클러스터를 어떤 도구로 세우고 관리할지 정하는 과정을 정리했다. 3년쯤 쓴 쉘 스크립트 자동화가 왜 한계에 부딪혔는지, 그래서 왜 Ansible로 넘어왔는지가 이 글의 전부다.
📋 선정 배경
약 3년 전, 처음 쿠버네티스 클러스터를 구축할 때는 kubeadm 기반의 쉘 스크립트로 OS 설정부터 클러스터링, 애플리케이션 설치까지 전 과정을 자동화했다. 처음엔 잘 돌았다. 문제는 시간이 지나면서 드러났다.
- 유지보수 비용: 스크립트가 커질수록 전체 로직이 머릿속에 안 들어왔다. 기능 하나 추가하거나 바꾸려면 스크립트 전체를 다시 훑어야 했다. 기억력 나쁜 편이라 반년만 지나면 내가 짠 스크립트도 남의 코드처럼 읽혔다.
- OS 호환성: 당시엔 특정 RHEL 버전에서만 설치해서 티가 안 났는데, Ubuntu 같은 다른 OS로 옮기려면 스크립트를 대대적으로 뜯어고쳐야 할 게 뻔했다.
정리하면, 초기 구축용으로는 충분했지만 오래 끌고 갈 물건은 아니었다는 뜻이다. 멱등성을 보장하면서 쉘 스크립트보다 손이 덜 가는 방법이 필요했다.
📊 비교
쉘 스크립트와 Ansible은 애초에 접근 방식이 다르다.
| 구분 | 쉘 스크립트 | Ansible |
|---|---|---|
| 접근 방식 | 절차 지향적(Procedural) | 선언적(Declarative) |
| 멱등성 | 보장하기 어려움 (수동 처리) | 기본적으로 보장 |
| 유지보수 | 복잡해질수록 가독성 저하 | YAML 기반, 모듈화 용이 |
| 오류 처리 | 재실행 시 부작용 우려 | 안정적인 재실행 |
| 이식성 | OS 변화에 민감 | 다양한 OS 지원 |
| 재사용성 | 낮음 (환경에 종속) | 높음 (Roles, Collections) |
| 학습 곡선 | 낮음 (기존 쉘 지식) | 중간 (Ansible·YAML 학습 필요) |
표로 늘어놓긴 했지만, 나한테 걸린 건 사실 한 줄이다. 쉘 스크립트는 명령어를 순서대로 실행할 뿐이라 “지금 어떤 상태인지”를 스스로 모른다. 중간에 실패하면 어디까지 됐는지 사람이 확인해야 하고, 다시 돌리면 이미 끝난 작업을 또 해서 사고가 난다.
Ansible은 “최종 상태가 이래야 한다”를 선언하면 거기에 맞춰 필요한 작업만 한다. 같은 플레이북을 몇 번 돌려도 결과가 같다. 이게 멱등성이다. YAML이라 읽기도 편하고, Roles·Collections로 잘라 두면 재사용도 쉽다. 학습 곡선이 좀 있다는 게 유일한 진입장벽인데, 이 정도는 감수할 만했다.
✅ 선정 사유
결국 Ansible을 골랐다. 이유를 추리면 세 가지다.
- 멱등성: 몇 번을 돌려도 같은 결과가 나온다는 것. 클러스터 상태를 안정적으로 유지하는 데 이만한 무기가 없었다.
- 유지보수: 구조화된 플레이북 덕에 가독성과 재사용성이 올라가면서, 반년 뒤의 내가 다시 읽어도 덜 괴로운 코드가 됐다.
- 생태계: 이미 잘 만들어진 걸 굳이 다시 짤 이유가 없었다. 프로덕션 레디 클러스터를 배포하는 Kubespray, GPU 드라이버와 CUDA 툴킷 설치를 자동화하는 NVIDIA GPU roles가 이미 있었다. 이걸 내 플레이북에 통합하니 구축부터 GPU 세팅까지 표준화된 한 흐름으로 묶였다.
NOTE
멱등성이 왜 중요한지 감이 안 온다면 이렇게 생각하면 쉽다. “패키지가 깔려 있으면 넘어가고, 없으면 설치한다”는 작업은 열 번을 돌려도 시스템을 딱 필요한 만큼만 건드린다. 이미 된 걸 또 하지 않는다는 것. 자동화에서 이 성질이 없으면 재실행 자체가 도박이 된다.