Ansible: 에이전트 없이 완성하는 자동화

** 서종호(가시다)님의 On-Premise K8s Hands-on Study 2주차 학습 내용을 기반으로 합니다. ** 

 

오늘은 Ansible에 대해서 이야기해보려고 한다. 스터디를 하면서 처음 들었다. 공부를 하고 느낀 점은, 이거 엣지 디바이스 관리하는데 꽤 괜찮게 사용할 수 있겠다는 생각을 좀 했다. 

 

아무튼 Ansible에 대해서 공부해보자.

 

Ansible이란?

공식 홈페이지에서 Ansible을 아래와 같이 설명하고 있다.

Ansible is open-source technology that can perform virtually any IT task and remove complexity from workflows.

Code that reads like documentation
Ansible is an automation language that can describe any IT environment, whether homelab or large scale infrastructure. It is easy to learn, beautiful code that reads like clear documentation.

Freedom from repetitive tasks
As an automation engine, Ansible ensures that your IT environment stays exactly as you describe it, no matter the complexity. Not only that, you can automate any command with Ansible to eliminate drudgery from your daily routine. Ansible gives you tooling to be more productive and solve problems that really matter.

 

거의 모든 IT 작업들을 실행할 수 있는 오픈소스라고 한다. 그래서 무엇을 자동화하는 거냐? 가령 이런 식이다. 하나의 마스터 노드가 있다고 하면, 이 마스터 노드가 관리하고 있는 관리 노드들이 있는데, 이 관리 노드들에 원하는 작업을 실행시킬 수 있다. 이를 SSH 기반으로 작동시킨다. 즉, 마스터 노드에서 관리 노드들을 SSH로 접근하여 원하는 작업을 실행시켜 작동시키는 것이다. 마스터 노드는 Ansible에서는 컨트롤 노드라고 한다.

 

Ansible 구성 요소

Ansible에서 중요한 구성 요소들은 아래와 같다.

• 컨트롤 노드 & 관리 노드
• 인벤토리
• 플레이북
• 모듈
• 핸들러
• 플러그인
• 롤

컨트롤 노드 & 관리 노드

하나하나 알아보자. 컨트롤 노드는 Ansible이 설치되어 있는 서버로, 관리 노드에 명령어를 보내는 역할을 한다. 관리 노드는 관리 노드에 의해 명령이 실행되는 Slave 같은 역할을 한다. 이 글의 제목에 "에이전트 없이"라고 했는데, 관리 노드에는 Ansible을 위한 어떠한 에이전트도 설치하지 않는다. 즉, "엇, 에이전트가 설치가 안되서요.. 아 에이전트랑 통신이 안되서요.." 이런 문제는 없다는 것이다. 그러면 어떻게 명령을 넘기냐? 그래서 SSH를 기반으로 움직인다고 하는 것이다.

$ ssh root@tnode1 ls -al /home/tnode-1/workspace
total 28
drwx------  5 root root 4096 Jan 14 01:49 .
drwxr-xr-x 23 root root 4096 Oct 24 07:40 ..
drwx------  3 root root 4096 Jan 14 01:49 .ansible
-rw-r--r--  1 root root 3106 Apr 22  2024 .bashrc
drwx------  2 root root 4096 Jan 14 00:51 .cache
-rw-r--r--  1 root root  161 Apr 22  2024 .profile
drwx------  2 root root 4096 Oct 24 07:42 .ssh

컨트롤 노드에서 tnode1이라고 하는 관리 노드에 대해서 ls 명령어 실행할 수 있다. 이것을 생각해보면, "아 저거 어떻게 잘 구조 작성해서 만들면 자동화 툴을 만들 수 있겠구나? 그게 Ansible이구나" 라고 생각할 수 있다. 자 백문이 불여일견, 일단 마스터 노드에 설치부터 해보자

$ pip3 install ansible

 

인벤토리

컨트롤 노드가 관리할 관리노드를 나열해둔 곳이다. 

[web]
tnode1 ansible_python_interpreter=/usr/bin/python3
tnode2 ansible_python_interpreter=/usr/bin/python3

[db]
tnode3 ansible_python_interpreter=/usr/bin/python3

[all:children]
web
db

위에서 [web], [db]는 그룹을 명시해둔 부분이다. tnode1~3은 IP 주소여도 되는데, /etc/hosts에 저장되어 있는 이름으로 바꿔쓴 것 뿐이다. 

 

플레이북

자, 이제 인벤토리를 통해 관리 노드들을 설정했으니, 관리 노드들에게 명령어를 실제로 실행하도록 해보자. 명령어를 실행하게 하기 위해서는 플레이북이라는 것을 만들어야 한다. 보통 yml 파일을 통해 만든다.

# check-os.yml
---
- hosts: all
  vars:
    supported_distros:
      - Ubuntu
      - CentOS

  tasks:
    - name: Print supported os
      ansible.builtin.debug:
        msg: "This {{ ansible_facts['distribution'] }} need to use apt"
      when: ansible_facts['distribution'] in supported_distros

위 yml 파일을 보면 알겠지만, Ansible에서 해석할 수 있는 key 들을 알아야 작성할 수 있다. 위 yml 파일을 해석해보면, supported_distros에는 Ubuntu와 CentOS가 있는데, 관리 노드가 Ubuntu이거나 CentOS라면 (when) debug 메세지로 "This {{ ansible_facts['distribution'] }} need to use apt"를 출력하라고 하는 것이다. 실행해 보면 아래와 같은 결과를 얻을 수 있다.

root@server:~/my-ansible# ansible-playbook check-os.yml

PLAY [all] **********************************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] **********************************************************************************************************************************************************************************************************************
ok: [tnode3]
ok: [tnode2]
ok: [tnode1]

TASK [Print supported os] *******************************************************************************************************************************************************************************************************************
ok: [tnode1] => {
    "msg": "This Ubuntu need to use apt"
}
skipping: [tnode3]
ok: [tnode2] => {
    "msg": "This Ubuntu need to use apt"
}

PLAY RECAP **********************************************************************************************************************************************************************************************************************************
tnode1                     : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
tnode2                     : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
tnode3                     : ok=1    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0

보면 tnode3은 스킵된 것을 확인할 수 있다. tonde3은 RedHat 계열이다. 

 

모듈 & 핸들러

Ansible에서 모듈은 관리 노드들에서 실행되는 작은 프로그램이다. Ansible의 모듈들은 수천개가 있다고 한다. 대표적으로 위에 check-os.yml에서 ansible.builtin.debug는 debug를 실행하는 빌트인 프로그램이라고 보면 된다. 

핸들러는 특정 플레이북의 테스크가 실행되어 관리 노드의 상태를 바꾸었을 때만 실행되는 조금 특별한 테스크라고 보면 된다.

예를 들어 특정 서버의 conf 파일이 변경되면 재시작을 해야 하는데, 이 과정에서 재시작이 핸들러를 통해 작성될 수 있다.

# handler-example.yml
---
- name: Deploy application and restart service
  hosts: webservers
  become: true  # Escalate privileges to root

  tasks:
    - name: Copy new configuration file
      ansible.builtin.copy: # Using the fully qualified collection name is a best practice
        src: files/myapp.conf
        dest: /etc/myapp/myapp.conf
        mode: '0644'
      notify:
        - Restart myapp service

  handlers:
    - name: Restart myapp service
      ansible.builtin.systemd_service: # Example using systemd service module
        name: myapp
        state: restarted
      listen:
        - "Restart myapp service" # Optional: Can use 'listen' for multiple notifications