Linux 서버를 운영하다 보면 동일한 작업을 여러 서버에 반복해야 하는 경우가 많습니다. 서버가 한 대라면 직접 SSH로 접속해 명령어를 실행해도 큰 문제가 없습니다. 하지만 운영 서버가 10대, 50대, 100대로 늘어나면 모든 서버에 접속하여 동일한 작업을 반복하는 것은 매우 비효율적입니다.
예를 들어 새로운 사용자 계정을 50대의 서버에 생성해야 한다고 가정해 보겠습니다. 관리자가 서버마다 SSH로 접속하여 useradd 명령어를 실행하고, 비밀번호를 설정하고, sudo 권한을 부여하는 방식은 시간이 오래 걸릴 뿐만 아니라 실수할 가능성도 높습니다.
이러한 문제를 해결하기 위한 대표적인 자동화 도구가 Ansible입니다.
Ansible은 하나의 관리 서버에서 여러 대의 Linux 서버를 동시에 관리할 수 있도록 도와주는 자동화 도구입니다. 사용자는 YAML 형식의 설정 파일인 Playbook을 작성하고, Ansible은 이를 기반으로 여러 서버에 동일한 작업을 수행합니다.
이번 글에서는 Ansible의 기본 구조부터 Inventory, Module, Playbook, YAML, 변수, 조건문, 반복문, Handler, Role의 개념과 실제 Linux 서버 자동화 방법까지 실무 중심으로 알아보겠습니다.
Ansible은 서버 구성 관리와 반복 작업 자동화를 위한 도구입니다.
일반적인 서버 관리 방식은 다음과 같습니다.
관리자
|
+-- SSH --> Server01
|
+-- SSH --> Server02
|
+-- SSH --> Server03
서버가 많아질수록 관리자는 동일한 작업을 여러 번 반복해야 합니다.
Ansible을 사용하면 구조가 다음과 같이 바뀝니다.
Ansible Controller
|
+------------+------------+
| | |
v v v
Server01 Server02 Server03
관리자는 Ansible Controller에서 한 번의 명령을 실행하고, Ansible이 여러 서버에 자동으로 작업을 수행합니다.
대표적인 자동화 작업은 다음과 같습니다.
사용자 생성
패키지 설치
서비스 시작 및 중지
설정 파일 배포
디렉터리 생성
파일 복사
방화벽 설정
서버 상태 확인
로그 관리
보안 정책 적용
Ansible의 중요한 특징 중 하나는 일반적으로 Agentless 방식이라는 점입니다.
많은 관리 도구는 각 서버에 별도의 Agent 프로그램을 설치해야 합니다.
하지만 Ansible은 일반적으로 SSH를 통해 관리 대상 서버에 접속합니다.
Ansible Controller
|
| SSH
|
+------> Linux Server 01
|
+------> Linux Server 02
|
+------> Linux Server 03
따라서 관리 대상 서버에는 일반적으로 다음 환경이 필요합니다.
SSH 접속 가능
Python 실행 환경
자동화 대상 계정
적절한 권한
관리 서버에서 여러 대상 서버를 중앙 집중적으로 관리할 수 있다는 점이 Ansible의 큰 장점입니다.
Rocky Linux 계열 환경에서는 설치 방법이 환경에 따라 달라질 수 있지만 기본적으로 패키지 관리자를 이용하여 설치할 수 있습니다.
예를 들어 다음과 같이 설치할 수 있습니다.
sudo dnf install ansible
설치 후 버전을 확인합니다.
ansible --version
Ansible이 정상적으로 설치되었다면 버전과 Python 환경 등의 정보가 표시됩니다.
실무에서는 Ansible을 설치한 서버를 Ansible Controller 또는 Control Node라고 부릅니다.
자동화 대상 서버는 일반적으로 다음과 같이 부릅니다.
Managed Node
Managed Host
Target Server
Ansible에서 어떤 서버를 관리할 것인지 정의하는 파일을 Inventory라고 합니다.
예를 들어 다음과 같은 서버가 있다고 가정해 보겠습니다.
web01 192.168.10.11
web02 192.168.10.12
db01 192.168.10.21
이를 Inventory 파일에 다음과 같이 작성할 수 있습니다.
[web]
192.168.10.11
192.168.10.12
[db]
192.168.10.21
여기서 [web]과 [db]는 서버 그룹입니다.
구조를 그림으로 표현하면 다음과 같습니다.
Inventory
|
+-- web
| +-- 192.168.10.11
| +-- 192.168.10.12
|
+-- db
+-- 192.168.10.21
서버를 역할별로 그룹화하면 자동화 작업을 훨씬 쉽게 관리할 수 있습니다.
예를 들어 웹 서버에만 Nginx를 설치하거나 데이터베이스 서버에만 PostgreSQL을 설치할 수 있습니다.
Inventory 파일을 지정하여 등록된 서버를 확인할 수 있습니다.
예를 들어 inventory.ini 파일이 있다면 다음과 같이 확인합니다.
ansible-inventory -i inventory.ini --list
서버 연결 여부를 간단하게 테스트하려면 ping 모듈을 사용할 수 있습니다.
ansible all -i inventory.ini -m ping
정상적으로 연결되면 다음과 비슷한 결과가 표시됩니다.
192.168.10.11 | SUCCESS => {
"changed": false,
"ping": "pong"
}
여기서 중요한 점은 Linux의 일반적인 ICMP Ping 테스트가 아니라 Ansible이 SSH로 접속하여 정상적으로 작업을 수행할 수 있는지 확인하는 테스트라는 것입니다.
Ansible에서 실제 작업을 수행하는 기능 단위를 Module이라고 합니다.
예를 들어 다음과 같은 작업을 생각해 볼 수 있습니다.
파일 복사
사용자 생성
패키지 설치
서비스 시작
디렉터리 생성
방화벽 설정
Ansible은 이러한 작업을 각각 Module로 제공합니다.
대표적인 Module은 다음과 같습니다.
ping
command
shell
copy
file
user
group
dnf
service
systemd
template
firewalld
예를 들어 모든 서버의 사용자 정보를 확인하려면 다음과 같이 사용할 수 있습니다.
ansible all -i inventory.ini -m command -a "id"
웹 서버에 Nginx를 설치할 수도 있습니다.
ansible web -i inventory.ini -b -m dnf -a "name=nginx state=present"
하지만 서버 관리 작업이 복잡해질수록 명령어를 직접 실행하는 방식보다 Playbook을 사용하는 것이 좋습니다.
Ansible Playbook은 자동화 작업의 절차를 YAML 파일로 작성한 것입니다.
예를 들어 웹 서버에 Nginx를 설치하고 서비스를 시작하는 작업을 생각해 보겠습니다.
일반적인 수동 작업은 다음과 같습니다.
1. 서버 접속
2. 패키지 설치
3. 서비스 시작
4. 서비스 자동 시작 설정
5. 방화벽 설정
Ansible Playbook에서는 이 과정을 하나의 YAML 파일로 정의할 수 있습니다.
---
- name: Install Nginx
hosts: web
become: true
tasks:
- name: Install Nginx package
dnf:
name: nginx
state: present
- name: Start Nginx service
systemd:
name: nginx
state: started
enabled: true
이 파일을 nginx.yml로 저장한 뒤 실행합니다.
ansible-playbook -i inventory.ini nginx.yml
그러면 Inventory의 web 그룹에 등록된 모든 서버에 동일한 작업이 수행됩니다.
Ansible Playbook은 YAML 형식을 사용합니다.
YAML에서 가장 중요한 것은 들여쓰기입니다.
예를 들어 다음 구조를 살펴보겠습니다.
- name: Web Server Setup
hosts: web
become: true
tasks:
- name: Install Nginx
dnf:
name: nginx
state: present
YAML에서는 일반적으로 탭(Tab) 대신 공백을 사용합니다.
들여쓰기가 잘못되면 Playbook 실행 오류가 발생할 수 있습니다.
따라서 Ansible을 사용할 때는 복잡한 Shell 명령어를 외우는 것만큼 YAML의 계층 구조를 이해하는 것이 중요합니다.
여러 서버에서 같은 작업을 수행하면서 값만 다르게 설정해야 하는 경우 변수를 사용할 수 있습니다.
예를 들어 사용자 이름을 변수로 정의할 수 있습니다.
---
- name: Create User
hosts: all
become: true
vars:
username: sysadmin
tasks:
- name: Create user
user:
name: "{{ username }}"
state: present
이 방식의 장점은 사용자 이름이 변경되더라도 Playbook 전체를 수정할 필요가 없다는 것입니다.
변수 변경
↓
Playbook 자동 반영
↓
여러 서버에 동일하게 적용
실무에서는 서버 환경에 따라 개발 서버, 테스트 서버, 운영 서버의 값을 다르게 관리할 수도 있습니다.
Ansible의 반복문을 사용하면 여러 사용자를 한 번에 생성할 수 있습니다.
---
- name: Create Multiple Users
hosts: all
become: true
vars:
users:
- admin01
- admin02
- developer01
tasks:
- name: Create users
user:
name: "{{ item }}"
state: present
loop: "{{ users }}"
구조는 다음과 같습니다.
users
|
+-- admin01
+-- admin02
+-- developer01
Ansible이 각 항목을 하나씩 반복하면서 모든 사용자 계정을 생성합니다.
Ansible에서는 특정 조건에서만 작업을 수행하도록 설정할 수 있습니다.
예를 들어 Rocky Linux 계열 서버에서만 특정 작업을 수행할 수 있습니다.
- name: Install package
dnf:
name: nginx
state: present
when: ansible_facts['os_family'] == "RedHat"
조건문은 다음과 같은 상황에서 유용합니다.
운영체제별 다른 설정
서버 역할별 다른 작업
특정 서비스가 존재하는 경우
환경 변수에 따른 설정
운영 서버와 개발 서버 구분
조건문을 사용하면 하나의 자동화 코드를 여러 환경에서 재사용하기 쉬워집니다.
시스템 엔지니어가 Ansible을 사용하는 대표적인 작업 중 하나가 설정 파일 배포입니다.
예를 들어 Nginx 설정 파일을 여러 서버에 배포할 수 있습니다.
- name: Copy Nginx Config
copy:
src: nginx.conf
dest: /etc/nginx/nginx.conf
owner: root
group: root
mode: '0644'
수동 작업에서는 서버마다 파일을 복사해야 합니다.
관리자
|
+-- nginx.conf --> web01
|
+-- nginx.conf --> web02
|
+-- nginx.conf --> web03
Ansible을 사용하면 한 번의 Playbook 실행으로 모든 웹 서버에 배포할 수 있습니다.
설정 파일을 변경한 경우에만 서비스를 재시작하고 싶은 경우가 있습니다.
이때 사용하는 것이 Handler입니다.
예를 들어 Nginx 설정 파일을 변경했을 때만 Nginx를 재시작하도록 구성할 수 있습니다.
---
- name: Configure Nginx
hosts: web
become: true
tasks:
- name: Deploy Nginx config
copy:
src: nginx.conf
dest: /etc/nginx/nginx.conf
notify:
- Restart Nginx
handlers:
- name: Restart Nginx
systemd:
name: nginx
state: restarted
동작 과정은 다음과 같습니다.
설정 파일 변경
|
v
notify 실행
|
v
Handler 호출
|
v
Nginx 재시작
반대로 설정 파일에 변경 사항이 없다면 불필요한 서비스 재시작을 하지 않습니다.
이는 운영 환경에서 매우 중요한 기능입니다.
여러 서버에 동일한 패키지를 설치하는 작업도 Ansible로 쉽게 처리할 수 있습니다.
- name: Install packages
dnf:
name:
- nginx
- vim
- curl
- rsync
state: present
여러 대의 서버에서 동일한 기본 운영 환경을 구성할 때 매우 유용합니다.
예를 들어 신규 서버가 추가되었을 때 다음과 같은 작업을 자동으로 수행할 수 있습니다.
기본 사용자 생성
↓
필수 패키지 설치
↓
SSH 설정
↓
방화벽 설정
↓
모니터링 Agent 설치
↓
서비스 시작
Ansible에서는 systemd Module을 사용하여 서비스를 관리할 수 있습니다.
예를 들어 Nginx 서비스를 시작하고 부팅 시 자동으로 실행하도록 설정할 수 있습니다.
- name: Start Nginx
systemd:
name: nginx
state: started
enabled: true
서비스를 재시작하려면 다음과 같이 작성합니다.
- name: Restart Nginx
systemd:
name: nginx
state: restarted
실무에서는 Nginx뿐 아니라 다음과 같은 서비스를 자동으로 관리할 수 있습니다.
sshd
nginx
httpd
postgresql
mariadb
redis
docker
prometheus
grafana-server
Ansible의 강력함은 여러 작업을 하나의 Playbook으로 연결할 수 있다는 것입니다.
예를 들어 새로운 웹 서버를 구축한다고 가정해 보겠습니다.
1. 사용자 생성
2. 패키지 업데이트
3. Nginx 설치
4. 설정 파일 배포
5. 서비스 시작
6. 방화벽 설정
이를 자동화하면 다음과 같은 형태가 됩니다.
---
- name: Web Server Setup
hosts: web
become: true
tasks:
- name: Update packages
dnf:
name: "*"
state: latest
- name: Create admin user
user:
name: webadmin
state: present
- name: Install Nginx
dnf:
name: nginx
state: present
- name: Deploy index page
copy:
src: index.html
dest: /usr/share/nginx/html/index.html
- name: Start Nginx
systemd:
name: nginx
state: started
enabled: true
관리자는 다음 명령어 한 번으로 웹 서버 환경을 구성할 수 있습니다.
ansible-playbook -i inventory.ini webserver.yml
Playbook이 많아지고 규모가 커지면 하나의 파일에 모든 내용을 작성하기 어려워집니다.
예를 들어 다음과 같은 구조를 생각해 볼 수 있습니다.
server.yml
|
+-- 사용자 생성
+-- 패키지 설치
+-- Nginx 설정
+-- PostgreSQL 설정
+-- 방화벽 설정
+-- 모니터링 설정
서버 구성 작업이 많아질수록 Playbook은 복잡해집니다.
이때 작업을 역할별로 분리하는 것이 Role입니다.
예를 들어 다음과 같이 구성할 수 있습니다.
roles/
├── common/
├── nginx/
├── postgresql/
├── docker/
└── monitoring/
각 Role은 자신의 역할에 필요한 파일과 작업을 관리합니다.
예를 들어 Nginx Role은 다음과 같이 구성할 수 있습니다.
roles/
└── nginx/
├── tasks/
├── handlers/
├── templates/
├── files/
├── vars/
└── defaults/
이렇게 구성하면 코드의 재사용성과 유지보수성이 크게 향상됩니다.
Role을 사용하면 메인 Playbook을 매우 간단하게 만들 수 있습니다.
---
- name: Configure Web Server
hosts: web
become: true
roles:
- common
- nginx
- monitoring
동작 구조는 다음과 같습니다.
Main Playbook
|
+-- common Role
|
+-- nginx Role
|
+-- monitoring Role
이러한 구조는 실제 기업 환경에서 Ansible 프로젝트를 관리할 때 매우 많이 사용됩니다.
Ansible을 이해할 때 중요한 개념 중 하나가 Idempotency, 즉 멱등성입니다.
쉽게 말하면 같은 Playbook을 여러 번 실행해도 원하는 상태가 유지되는 특성입니다.
예를 들어 다음 작업을 보겠습니다.
dnf:
name: nginx
state: present
첫 번째 실행에서는 Nginx가 설치됩니다.
두 번째 실행에서는 이미 설치되어 있으므로 다시 설치하지 않습니다.
첫 번째 실행
Nginx 없음
↓
설치
↓
changed
두 번째 실행
Nginx 있음
↓
변경 없음
↓
ok
이러한 특성 때문에 Ansible은 단순히 명령어를 반복 실행하는 도구보다 서버의 원하는 상태를 관리하는 데 적합합니다.
Ansible을 학습할 때는 다음과 같은 프로젝트를 직접 만들어 보는 것이 좋습니다.
호스트 이름 설정
시간대 설정
관리자 계정 생성
sudo 권한 설정
기본 패키지 설치
SSH 설정 파일 배포
Root 로그인 제한
SSH 키 설정
방화벽 설정
sshd 재시작
Nginx 설치
설정 파일 배포
웹 페이지 배포
서비스 시작
자동 시작 설정
방화벽 설정
PostgreSQL 설치
데이터 디렉터리 설정
서비스 시작
계정 생성
데이터베이스 생성
백업 스크립트 배포
Docker 설치
Docker Compose 설치
서비스 시작
애플리케이션 파일 배포
Container 실행
Bash와 Ansible은 경쟁 관계가 아닙니다.
두 기술은 서로 다른 영역에서 사용됩니다.
Bash
|
+-- 서버 내부 작업 자동화
+-- 로그 분석
+-- 파일 처리
+-- 백업
+-- 시스템 점검
Ansible
|
+-- 여러 서버 중앙 관리
+-- 패키지 설치
+-- 설정 파일 배포
+-- 사용자 관리
+-- 서비스 구성
실제 운영 환경에서는 두 기술을 함께 사용하는 경우가 많습니다.
예를 들어 Ansible로 여러 서버에 백업 Shell Script를 배포하고, 각 서버에서는 Cron이 해당 Script를 정기적으로 실행하도록 구성할 수 있습니다.
Ansible
|
+-- Server01 --> backup.sh
|
+-- Server02 --> backup.sh
|
+-- Server03 --> backup.sh
각 서버의 Cron
|
v
정해진 시간에 backup.sh 실행
Ansible을 익힌 이후에는 자동화 범위를 더욱 넓힐 수 있습니다.
Linux
↓
Bash
↓
Shell Script
↓
Cron
↓
Ansible
↓
Git
↓
CI/CD
↓
Docker
↓
Kubernetes
↓
Terraform
↓
Cloud
Ansible은 서버 내부의 설정을 자동화하는 데 강력합니다.
반면 Terraform은 클라우드 인프라 자체를 생성하고 관리하는 데 적합합니다.
예를 들어 다음과 같은 구조를 만들 수 있습니다.
Terraform
|
v
AWS EC2 생성
|
v
Ansible
|
v
Linux 서버 설정
|
v
Docker 설치
|
v
Application 배포
이러한 구조는 현대적인 Infrastructure as Code 환경의 대표적인 형태입니다.
Ansible은 시스템 엔지니어가 여러 Linux 서버를 효율적으로 관리하기 위한 매우 중요한 자동화 도구입니다.
서버가 한두 대일 때는 직접 SSH로 접속하여 작업할 수 있습니다. 하지만 서버 수가 증가할수록 수동 작업은 시간과 비용이 증가하고 설정 오류의 가능성도 높아집니다.
Ansible을 이용하면 다음과 같은 작업을 코드로 관리할 수 있습니다.
Inventory
↓
관리 대상 서버 정의
↓
Module
↓
개별 작업 수행
↓
Playbook
↓
자동화 절차 정의
↓
Variables
↓
환경별 설정 관리
↓
Loop / When
↓
반복 및 조건 처리
↓
Handler
↓
변경 시 서비스 제어
↓
Role
↓
대규모 프로젝트 구조화
시스템 엔지니어가 반드시 익혀야 할 핵심 Ansible 기술을 정리하면 다음과 같습니다.
1. Inventory 구성
2. SSH 기반 서버 연결
3. Module 사용
4. YAML 문법
5. Playbook 작성
6. 변수 관리
7. 조건문과 반복문
8. 파일 배포
9. Handler
10. Role 구조화
Ansible을 제대로 활용하면 서버 관리 방식은 크게 달라집니다.
기존에는 다음과 같은 방식이었다면,
서버 접속
↓
명령어 실행
↓
다음 서버 접속
↓
동일 작업 반복
Ansible을 사용하면 다음과 같이 바뀝니다.
Playbook 작성
↓
Git으로 코드 관리
↓
Ansible 실행
↓
여러 서버 자동 구성
↓
동일한 환경 유지
결국 Ansible의 핵심은 단순히 여러 서버에서 명령어를 실행하는 것이 아닙니다. 서버의 설정과 운영 절차를 사람이 기억하는 방식에서 코드로 관리하는 것입니다.
이 과정을 익히면 Linux 서버를 수동으로 관리하는 시스템 엔지니어에서 벗어나, 여러 서버의 구성과 운영 환경을 자동화하고 표준화할 수 있는 엔지니어로 발전할 수 있습니다.