Ansible이란 — 에이전트 없는 자동화
Ansible은 서버 구성·배포·운영 작업을 코드(YAML)로 선언해 여러 서버에 일관되게 적용하는 자동화 도구입니다. 가장 큰 특징은 에이전트리스(agentless) — 대상 서버에 별도 데몬을 설치하지 않고, SSH와 Python만 있으면 동작합니다.
- 멱등성(idempotency): 같은 플레이북을 몇 번 돌려도 결과가 동일합니다. "이미 원하는 상태면 건드리지 않음".
- 선언형: "무엇을 어떤 상태로" 기술하면 Ansible이 현재 상태와 비교해 필요한 변경만 수행합니다.
- 푸시 방식: 제어 노드에서 대상 노드로 SSH를 통해 명령을 밀어 넣습니다.
셸 스크립트는 "실행할 명령의 나열"이라 두 번 돌리면 부작용이 생기기 쉽습니다. Ansible 모듈은 대부분 멱등해서 반복 실행이 안전합니다 — 이것이 셸 스크립트 대신 Ansible을 쓰는 핵심 이유입니다.
설치
제어 노드(작업을 지시하는 내 머신/관리 서버)에만 설치하면 됩니다.
# Ubuntu / Debian
sudo apt update && sudo apt install -y ansible
# RHEL / CentOS / Rocky
sudo dnf install -y ansible-core
# pip (버전 고정이 필요할 때)
python3 -m pip install --user ansible
ansible --version대상 서버에는 SSH 접속과 Python 3만 준비되어 있으면 됩니다.
인벤토리 — 관리 대상 정의
인벤토리는 "어떤 서버들을 어떤 그룹으로 관리할지" 적는 파일입니다.
# inventory.ini
[web]
web1 ansible_host=10.0.0.11
web2 ansible_host=10.0.0.12
[db]
db1 ansible_host=10.0.0.21
[prod:children] # web + db를 묶는 상위 그룹
web
db
[all:vars]
ansible_user=deploy
ansible_ssh_private_key_file=~/.ssh/deploy.pem연결이 되는지 먼저 ping 모듈로 확인합니다(ICMP가 아니라 SSH+Python 확인).
ansible -i inventory.ini all -m ping
# web1 | SUCCESS => { "ping": "pong" }Ad-hoc 명령 — 플레이북 없이 한 줄로
간단한 일회성 작업은 -m(모듈) -a(인자)로 바로 실행합니다.
# 전체 서버 uptime 확인
ansible -i inventory.ini all -a "uptime"
# web 그룹에 패키지 설치 (권한 상승 -b = become)
ansible -i inventory.ini web -b -m apt -a "name=nginx state=present"
# 서비스 재시작
ansible -i inventory.ini web -b -m service -a "name=nginx state=restarted"플레이북 — 작업을 파일로 선언
플레이북은 여러 작업(task)을 순서대로 정의한 YAML입니다.
# site.yml
- name: 웹 서버 구성
hosts: web
become: true # sudo로 실행
vars:
doc_root: /var/www/app
tasks:
- name: Nginx 설치
apt:
name: nginx
state: present
update_cache: true
- name: 문서 루트 디렉터리 생성
file:
path: "{{ doc_root }}"
state: directory
owner: www-data
mode: "0755"
- name: 설정 파일 배포
template:
src: nginx.conf.j2
dest: /etc/nginx/sites-available/app.conf
notify: reload nginx # 변경 시에만 핸들러 호출
handlers:
- name: reload nginx
service:
name: nginx
state: reloaded실행 전 문법 점검과 드라이런(변경 미리보기)을 습관화하세요.
ansible-playbook -i inventory.ini site.yml --syntax-check
ansible-playbook -i inventory.ini site.yml --check --diff # 드라이런
ansible-playbook -i inventory.ini site.yml # 실제 적용자주 쓰는 모듈
| 모듈 | 용도 |
|---|---|
apt / dnf / package | 패키지 설치·제거 |
service / systemd | 서비스 시작·중지·활성화 |
copy / template | 파일 배포(정적 / Jinja2 템플릿) |
file | 디렉터리·권한·심볼릭 링크 |
lineinfile / blockinfile | 설정 파일 일부 수정 |
user / group | 계정 관리 |
git | 저장소 체크아웃 |
command / shell | 임의 명령(멱등하지 않으니 최소화) |
command/shell은 Ansible이 상태를 판단할 수 없어 매번 "changed"로 잡힙니다. 꼭 필요할 때는 creates=/removes= 인자나 changed_when으로 멱등성을 직접 부여하세요.
핸들러와 멱등성
핸들러는 변경이 실제로 발생했을 때만 실행되는 특수 작업입니다. 설정 파일이 바뀌었을 때만 서비스를 리로드하는 패턴에 씁니다. notify로 호출하고, 여러 작업이 같은 핸들러를 notify해도 플레이 마지막에 한 번만 실행됩니다.
같은 플레이북을 두 번 돌려 보면 두 번째 실행은 대부분 changed=0이어야 합니다. 이것이 제대로 된 멱등 플레이북의 신호입니다.
롤(Role) — 재사용 가능한 구조로 분리
프로젝트가 커지면 작업을 롤 단위로 나눕니다. 표준 디렉터리 구조를 따르면 Ansible이 자동으로 파일을 인식합니다.
roles/
nginx/
tasks/main.yml # 작업
handlers/main.yml # 핸들러
templates/ # Jinja2 템플릿
defaults/main.yml # 기본 변수(낮은 우선순위)
vars/main.yml # 변수(높은 우선순위)ansible-galaxy init roles/nginx # 롤 뼈대 생성# site.yml — 롤 사용
- hosts: web
become: true
roles:
- nginx
- { role: app, tags: ["deploy"] }실전 팁
--limit으로 범위 축소:ansible-playbook site.yml --limit web1— 한 서버만 먼저 검증.--tags/--skip-tags: 큰 플레이북에서 배포 부분만 실행.- Vault로 비밀 관리:
ansible-vault encrypt secrets.yml로 암호·키를 암호화해 저장하고--ask-vault-pass로 복호화. ansible.cfg로 기본값 고정: 인벤토리 경로, become 여부, SSH 옵션을 매번 타이핑하지 않도록.
# ansible.cfg
[defaults]
inventory = ./inventory.ini
host_key_checking = False
retry_files_enabled = FalseAnsible은 "실행 스크립트"가 아니라 "원하는 상태의 선언"으로 사고를 바꾸면 훨씬 강력해집니다. 작은 ad-hoc 명령부터 시작해, 반복되는 작업을 플레이북으로, 재사용할 것을 롤로 승격시키는 순서로 익히면 자연스럽게 규모를 키울 수 있습니다.
이 가이드는 AI 도구를 활용해 초안을 구성하고 사람이 명령어·문맥을 검토해 발행했습니다. 운영체제와 도구 버전에 따라 결과가 달라질 수 있으므로 적용 전 공식 문서를 함께 확인하세요. 오류를 발견하시면 이메일로 제보해 주세요.
질문 & 답변 (Q&A)
이 가이드에 대해 궁금한 점을 질문해보세요. 확인 후 답변드립니다.