IT Risk & Control

Chef vs Puppet

Barram 2020. 10. 31. 00:50

IT 보안팀과 함께 회사내 시스템 베이스라인 관리활동관리 활동(baseline management)과 데브옵스(DevOps)에 관련된 회의를 하던 중 CHEF와 puppet 이야기가 나왔다. IT 감사/통제활동 관리에 관한 업무를 해왔었지만 시스템관리에 관련된 일을 해본 적이 없어서 CHEF와 puppet이 다소 생소한 개념으로 다가왔다.  기본적인 개념을 이해하기 위해 인터넷을 검색하면서 배운 내용을 아래와 같이 정리해본다.

 

규모가 제법 큰 회사들은 다양한 시스템환경과 복잡한 네트워크 구조를 가지고 있다. 원도우 서버 플랫폼에 응용프로그램 (애플리케이션)이 돌아가는 클라이언트/서버 환경이 일반적인 환경이지만 필요에 따라서 유닉스(UNIX)/리눅스 (RHEL) 플랫폼 또는 마이크로 소프트 SQL 서버 플랫폼등을 이용할 수도 있다. 이렇게 다양한 시스템환경에서 서버를 관리하는 시스템 관리자 입장에서 다수의 시스템이 동시다발적으로 문제를 일으킨다면 그리 간단한 문제가 아니다. 이를 해결하기 위해 서버 설계, 설치, 환경설정 및 관리를 자동화시켜주는 인프라 구성관리도구 (Configuration management tool)가 이용된다. 이 도구를 이용하면 시스템관리자는 최적의 시스템환경설정을 정의하는 코드 (Code)를 만들어준 다음 각각의 서버에 어떻게 그 환경을 설정하는지에 대한 지시를 푸쉬만 해주면 된다. 이런 활동을 도와주는 자동화툴로는 쉐프(CHEF), 퍼펫 (puppet), 앤서블 (ansible) 그리고 솔트스택 (salt stack) 등이 있다.

 

셰프 (CHEF)

쉐프 (CHEF)는 일일히 수작업으로  인프라 리소스(Infrastructure resource)를 설정/관리하는 대신  코드(code)를 이용하여 이러한 활동을 자동화시키는 구성관리도구 (configuration management tool)이다.  시스템이용자는 루비 (Ruby)라는 특정영역 언어 (domain-specific language- DSL) 코딩을 통해 스크립트를 만들어서 본인이 설계하고자 하는 시스템 환경을 정의할 수 있다. 이것을  레서피(recipe)라고 한다. 그리고 다양한 시스템 환경을 고려한 레서피들를 모아서 필요한 상황에 따라 각기 다른 레서피를 쓸 수 있도록 쿡북(cookbook)을 만들기도 한다. 만일 시스템이 문제를 일으킨다면 필요한 레서피를 찾아서 적용만 시켜주면 되므로 시스템 관리자는 매우 효율적으로 시스템 에러/실패 상황에 대처할 수 있다.

 

 쉐프 (CHEF)는  인프라스트럭쳐 (infrastructure)를 코드로 변환시켜 관리할 수 있도록 해주는 자동화 도구이기 때문에 "Infrastructure as a code"라고 불리기도 한다. 시스템관리정책 및 환경설정 (policies and configuration)을 코드로 전환시켜주고 이 코드들을 지속적으로 테스트해주면서 쉐프를 통해 배포하여 시스템이 최적의 환경을 유지하도록 해주므로 주로 데브옵스 (DevOps)에서 자주 이용된다.

 

셰프(CHEF)의구성요소

  • 레시피(recipe): 시스템 구성설정 및 업데이트를 위해 코딩으로 스크립트 제작. 인터넷 커뮤니티에서 루비를 이용한 레서피를 만드는 사례를 쉽게 찾을 수 있다
  • 나이프 (Knife): 레서피와 서버시스템 간 커뮤니케이션을 하는데 이용되는 명령문 ( command)
  • 쿡북 (Cookbook): 다양한 시스템환경을 지원하고 위해 다수의 레서피가 준비되는데 이를 모아 하나의 쿡북을 만든다. 쿡북은 다양한 레서피를 준비하는데 있어서 일관성 유지 및 회사시스템정책을 준수하는데 도움을 준다.
  • 노드(Node):  애플케이션 서버, 클라이언트, 네트워크장비 등 회사 네트워크에 연결된 컴퓨터 장비를 말한다. 오하이(Ohai)라는 유틸리티툴이 노드의 현 시스템 설정을 불러오면 쉐프 클라이언트 (Chef client)는 쿡북에 있는 레서피를 이용해 노드의 환경설정을 해준다.

쉐프(Chef)를 이용한 아키텍쳐 (Architecture)

셰프(Chef)를 이용한 아키텍처 (Architecture)

 

위 그림에서 볼 수 있듯이 시스템관리자는 자신의 로컬 워크스테이션 (local worksation)에서 각각의 노드에 필요한 시스템 환경설정을 코딩하여 레서피형태로 저장한다. 각각의 레서피는 쿡북(cookbook)에 저장되며 쉐프 서버를 통해 노드에 적용/배치된다. 기업조직이 성장해가면서 요구되는 시스템 확장, 패치, 업그레이드는 레서피를 변경/업그레이드함으로써 보다 신속하고 안정적으로 관리할 수 있게 된다. 또한 레서피의 버전 관리를 통해 새로운 시스템에 문제가 발생시 바로 이전 시스템환경으로 돌아가는데 용이하다 (rollback). 쉐프 서버에 있는 다수의 레서피들과 쿡북을 업데이트/관리하는데는 주로 나이프(Knife)를 이용하게 된다. 또한 각각의 노드에 있는 시스템의 현재 환경설정상태 (current state)를 상시적으로 파악하는 것 역시 쉐프 아키텍쳐에서 중요한 부분중 하나이다. 이를 위해 오하이(ohai)라는 노드에 설치된 유틸리티를 통해 노드의 시스템 상태를 확인하고 쉐프 서버에 있는 쿡북의 레서피를 이용해 시스템 설정을 노드에 적용시키게 된다. 만일 업데이트된 레서피의 시스템 설정 적용이 실패하게 되면 쿡북에 저장되었던 이전상태의 시스템환경으로 노드를 설정해주게 된다. 시스템 관리자는 이에 대한 시스템 공지 (automatic notification)을 받게 되고 실패한 노드에 대해 수작업으로 업데이트를 해주면 된다.  물론 이것은 쉐프 아키텍쳐에서 흔치 않은 경우일테지만 말이다.

 

셰프의강점과 주요이용고객

  • Microsoft Azure, Amazon E2C, Internap, SoftLayer, Rackspace와 같은 클라우드기반 플랫폼과 쉽게 통합 가능하며 새로운 기기의 구성도 가능
  • 셰프 이용자 커뮤니티를 통한 지식공유
  • AIX, RHEL/CentOS, Solaris, Ubuntu와 같은 모든 리눅스/유닉스 플랫폼 지원 가능
  • 주요 이용고객: Mozilla, Facebook, Xero, Expedia, Rackspace

 

퍼펫트(puppet)

페펫트 역시 쉐프와 마찬가지로 다수의 서버플랫폼을 코딩을 통해 관리하는 Infrastructure as a code 서비스를 제공하는 구성 관리 도구 (configuration management tool)이다. 쉐프에서 제공하는 서비스와 마찬가지로 네트워크에 연결된 노드가 의도된 상태의 구성설정이 되어 있는지 확인하고 코드를 이용해 시스템 업데이트 또는 애플리케이션 배포/배치작업을 하게 된다.  또한 특정한 노드만을 선택하여 애플리케이션 배포를 할 수 있다.  기능적인 면에서 퍼펫트는 쉐프와 동일한 기능을 수행한다고 볼 수 있다. 하지만 퍼펫트를 이용한 아키텍쳐에서 차이가 드러난다.

 

퍼펫트의 구성요소

  • 퍼펫트의 구성요소는 크게 퍼펫트 서버(puppet server)와 페펫트 클라이언트(puppet client)로 이루어진다. 우선 퍼펫트 서버의 구성요소에 대해 자세히 알아보자.
    • 페펫트 매스터 (puppet master):  시스템 구성관리목록 (Manifest), 템플릿 (template), 파일 (file)로 이루어진 시스템 주요 구성관리 파일(main configuration files)을 포함하고 있다.
    • 시스템 구성관리목록 (Manifest): 실제 퍼펫트 클라이언트의 구성을 설정하는 코드. 셰프와 마찬가지로 루비(ruby)라는 언어를 이용한다.
    • 템플릿 (Template): 코드를 수집하고 문서화한 자료
    • 파일 (File): 실제 배포되어지는 컨텐트(content). 시스템 업데이트/애플리케이션 배포를 위해 실제 클라이언트에 다운로드하는 파일을 말한다.
    • 그리고 이 세가지를 총칭하여 "모듈 (module)"이라고 부른다.
    • 이러한 모듈에는 인증서 (certificate authority)가가 적용되어 클라이언트가 매스터에 의해 인증된 모듈 및 파일을 이용하고 다운로드받도록 확인시켜준다.
  • 퍼펫트 클라이언트: 환경설정의 대상이 되는 컴퓨팅 기계/디바이스를 일컫는다.
    • 에이전트(Agent): 매스터서버와 지속적으로 인증확인을 위해 교신하는데 이용된다.
    • 팩터 (factor): 클라이언트 현재 구성설정정보를 모아서 매스터서버로 보내주는 역할을 한다.

퍼펫트(puppet)를   이용한   아키텍쳐

퍼펫트를 이용한 아키텍쳐

퍼펫트는 구성요소에서 말했듯이 마스터와 슬래이브 아키텍쳐 (master-slave architecture)이다. 회사이다.회사 내 네트워크에 분산되어있는 클라이언트는 에이전트를 통해 아래 기술된 방식으로 마스터 서버와 지속적으로 상호교신한다.

  1. 에이전트가 클라이언트의 기기 ID와 함께 인증서 (certificate)를 매스터 서버에 보내면 마스터 서버는 인증서에 인증사인을 해서 클라이언트에게 회신하게 된다.  이것은 안전하고 (secured) 상호확인된 (verifiable) 파일/정보교환을 위한  인증프로세스 (authentication process)이다.
  2. 마스터서버와 클라이언트 간 상호 인증이 이루어지면 클라이언트는 현재 구성설정정보를 알려주는 팩트(fact)를 마스터 서버에 보낸다. 
  3. 마스터서버는 클라이언트가 보낸 팩트를 이용하여 시스템 업데이트 목록 (manifest)를 카탈로그로 만든 다음 각각의 클라이언트로 보내주게 된다. 
  4. 클라이언트의 에이전트는 카탈로에 있는 시스템 업데이트 목록을 수행하여 시스템 업데이트 및 애플리케이션 배치를 하게된다.
  5. 업데이트 및 배치가 끝난 후 에이전트는 마스터서버에 보고서를 보내 클라이언트에 설치된 소프트웨어에 대한 최신정보를 업데이트시켜준다.

퍼펫트의 강점과 주요이용고객

 

  • 퍼펫트은 Microssoft Windows Server, CentOS, Linux 또는 Oracle Enterprise와 같이 루비(Ruby)가 설치되어진 다양한 플랫폼에서 운용가능
  • 광범위한 퍼펫트 개발자 커뮤니티와 더불어 위키페이지와 같은 문서화된 지식공유
  • 주요 이용고객: Spotify, Google, Staples, US Air Force, AT&T, AON  
  • 거대한 인프라 (5천개 이상의 기기)상에서 시스템/애플리케인 배치 가능

 

마치며.

시스템 관리자가 아닌 IT 리스크/통제활동 관리자로서 셰프와 퍼펫트에 대한 기본개념을 정리해보았다. 필자가 잘못된 내용을 기술한 것이 있으면 지적해주시면 감사하겠다. 정보를 읽고 번역하고 쓰면서 느낀 건데 정보기술을 다루는 글쓰기는 정말 쉽지 않다는 것을 깨달았다. 나름 이해했다고 생각하고 글을 쓰기 시작했는데 겨우겨우 어렵게 마무리하는 것을 보니 아직 이해가 부족하다는 생각이 든다. 종종 시간 나는 대로 계속 이 글을 업데이트해보겠다.

 

글을 쓸 때 이용한 자료 목록

1. JanBask Training, "Chef vs puppet: Difference between which one is best", www.janbasktraining.com/blog/chef-vs-puppet/ (10/30/2020)

2. "Chef & puppet", en.wikipedia.org/wiki/Main_Page (10/30/2020)

3. Simplilearn, "What is Chef in DevOps?", Youtube (10/30/2020)

4. Simplilearn, "what is puppet? How puppet works?", Youtube (10/30/2020)