오늘 Deview 2014에서 기존의 bash script와 ansible의 차이에 대한 질문을 제대로 답변을 못했던 것 같아 정리해 본다. 배포 관점에서는 똑같지만, ansible이 보다 훨씬 쉽게 다룰 수 있고 높은 수준의 개발이 가능한 보완재라 생각한다.
나는 naver에서 배포시스템의 bash script 만으로는 한계를 느꼈는데, 그 이유를 들면 다음과 같다.
- 소수점 연산
- 병렬 지원
- 수십개의 서비스 프로젝트를 관리하다 보니, 관리할 내용이 너무 많았다. 체계화된 시스템의 한계를 만남
(모니터링, 배포, 설정, SSL 설정...)
- 지저분해지는 소스
- 쓰레드 비지원
- 설치/실행스크립트 배포
perl을 이용해서 개발해 보니 소스가 굉장히 깔끔해지고 병렬/쓰레드 지원 코드로 성능 이슈를 해결했다.
bash보다는 높은 수준의 추상화, strict 한 bash script 코딩보다는 perl의 시스템 코딩이 훨씬 깔끔하고 문제 해결이 쉬웠다. 특히 반복적인 코딩에는 고급언어로서 해결을 보았던 것 같다.
단순한 목적 해결관점에서는 bash script나 ansible이나 동일하다. 그러나 서비스 확장에 따른 다양한 툴/쓰레드/병렬 지원은 필수가 된다. 그럴 때 아주 위력을 발휘한다. bash script로 개발하다 만나는 문제를 provision 툴이 비슷한 부분으로 해결하는 듯 하다.
- 소수점 연산 지원
- 병렬 배포 지원
- 내부 디렉토리 체계화 (role, playbooks...)
- 모니터링 체계 수립
- 깔끔해지는 소스
- 설치는 provision툴에서 진행하고 실행하는 스크립트만 배포
- 멱등성 (이미 변경을 원하지 않는다면 넘어감. 따라서 skip이 있으니 빠른 작업이 가능)
- 상태 저장 (특정 리눅스의 명령의 결과를 다른 서버에서도 사용할 수 있도록 함)
- 전역 변수화 (서버마다의 변수를 사용할 수 있지만 정의된 모든 서버에서의 변수화가 가능- 전역 변수처럼)
게다가 python 이나 perl은 리눅스 기반의 OS에는 모두 깔려 있지 않은가? 이게 가장 큰 장점이기도 한 것 같다. 바로 써먹을 수 있다는 점인듯 하다.
'Ansible-Puppet-Chef' 카테고리의 다른 글
[ansible] ansible의 paramiko (0) | 2014.09.30 |
---|---|
Deview 2014 - Ansible의 이해와 활용 발표 자료 (0) | 2014.09.30 |
ansible conference 자료 (0) | 2014.09.29 |
[ansible] jinja2 적용할 때 copy/template 유의 (0) | 2014.09.10 |
[ansible] command 명령 내리기 (0) | 2014.09.10 |