개요

오픈 소스 IT 자동화 도구로 사용자가 수작업으로 진행하던 프로비저닝, 환경 설정, 애플리케이션 배포 등의 IT 업무를 코드 기반으로 작성하여 여러 환경에 동일하게 적용할 수 있도록 돕는 역할을 수행

• RedHat이 개발하고 관리

특징

• No Agent(Agentless)
  예전에 많이 사용하던 Puppet이나 Chef는 자동화 관리 대상 서버에 별도의 에이전트를 설치하고 이를 통해 자동화 업무를 수행했는데, 이러한 데몬 형식의 에이전트에 기반한 자동화 도구는 관리를 위한 복잡한 추가 작업이나 운영체제 버전에 따라 추가 패키지나 모듈을 설치하는 등의 작업이 발생한다.
  반면, Ansible은 별도의 Agent 설치 없이 SSH로 접속해서 Python Code를 수행한다.

• Idempotent(멱등성)
  멱등성 : 동일한 연산 또는 작업을 여러 번 수행하더라도 결과가 달라지지 않는 성질
  Ansible을 통해 동일한 운영 작업을 여러 번 수행해도 동일한 결과를 만들어 낸다.

• 쉬운 사용법과 다양한 모듈 제공
  자동화 단계는 에디터만 있으면 YAML 문법을 사용하여 쉽게 작성하고 읽을 수 있다. 파일 복사와 같은 일반 시스템 관리 모듈부터 다양한 환경의 퍼블릭 클라우드 관련 모듈 및 컬렉션까지 제공한다. 또한 playbook 샘플을 찾아보기 쉽다.

용도

• 시스템 환경 설정
• 애플리케이션 설치
• 퍼블릭이나 프라이빗 클라우드 시스템의 가상 서버 생성
• 매일 점검해야 하는 시스템의 상태 체크
  즉, 여러 시스템에 동일한 작업을 해야 하는 상황에 주로 이용한다.

사용 가능한 운영체제

• Linux
• Mac OS
• BSD 계열의 유닉스
• WSL을 지원하는 윈도우
  
  

공식 깃허브 : https://github.com/ansible
공식 문서 : https://docs.ansible.com/ansible/latest/index.html

Ansible Architecture

*Community Ansible과 Red Hat Ansible Automation Platform의 차이는 RDS 유형을 고를 때 Aurora Postgresql과 일반 Postgresql의 차이와 유사하다고 생각하면 된다.

1. Community Ansible

오픈 소스 형태

• 제어 노드와 관리 노드라는 두 가지 유형의 시스템으로 구성되어 있다.
• Ansible은 제어 노드에 설치되어 실행되고 Ansible이 실행되기 위해서는 python이 기본적으로 설치되어 있어야 한다.
• Ansible 안에는 다양한 모듈과 플러그인이 함께 설치되어 있으며 Ansible이 관리하는 노드 정보를 저장하고 있는 인벤토리와 관리 노드에서 수행할 작업 절차가 작성되어 있는 playbook이 존재한다.

컴포넌트

• 제어 노드
  • ansible이 설치되는 노드
  • 리눅스 운영체제가 설치된 컴퓨터라면 제어 노드가 될 수 있음
  • ansible은 파이썬 모듈을 이용하므로 ansible을 설치하고 실행하려면 파이썬이 설치되어 있어야 함
• 관리 노드
  • ansible이 제어하는 원격 시스템 또는 호스트
  • 관리 노드는 리눅스가 설치된 노드일 수도 있고 윈도우가 설치된 노드일 수도 있음
  • public cloud나 private cloud의 가상 서버도 가능
  • 별도의 에이전트를 설치하지는 않지만 관리노드는 제어노드와 SSH 통신이 가능해야 함
• Inventory
  • 제어노드가 제어하는 관리노드의 목록을 나열해 놓은 파일
  • ansible은 인벤토리에 사전에 정의되어 있는 관리노드에만 접근 가능
• Module
  • ansible은 관리 노드의 작업을 수행할 때 SSH를 통해 연결한 후 ansible module이라는 스크립트를 push해서 작동
  • 대부분의 모듈은 원하는 시스템 상태를 설명하는 매개변수를 허용하며 모듈 실행이 완료되면 제거됨
• Plugin
  • ansible의 핵심 기능을 강화하는 역할을 수행
  • 모듈이 대상 시스템에서 별도의 프로세스로 실행되는 동안 플러그인은 제어 노드에서 실행됨
  • ansible의 핵심 기능(데이터 변환, 로그 출력, 인벤토리 연결 등)에 대한 옵션 및 확장 기능을 제공
• Playbook
  • ~~
  • 관리 노드에서 수행할 작업들을 YAML 문법을 이용해서 순서대로 작성해 놓은 파일
  • ansible은 playbook을 활용하여 관리노드에 SSH로 접근해 작업을 수행

2. Red Hat Ansible Automation Platform

레드햇 서브스크립션을 이용

• 주요 컴포넌트는 Community Ansible과 동일
• 커뮤니티 앤서블과 다르게 인벤토리, 제어노드에 대한 인증 정보, 실행 환경 등을 관리하는 CMDB(Configuration Management DataBase)가 존재
• 자원들을 관리하는 관리 웹 UI가 존재하면 REST API도 제공
• 사용자가 외부에서 작성한 내용을 앤서블 관리 웹 UI를 통해서 가져올 수 있음
• 3가지 필수 컴포넌트와 1가지 옵셔널 컴포넌트로 구성됨

컴포넌트

• 오토메이션 컨트롤러 : 앤서블 타워로 불리우던 관리 웹 UI
• 실행 환경 : 앤서블 모듈과 플러그인이 존재하는 컨테이너 기반의 실행환경
• PostgreSQL : 인벤토리, 인증정보, 실행환경 등의 메타데이터를 관리하는 CMDB
• 오토메이션 허브(옵션) : 레드햇에서 기술 지원을 받을 수 있는 컬렉션 제공 서비스

구성에 따른 아키텍쳐

• All in One : 하나의 노드에 필수 컴포넌트를 전부 구성
• AAP using External DB : PostgreSQL을 별도의 노드로 그리고 오토메이션 컨트롤러와 실행 환경은 동일한 노드로 구성
• Private Automation HUB : AAP using External DB와 동일한 아키텍쳐에 오토메이션 허브를 내부에서 사용할 수 있도록 별도의 노드로 구성한 것으로 인터넷이 되지 않는 환경에서 주로 사용함

Ansible 설치

1. 제어노드에 ansible 설치

• 파이썬이 설치되어 있는지 확인 후 설치되어 있지 않으면 설치

# 확인
python --version
# >> Python 3.12.3

• ansible 설치

sudo apt update
apt install -y ansible 
# 또는
yum install -y ansible

# 확인
ansible --version

• ansible에 관련된 설정은 /etc/ansible이라는 디렉토리를 이용한다.
  • 환경 설정 파일 : ansible.cfg
  • 인벤토리 설정 : hosts

mkdir /etc/ansible
cd /etc/ansible

2. 인벤토리 작성

자동화 대상 호스트 설정 작업

인벤토리 파일은 텍스트 파일이며 앤서블이 자동화 대상으로 하는 관리 호스트를 지정하기 위해 사용한다.
INI 형식(이름=값) 또는 YAML을 포함한 다양한 형식을 이용해서 작성 가능하다.

• IP를 이용해서 인벤토리 파일 작성

192.168.100.5
192.168.100.6
192.168.100.7

• 호스트 이름으로 파일 작성
  이 경우는 /etc/hosts 파일에 호스트 이름이 등록되어 있어야 한다.

192.168.100.5 tnode1.exp.com
192.168.100.6 tnode2.exp.com
192.168.100.7 tnode3.exp.com

• 역할에 따른 호스트 그룹 설정

  • 그룹별 호스트 설정

  [webservers]
  web1.example.com
  web2.example.com
  192.0.2.42
  
  [db-server]
  db01.example.com
  db02.example.com

  • 호스트는 여러 그룹에 속할 수 있음

  [web-servers]
  web1.example.com
  web2.example.com
  192.0.2.42
  
  [db-server]
  db01.example.com
  db02.example.com
  
  [east-datacenter]
  web1.example.com
  db1.example.com
  
  [west-datacenter]
  web2.example.com
  db2.example.com
  
  [development]
  192.0.2.42

  • 중첩 그룹 가능

  [web-servers]
  web1.example.com
  web2.example.com
  
  [db-servers]
  wdb1.example.com
  db2.example.com
  
  [datacenter.children]
  web-servers
  db-servers

• 범위 가능[start:end]

  [web-servers]
  web[1:2].example.com
  
  [defaults]
  192.168.4.[0:255]
  
  [dns]
  [a:c].dns.example.com
  
  [ipv6]
  2001:db8::[a:f]

• EC2의 경우

  [컴퓨터이름] ansible_host=[IP(private IP도 가능)] ansible_user=[계정] ansible_ssh_private_key_file=[pem 파일 경로]

인벤토리 작성을 마쳤으면 인벤토리 파일의 내용을 확인해보자.
ansible-inventory -i 파일경로 --list

3. SSH 접속 설정

3-1. SSH 접속을 할 유저 생성하기(생략 가능)

# 유저 생성
sudo adduser [유저이름]
sudo passwd [유저이름]

# 권한 변경
sudo chmod u + w /etc/sudoers
sudo vi /etc/sudoers

# /etc/sudoers에 하단 내용 추가
유저이름 ALL=(ALL:ALL) ALL
  
# ssh 재시작
sudo service ssh(sshd) restart

이제 생성한 유저를 이용해서 ssh 접속이 가능하다.
하지만 ansible은 비밀번호 입력없이 ssh 접속이 가능해야 한다.

위처럼 ansible의 내장 모듈인 ping을 사용해서 관리 노드가 연결되었는지 확인하려고 하면 SSH 접속을 위한 키 또는 비밀번호가 제공되지 않았기 때문에 인증이 실패했다는 에러가 발생한다.

3-2. 제어노드의 키를 관리노드에 등록하기

# 접속하고자 하는 컴퓨터(제어노드)에서
ssh-keygen
ssh-copy-id [원격서버계정]@[원격서버IP]

ssh-copy-id [원격서버계정]@[원격서버IP]는 어떤 작업을 하는걸까?
ssh-keygen 명령을 통해 생성한 제어 노드의 공개 키(id_rsa.pub)를 읽어서 SSH로 <사용자>@<관리노드>에 접속한 후 그 공개 키를 관리 노드의 ~/.ssh/authorized_keys 파일에 추가하는 작업
=> 그 결과, 제어 노드에서 ssh <사용자>@<관리노드 IP>를 할 때 비밀번호를 입력하지 않고도 접속이 가능해진다.

제어 노드의 공개키를 관리 노드에 등록해줌으로써 제어노드가 관리노드에 비밀번호 없이 접속할 수 있게 되었다.

[EC2의 경우]
EC2의 경우 ssh 접속을 위해 EC2를 생성할 때 지정한 pem 파일이 필요하다. 하지만 pem 파일은 현재 호스트 컴퓨터만에 존재하므로 저장된 pem키를 해당 EC2로 전송해서 사용해야 한다.

• EC2에 파일 전송
  sudo scp -i pem파일경로 전송할파일경로 계정@전송할EC2퍼블릭DNS:복사될경로

4. ansible 모듈을 통해 인벤토리 생성 확인

위에서 수행한 ansible -m ping과 같이 ansible에서 제공하는 모듈을 사용하여 인벤토리가 정상적으로 생성되어 제어노드가 관리노드를 잘 관리할 수 있는지 확인해보자.

ansible 모듈 목록 : https://docs.ansible.com/ansible/2.9/modules/list_of_all_modules.html#

• host 접속 가능 여부 확인 : ansible all -m ping

• 메모리 확인 : ansible all -m shell -a "free -h"

• 파일 복사 : ansible 인벤토리이름 또는 all -m copy -a "src=복사할파일 dest=복사될경로"

• 패키지 설치 : ansible 인벤토리이름 또는 all -m apt -a "name=패키지이름 state=present" -b

Playbook

YAML 포맷으로 작성하고 ansible-playbook 명령으로 실행한다.

사용법

• 작성 : 관리노드에서 수행하고자 하는 작업을 YAML 포맷으로 작성한다.

# first-playbook.yml
---

- hosts: all

  tasks:

    - name: Print Message
      debug:
        msg: Hello Ansible World

• 문법 검사 : ansible-playbook --syntax-check 파일경로

• 실행 : ansible-playbook 파일경로

• 실행 점검: ansible-playbook --check 파일경로
  실행 점검을 통해 관리 대상 호스트를 실제로 변경하지 않고 어떤 내용이 변경될지 미리 알 수 있다.

실습

playbook을 통해 관리노드에 작업을 수행해보자.

• sshd 서비스 재시작

# restart-service.yml
---

- hosts: itstudy

  tasks:

    - name: Restart sshd service

      ansible.builtin.service:

        name: ssh

        state: restarted

ssh.service를 재시작하는 과정에서 연결이 끊겨 버렸기 때문에, 재시작이 실패한 것으로 간주되어 에러가 발생한다.

• 파일 복사
  • copy 모듈을 사용한다.
  • src는 복사할 파일 경로
  • dest는 복사될 디렉토리
  • owner는 파일의 소유자
  • mode는 파일의 권한

- hosts: itstudy
  tasks:
    - name: copying file with playbook
      copy:
        src: ~/sample.txt
        dest: /tmp
        owner: ubuntu
        mode: 0644

• 파일 다운로드

  • get_url 모듈을 사용한다.
  • url에 다운로드 받을 url을 설정
  • dest에 다운로드 경로를 설정

• 파일 관련 명령

  • file 모듈을 사용한다.
  • path에 생성할 파일이나 디렉토리를 설정
  • state에 종류를 설정
  • mode에 파일의 접근 권한을 설정
  • become 과 become_user 는 ansible에서 권한을 변경하고자 할 때 사용하는 속성으로 파일 관련 명령과 자주 쓰인다.
    ex sudo 명령을 사용하고자 하는 경우 become과 become_user를 사용