Ansible (Red Hat Ansible) | KAITRUST AI 백과사전

📖 상세 설명

Ansible은 Red Hat이 개발한 IT 자동화 도구로, 서버 설정 관리(Configuration Management), 애플리케이션 배포, 오케스트레이션을 YAML 기반의 플레이북으로 수행합니다. 가장 큰 특징은 에이전트리스(Agentless) 방식으로, 대상 서버에 별도 소프트웨어 설치 없이 SSH만으로 작업을 수행합니다.

Ansible의 핵심 개념은 Inventory(대상 서버 목록), Playbook(실행할 작업), Module(개별 작업 단위), Role(재사용 가능한 플레이북 묶음)입니다. Playbook은 선언적(Declarative)으로 작성되어 "nginx가 설치되어 있고 실행 중이어야 한다"고 정의하면, Ansible이 현재 상태를 확인하고 필요한 작업만 수행합니다(멱등성).

Terraform과 자주 비교되는데, 둘은 역할이 다릅니다. Terraform은 인프라 프로비저닝(VM, 네트워크 생성)에 강하고, Ansible은 프로비저닝된 서버 위에 소프트웨어를 설치하고 설정하는 데 강합니다. 실무에서는 "Terraform으로 EC2 생성 -> Ansible로 nginx 설치"처럼 조합해서 사용합니다.

Ansible Galaxy는 커뮤니티가 만든 Role을 공유하는 저장소로, nginx, docker, kubernetes 같은 일반적인 설정은 검증된 Role을 가져다 쓸 수 있습니다. AWX(오픈소스) 또는 Ansible Tower(상용)를 사용하면 웹 UI에서 플레이북을 실행하고, 권한 관리와 감사 로그까지 관리할 수 있습니다.

💻 코드 예제

# deploy-app.yml - 웹 애플리케이션 배포 플레이북
---
- name: Deploy Web Application
  hosts: webservers
  become: yes  # sudo 권한으로 실행
  vars:
    app_version: "{{ lookup('env', 'APP_VERSION') | default('latest') }}"
    app_port: 8080

  tasks:
    - name: Install required packages
      apt:
        name:
          - docker.io
          - docker-compose
          - python3-docker
        state: present
        update_cache: yes

    - name: Create app directory
      file:
        path: /opt/myapp
        state: directory
        mode: '0755'

    - name: Copy docker-compose file
      template:
        src: templates/docker-compose.yml.j2
        dest: /opt/myapp/docker-compose.yml
      notify: Restart application

    - name: Pull latest Docker image
      docker_image:
        name: "myregistry/myapp:{{ app_version }}"
        source: pull
        force_source: yes

    - name: Ensure application is running
      docker_compose:
        project_src: /opt/myapp
        state: present
      register: output

    - name: Wait for application to be healthy
      uri:
        url: "http://localhost:{{ app_port }}/health"
        status_code: 200
      retries: 10
      delay: 5

  handlers:
    - name: Restart application
      docker_compose:
        project_src: /opt/myapp
        state: present
        restarted: yes

# 실행: ansible-playbook -i inventory/prod deploy-app.yml -e "APP_VERSION=v1.2.3"

🗣️ 실무에서 이렇게 말해요

시니어: "신규 서버 50대에 모니터링 에이전트 설치해야 하는데, Ansible로 한번에 밀면 될 것 같아요."

주니어: "인벤토리에 새 서버 그룹 추가하고, 기존 datadog role 그대로 쓰면 되겠네요?"

시니어: "네, --limit으로 먼저 5대만 테스트하고 문제없으면 전체 적용해요."

면접관: "Configuration Management 도구 경험이 있으신가요?"

지원자: "Ansible을 주로 사용했습니다. 에이전트리스라 도입이 쉬웠고, YAML이라 팀원들 학습 곡선도 낮았어요. 200대 서버의 패키지 업데이트, 설정 변경을 플레이북으로 관리했고, AWX로 웹 UI에서 실행 이력과 권한을 관리했습니다."

리뷰어: "이 task에서 apt update를 매번 하면 느려요. update_cache_valid_time 옵션 써서 캐시 만료 시에만 업데이트하게 바꿔주세요."

작성자: "아, 맞다. cache_valid_time: 3600 추가할게요. 그리고 handler 빼먹은 것도 추가합니다."

⚠️ 주의사항

멱등성을 깨는 task를 조심하세요. shell/command 모듈은 항상 실행되므로 changed_when/creates 조건을 명시하거나, 가능하면 전용 모듈(apt, yum, file 등)을 사용하세요.
비밀번호, API 키 같은 시크릿은 플레이북에 평문으로 넣지 말고 ansible-vault로 암호화하세요. CI/CD에서는 vault password를 환경변수로 주입합니다.
대규모 환경에서는 --forks 옵션으로 병렬 실행 수를 조절하세요. 기본값 5는 너무 적을 수 있고, 너무 높으면 네트워크 병목이 생깁니다.

🔥 실제 장애 사례

중견 기업 사례 2021

멱등성 무시한 플레이북으로 전체 서버 설정 덮어쓰기

원인: shell 모듈로 설정 파일을 직접 echo 덮어쓰기, changed_when 미설정으로 매번 실행

영향: 500대 서버의 수동 설정값이 일괄 초기화, 12시간 서비스 불안정

해결: 수동으로 각 서버 설정 복구, 백업에서 설정 파일 복원

교훈: shell/command 대신 전용 모듈 사용, 프로덕션 전 --check 모드로 dry-run 필수

스타트업 사례 공통

Vault 비밀번호 Git 커밋으로 시크릿 노출

원인: ansible-vault password를 .vault_pass 파일로 저장 후 .gitignore 누락

영향: DB 비밀번호, API 키가 공개 리포지토리에 노출

해결: 모든 시크릿 교체, 리포지토리 히스토리에서 파일 완전 제거

교훈: vault password는 환경변수 또는 CI/CD 시크릿 매니저 사용, git-secrets 훅 설정

📝 이해도 퀴즈

📚 더 배우기

💬 질문 & 기여

❓ 질문하기 ✏️ 수정 제안

이 페이지에 오류가 있거나 추가하고 싶은 내용이 있다면 알려주세요!

Ansible