Configuration management & Orchestration tools
- Taejoon Moon
Provisioning 관련하여
OS설치, OS설정, 애플리케이션 배포를 모두 Prpvisioning 이라고 지칭하겠습니다.
각 단계별 필요한 기능, 요구사항, 툴이 다를 수 있습니다.
OS설치-시스템 설정-애플리케이션 서비스 단계로 나눕니다.
- OS 설치단계에서는 물리적인 하드웨어에 OS를 설치할 수 있도 있고 가상화 환경에 설치를 할 수도 있습니다.
물리적인 하드웨어라면 pxe, dhcp, tftp 를 이용하고 원격으로 OS설치를 하고 VM이라면 이미지 복사만으로도 간단히 되겠지요.
kickstart에 대해서는 따로 이야기를 하겠습니다.
- OS 를 설치했다면 시스템 설정을 해야 합니다. OS 설치 후 기본적인 설정은 kickstart 안에 넣으면 되지만 지속적으로 관리를 해야 하는 부분은 system configuration 관리툴에 집어 넣어야 합니다. 기본적인 보안설정, 불필요한 서비스 내리기, dns 설정, 타임서버 설정, 등등... 일회성 변경이 아니라 지속적으로 설정을 유지해야 할 것들은 모두 system configuraition 에 들어가야 합니다.
- 애플리케이션 서비스 : 시스템 설정을 했다면 필요한 애플리케이션 서비스를 올리고 관리하는 작업이 필요합니다. system configuraiton 은 지속적으로 유지해야 하는 설정을 담는 반면 applicaton은 특정 애플리케이션을 설치, 삭제, 서비스 활성화, 비활성화 등의 작업이 있을 것입니다.
아주 소스의 인원만 있는 소수의 회사라면 system configuration 툴과 애플리케이션 서비스 툴은 공용으로 써도 되지만 규모가 커지면 서로 관리범위가 나누어지므로 분리하는것이 좋을 것입니다.
System configuration
cfengine, pupet, bcfg2, slack, chef 등의 툴들이 있습니다.
cfengine 은 아주 오래된 고전적인 툴입니다. 2005년도인가 2006년도에 sysadmin 세미나때 설명을 많이 했었는데요. 근 몇년간 puppet 이 엄청나게 치고 올라오고 있고 해외 컨퍼런스에서도 아주 많이 다르고 있습니다. (cfengine version3는 아직 사용해보지 않아서 잘 모름) chef 도 요즘 많이 거론되고 있는 듯 한데 직접 사용해보지 않아서 머라고 말은 못하겠습니다만 기본적인 아이디어는 비슷하겠죠.
이런 툴을 쓰는 목적은 시스템 설정을 중앙에서 관리하고 시스템 엔지니어가 각자의 방식으로 관리하는게 아니라 일관된 표준 방식으로 관리하기 위해 필요합니다.
이런 툴로 시스템 설정을 한 경우 예를 들어 시스템 엔지니어가 바뀌었다 물론 초반에는 툴을 이해해야 하기 때문에 힘들지만 코드를 보면 모든 시스템 설정을 이해할 수 있습니다.
cfengine, puppet 등은 중앙의 서버가 있어서 각 시스템에서 주기적으로 중앙의 서버에서 업데이트가 된 것이 있는지 확인하여 시스템 설정을 업데이트 합니다.
cfengine v2의 경우는 속도는 빠른 것 같습니다만 puppet 과 비교를 하면 설정도 이해하기 어렵고 각 서비스간의 관계(예를 들어 snmpd.conf 가 업데이트도면 snmpd를 내린다 등등)을 설정하거나 각종 다양한 조건에 따라 구현하기가 불편합니다.
이에 비해 puppet은 우리가 쉘스크립트에서 쓰는 것과 같이 다양한 조건을 손쉽게 코드에 구현할 수 있습니다. 템플릿 기능이 매우 유용한데요. 코드를 인프라로 관리해야 한다고 하지요. 예를 들어 acl 설정을 apache, iptables 등에서 사용할 경우 해당 acl설정을 변수로 따로 빼놓고 apache acl, iptables acl은 템플릿으로 구현을 해 놓습니다. 그러면 만약 acl하나를 업데이트할 경우 자동으로 apache 설정파일을 변경하고 apache 재시작, iptables 설정을 업데이트하고 iptables 재시작하는 것이 자동으로 이루어집니다. 이 acl은 tcp-wrapper 에도 템플릿으로 구현했다면 이것도 자동으로 업데이트가 되겠지요. 동일한 소스에서 가져오는 설정을 개별로 따로따로 관리할 경우에는 불가능한 이야기입니다.
slack 은 cfengine, puppet 과는 성격이 좀 다른데요. slack 서버에 설정한 내용은 slack client 가 rsync 기반으로 정보를 가져옵니다. cfengine, puppet 등 일반적인 설정관리툴들이 자체 언어를 지원하는데 slack 은 그렇지는 않고 자기가 모든 것들을 스크립트 등으로 구현해야 합니다. 예를 들어 모든 시스템 설정이 동일한 클러스터링 환경에서 한방에 설정을 하는 경우는 적합할 수 있습니다. 그렇지만 자기가 일일이 스크립트를 관리해야 하고 시스템 환경이 동일하게 아니라 여러가지 복잡하다면 관리하기는 쉽지 않습니다.
어떤 툴을 쓰건 소스는 svn 등의 버전관리 시스템을 통해서 관리해야 하고 commit 을 하기 전 해당 툴의 문법이 맞는지 체크하고 commit 후 관련된 사람들에게 이메일 발송을 통하여 변경사항을 공유하는 것이 필요합니다. 이 부분은 나중에 Version control 이야기 할 때 이야기를 해 보겠습니다.
application service orchestration
- Fabric http://docs.fabfile.org/en/1.5/tutorial.html
- capistrano https://github.com/capistrano/capistrano/wiki
- func https://fedorahosted.org/func/
- ControlTier http://doc36.controltier.org/wiki/ControlTier
원격으로 ssh 하는 기능 같은 것을 명령행에서도 할 수 있고 웹gui에서도 할 수 있습니다. 이건 미리 사전에 해당 명령을 정의해 놓았기 때문이지요. apache 를 예로 들면 사전에 apache 설치, 제거, apache 활성화, apache 비활성화 를 정의해 놓습니다. 그리고나서 controltier 명령을 이용하여 원하는 시스템을 필터링해서 apache를 설치하고 재시작해라 라고 명령을 내릴 수 있습니다.
조금 더 확장을 하면 이런 시나리오도 가능합니다. active/stanby 로 구성된 웹서버가 있고 dbms가 연동되어 있다고 할경우 워크플로우를 만듭니다. stadnby 서버의 apache 가 내려가 있는지 확인한다 -> active 서버에서 apache 내린다 -> DBMS를 내린다 -> DBMS를 올린다 -> standby 서버의 apache 를 올린다
이런 과정을 사람이 수작업으로 하는 것이 아니고 사전에 워크플로우를 정의하여 자동으로 처리하는 것입니다.
이런 것을 명령어로도 할 수 있고 GUI에서 클릭클릭하여 할 수도 있습니다. 시스템에 대해서 잘 모르는 사람이라도 명령어를 몰라도 웹화면보고 apache를 설치한다, apache를 활성화한다는 누구나 쉽게 할 수 있지요.
이러한 workflow 툴과 system configuration 툴을 조합하면 더 많은 자동화 작업이 가능할 것이라 판단이 됩니다. - mcollective http://www.puppetlabs.com/mcollective/introduction/
이 툴은 puppet 만든 곳에서 함께 만든 것입니다. puppet은 중앙에서 시스템 설정을 가져와 적용하는 시스템이라면 Mcollective는 병렬 ssh 툴이나 애플리케이션 배포쪽에 더 가깝습니다.
Mcolective 사이트를 보면 Publish Subscribe Middleware 기술을 쓴다고 나옵니다. 이 부분은 MQ라고 하는 기능을 이용하는 것인데요 저도 이 기술에 아직 익숙하지 않지만 개발쪽 하시는 분들은 많이 접하는 기술일 겁니다. (RabbitMQ, AcitveMQ 등의 오픈소스 프로그램이 있음)
예를 들어 apache 가 돌아가고 있는 시스템을 찾아보자고 Mcollective 서버에 질의를 하면 Mcollective 서버는 브로드캐스팅으로 요청을 보냅니다. 그러면 Mcollective 서버에 가입되어 있는 모든 시스템에서 이 요청을 받고 자기가 여기에 해당하면 Mcollective 서버로 응답을 해 줍니다. Mcollective 서버는 이러한 응답을 모아서 레포팅을 해 줍니다.
병렬 ssh 툴의 경우 멀티스레드를 이용하고 요청을 분산시킨다고 하더라도 이런 작업을 처리해야하고 다시 결과를 모아야합니다. 시스템규모가 커지면 어찌되었건 결과모으기가 쉽지 않습니다. Mcollective 는 각 시스템에 대한 요청과 응답받고 하는 부분을 MQ 기능을 이용하여 분산처리하는 것입니다. 시스템 규모가 커지면 MQ서버를 좀 더 늘리고 MQ 서버에 대한 failover 구성 등을 통하여 장애가 나도 상관없이 결과를 받을 수 있도록 구성하는 것이 가능합니다. - Configuration management & Orchestration tools