Ansible Overview

Agentless/SSH/Push 기반 아키텍처, 핵심 구성요소, Ad-hoc vs Playbook

📚 시리즈 네비게이션

이전	현재	다음
-	Ansible Overview	Playbook

🎯 Ansible이란?

Ansible: 서버 구성 관리, 애플리케이션 배포, 작업 자동화를 위한 Agentless IT 자동화 도구

Red Hat (현 IBM) 소유, 오픈소스 (GPLv3)
Python 기반, YAML로 작업 정의
SSH 기반 통신, 대상 서버에 에이전트 설치 불필요

핵심 철학:

Simple: YAML로 읽기 쉬운 자동화 코드
Agentless: 대상 서버에 Python + SSH만 있으면 됨
Powerful: 수천 대 서버 동시 관리 가능
Idempotent: 여러 번 실행해도 동일한 결과

🏗️ 아키텍처

전체 구조

flowchart TD
    User["운영자"]

    subgraph Control["Control Node"]
        Ansible["Ansible Engine"]
        Inventory["Inventory<br/>(대상 서버 목록)"]
        Playbook["Playbook<br/>(작업 정의 YAML)"]
        Modules["Modules<br/>(실행 단위)"]
    end

    subgraph Managed["Managed Nodes (대상 서버)"]
        S1["Web Server"]
        S2["WAS Server"]
        S3["DB Server"]
    end

    User --> Ansible
    Ansible --> Inventory
    Ansible --> Playbook
    Ansible --> Modules
    Ansible -->|"SSH"| S1
    Ansible -->|"SSH"| S2
    Ansible -->|"SSH"| S3

동작 방식

sequenceDiagram
    participant User as 운영자
    participant Control as Control Node
    participant Managed as Managed Node

    User->>Control: ansible-playbook site.yml 실행
    Control->>Control: Inventory에서 대상 서버 확인
    Control->>Control: Playbook 파싱 (YAML → 실행 계획)
    Control->>Managed: SSH 연결
    Control->>Managed: Python 모듈 전송 (임시)
    Managed->>Managed: 모듈 실행
    Managed->>Control: 실행 결과 반환 (JSON)
    Managed->>Managed: 임시 파일 삭제
    Control->>User: 결과 출력 (ok/changed/failed)

핵심 포인트:

Control Node에서 대상 서버로 SSH를 통해 Python 모듈을 전송
모듈이 대상 서버에서 실행되고 결과를 JSON으로 반환
실행 후 임시 파일 자동 삭제 → 대상 서버에 흔적 없음

🆚 Agentless vs Agent 기반

Agent 기반 (Puppet, Chef)

flowchart LR
    Master["Master Server<br/>(중앙 관리)"]

    subgraph Nodes["Managed Nodes"]
        N1["Server 1<br/>+ Agent"]
        N2["Server 2<br/>+ Agent"]
        N3["Server 3<br/>+ Agent"]
    end

    N1 -->|"Pull (주기적)"| Master
    N2 -->|"Pull (주기적)"| Master
    N3 -->|"Pull (주기적)"| Master

Agentless (Ansible)

flowchart LR
    Control["Control Node<br/>(Ansible)"]

    subgraph Nodes["Managed Nodes"]
        N1["Server 1<br/>(SSH + Python)"]
        N2["Server 2<br/>(SSH + Python)"]
        N3["Server 3<br/>(SSH + Python)"]
    end

    Control -->|"Push (SSH)"| N1
    Control -->|"Push (SSH)"| N2
    Control -->|"Push (SSH)"| N3

항목	Ansible (Agentless)	Puppet/Chef (Agent)
에이전트	불필요	필요 (설치/관리)
통신 방식	Push (SSH)	Pull (Agent → Master)
대상 요구사항	SSH + Python	Agent 데몬
초기 설정	간단	복잡 (Agent 배포)
실행 방식	수동/스케줄	주기적 자동 (15~30분)
상태 유지	실행 시점만	지속적 상태 수렴
보안	SSH 키 기반	Agent-Master 인증서
확장성	수천 대	수만 대

Ansible의 장단점:

장점	단점
에이전트 관리 부담 없음	지속적 상태 수렴 없음 (실행 시점만)
학습 곡선 낮음 (YAML)	대규모 환경에서 SSH 연결 오버헤드
빠른 도입 가능	Windows 지원 제한적 (WinRM)
기존 인프라 변경 없이 적용	실시간 모니터링 없음 (기본)

🆚 자동화 도구 비교

구성 관리 도구 (Configuration Management)

도구	언어	접근 방식	에이전트	선언형/절차형
Ansible	YAML	Push	없음	선언형 (+ 절차형)
Puppet	Puppet DSL	Pull	필요	선언형
Chef	Ruby (DSL)	Pull	필요	절차형
SaltStack	YAML	Push/Pull	선택	선언형

IaC 도구와의 차이

구분	Ansible	Terraform
주 용도	서버 구성/배포	인프라 프로비저닝
대상	OS 내부 (패키지, 설정 등)	인프라 리소스 (VM, 네트워크 등)
상태 관리	없음 (Stateless)	있음 (State File)
멱등성	모듈별 보장	Plan → Apply
실행 방식	절차적 실행 순서	의존성 그래프 기반

💡 Ansible과 Terraform은 경쟁이 아니라 보완 관계. Terraform으로 인프라 생성 → Ansible로 서버 구성하는 조합이 일반적.

flowchart LR
    TF["Terraform<br/>인프라 생성<br/>(VM, 네트워크, SG)"]
    AN["Ansible<br/>서버 구성<br/>(패키지, 설정, 배포)"]
    Result["운영 가능한<br/>서버"]

    TF -->|"VM 생성 완료"| AN -->|"구성 완료"| Result

📦 핵심 구성 요소

1. Inventory

대상 서버 목록을 정의하는 파일.

INI 형식:

# /etc/ansible/hosts 또는 프로젝트별 inventory
 
[web]
web-01 ansible_host=192.168.1.10
web-02 ansible_host=192.168.1.11
 
[was]
was-01 ansible_host=192.168.1.20
 
[db]
db-01 ansible_host=192.168.1.30
 
# 그룹의 그룹
[app:children]
web
was
 
# 그룹 변수
[web:vars]
ansible_user=deploy
ansible_port=22

YAML 형식:

# inventory.yml
all:
  children:
    web:
      hosts:
        web-01:
          ansible_host: 192.168.1.10
        web-02:
          ansible_host: 192.168.1.11
    was:
      hosts:
        was-01:
          ansible_host: 192.168.1.20
    db:
      hosts:
        db-01:
          ansible_host: 192.168.1.30

주요 변수:

변수	설명	기본값
`ansible_host`	접속 IP/호스트명	호스트 이름
`ansible_port`	SSH 포트	22
`ansible_user`	SSH 사용자	현재 사용자
`ansible_ssh_private_key_file`	SSH 키 경로	~/.ssh/id_rsa
`ansible_become`	sudo 사용 여부	false
`ansible_python_interpreter`	Python 경로	/usr/bin/python3

2. Module

Ansible이 대상 서버에서 실행하는 작업 단위.

카테고리	모듈	설명
패키지	`apt`, `yum`, `dnf`	패키지 설치/제거
파일	`copy`, `template`, `file`	파일 복사/생성/권한
서비스	`systemd`, `service`	서비스 시작/중지/활성화
사용자	`user`, `group`	사용자/그룹 관리
명령	`command`, `shell`, `raw`	명령어 실행
네트워크	`firewalld`, `ufw`	방화벽 설정
클라우드	`amazon.aws.`, `azure.`	클라우드 리소스 관리

멱등성 (Idempotency):

# 이 task를 10번 실행해도 Apache는 1번만 설치됨
- name: Install Apache
  apt:
    name: apache2
    state: present   # 이미 있으면 skip

state 값	의미
`present`	있어야 함 (없으면 설치)
`absent`	없어야 함 (있으면 제거)
`latest`	최신 버전이어야 함
`started`	실행 중이어야 함
`stopped`	중지 상태여야 함

⚠️ command, shell 모듈은 멱등성을 보장하지 않음. 가능하면 전용 모듈 사용 권장.

3. Playbook

YAML로 작성하는 자동화 시나리오. Ansible의 핵심.

# site.yml
---
- name: Web Server 구성
  hosts: web
  become: yes          # sudo 사용
 
  tasks:
    - name: Nginx 설치
      apt:
        name: nginx
        state: present
        update_cache: yes
 
    - name: Nginx 설정 파일 배포
      template:
        src: templates/nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Restart Nginx
 
    - name: Nginx 서비스 시작
      systemd:
        name: nginx
        state: started
        enabled: yes
 
  handlers:
    - name: Restart Nginx
      systemd:
        name: nginx
        state: restarted

구조:

flowchart TD

0x2A Engineering

탐색기

01. Ansible Overview