SaltStack과 Ansible

이동건·2021년 3월 19일

IaC SaltStack ansible

Infra

목록 보기

1/1

Infrastructure as Code

코드형 인프라(IAC)의 정의

오픈소스 구성 관리 업체인 퍼펫(Puppet)의 아키텍처 부사장 나이젤 커스텐은

IAC를 가장 간단히 정의하면 인프라를 마치 소프트웨어처럼 취급할 수 있게 되는 것

이라면서 “가상 API, IaaS, 클라우드 리소스 프로비저닝, 프로비저닝 프로세스를 시작하도록 하드웨어에 프로그램으로 지시하기 등이 모두 IAC”라고 설명했다.

코드형 인프라(IAC)의 특징

- 소프트웨어 시스템처럼 코드를 통해 인프라를 정의하는 접근방식
- 프로비저닝\, 시스템 변경 및 구성에 대한 일관되고 반복적인 과정을 자동화.
- 인프라에 구성 및 변경 사항에 대한 정의를 만든 후에 시스템에 적용

코드형 인프라(IAC) 툴

각 툴에는 자체 도메인 특화 언어(Domain Specific Language, DSL)가 있지만, DSL은 일반적으로 YAML이나 JSON을 기반으로 한다. 예를 들어 테라폼은 해시코프 구성 언어(Hashicorp Configuration Language, HCL)라는 JSON 기반의 자체 DSL을 사용한다.

SaltStack

Saltstack은 대규모 인프라를 관리하기 위한 자동화 관리 시스템이다.

Saltstack의 장점

1. 빠르다. server 와 agent 간 zeromq 를 통해 통신하는데, agent 요청에 대해 비동기 병렬로 처리 하기 때문에 agent가 많아져도 수 초안에 처리가 가능하다.

2. 구조가 심플하다. Server-agent 기반의 매우 단순한 구조이다. 서버의 경우 DB 조차 사용하지 않는다.

3. 풍부한 모듈 지원. 인프라 환경 구성을 위한 거의 대부분의 작업을 지원하는 내장 모듈이 존재한다. 그리고 이를 이용해 다수의 서버를 프로그래머블하게 제어하는게 가능하다. (= Infrastructure as a Code )

Saltstack Architecture

1. Salt-Master

Saltstack에서 Server 역할을 담당한다. Master는 등록된 Minion 에게 명령을 publishing 하고 그 결과를 취합하여 보여주는 역할이다. 1대의 single master가 minion 수천대까지 관리 가능하다.

2. Salt-Minion

Agent의 역할이며, 구성 자동화를 하기 위한 대상 서버에 설치하면 된다. Master의 명령을 기다리고 있다가 명령이 오면 그에 맞춰 작업을 수행하게 된다.
만약, 서버에 minion을 설치하기 어려운 상황이라면 Ansible 처럼 SSH로 명령 push가 가능하게도 지원된다.

3. ZeroMQ

Salt-master와 Salt-minion 간 통신에 ZeroMQ 라는 비동기 메시징 라이브러리를 사용한다.
Salt-master를 설치하면 zeroMQ도 함께 설치 된다. publish Port로 4505 / Return Port 로 4506 을 사용한다. (포트 수정 가능)

Port 4505는 Publisher로서, 모든 salt-minion 들이 명령을 받기 위해 해당 포트를 listening 한다. salt-master는 이 포트를 통해 명령을 전달하며, 모든 minion은 비동기 형태(asynchronous) 로 동시에 명령을 받아 수행하게 된다.
Port 4506은 minion 들이 수행한 작업 결과를 받게 되는 역할로 사용된다. 그리고 결과 리턴 뿐 아니라 minion이 master에게 파일을 요청하거나 minion의 특정 데이터 값(Salt pillar) 을 요청하는 포트로도 사용된다.

Saltstack의 특징

1. Python 기반

Saltstack 자체가 Python 으로 개발되었으며, Saltstack에서 실행되는 모든 명령 실행 코드는 Python 기반의 Module / Function 으로 구현되어 있다.

2. YAML / Jinja2 포맷의 설정 파일

자동화할 작업들을 명세하는 sls 파일들은 YAML 포맷을 기본으로 한다. 또한 template 파일의 경우, 로직에 대한 처리는 Jinja2 template 을 사용한다. Jinja의 경우 기존에 Django나 Flask 같은 프레임워크에서도 많이 사용된 기술이기 때문에 어렵지 않게 사용이 가능하다.

3. ZeroMQ 기반의 메시징 처리

4. AES 암호화 통신

salt-minion 이 master에 처음 등록될때 minion은 master에게 자신의 public key를 전달하게 된다. 그리고 master는 이 public key를 저장하고 해당 minion의 등록을 허락하는 절차를 거치게 된다. 이후 master와 minion은 ZeroMQ를 통해 통신할때 public key와 AES key를 이용해 암호화 되어 통신하게 된다.

Salt Remote Execution

Salt 문법

Salt 기본 문법
- Target
  - Target이 '*'이면 모든 Minion에 전달
  - 각 Minion은 명령을 검사하고 대상과 비교하여 평가하며 명령을 실행할지 여부를 결정
  - 대상 시스템은 명령을 실행한 후 결과를 요청 서버로 리턴
- Module.Function
  - 위의 예제에서는 Module은 test이고 Function은 rand_sleep
  - test Module의 rand_sleep이라는 Function을 실행
- Arguments
  - 실행되는 Module.Function에 인자값을 부여
각 명령은 별도의 Worker 스레드로 분리되어 Minion은 여러 작업을 한번에 처리할 수 있음

SaltStack 설치

SaltStack Architecture

SaltStack은 Master, Minion으로 이뤄져 있다.

– Master
Salt 명령어 실행과 상태등을 관리하는 중앙서버다.
– Minion
Master에 대한 연결을 유지 및 명령을 기다리는 Agent다.

Master와 Minion은 ZeroMQ를 통해 AES 암호화 알고리즘으로 통신을 하며, Minion들을 제어 한다.

saltstack 설치 및 구성

master node:
dg-salt-master: 192.168.0.12

minion node:
dg-salt-minion-1.novalocal: 192.168.0.11
dg-salt-minion-2.novalocal: 192.168.0.5

원격으로 셸 명령 실행

httpd 테스트

sudo salt dg-salt-minion-1.novalocal pkg.install httpd
sudo salt dg-salt-minion-1.novalocal cmd.run 'rpm -q httpd'
sudo salt dg-salt-minion-1.novalocal service.start httpd

sls 파일 쓰기

mkdir -p /srv/salt/apache/files

구성

#apache/install.sls 
apache:
  pkg.installed:
    - pkgs:
      - httpd
      - php
  file.managed:
    - source: salt://apache/files/httpd.conf
    - name: /etc/httpd/conf/httpd.conf
  service.running:
    - name: httpd
    - enable: true
    - watch:
        - file: apache

설정 파일을 이용한 설치

[centos@dg-salt-master files]$ sudo salt dg-salt-minion-1.novalocal state.sls apache.install
dg-salt-minion-1.novalocal:
----------
          ID: apache
    Function: pkg.installed
      Result: True
     Comment: All specified packages are already installed
     Started: 12:16:05.139367
    Duration: 766.88 ms
     Changes:
----------
          ID: apache
    Function: file.managed
        Name: /var/www/html/index.html
      Result: True
     Comment: File /var/www/html/index.html updated
     Started: 12:16:05.909610
    Duration: 27.433 ms
     Changes:
              ----------
              diff:
                  ---
                  +++
                  @@ -1 +1 @@
                  -dg-salt-minion-1.novalocal
                  +hello world!
----------
          ID: /etc/httpd/conf/httpd.conf
    Function: file.managed
      Result: True
     Comment: File /etc/httpd/conf/httpd.conf is in the correct state
     Started: 12:16:05.938215
    Duration: 9.752 ms
     Changes:
----------
          ID: apache
    Function: service.running
        Name: httpd
      Result: True
     Comment: The service httpd is already running
     Started: 12:16:05.948187
    Duration: 73.784 ms
     Changes:

Summary for dg-salt-minion-1.novalocal
------------
Succeeded: 4 (changed=1)
Failed:    0
------------
Total states run:     4
Total run time: 877.849 ms

Grains 구성

Grains는 SaltStack의 미니언 측에 저장되는 SaltStack의 구성 요소입니다.
솔트 미니언이 시작되면 수집 된 데이터가 그레인에 정적으로 저장되고 미니언이 다시 시작될 때만 데이터가 업데이트됩니다.
Grains는 정적 데이터이므로 자주 수정하지 않는 것이 좋습니다.
마스터 측에서 정보보기

salt dg-salt-minion-1.novalocal grains.ls
salt dg-salt-minion-1.novalocal grains.items
salt dg-salt-minion-1.novalocal grains.item ipv4
salt dg-salt-minion-1.novalocal grains.item fqdn

미니언쪽에 Grains 추가

dg-salt-minion-1.novalocal

[centos@dg-salt-minion-1.novalocal~]# vim /etc/salt/minion
129 grains:
130   roles:
131     - apache
[centos@dg-salt-minion-1.novalocal~]# systemctl restart salt-minion

dg-salt-minion-2.novalocal

[centos@dg-salt-minion-2.novalocal~]# vim /etc/salt/minion
129 grains:
130   roles:
131     - nginx
[centos@dg-salt-minion-2.novalocal~]# systemctl restart salt-minion.service

마스터에서보기

salt dg-salt-minion-1.novalocal grains.item roles
salt dg-salt-minion-2.novalocal grains.item roles

Grains 모듈 작성

mkdir /srv/salt/_grains

vim /srv/salt/_grains/mygrains.py

def my_grains():
    grains = {

    }
    grains['salt'] = 'stack'
    grains['hello'] = 'world'
    return grains

Grains 모듈을 미니언 node과 동기화

salt '*' saltutil.sync_grains

미니언 쪽에서 볼 수 있습니다. /var/cache/salt/minion/files/base/_grains/mygrains.py

salt '*' grains.item salt
salt '*' grains.item hello

Grains 매칭 애플리케이션

대상의 미니언 일치

salt -G roles:apache cmd.run hostname
salt -G roles:nginx test.ping
salt -G salt:stack test.ping
salt -G hello:world test.ping

ansible

About Ansible

ansible 은 여러대의 서버를 효율적으로 관리하기 위해 고안된 환경 구성 자동화 도구 중 하나로,
agentless (ssh), 멱등성, 다양한 모듈 지원, 접근 용이성 (python) 등의 특징이 있다.

Ansible의 주요 목표는 단순성과 사용 편의성이다. 또한 보안과 안정성에 중점을 두고 있으며 부품 이동의 최소화, 전달을 위한 OpenSSH의 사용, 프로그램에 익숙하지 않은 사람까지도 이해하기 쉽도록 설계된 언어라는 특징이 있다.

Ansible은 에이전트 없이 시스템을 관리한다. OpenSSH는 가장 많이 검토된 오픈 소스 구성 요소 중 하나이므로 보안 노출이 크게 줄어든다.

Ansible 개념

Control node

Ansible이 설치된 (종류에 상관없이) 모든 시스템

어떤 제어 노드에서든 /usr/bin/ansible 또는 usr/bin/ansible-playbook 호출함으로써 command와 playbook을 실행할 수 있다. Python이 설치돼있다면 어떤 컴퓨터든 컨트롤 노드로 사용될 수 있다. 단, Windows 시스템을 제어 노드로 사용할 수는 없다. 여러 제어 노드를 가지는 것은 가능하다.

Managed nodes

Ansible로 관리하는 네트워크 장치 (and/or servers)

관리되는 노드는 때때로 호스트(host)라고도 한다. 관리되는 노드에 Ansible이 설치 돼있지는 않다.

Inventory

관리되는 노드의 목록

인벤토리 파일은 때때로 호스트 파일이라고도 한다. 인벤토리는 관리되는 노드에 대한 각각의 IP주소와 같은 정보를 지정할 수 있다. 또한 인벤토리는 관리 노드를 구성하여 쉽게 확장 가능하도록 그룹을 만들고 중첩시킬 수 있다.

Modules

Ansible 코드의 실행 단위

각 모듈은 특정 유형의 데이터베이스에서 사용자를 관리하는 것부터 특정 유형의 네트워크 장치에서 VLAN 인터페이스 관리까지 특정한 용도로 사용된다. 작업으로 단일 모듈을 호출하거나, 플레이북에서 여러 다른 모듈을 호출 할 수도 있다.

Tasks

Ansible의 작업 단위

ad-hoc 명령을 사용하여 단일 작업을 한 번 실행할 수 있다.

Playbooks

반복해서 실행하고자 해당 작업을 실행 순서대로 저장해 놓은 정렬된 작업 리스트

플레이북에는 task 뿐만 아니라 변수도 포함될 수 있다. 플레이북은 YAML로 작성돼있으며 읽거나 쓰거나 공유하거나 이해하는데 어렵지 않다.

Ansible Playbook을 통한 Nginx 설치 및 삭제

2대의 Client에 Nginx을 설치하기 위하여 YAML 문법을 통해 Playbook을 작성합니다.

install_nginx.yml 파일에 아래의 YAML 문법으로 Task 및 Handlers를 작성합니다.

---
- hosts: test                                   # Task를 실행할 [Host] or [Host Group] or [All]을 지정합니다.
  remote_user: root                             # Client Server에서 Task를 실행할 User를 지정합니다.
  tasks:
      - name: Install nginx web server          # Task의 이름을 정의합니다.
        yum: name=nginx state=latest            # Task를 통해 작업할 내용을 정의합니다.
        notify:                                 # Task 작업이 완료 된 후 수행할 액션을 handlers를 참조하여 수행합니다.
          - restart nginx
  handlers:
      - name: restart nginx
        service: name=nginx state=restarted     # task의 notify에 name과 동일한 "restart nginx"가 있을 경우 작동하며 Task 작업이 완료된 후 nginx service를 재시작 합니다.

ansible과 saltstack 비교

ansible은 시작하기가 훨씬 쉽습니다 (SSH를 통해 작동하므로 대상 머신에 SSH로 연결할 수 있으면 작동합니다). 그러나 결과적으로 관리하려는 모든 머신에 대해 SSH 연결을 열어야하기 때문에 솔트 스택만큼 확장되지 않는 경향이 있습니다.
이와 대조적으로 Saltstack은 zeromq를 사용하여 미니언과 통신합니다. 미니언은 마스터 (4505)의 하나의 zeromq 포트에서 명령을 수신하고 다른 포트 (4506)를 통해 결과를 반환합니다. 엄청나게 빠르며 확장성이 높습니다.


	ansible	salt
구현 언어	Python	Python
정의 파일	YAML	YAML, 독자 DSL(Python 베이스)
에이전트 설치	Push (AgentLess)	선택가능
Github Star	38k	10k
장점	* 설치 및 설정이 쉽다 * Agentless * 다양한 모듈 지원 * 멱등성 * SSH / winRM 연결 방식은 다른 모델과 비교하여 안전하다	* 확장성과 복원력이 뛰어나다 * 미니언의 사용은 더 많은 옵션과 유연성을 제공 * 에이전트 기반 아키텍처를 통해 Windows 또는 Linux 기반 호스트에 비콘을 배포하고 이벤트를 로컬에서 감지 할 수 있다. * ZeroMQ로 인한 대규모 배포를 위한 고성능
단점	* SSH 통신 속도 * 모니터링 및 API 부족 * 이벤트 기반 자동화 스토리가 없으며 플레이 북 기간 동안 대상 호스트를 제어 할 수 있으며 그게 전부이며 장기 실행 작업을 가질 수 없다	* No GUI

결론 Ansible은 자동화 된 서버 구성 및 배포가 간단하고 빨랐다. SaltStack은 확장성, zeromq를 이용한 속도 및 아키텍처가 뛰어났다. 또한 이벤트를 감지할 수 있다는 점이 장점이었다. 클라우드 배포의 경우 Salt 아키텍처가 더 적합하다고 생각되었다.

이동건

코드를 통한 세계의 창조