[후기] ansible 세미나 참가

458 views
Skip to first unread message

문태준

unread,
Jun 21, 2016, 9:12:19 AM6/21/16
to sysadminstudy
지난주 금요일에는 ansible 세미나가 있어서 참가를 했었습니다. ansible 은 configuration 관리 기능(puppet/chef 등과 비교 가능)과 원격 명령 실행 기능(fabric, func, capistrano)이 있는 프로그램으로 saltstack 도 두가지 기능을 함께 제공합니다.

시스템관리자나 자동화 프로그램에 대해서 관심이 있는 사람들이야 puppet/chef/ansible/saltstack 등을 들어보거나 사용을 해보았을 건데요. 저는 cfengine, puppet, saltstack, mcollective, fabric 등을 사용을 했었습니다.

그중 제가 재밌있고 흥미롭게 보았던 부분이 아리스타네트웍스에서 발표를 한 네트워크 장비를 ansible 로 관리하는 부분입니다. 

네트워크 장비의 경우도 요즘에는 API를 제공을 할 것 같은데요. puppet,saltstack 등 다른 프로그램의 경우에도 네트워크 장비를 설정하는 내용들이 나오기는 하는데 제가 직접 네트워크쪽 장비를 설정할 일이 없다보니 눈으로 볼 기회가 없었습니다.

아리스타네트웍스의  NOS인 EOS의 경우 리눅스 배포판을 커스터마이징해서 사용을 해서 기존에 리눅스에 돌아가던 프로그램을 그대로 올려서 사용할 수 있는 장점이 있더군요.
물론 네트워크 장비의 경우 서버보다는 문제가 생긴 경우 영향도가 더 크지만 규모가 커지는 경우 코드로 관리를 한다면 자동화도 가능하고 사람의 실수도 줄일 수 있습니다. 네트워크쪽에서 이런 설정관리툴을 사용하는 사례가 있었는지 궁금했었습니다.

오렐리의 책에서도 네트워크 자동화를 언급할 책들이 최근 계속 나오고 있습니다.


Network Programmability and Automation http://shop.oreilly.com/product/0636920042082.do

ansible 에서 제공하는 네트워크 모듈 : http://docs.ansible.com/ansible/list_of_network_modules.html

Taejoon Moon

unread,
Jun 21, 2016, 9:13:53 AM6/21/16
to sysadm...@googlegroups.com
세미나때 제가 대규모 서버 운영시 질문을 했었는데 오늘 레드햇 코리아분이 답변 주신 내용입니다. 

-----
ansible performance tuning

이번 세미나를 통해 여러분이 ansible의 성능 및 대규모 호스트의 관리 방법에 대한 질문을 주셨는데 저의 ansible 경험이 부족하여 정확한 답변을 드리지 못하였습니다. 수십대 수준이 아닌 수천대 수만대가 여러 곳에 분산되었을 때 어떻게 효율적으로 관리할 수 있는 고민하게 되었습니다. 그래서 자료를 조사하다가 좋은 성능 관리 기법을 찾게 되어 소개해드리려고 합니다.
원문은 아래와 같습니다.
https://www.ansible.com/blog/ansible-performance-tuning

[요약]
1. 패키지 미러사이트를 효율적으로 사용하기 
- 수천대의 서버들이 인터넷 repository를 사용하게 하지말고, 그룹별 또는 지역별 repository를 구성하여 여기서 다운받게 하는 것입니다. 특히 기업IDC에서와 같이 폐쇄망을 사용할 때는 이렇게 local repository를 만들고 모든 repository를 동기화 시켜 놓는 것이 패키지 다운로드 시간과 관리면에서 좋을 것입니다.

2. 패키지 설치를 효율적으로 하기
- with_items 를 활용해서 하나의 ssh 세션으로 패키지를 설치하게 하는 것입니다. yum module을 여러개 사용할 때와 하나의 yum module을 쓰는 차이점은 아래 명령의 차이와 같을 것입니다.
<code>
‪#‎yum‬ install python python-doc #(하나의 세션사용)
or
#yum install python; yum install python-doc #(두개의 세션사용)
</code>

3. Fork 수 알기
- folk 파라미터는 ansible이 동시에 몇 개의 host에 작업을 실행하는가를 결정합니다. 기본값은 상당히 보수적으로 설정되어 값이 "5"이며 5대의 서버에서만 동시에 실행되고 이 작업이 끝나야 다른 호스트에서 해당 작업들이 수행되기 때문에 실행시간이 늘어나게 됩니다. 즉, ansible이 관리하는 서버들이 수천대라고 하면 fork 를 100 이상으로 늘려서 작업시간을 빨리 끝내게 할 수 있습니다. folk는 동시에 작업이 실행될 호스트수라고 생각하기면 될 것입니다.

4. openssh 연결 팁
- ansible.cfg에서 "ControlPersist" 값을 늘려 connection timeout값을 늘려주는 방법. 
- "pipelining" 설정을 통해 ansible module의 파일 전송 속도를 향상 시킬 수 있음
- 위 두 부분은 테스트가 필요합니다.

5. ansible 전용 ssh 클라이언트(paramiko) 사용하기
- 기본 openSSH 클라이언트는 작업마다 새로운 ssh connection을 맺어서 작업을 수행하고 관리호스트가 많은 경우에는 이 시간도 상당히 많은 시간을 잡아먹습니다. 하지만 "paramiko" 의 "accelerated mode"를 사용하게 되면 기본에 비해 4-5배 성능향상을 볼 수 있습니다.

6. Pull Mode 사용
- 다른 puppet이나 chef 와 달리 ansible은 push 방식입니다.즉 중앙서버에서 관리되는 호스트들로 명령을 밀어넣는 방식입니다. 하지만 pull 모드를 사용하면 관리되는 호스트들에서 중앙서버에 직접 명령을 요청할 수 있게 됩니다.

7. Immutable Systems
- ‪#‎정확한‬ 작동방식을 제가 모르기 때문에 생략하겠습니다. 원문을 참고하시기 바랍니다.


2016년 6월 21일 오후 10:12, 문태준 <taejoo...@gmail.com>님이 작성:

--
이 메일은 Google 그룹스 'sysadminstudy' 그룹에 가입한 분들에게 전송되는 메시지입니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 sysadminstud...@googlegroups.com에 이메일을 보내세요.
이 그룹에 게시하려면 sysadm...@googlegroups.com에 이메일을 보내세요.
https://groups.google.com/group/sysadminstudy에서 이 그룹을 방문하세요.
더 많은 옵션을 보려면 https://groups.google.com/d/optout을(를) 방문하세요.

Taejoon Moon

unread,
Jun 21, 2016, 9:14:31 AM6/21/16
to sysadm...@googlegroups.com
마지막으로 위 글에 제가 달은 답변입니다... 연달아 이메일을...

도움이 되는 자료네요.
몇가지 의견을 적어보았습니다.

1. 패키지 미러사이트를 효율적으로 사용하기 -> 글로벌하게 운영을 하는 경우에는 다운로드 속도 문제로 고생을 합니다. 글로벌 CDN 같은거 이용하여 처리를 하지요. 어찌되었건 가까운 곳에서 파일들을 다운로드 받을 수 있도록 구성을 해야 겠지요.

2. 패키지 설치를 효율적으로 하기 -> CM tool에서 구성을 할 때 여러 개의 패키지를 설치한다면 배열 같은거 이용하여 처리를 하는게 코드면에서도 더 깔끔하지요. single transaction block 은 여러 번 yum 실행을 하지 않도록 해서 시간을 줄인다는 의미이겠지요?

3. Fork 수 알기 -> 이 부분은 실제 운여을 하면서 조정을 해야 하는 부분이겠네요. 그런데 5라면 기본 설정 자체가 좀 낮은 편 같습니다.

4. openssh 연결 팁 -> 이 부분은 잘 모르겠네요. 나중에 한번 찾아봐야 겠군요.

5. ansible 전용 ssh 클라이언트(paramiko) 사용하기 -> RHEL6 과 그 이전 버전에서는 pipelining 기능이 지원이 안되기 때문에 accelerated mode 를 통해서 성능 보완을 할 수 있다는 말이군요. 문서만 보고는 pipelining 이라는게 무엇인지 정확히 이해가 가지는 않네요.

6. Pull Mode 사용 -> you’ll lose out on centralized logging. ansible에서 제공하는 로깅을 사용할 수 없나 보군요.. "If you want to achieve periodic check-in without giving up the central history, Ansible Tower has a nice provisioning callback feature that provides this." 이건 무슨 의미인지 모르겠습니다.

7. Immutable Systems -> Immutable Systems 는 Docker와 같은 것을 말하지요. ansible 같은 프로그램으로 이미지를 만들고 cloud 기술을 이용하여 그 이미지를 배포하는 것을 말하는데요. 이렇게 하면 이미지 단위로 관리를 하는 것이니까 설치 시간이 필요없겠지요. Docker 이미지를 만들 때 설정을 수동으로 명시하지 않고 ansible 이나 puppet 등을 이용하여 설정하는 것을 생각해 볼 수 있겠네요. 이런 경우에는 이미지를 관리하는 프로그램와 연관이 필요할건데요. 원글에서 명시되어 있는 https://www.packer.io/ 같은 경우도 단일한 소스 파일에서 Amazon EC2, DigitalOcean, Docker, Google Compute Engine, QEMU, VirtualBox, VMware 등의 이미지를 만들어주는 프로그램입니다. ansible 등과 플러그인을 통해서 서로 연관을 해서 쓴다는 말이겠군요.

Immutable Systems 의 aminiator 를 따라가다보니 NetflixOSS Ansible Playbooks 정도로 나오는 군요. 이건 한번 나중에 살펴봐야겠네요.

다른 프로그램을 살펴 보지요.
mcollective 는 ActiveMQ,RabbitMQ 와 같은 publish/subscribe 미들웨어를 이용해서 확장을 할 수 있도록 구현이 되어있구요.

saltstack은 ZeroMQ는 분산메시징 라이브러리를 이용하며 Salt Transport 에서 보시면 Publish-Subscribe 방식을 사용합니다. 
syndic 이라는 것을 이용하여 여러 대의 마스터에서 나누어서 처리를 하고 Master of Masters 와 통신을 한다고 합니다. (이 부분은 제가 테스팅을 해보지는 않아서)

Mcollective, saltstack 모두 비동기 메시징 같은 기술을 이용하여 처리를 하고 있지요.

아무튼 나중에 위 문서에 있는 내용을 가지고 테스팅을 하면 도움이 뙬 듯 하네요.

2016년 6월 21일 오후 10:13, Taejoon Moon <taejoo...@gmail.com>님이 작성:

Jaehun Shin

unread,
Jun 21, 2016, 2:42:54 PM6/21/16
to sysadm...@googlegroups.com
ansible과 puppet을 직접 비교한다면 어느 쪽이 더 낫다고 할 수 있을까요?

2016년 6월 21일 오후 10:14, Taejoon Moon <taejoo...@gmail.com>님이 작성:



--
大逆戰

Taejoon Moon

unread,
Jun 23, 2016, 12:45:41 AM6/23/16
to sysadm...@googlegroups.com
질문이 너무 간단한데요.

Puppet은 설정관리 기능만 있고 ansible은 설정관리 기능 + 원격 명령 실행 기능이 있습니다.
Pupppet 개발사에서 mcollective 라고 원격 명령 실행 프로그램을 오픈소스로 제공하며 상용버전인 Puppet Enterprise에는 포함이 되어 있습니다.
ruby, python 언어를 꼭 알아야 설정관리 프로그램을 쓸 수 있는 것은 아닌데 어찌되었건 모듈을 직접 만든다면 해당 언어에 대해 어느 정도 익숙해야 합니다.
그리고 어떤 프로그램을 쓰건 규모가 커지면 커질수록 초기에 설계, 디자인 할 때 잘 해놓지 않으면 고생을 하더라구요.
그래서 제가 엄청나게... 고생을 했습니다. 한번 도입하면 중간에 바꾸기는 쉽지 않지요.

- 설정관리 기능 비교
Puppet/Chef : ruby
Saltstck/Ansible : python


https://en.m.wikipedia.org/wiki/Infrastructure_as_Code

Notable CCA tools include:

Tool Name Released by Method Approach
Ansible Tower Ansible Push Declarative & Imperative
CFEngine CFEngine Pull Declarative
Chef Chef Pull Imperative
Otter Inedo Push Declarative & Imperative
Puppet Puppet Pull Declarative
SaltStack SaltStack Push Declarative & Imperative

2013년 자료이기는 하지만 장단점 설명된 표
http://www.infoworld.com/article/2609482/data-center/data-center-review-puppet-vs-chef-vs-ansible-vs-salt.html?page=4


chef는 제가 써보지 않았구요.
커뮤니티에서 제공되는 각종 모듈의 성숙도를 보면 Puppet 이 좀 더 나은 것 같기는 합니다. 예를 들어 saltstack에서 apache 모듈을 돌리려고 하니 ubuntu는 잘되는데 CentOS는 에러가 나더군요. Openldap 에서 slapd.conf 를 읽지 읽고 설정정보도 ldap db에 넣는 기능이 있는데 Puppet module에서는 이 부분까지 지원을 하는 반면 Saltstack, Ansible의 모듈에서는 이 부분이 없구요. 물론 직접 만들고 고쳐서 쓰면 되는건데 조금이라도 작업을 줄이려고 한다면 고민되는 부분이지요.
한글 자료는 chef가 더 많은 듯 한데 글로벌하게는 설정관리 프로그램으로는 Puppet이 가장 많이 사용되는 것 같습니다.

현재 설정관리프로그램, 원격으로 명령을 실행하는 프로그램을 아무것도 쓰지 않고 있다하면 Ansible/Saltstack을 쓰면 둘다 해결할 수 있기에 편리할 겁니다.
그게 아니라 어느 한가지를 쓰고 있다고 하면 나머지 한가지를 적절한 것 골라서 써야 겠지요.
언어측면에서 ruby/python 어디가 편하냐도 판단을 해봐야 하구요. 자기한테 익숙한 언어를 쓰는게 더 낫거든요.
saltstack 모듈도 만들려고 하다보니까 python을 다시 공부하게 되더라구요.

설정관리용으로 Ansible/Saltstack 둘중에서 고른다고 한다면 아직까지 저는 Saltstack에 더 손이 갑니다. 물론 아직 제가 ansible 은 사용하지 않고 아주 간단히만 테스팅을 해봤기에 깊은 지식이 없기는 합니다만.
이 부분은 코드를 가지고 비교를 해야 하거든요.

이 부분은 말로 설명하기 쉽지 않네요.
apache 모듈에 대한 url 링크를 걸어봅니다.

막상 다시 puppet module을 보니 puppet module은 너무 지나치게 복잡하게 짜는 것 같고 ansible은 상대적으로 간단합니다.
ansible에 비하면 saltstack formula는 상대적으로 더 복잡해 보이기는 하는데 여러 개의 OS, 여러 환경을 사용한다면 오히려 saltstack이 나아 보이더라구요.\
아래 ansible/saltstack 코드를 비교해보면 ansible은 각 os별 설정이 메인 설정에 들어가는데 saltstack은 각 OS별 차이가 나는 부분은 별도의 파일로 뺍니다. (puppet 도 이와 비슷함)
fabric, capistrano는 일단 빼고 말하겠습니다.

mcollective는 pub/sub 미들웨어 사용하여 확장성 면에서 좋고 규모가 커지면 미들웨어만 늘리면 됩니다. 그런데 제공되는 모듈? 플러그인? 이 별로 없습니다. ruby로 직접 다 만들어서 구현을 해야 합니다. 근데 다량의 서버에서 명령을 실행한 결과를 레포팅해주는 것이 정말 편리하게 되어 있기는 합니다.

ansible/saltstack 을 보면 제대로 잘 돌아가는지까지는 모르겠지만 미리 만들어져 있는 것들이 정말 많습니다.  (saltstack 에서 lvs 실행하는 기능이 있는데 생각보다 기능이 너무 간단하더라구. 물론 내가 만들 수 있기는 하지만)

ansible 는 ssh 방식이고 saltstack 은 agent 방식인데 pub/sub 를 이용하여 확장성을 가지고 있지요.
saltstack 의 경우는 실행한 결과를 다른 곳에서 보내기, 모니터링 시스템과 연동하여 특정 이벤트 발생시 특정 작업 실행하기 등 원격 명령 실행하는 기능 말고도 여러가지 부가 기능들이 많습니다.
대신 ansible은 saltstack에 비하면 사용하기가 훨씬 간단하고 쉽습니다.
웹에서 제공하는 매뉴얼은 ansible 이 saltstack보다 훨씬 낫더라구요. saltstack 매뉴얼보면서 비슷한 내용이 이리저리 반복되고 흩어져 있어서 괴로웠습니다.

ansible/saltstack의 원격 명령 실행 기능중에서 고르라고 하면 아직까지 저는 saltstack에 마음이 더 갑니다.
상대적으로 짧은 시간내에 적용하기 쉬운 것은 ansible인 것 같습니다.



2016년 6월 22일 오전 3:42, Jaehun Shin <gunsmo...@gmail.com>님이 작성:

Jaehun Shin

unread,
Jun 23, 2016, 1:43:59 AM6/23/16
to sysadm...@googlegroups.com
질문은 너무 간단했는데 자세한 설명 정말 고맙습니다.

처음에는 간단히 작성한 puppet module이 추가 사항을 하나씩 덧붙이다보면 이해하기 어려워지는게 불만이 있었습니다. ansible을 바로 도입하기에는 곤란한 상황이었는데 태준님 설명으로 많은 도움이 되었습니다.

2016년 6월 23일 오후 1:45, Taejoon Moon <taejoo...@gmail.com>님이 작성:



--
大逆戰
Reply all
Reply to author
Forward
0 new messages