Ansible Role 구조화 완벽 가이드

Ansible에서 재사용 가능한 코드를 작성하기 위한 Role 구조화 방법을 알아봅니다. 디렉토리 구조부터 의존성 관리, 재사용 전략까지 실무에서 바로 적용할 수 있는 내용을 다룹니다.

---

목차

1. Role의_필요성과_장점
2. Role_디렉토리_구조
3. Role_생성하기
4. Role에서_변수_관리
5. Role_의존성_정의
6. Role_재사용_전략

---

1. Role의 필요성과 장점

김개발 씨는 입사 첫 달부터 서버 설정 작업을 맡게 되었습니다. 처음에는 단순히 플레이북 하나에 모든 태스크를 작성했는데, 어느 날 선배가 코드를 보더니 이렇게 말했습니다.

"이거, Role로 분리하면 나중에 훨씬 편해질 텐데요."

Role은 Ansible에서 관련된 태스크, 변수, 핸들러, 템플릿 등을 하나의 재사용 가능한 단위로 묶어놓은 것입니다. 마치 레고 블록처럼 필요할 때마다 조립해서 사용할 수 있습니다.

Role을 제대로 활용하면 코드 중복을 줄이고, 팀 전체가 일관된 방식으로 인프라를 관리할 수 있습니다.

다음 코드를 살펴봅시다.

# 기존 방식: 모든 것이 한 파일에 뒤섞여 있음
- name: Install nginx
  apt:
    name: nginx
    state: present

- name: Copy nginx config
  template:
    src: nginx.conf.j2
    dest: /etc/nginx/nginx.conf

- name: Start nginx
  service:
    name: nginx
    state: started

# Role 방식: 깔끔하게 역할 호출
- hosts: webservers
  roles:
    - nginx

김개발 씨는 입사한 지 한 달이 된 주니어 DevOps 엔지니어입니다. 오늘도 새벽까지 서버 설정 스크립트를 작성하느라 고생했습니다.

웹 서버 10대에 동일한 Nginx 설정을 배포해야 했거든요. 플레이북 파일 하나에 모든 태스크를 쭉 나열해서 작성했습니다.

apt로 패키지 설치하고, 설정 파일 복사하고, 서비스 시작하고. 코드가 200줄을 훌쩍 넘어갔지만, 어쨌든 잘 동작했습니다.

다음 주에 문제가 생겼습니다. 이번에는 API 서버에도 Nginx를 설치해야 했습니다.

김개발 씨는 지난번 플레이북에서 Nginx 관련 부분을 복사해서 새 파일에 붙여넣었습니다. 그런데 한 달 후, 보안 취약점이 발견되어 Nginx 설정을 변경해야 했습니다.

두 파일 모두 수정해야 했습니다. 한쪽은 수정했는데 다른 쪽을 깜빡 잊어버렸습니다.

결국 장애가 발생했고, 선배 박시니어 씨가 이 상황을 보고 말했습니다. "Role을 쓰면 이런 일이 없을 텐데요." Role이란 정확히 무엇일까요?

쉽게 비유하자면, Role은 마치 요리 레시피 카드와 같습니다. 된장찌개를 끓일 때마다 재료 목록과 조리 순서를 처음부터 새로 적지 않잖아요.

레시피 카드 한 장만 있으면 언제든 똑같은 된장찌개를 만들 수 있습니다. Ansible Role도 마찬가지입니다.

Nginx 설치와 설정에 필요한 모든 것을 하나의 Role로 만들어두면, 어떤 서버에든 그 Role만 적용하면 됩니다. 웹 서버든, API 서버든, 심지어 다른 프로젝트에서도 같은 Role을 재사용할 수 있습니다.

Role을 사용하면 얻을 수 있는 장점이 많습니다. 첫째, 코드 중복이 사라집니다.

같은 설정을 여러 곳에 복사해 붙여넣을 필요가 없습니다. 둘째, 유지보수가 쉬워집니다.

버그를 수정하거나 기능을 추가할 때 한 곳만 고치면 됩니다. 셋째, 팀 협업이 편해집니다.

다른 팀원이 만든 Role을 가져다 쓸 수 있으니까요. 실제 코드를 보면 차이가 확연합니다.

기존 방식에서는 Nginx 관련 태스크가 10줄, 20줄씩 플레이북 여기저기에 흩어져 있었습니다. Role 방식에서는 단 한 줄로 끝납니다.

roles 목록에 nginx라고 적기만 하면 됩니다. 물론 Role을 처음 만들 때는 시간이 좀 더 걸립니다.

하지만 두 번째 사용부터는 시간을 절약하게 됩니다. 세 번, 네 번 사용하면 투자한 시간을 훨씬 뛰어넘는 효율을 얻습니다.

다시 김개발 씨 이야기로 돌아가 봅시다. 박시니어 씨의 조언을 듣고 Nginx Role을 만들었습니다.

처음에는 어색했지만, 일주일 후 새로운 프로젝트에서 그 Role을 재사용했을 때 감탄했습니다. "아, 이래서 Role을 쓰는 거구나!"

실전 팁

💡 - Role 이름은 역할을 명확히 나타내도록 짓습니다. webserver보다 nginx가 더 명확합니다.

• 처음부터 완벽한 Role을 만들려 하지 마세요. 간단하게 시작해서 점차 개선해 나가면 됩니다.

---

2. Role 디렉토리 구조

김개발 씨가 드디어 첫 번째 Role을 만들기로 결심했습니다. 그런데 막상 시작하려니 막막했습니다.

"Role 폴더 안에 뭘 넣어야 하지?" 선배에게 물어보니 종이에 구조도를 그려주며 설명을 시작했습니다.

Ansible Role은 정해진 디렉토리 구조를 따릅니다. tasks, handlers, templates, files, vars, defaults, meta 등 각 폴더가 고유한 역할을 담당합니다.

이 구조를 이해하면 어떤 Role을 보더라도 빠르게 파악할 수 있습니다.

다음 코드를 살펴봅시다.

roles/
  nginx/                    # Role 이름
    tasks/
      main.yml             # 핵심 태스크 정의
    handlers/
      main.yml             # 서비스 재시작 등 핸들러
    templates/
      nginx.conf.j2        # Jinja2 템플릿 파일
    files/
      index.html           # 정적 파일
    vars/
      main.yml             # Role 내부 변수
    defaults/
      main.yml             # 기본값 (우선순위 낮음)
    meta/
      main.yml             # 의존성 정의

박시니어 씨가 화이트보드에 폴더 구조를 그리기 시작했습니다. "Role은 아파트 같은 거야.

각 층마다 용도가 정해져 있지. 1층은 상가, 2층부터는 주거공간처럼." 가장 먼저 tasks 폴더를 그렸습니다.

"여기가 Role의 심장이야. 실제로 실행될 태스크들이 여기 들어가." tasks 폴더 안에는 보통 main.yml 파일이 있습니다.

Ansible이 Role을 실행할 때 가장 먼저 찾는 파일이 바로 이것입니다. 다음으로 handlers 폴더입니다.

"설정 파일이 바뀌면 서비스를 재시작해야 하잖아? 그런 트리거 작업들을 여기 넣어." 핸들러는 notify로 호출되었을 때만 실행되는 특별한 태스크입니다.

중복 호출되어도 마지막에 한 번만 실행됩니다. templates 폴더는 Jinja2 템플릿을 담습니다.

설정 파일처럼 서버마다 내용이 조금씩 달라야 하는 파일들입니다. 변수를 활용해서 동적으로 내용을 생성할 수 있습니다.

파일 확장자는 보통 .j2를 사용합니다. files 폴더는 템플릿이 아닌 정적 파일을 담습니다.

변수 치환 없이 그대로 복사되는 파일들입니다. 인증서 파일이나 바이너리 파일 같은 것들이 여기 들어갑니다.

변수 관련 폴더가 두 개 있습니다. defaults와 vars입니다.

둘 다 변수를 정의하지만 우선순위가 다릅니다. defaults는 기본값으로, 다른 곳에서 같은 변수를 정의하면 덮어씌워집니다.

vars는 Role 내부에서 쓸 변수로, 우선순위가 더 높습니다. 마지막으로 meta 폴더입니다.

Role에 대한 메타데이터를 담습니다. 가장 중요한 것은 의존성 정보입니다.

이 Role이 실행되기 전에 먼저 실행되어야 할 다른 Role을 지정할 수 있습니다. 김개발 씨가 고개를 끄덕였습니다.

"그럼 이 폴더들을 다 만들어야 하나요?" 박시니어 씨가 웃으며 답했습니다. "아니, 필요한 것만 만들면 돼.

Ansible이 알아서 있는 폴더만 읽어." 실제로 간단한 Role이라면 tasks 폴더 하나만 있어도 동작합니다. 프로젝트가 커지면서 필요에 따라 다른 폴더들을 추가하면 됩니다.

이렇게 정해진 구조가 있기 때문에 다른 사람이 만든 Role도 쉽게 이해할 수 있습니다. 한 가지 더 알아두면 좋은 것이 있습니다.

각 폴더의 main.yml은 자동으로 로드됩니다. 하지만 태스크가 많아지면 main.yml에서 다른 파일을 include할 수도 있습니다.

예를 들어 install.yml, configure.yml, deploy.yml로 나눌 수 있습니다.

실전 팁

💡 - 모든 폴더를 만들 필요는 없습니다. 필요한 것만 만들면 Ansible이 알아서 처리합니다.

• main.yml이 너무 길어지면 용도별로 파일을 분리하고 include_tasks로 불러오세요.

---

3. Role 생성하기

이론은 충분히 들었습니다. 김개발 씨는 드디어 직접 Role을 만들어보기로 했습니다.

키보드에 손을 올리는 순간, 문득 궁금해졌습니다. "폴더를 일일이 다 만들어야 하나?" 다행히 Ansible에는 편리한 명령어가 있었습니다.

ansible-galaxy init 명령어를 사용하면 Role의 기본 구조를 자동으로 생성할 수 있습니다. 필요한 모든 폴더와 기본 파일이 만들어지므로 바로 코드를 작성할 수 있습니다.

생성된 구조에 실제 태스크와 설정을 채워넣으면 Role이 완성됩니다.

다음 코드를 살펴봅시다.

# Role 기본 구조 생성
ansible-galaxy init roles/nginx

# 생성된 tasks/main.yml 편집
---
# roles/nginx/tasks/main.yml
- name: Install nginx package
  apt:
    name: nginx
    state: present
  become: true

- name: Copy nginx configuration
  template:
    src: nginx.conf.j2
    dest: /etc/nginx/nginx.conf
  notify: Restart nginx

- name: Ensure nginx is running
  service:
    name: nginx
    state: started
    enabled: true

김개발 씨가 터미널을 열었습니다. 박시니어 씨가 알려준 대로 ansible-galaxy init 명령어를 입력했습니다.

Enter 키를 누르는 순간, 마법처럼 폴더들이 생겨났습니다. ansible-galaxy는 Ansible의 Role 관리 도구입니다.

init 명령은 새 Role의 뼈대를 만들어줍니다. roles/nginx라고 지정하면 roles 폴더 안에 nginx라는 Role이 생성됩니다.

ls 명령으로 확인해보니 정말 모든 폴더가 만들어져 있었습니다. tasks, handlers, templates, files, vars, defaults, meta, 그리고 README.md까지.

각 폴더 안에는 main.yml 파일도 미리 생성되어 있었습니다. 이제 실제 내용을 채워넣을 차례입니다.

가장 먼저 할 일은 tasks/main.yml을 편집하는 것입니다. 여기에 Nginx를 설치하고 설정하는 태스크를 작성합니다.

첫 번째 태스크는 패키지 설치입니다. apt 모듈을 사용해서 nginx 패키지를 설치합니다.

become: true는 sudo 권한으로 실행하라는 의미입니다. 패키지 설치에는 관리자 권한이 필요하니까요.

두 번째 태스크는 설정 파일 복사입니다. template 모듈을 사용합니다.

src에는 템플릿 파일 이름을, dest에는 복사될 경로를 지정합니다. 템플릿 파일은 templates 폴더에서 자동으로 찾습니다.

여기서 중요한 것은 notify입니다. 이 태스크가 실제로 변경을 만들었을 때, 즉 설정 파일이 바뀌었을 때 핸들러를 호출합니다.

설정이 바뀌면 Nginx를 재시작해야 적용되니까요. 세 번째 태스크는 서비스 시작입니다.

service 모듈로 Nginx가 실행 중인지 확인하고, 부팅 시 자동 시작되도록 enabled: true를 설정합니다. handlers/main.yml에는 Restart nginx 핸들러를 정의합니다.

이름이 notify에서 지정한 것과 정확히 일치해야 합니다. templates 폴더에는 nginx.conf.j2 파일을 만듭니다.

기본 Nginx 설정에 Jinja2 변수를 넣어서 서버마다 다른 값을 적용할 수 있게 합니다. 김개발 씨는 모든 파일을 작성하고 저장했습니다.

이제 플레이북에서 이 Role을 사용할 수 있습니다. roles 목록에 nginx를 추가하기만 하면 됩니다.

첫 번째 Role이 완성되었습니다. 처음에는 복잡해 보였지만, 막상 해보니 그리 어렵지 않았습니다.

중요한 것은 각 폴더의 역할을 이해하고, 적절한 곳에 코드를 배치하는 것입니다.

실전 팁

💡 - ansible-galaxy init을 사용하면 빠르게 시작할 수 있습니다. 불필요한 폴더는 나중에 삭제해도 됩니다.

• notify의 이름과 handler의 이름은 정확히 일치해야 합니다. 오타에 주의하세요.
• 처음에는 간단한 Role부터 시작해서 점점 복잡한 기능을 추가해 나가세요.

---

4. Role에서 변수 관리

Role이 잘 동작하는 것을 확인한 김개발 씨는 뿌듯했습니다. 그런데 문제가 생겼습니다.

테스트 서버에는 포트 8080, 운영 서버에는 포트 80을 사용해야 했습니다. 같은 Role인데 설정만 다르게 하려면 어떻게 해야 할까요?

Role에서 변수를 활용하면 같은 Role을 다양한 환경에서 유연하게 사용할 수 있습니다. defaults 폴더에 기본값을 정의하고, 사용 시점에 다른 값으로 덮어쓸 수 있습니다.

이를 통해 하나의 Role로 개발, 테스트, 운영 환경을 모두 지원할 수 있습니다.

다음 코드를 살펴봅시다.

# roles/nginx/defaults/main.yml
---
nginx_port: 80
nginx_worker_processes: auto
nginx_worker_connections: 1024
nginx_server_name: localhost

# roles/nginx/templates/nginx.conf.j2
worker_processes {{ nginx_worker_processes }};

events {
    worker_connections {{ nginx_worker_connections }};
}

http {
    server {
        listen {{ nginx_port }};
        server_name {{ nginx_server_name }};
    }
}

# 플레이북에서 변수 덮어쓰기
- hosts: test_servers
  roles:
    - role: nginx
      vars:
        nginx_port: 8080

박시니어 씨가 김개발 씨의 고민을 듣고 말했습니다. "그래서 변수가 필요한 거야.

Role은 레시피지만, 재료의 양은 상황에 따라 달라질 수 있잖아." 요리에 비유하면 이해하기 쉽습니다. 된장찌개 레시피는 하나지만, 2인분을 만들 때와 4인분을 만들 때 재료 양이 다릅니다.

Role도 마찬가지입니다. 구조는 같지만 서버 환경에 따라 설정값이 달라야 합니다.

Ansible Role에서 변수는 두 곳에서 정의할 수 있습니다. defaults 폴더와 vars 폴더입니다.

둘의 차이는 우선순위입니다. defaults에 정의된 변수는 가장 낮은 우선순위를 갖습니다.

다른 곳에서 같은 이름의 변수를 정의하면 덮어씌워집니다. 반면 vars에 정의된 변수는 우선순위가 높아서 쉽게 덮어씌워지지 않습니다.

일반적으로 외부에서 바꿀 수 있어야 하는 값은 defaults에 넣습니다. 포트 번호, 도메인 이름, 리소스 제한 같은 것들입니다.

Role 내부에서만 쓰는 값은 vars에 넣습니다. 코드를 보면 defaults/main.yml에 nginx_port, nginx_worker_processes 같은 변수들이 정의되어 있습니다.

이것들이 기본값입니다. 아무것도 지정하지 않으면 이 값들이 사용됩니다.

템플릿 파일에서는 이 변수들을 사용합니다. 이중 중괄호 안에 변수 이름을 넣으면 됩니다.

Ansible이 템플릿을 렌더링할 때 실제 값으로 치환됩니다. 플레이북에서 Role을 호출할 때 vars를 지정하면 기본값을 덮어쓸 수 있습니다.

테스트 서버에는 nginx_port를 8080으로 지정하고, 운영 서버에는 기본값 80을 그대로 사용할 수 있습니다. 변수 네이밍에도 규칙이 있습니다.

Role 이름을 접두사로 붙이는 것이 좋습니다. nginx_port처럼요.

이렇게 하면 다른 Role의 변수와 이름이 충돌하는 것을 방지할 수 있습니다. 인벤토리 파일에서 그룹별로 변수를 정의하는 방법도 있습니다.

group_vars 폴더에 그룹 이름과 같은 파일을 만들고 변수를 정의하면 됩니다. 이렇게 하면 플레이북을 건드리지 않고도 환경별 설정을 관리할 수 있습니다.

김개발 씨는 이 방법으로 테스트 서버와 운영 서버 문제를 해결했습니다. 같은 Role, 다른 변수.

코드 중복 없이 두 환경을 모두 지원하게 되었습니다.

실전 팁

💡 - 변수 이름에 Role 이름을 접두사로 붙이면 충돌을 방지할 수 있습니다.

• 민감한 정보는 ansible-vault로 암호화하여 관리하세요.
• 변수가 너무 많아지면 defaults/main.yml을 여러 파일로 분리할 수 있습니다.

---

5. Role 의존성 정의

김개발 씨의 Nginx Role이 인기를 얻었습니다. 팀원들이 이 Role을 사용하기 시작했는데, 가끔 오류가 발생했습니다.

알고 보니 Nginx 설치 전에 필요한 패키지가 없어서 생기는 문제였습니다. 매번 주의사항을 설명하기도 번거로웠습니다.

Role 의존성을 정의하면 특정 Role이 실행되기 전에 필요한 다른 Role이 자동으로 먼저 실행됩니다. meta/main.yml 파일에 dependencies를 설정하면 됩니다.

이를 통해 Role 간의 실행 순서를 보장하고, 사용자가 의존성을 신경 쓰지 않아도 됩니다.

다음 코드를 살펴봅시다.

# roles/nginx/meta/main.yml
---
dependencies:
  - role: common
  - role: ssl_certificates
    vars:
      ssl_domain: "{{ nginx_server_name }}"
  - role: firewall
    vars:
      firewall_allowed_ports:
        - "{{ nginx_port }}"

# roles/common/tasks/main.yml
---
- name: Update apt cache
  apt:
    update_cache: true
    cache_valid_time: 3600

- name: Install essential packages
  apt:
    name:
      - curl
      - wget
      - vim
    state: present

박시니어 씨가 김개발 씨에게 조언했습니다. "Role을 레고 블록에 비유했잖아.

어떤 블록은 다른 블록 위에 올려야만 제대로 맞물려. 그런 관계를 의존성이라고 해." Nginx가 제대로 동작하려면 몇 가지가 먼저 갖춰져야 합니다.

시스템 패키지가 최신이어야 하고, SSL 인증서가 있어야 하고, 방화벽에서 포트가 열려 있어야 합니다. 이런 것들을 매번 수동으로 확인하는 것은 번거롭고 실수하기 쉽습니다.

meta/main.yml 파일이 바로 이 문제를 해결합니다. dependencies 키 아래에 필요한 Role들을 나열하면 됩니다.

Ansible이 nginx Role을 실행하기 전에 이 Role들을 자동으로 먼저 실행합니다. 코드를 보면 세 가지 의존성이 정의되어 있습니다.

common Role, ssl_certificates Role, firewall Role입니다. Ansible은 이 순서대로 Role을 실행하고, 마지막에 nginx Role을 실행합니다.

의존성을 정의할 때 변수를 전달할 수도 있습니다. ssl_certificates Role에는 ssl_domain 변수를, firewall Role에는 firewall_allowed_ports 변수를 전달하고 있습니다.

이렇게 하면 의존 Role이 현재 Role의 설정에 맞게 동작합니다. 주의할 점이 있습니다.

의존성은 매번 실행됩니다. nginx Role을 호출할 때마다 common, ssl_certificates, firewall Role이 실행됩니다.

같은 플레이북에서 다른 Role이 이미 common을 실행했더라도 다시 실행됩니다. 이것이 문제가 될 수 있습니다.

불필요한 중복 실행이 시간을 낭비하니까요. 이를 방지하려면 의존 Role에 조건을 달거나, Ansible의 allow_duplicates 옵션을 사용합니다.

대부분의 경우 태스크가 멱등성을 갖도록 작성하면 중복 실행되어도 문제가 없습니다. 멱등성이란 같은 작업을 여러 번 실행해도 결과가 같다는 것입니다.

패키지 설치 태스크가 이미 설치된 패키지를 다시 설치하려 할 때, 실제로는 아무 변경도 일어나지 않고 넘어갑니다. 의존성을 정의할 때 또 하나 주의할 점은 순환 의존성입니다.

A Role이 B를 필요로 하고, B Role이 A를 필요로 하면 문제가 생깁니다. Ansible이 어디서 시작해야 할지 모르기 때문입니다.

의존성 그래프가 순환하지 않도록 설계해야 합니다. 김개발 씨는 Nginx Role에 의존성을 추가했습니다.

이제 팀원들이 이 Role을 사용할 때 common Role을 먼저 실행했는지 확인할 필요가 없습니다. Ansible이 알아서 처리해주니까요.

실전 팁

💡 - 의존성은 꼭 필요한 것만 추가하세요. 너무 많으면 실행 시간이 길어집니다.

• 순환 의존성이 생기지 않도록 Role 간 관계를 미리 설계하세요.
• 의존성 Role에 when 조건을 달아 필요할 때만 실행되게 할 수 있습니다.

---

6. Role 재사용 전략

김개발 씨의 Role들이 점점 늘어났습니다. Nginx, MySQL, Redis, Elasticsearch...

어느 날 다른 팀에서 연락이 왔습니다. "그 Role들 우리도 쓸 수 있을까요?" 한 팀에서 만든 Role을 회사 전체가 공유하려면 어떻게 해야 할까요?

Role을 효과적으로 재사용하려면 몇 가지 전략이 필요합니다. Ansible Galaxy를 통해 공개 Role을 활용하고, 내부 Role은 별도 저장소로 관리하며, requirements.yml로 의존성을 선언합니다.

잘 설계된 Role은 마치 라이브러리처럼 여러 프로젝트에서 재사용됩니다.

다음 코드를 살펴봅시다.

# requirements.yml - 외부 Role 의존성 선언
---
roles:
  # Ansible Galaxy에서 가져오기
  - name: geerlingguy.docker
    version: 6.1.0

  # Git 저장소에서 가져오기
  - name: company_nginx
    src: git@github.com:mycompany/ansible-role-nginx.git
    version: v2.1.0
    scm: git

  # 내부 Galaxy 서버에서 가져오기
  - name: internal.monitoring
    src: https://galaxy.internal.company.com

# Role 설치 명령
# ansible-galaxy install -r requirements.yml

# 플레이북에서 사용
- hosts: webservers
  roles:
    - geerlingguy.docker
    - company_nginx
    - internal.monitoring

박시니어 씨가 김개발 씨를 불러 큰 그림을 설명하기 시작했습니다. "이제 Role을 잘 만드는 것 다음 단계야.

어떻게 하면 만든 Role을 여러 곳에서 재사용할 수 있을지 생각해봐야 해." Role 재사용에는 크게 세 가지 방법이 있습니다. 첫째, Ansible Galaxy에서 다른 사람이 만든 Role을 가져다 쓰는 것입니다.

둘째, Git 저장소에 Role을 올려두고 여러 프로젝트에서 가져다 쓰는 것입니다. 셋째, 내부 Galaxy 서버를 운영하는 것입니다.

Ansible Galaxy는 Ansible Role의 앱스토어 같은 곳입니다. 수많은 개발자가 만든 Role이 공개되어 있습니다.

Docker, PostgreSQL, Redis 같은 흔한 소프트웨어는 이미 잘 만들어진 Role이 있습니다. 바퀴를 다시 발명할 필요가 없습니다.

Galaxy에서 Role을 설치하는 것은 간단합니다. ansible-galaxy install 명령 뒤에 Role 이름을 적으면 됩니다.

예를 들어 geerlingguy.docker는 Docker 설치에 널리 쓰이는 Role입니다. 하지만 여러 Role을 사용하다 보면 관리가 복잡해집니다.

이때 requirements.yml 파일이 도움됩니다. 필요한 모든 Role을 이 파일에 나열해두고, ansible-galaxy install -r requirements.yml 명령으로 한 번에 설치합니다.

requirements.yml에는 Galaxy Role뿐 아니라 Git 저장소의 Role도 지정할 수 있습니다. 회사 내부에서 만든 Role을 GitHub나 GitLab에 올려두고, 여러 프로젝트에서 가져다 쓸 수 있습니다.

version을 지정하면 특정 버전을 고정할 수 있어 안정성이 높아집니다. 규모가 큰 회사에서는 내부 Ansible Galaxy 서버를 운영하기도 합니다.

Ansible Automation Hub가 그 예입니다. 회사 내부에서만 사용하는 Role을 여기서 관리하고, 팀 간에 공유합니다.

Role을 재사용 가능하게 만들려면 몇 가지 원칙을 따라야 합니다. 첫째, 변수를 잘 설계해야 합니다.

하드코딩된 값 대신 변수를 사용하면 다양한 환경에서 쓸 수 있습니다. 둘째, 문서화가 중요합니다.

README에 어떤 변수가 있고, 어떻게 사용하는지 적어두어야 합니다. 셋째, 버전 관리를 해야 합니다.

Git 태그로 버전을 표시하면 특정 버전을 고정해서 사용할 수 있습니다. 넷째, 테스트를 작성합니다.

Molecule 같은 도구로 Role을 테스트하면 변경할 때 안심이 됩니다. 김개발 씨는 이 조언을 따라 Nginx Role을 회사 GitHub에 올렸습니다.

README를 작성하고, 버전 태그를 붙이고, 다른 팀이 사용할 수 있게 안내했습니다. 다른 팀에서 문의가 올 때마다 뿌듯함을 느꼈습니다.

내가 만든 코드가 회사 여러 곳에서 쓰이고 있구나.

실전 팁

💡 - Galaxy에서 Role을 선택할 때는 다운로드 수와 최근 업데이트 날짜를 확인하세요.

• requirements.yml은 반드시 버전 관리에 포함시키세요. 팀원 모두 같은 Role 버전을 사용해야 합니다.
• 내부 Role에도 CHANGELOG를 작성해서 변경 이력을 추적하세요.

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!