참고 : terraform & Ansible외의 도구 개념 및 관계 - 1

안녕하세요!! 하씨가문의 영광입니다

그동안 Terraform 과 Ansible에 대해서 자세히 알아보았는데요. 

IaC 종류에는 이들외에도 여러 도구들이 존재합니다! 

그래서 2번에 걸쳐!! Terraform 과 Ansible외의 도구들에 대해서 알아보는 시간을 가져보도록 하겠습니다 

그럼 출발해볼까요? 

 

Puppet

Puppet은 Ruby로 만들어진 시스템 관리 자동화 툴입니다.

주로 설정, 관리 배포, Orchestrate와 같은 일을 하기위해 사용됩니다.

 

**Ruby : 단순함과 생산성에 초점을 둔 동적 오픈소스 프로그래밍 언어입니다. 자연스럽게 읽히고 쓰기 쉬운 우아한 문법을 가지고 있습니다.

 

Puppet을 사용하는 이유로는 반복되는 업무를 자동화하기 위함입니다.

예를 들어 패키지를 5개의 서버에 설치해야한다면,  5번의 반복되는 작업을 하여 손쉽게 할 수 있습니다.

하지만 만약 100개 이상의 서버에 같은 작업을 해야한다면..... 음...집에 못갈지도 모릅니다. ㅜㅜ

 

이러한 이유로, 인프라 DevOps 엔지니어가 집에 갈수있도록 조직의 업무를 자동화하기 위해 많이 사용합니다.

 

Puppet 주요 특징

Master Agent Pull 기반

시스템 관리 툴은 Pull기반과 Push 기반으로 나뉩니다.

여기서 Puppet은 Pull기반 툴이며, Master - Agent로 구성됩니다.

 

Puppet처럼 시스템을 관리할 수 있는 툴 중에 Push Base 툴은 대표적으로 Ansible이 있습니다.

용어나 그림에서 알 수 있듯이 Pull Base는 Master에게 요청해서 작업을 해야하는 업무이고, Push Base는 Master가 직접 작업을 하달합니다.

 

Puppet은 각각 관리하는 서버에 Agent설치가 필요합니다.(이것도 Agentless인 Ansible과 또다른점이죠!)

Agent는 default 1800초마다 Master에게 필요한 변경사항을 확인하고 반영합니다.

 

Agent 서버는 Linux, Window, Solaris 등 대부분의 OS를 지원하지만, Master 서버의 경우, Linux서버 위에 설치되어야합니다.

 

DSL 제공, Declarative(선언형)

Puppet은 DSL(Domain Specific Language)을 제공하고 declarative(선언형) 프로그래밍을 지원합니다.

 

**Imperative vs Declarative**

Imperative : 모든 작업과정을 일일히 작업해주는 것

Declarative : 정의한 내용대로 작업하는것

 

Declarative(선언형)한 프로그래밍은 Imperative한 프로그래밍 보다 가용성이 높은 상태로 사용이 가능합니다.

즉! Puppet은 미리 정의한 resource를 기반으로 자체 언어를 제공하여 긴 스크립트를 적은 내용으로 구현이 가능합니다.

 

멱등성

작업을 여러 번 수행해도 항상 결과가 같은 성질을 의미합니다.

앞에서 다루었듯이 Provision이나 자동화의 개념에서 매우 중요한 성질입니다.

 

Puppet 작업 흐름

관리자는 Master에 접속해서 Agent에 반영 할 Puppet code를 작성합니다.

 

Puppet code 작성이 완료되면, Agent가 Master와 통신할 수 있도록 Secure certificates를 정의하고 Puppet master는 8140포트(Puppet master server) 를 개방하여 통신이 가능하도록 합니다.

여기까지는 작업을 위한 설정과정이고, Agent가 Master에게 변경작업이 필요한지 확인할 때 아래 흐름대로 작업이 이루어집니다.

 

1. 통신이 정의되었다면 Agent는 master에게 agent host의 전반적인 정보인 Fact 정보(hostname, kernal detail, ip address 등)를 보낸다.

 

2. Puppet은 이러한 Fact정보를 이용해서 Agent에 반영되어야할 설정 목록인 Catalog(패키지 제어, 계정 제어, 시스템 재시작 등)를 컴파일하고 Agent는 받은 Catalog를 기반으로 변경사항을 반영한다.

 

3. Agent는 이후 master에게 변경 결과 여부를 보고하는 Report를 보낸다.

 

참고자료 : https://myjamong.tistory.com/243

 

 

Chef

 

Chef는 Configuration Management에 사용되는 도구로 Puppet과 밀접하게 경쟁하고 있습니다.

시스템 구성을 작성하기 위해 Ruby와 DSL(Domain-Specific language)을 사용합니다.

 

Internap, Amazon EC2, Google Cloud Platform, OpenStack, SoftLayer, Microsoft Azure 및 Rackspace와 같은 클라우드 기반 플랫폼과 통합하여 새 머신을 자동으로 프로비저닝하고 구성할 수 있습니다.

 

또한!! Chef는 인프라 관련 설정 및 설치 등을 코드로 형상관리 해주는 프레임 워크로 생각하면됩니다.

Bash Script는 애플리케이션 설치에 대한 예외처리를 하나하나 모두 신경써야 합니다.

반면, Chef는 전문적인 형상관리 도구이므로 제공되는 기능이 다양하므로 Bash Script의 단점을 보완할 수 있습니다.

 

Chef는 전통적으로 리눅스를 관리하기 위해 사용이 되었으나, 이후의 버전들은 MS Windows도 지원하고 있습니다.

 

Chef 구성요소

CookBook

• 노드에 적용할 인프라 설정 및 소프트웨어 설치를 가지고 있는 코드이다.
• recipe, resource definition, attribute, library, cookbook file, template file, metadata의 모음이다.
• cookbook은 Chef에서 공유되고 분배의 단위이다.
• Chef를 사용하는 대부분은 Cookbook를 쓰는 일이다.

 

Run list

• Node에서 실행될 Cookbook(recipe)의 목록이다.

 

Roles

• Node에서 실행될 Cookbook(recipe)의 묶음이다.

 

Data Bag

• Chef Server에 저장되는 key/value 형식의 데이터 저장소, data bags의 데이터는 모든 Cookbook에서 전역변수처럼 사용할 수 있다.

 

Chef의 아키텍처

 

Master - Agent로 구성된 Puppet과 비교하자면 Chef는 Client - Server 로 구성되어있습니다. 그러나, Chef에는 Workstation이라는 추가 구성 요소가 있습니다.

 

Chef Workstation

• Chef 사용자가 구성을 생성, 테스트 및 적용할 수 있는 로컬 개발 플랫폼이며, 로컬 데스크톱, Chef DK가 설치된 랩탑이 될 수 있다.
• 프로덕션으로 승격하기 전에 개발/테스트 환경으로 사용할 수 있습니다.

 

Chef Server

• Chef-Server 소프트웨어가 설치되고 구성되어 있는 서버입니다.
• Chef의 코드를 관리하고 Chef Workstation에서 구성 코드에 액세스 하는 작업을 담당합니다.
• Chef서버는 Linux 시스템이어야 하며 다른 운영 체제는 지원하지 않습니다.

 

Chef Client

• 셰프 코드 및 바이너리의 기타 종속 파일과 같은 구성 세부 정보를 위해 셰프 서버에 접속하는 서버가 있습니다.
• Chef 서버에서 코드를 가져와 로컬로 배포합니다.

 

지금까지 Puppet & Chef에 대해 알아보았습니다.

다음에는 또다른 IaC 도구들에 대한 내용을 가져올예정이니 많이 기대해주세요~!