서버가 10대로 늘어나면 어떻게 되나요. 한 대씩 SSH로 접속해 똑같은 명령을 반복합니다. 한 대는 설정이 빠지고, 다른 한 대는 오타가 납니다. 나중에는 어느 서버가 어떤 상태인지 아무도 모르게 됩니다. Ansible은 이 문제를 “원하는 상태를 코드로 선언”하는 방식으로 해결합니다. 이 글에서는 Ansible playbook으로 VPS 초기 세팅 전체를 자동화하는 실전 가이드를 다룹니다.
Ansible이란 — 선언적·에이전트리스·멱등성
Ansible은 선언적 구성 관리 도구입니다. “명령을 어떤 순서로 칠까”가 아니라 “서버가 이 상태여야 한다”를 YAML 파일로 적습니다. 그러면 Ansible이 현재 상태를 확인하고 필요한 변경만 적용합니다.
세 가지 핵심 특성:
- 선언적(declarative): “nginx를 설치해”가 아니라 “nginx가 설치되어 있어야 해”로 적습니다. W28 셸 스크립팅의 명령형(imperative) 접근과의 가장 큰 차이입니다.
- 에이전트리스(agentless): 대상 서버에 에이전트를 설치할 필요가 없습니다. SSH만 열려 있으면 됩니다. 배울 것도 관리 포인트도 적습니다.
- 멱등성(idempotency): 같은 playbook을 여러 번 실행해도 결과가 항상 같습니다. 셸 스크립트는 두 번 실행하면 패키지가 중복 설치되거나 설정이 꼬일 수 있지만, Ansible은 이미 원하는 상태면 아무것도 하지 않습니다.
1. inventory 파일 — 대상 서버 정의
먼저 어느 서버에 적용할지 적은 hosts.ini를 만듭니다.
# hosts.ini
[web]
web1 ansible_host=203.0.113.10
web2 ansible_host=203.0.113.11
[db]
db1 ansible_host=203.0.113.20
[all:vars]
ansible_user=deploy
ansible_ssh_private_key_file=~/.ssh/id_ed25519서버를 역할별 그룹(web, db)으로 묶습니다. 그룹별로 다른 playbook을 적용할 수 있습니다. 연결을 확인합니다:
ansible all -i hosts.ini -m ping
# web1 | SUCCESS => {"changed": false, "ping": "pong"}
# web2 | SUCCESS => ...
# db1 | SUCCESS => ...SSH 키가 설정되어 있어야 합니다(W22 방화벽/SSH 보안 참고).
2. playbook YAML 구조
playbook은 “어느 호스트 그룹에 어떤 작업을 적용할지”를 정의합니다.
# setup.yml
- name: VPS 초기 세팅
hosts: all
become: yes # sudo 권한
vars:
deploy_user: deploy
ssh_port: 22
tasks:
- name: 시스템 패키지 최신화
apt:
update_cache: yes
upgrade: dist
- name: 필수 패키지 설치
apt:
name:
- nginx
- ufw
- fail2ban
- unattended-upgrades
state: present
- name: deploy 사용자 생성
user:
name: "{{ deploy_user }}"
shell: /bin/bash
groups: sudo
append: yes
- name: 방화벽 활성화
ufw:
rule: allow
port: "{{ item }}"
proto: tcp
loop:
- "22"
- "80"
- "443"
- name: nginx 서비스 시작 + 자동 시작
service:
name: nginx
state: started
enabled: yes실행은 한 줄입니다. 10대든 100대든 같습니다.
ansible-playbook -i hosts.ini setup.yml3. 멱등성 실전 — 두 번 실행해도 안전
위 playbook을 두 번 실행하면 어떻게 될까요. Ansible은 각 작업(task)마다 현재 상태를 먼저 확인합니다. 이미 패키지가 설치되어 있으면 ok, 변경이 필요하면 changed를 보고합니다.
PLAY RECAP ***
web1 : ok=8 changed=3 unreachable=0 failed=0 # 첫 실행
web1 : ok=8 changed=0 unreachable=0 failed=0 # 두 번째 실행두 번째 실행에서 changed=0인 것이 핵심입니다. 셸 스크립트였다면 패키지 재설치, 사용자 중복 생성 등 사이드 이펙트가 생길 수 있습니다. Ansible은 “이미 원하는 상태”면 손대지 않습니다. 이것이 멱등성입니다.
4. role 구조로 재사용하기
playbook이 길어지면 role로 분리합니다. role은 “특정 역할을 수행하는 작업 묶음”입니다.
# role 생성
ansible-galaxy init common
ansible-galaxy init nginx
ansible-galaxy init security
# 디렉터리 구조
roles/
common/
tasks/main.yml # 사용자 생성, 패키지 설치
nginx/
tasks/main.yml # nginx 설치 + 설정
templates/nginx.conf.j2
security/
tasks/main.yml # ufw, fail2ban, SSH 강화playbook에서 role을 호출합니다:
- name: VPS 전체 세팅
hosts: all
become: yes
roles:
- common
- security
- nginxW29 Nginx 리버스 프록시 설정을 role로 재작성하면, 새 서버에 Nginx 설정이 필요할 때 이 role만 부르면 됩니다. 재사용성이 극적으로 올라갑니다.
5. 실전 playbook — VPS 초기 세팅 전체를 한 번에
지금까지의 요소를 합치면, 새 VPS를 받자마자 다음을 한 번에 적용할 수 있습니다:
- 사용자 생성 + sudo 권한 + SSH 키 배포
- ufw 방화벽 (22/80/443만 오픈)
- fail2ban으로 SSH 무차별 대입 차단 (W25)
- Nginx 설치 + 기본 사이트 (W29)
- unattended-upgrades로 자동 보안 업데이트
- systemd 서비스 등록 (W24)
전체가 코드로 선언되어 있으니 git에 커밋하면 서버 구성 자체가 버전 관리됩니다. 새 서버가 추가되면 hosts.ini에 한 줄 추가하고 playbook을 다시 실행하면 끝입니다.
Ansible vs 셸 스크립트 — 언제 뭘 쓸까
W28에서 셸 스크립팅으로 VPS 자동화를 다뤘습니다. 그렇다면 Ansible은 언제 필요할까요?
| 구분 | 셸 스크립트 (W28) | Ansible playbook |
|---|---|---|
| 적합 규모 | 1-3대, 일회성 작업 | 3대 이상, 반복·표준화 필요 |
| 멱등성 | 직접 구현해야 | 기본 보장 |
| 상태 관리 | 어느 서버가 어느 상태인지 추적 어려움 | facts + changed/ok 리포트 |
| 학습 비용 | 낮음 (bash) | 중간 (YAML + 모듈) |
한두 대면 셸 스크립트가 빠릅니다. 서버가 늘거나 팀이 커지면 Ansible이 압도적으로 유리합니다.
마무리 — 다음 단계: k3s 클러스터
Ansible playbook으로 서버 구성을 코드로 선언하는 방법을 정리했습니다. 이 패턴은 다음 편에서 다룰 k3s 경량 Kubernetes 설치 자동화에도 그대로 적용됩니다. Ansible role로 k3s를 여러 VPS에 한 번에 설치하는 시나리오까지 이어집니다. VPS 데브옵스 시리즈의 마지막 편을 참고하세요.
VPS 데브옵스 시리즈. 추천 VPS 링크는 설명란에서 확인하세요.
