Ansible 구성 요소를 활용한 배포 자동화

Ansible을 이용하여 배포를 자동화하는 시나리오를 설명한다. 제시된 예제는 Ansible의 핵심 구성 요소인 inventory, playbook, role, template이 어떻게 배포 파이프라인을 자동화하는지 보여준다.

전체 구조는 다음과 같다

ansible-deploy/
├── inventory.ini             # (inventory) 대상 서버 목록
├── svc_deploy.yml            # (playbook) 작업 흐름의 시작점
└── roles/                    # (role) 재사용 가능한 작업 단위들의 모음
    ├── config/               # 'config' role
    │   └── tasks/
    │       └── main.yml      #  - 디렉터리 생성, 설정 파일 다운로드 작업
    └── deploy/               # 'deploy' role
        ├── tasks/
        │   └── main.yml      #  - 파일 복사, 서비스 생성 및 시작 작업
        └── templates/
            └── service.j2    # (template) systemd 서비스 파일의 원본

 

1. inventory

inventory는 Ansible이 관리할 대상 서버(호스트)의 목록을 정의하는 파일이다. 호스트는 IP 주소나 도메인 이름으로 지정될 수 있으며, 그룹으로 묶어 관리한다.

inventory.ini

[user]
10.0.0.11

[order]
10.0.0.12

[payment]
10.0.0.13

• [user], [order] 등 대괄호로 표시된 항목은 호스트 그룹이다.
• 예시로 호스트 그룹의 이름을 배포 대상 서비스의 이름과 일치시켰다. 이 규칙을 통해 playbook 실행 시 변수(service_name)를 이용하여 작업을 수행할 대상 그룹을 동적으로 지정할 수 있다.

 

2. playbook

playbook은 특정 호스트 그룹에 대해 실행할 작업의 순서와 내용을 정의하는 YAML 파일이다. 배포 프로세스의 최상위 실행 단위이다.

- name: Deploy MSA Service
  hosts: "{{ service_name }}"
  become: yes
  roles:
    - config
    - deploy

• hosts: "{{ service_name }}": 이 playbook이 실행될 호스트 그룹을 지정한다. 실행 시 -e 옵션으로 전달된 service_name 변수 값에 따라 대상 그룹이 결정된다. 예를 들어 service_name=user로 실행하면 inventory의 [user] 그룹을 대상으로 한다.
• become: yes: playbook 내의 모든 작업을 관리자(root) 권한으로 실행하도록 설정한다.
• roles: 해당 호스트에 적용할 role(Role)의 목록이다. config role과 deploy role이 순차적으로 실행된다.

 

3. role

role은 특정 목적을 가진 작업(Tasks), 핸들러, template, 파일 등의 자원을 구조화된 디렉터리 형태로 묶은 재사용 단위이다. 복잡한 playbook을 논리적으로 분리하고 관리를 용이하게 한다.

3.1. config role

서비스 배포에 필요한 사전 환경설정을 수행한다. 서비스 디렉터리 생성 및 설정 파일 다운로드를 담당한다.

roles/config/tasks/main.yml

- name: Create service directory
  file:
    path: "/opt/{{ service_name }}"
    state: directory

- name: Download config file
  get_url:
    url: "http://configs.internal/{{ service_name }}/config.yml"
    dest: "/opt/{{ service_name }}/config.yml"

• file 모듈을 사용하여 /opt/{{ service_name }} 경로에 디렉터리를 생성한다.
• get_url 모듈을 사용하여 중앙 설정 서버로부터 각 서비스에 맞는 설정 파일을 다운로드한다.

3.2. deploy role

애플리케이션을 서버에 배포하고, 이를 시스템 서비스로 등록 및 실행한다.

roles/deploy/tasks/main.yml

- name: Copy JAR file
  copy:
    src: "files/{{ service_name }}-{{ service_version }}.jar"
    dest: "/opt/{{ service_name }}/{{ service_name }}.jar"

- name: Create systemd service
  template:
    src: service.j2
    dest: "/etc/systemd/system/{{ service_name }}.service"

- name: Reload systemd
  command: systemctl daemon-reload

- name: Start service
  service:
    name: "{{ service_name }}"
    state: restarted
    enabled: yes

• copy 모듈은 service_name과 service_version 변수를 조합하여 로컬의 소스 파일을 찾아 원격 서버로 복사한다.
• template 모듈은 service.j2 template을 이용해 서비스별 systemd 서비스 유닛 파일을 생성한다.
• service 모듈은 생성된 서비스를 재시작하고, 시스템 부팅 시 자동 실행되도록 활성화한다.

 

4. template

template은 변수를 포함하는 파일로, playbook 실행 시 변수 값이 치환되어 동적인 결과 파일을 생성하는 데 사용된다. Jinja2 template 언어를 사용한다.

service.j2

[Unit]
Description={{ service_name }} service
After=network.target

[Service]
User=ubuntu
WorkingDirectory=/opt/{{ service_name }}
ExecStart=/usr/bin/java -jar /opt/{{ service_name }}/{{ service_name }}.jar --spring.config.location=/opt/{{ service_name }}/config.yml
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

• deploy role이 이 template을 처리할 때, {{ service_name }}과 같은 변수들은 실행 시점에 전달된 실제 값(예: 'user')으로 대체된다.
• 이를 통해 각 서비스의 특성에 맞는 user.service, order.service 등의 설정 파일을 동적으로 생성할 수 있다.

최종적으로 아래와 같은 명령어를 통해 특정 서비스의 배포가 실행할 수 있다.

# user 서비스 (버전 1.0.0) 배포
ansible-playbook -i inventory.ini svc_deploy.yml -e "service_name=user service_version=1.0.0"

# order 서비스 (버전 2.3.1) 배포
ansible-playbook -i inventory.ini svc_deploy.yml -e "service_name=order service_version=2.3.1"