소개
역할은 작동하는 자동화 단위를 묶어 사용자가 구현을 중복하지 않고 데이터를 제공하게 합니다. 공개 기본값이 있는 역할을 만들고 호스트별 페이지를 렌더링하며 구성 검증과 재로드 동작을 역할 안에 유지한 다음 두 인벤토리 그룹에서 재사용합니다. 실제 관리 파일과 HTTP 응답으로 역할이 실제 호출되었는지 검증합니다.
기본값을 갖춘 역할 만들기 및 호출하기
이 단계에서는 웹 사이트 자동화를 역할로 옮기고 재사용 가능한 기본 입력을 사용하는 짧은 플레이북으로 호출합니다.
역할은 표준 디렉터리 아래에 관련 태스크, 기본 변수, 템플릿, 핸들러를 묶습니다. tasks/main.yml은 태스크 진입점이고 defaults/main.yml은 사용자가 덮어쓸 수 있는 낮은 우선순위 값을 제공합니다. 템플릿 소스는 templates 아래에 두며 handlers/main.yml에는 나중에 변경 기반 서비스 동작을 둡니다.
준비된 인벤토리는 이미 sites 부모 그룹 아래 canary에 web1, stable에 web2를 배치합니다. nginx는 사전 요구 사항으로 설치되어 있습니다. 그룹을 확인합니다.
cd /home/labex/project
ansible-inventory --graph
mkdir -p로 역할 디렉터리를 만듭니다. 여러 경로 인수는 명명된 각 디렉터리를 만듭니다.
mkdir -p roles/managed_site/tasks roles/managed_site/defaults roles/managed_site/templates roles/managed_site/handlers
용도를 명확하게 하도록 공개 역할 변수에 site_ 접두사를 붙입니다. 모든 사용자가 사용할 수 있는 공통 기본값으로 시작합니다.
cat > roles/managed_site/defaults/main.yml <<'YAML'
site_environment: training
site_port: 8080
site_maintenance: false
YAML
페이지 템플릿은 각 대상 이름과 수집된 배포판과 함께 역할 입력을 사용합니다.
cat > roles/managed_site/templates/page.txt.j2 <<'JINJA'
host={{ inventory_hostname }}
environment={{ site_environment }}
distribution={{ ansible_facts.distribution }}
JINJA
역할의 태스크 진입점을 만듭니다. 역할 안에서 src: page.txt.j2는 해당 역할의 templates 디렉터리 아래에서 해석됩니다. 대상은 계속 절대 관리 경로입니다.
cat > roles/managed_site/tasks/main.yml <<'YAML'
- name: Prepare the role-managed website directory
ansible.builtin.file:
path: /var/www/role-site
state: directory
owner: root
group: root
mode: "0755"
- name: Render the role-managed page
ansible.builtin.template:
src: page.txt.j2
dest: /var/www/role-site/index.html
owner: root
group: root
mode: "0644"
YAML
roles 키워드로 역할을 호출합니다. 바깥 플레이는 대상을 선택하고 팩트를 수집하며 become을 요청하고 역할은 재사용 태스크를 제공합니다.
cat > site.yml <<'YAML'
- name: Apply the managed site role with defaults
hosts: sites
gather_facts: true
become: true
roles:
- managed_site
YAML
사용 플레이북을 통해 역할을 검증하고 실행합니다.
ansible-playbook site.yml --syntax-check
ansible-playbook site.yml
역할이 만든 실제 페이지를 확인합니다.
ansible sites -m ansible.builtin.command -a 'cat /var/www/role-site/index.html'
둘 다 기본값에서 온 environment=training과 자신의 호스트 이름, distribution=Ubuntu를 보여야 합니다. 역할 디렉터리를 만들기만 해서는 역할이 실행되거나 관리 파일이 생성되지 않습니다.
재사용 역할 안에 템플릿과 핸들러 유지하기
이 단계에서는 후보 검증과 자체 재로드 핸들러를 포함하여 역할이 웹 사이트를 구성하고 실행하게 합니다.
페이지 소스 옆에 완전한 nginx 템플릿을 둡니다. 역할의 site_ 입력, 앞서 연습한 upper 필터, 부울 분기를 사용합니다.
cat > roles/managed_site/templates/nginx.conf.j2 <<'JINJA'
events {}
http {
server_tokens off;
server {
listen {{ site_port }};
root /var/www/role-site;
index index.html;
add_header X-Environment "{{ site_environment | upper }}" always;
{% if site_maintenance %}
add_header X-Maintenance "enabled" always;
{% else %}
add_header X-Maintenance "disabled" always;
{% endif %}
}
}
JINJA
대체 전에 렌더링 구성을 검증하고 nginx started를 명시적으로 유지하는 역할 태스크를 덧붙입니다. 변경된 구성은 역할의 이름 있는 핸들러에 알립니다.
cat >> roles/managed_site/tasks/main.yml <<'YAML'
- name: Render and validate the role-managed nginx configuration
ansible.builtin.template:
src: nginx.conf.j2
dest: /etc/nginx/nginx.conf
owner: root
group: root
mode: "0644"
validate: /usr/sbin/nginx -t -c %s
notify: Reload managed site
- name: Keep the role-managed service running
ansible.builtin.service:
name: nginx
state: started
YAML
각 사용 플레이북에 중복하지 말고 역할의 핸들러 진입점에 핸들러를 작성합니다.
cat > roles/managed_site/handlers/main.yml <<'YAML'
- name: Reload managed site
ansible.builtin.service:
name: nginx
state: reloaded
YAML
변경하지 않은 사용 플레이북을 실행합니다. 이제 역할이 전체 배포 동작을 제공합니다.
ansible-playbook site.yml
두 호스트 모두 기본 포트 8080에서 자신의 사이트를 시작해야 합니다. 각 대상을 자신의 루프백 엔드포인트로 확인합니다.
ansible sites -m ansible.builtin.command -a 'curl --fail --silent --show-error -i http://127.0.0.1:8080/'
각 본문은 자신의 호스트와 environment=training을 식별해야 합니다. 헤더에는 X-Environment: TRAINING과 X-Maintenance: disabled가 있어야 합니다. 출력은 컨트롤러에만 있는 시연이 아니라 역할이 구성한 실행 서비스에서 나옵니다.
그룹 변수 덮어쓰기로 같은 역할 재사용하기
이 단계에서는 재사용 기본값이나 태스크 파일을 편집하지 않고 같은 역할을 두 그룹 컨텍스트에 적용합니다.
역할 기본값은 의도적으로 우선순위가 낮습니다. 인벤토리 그룹 변수는 같은 구현을 유지하면서 공개 입력을 덮어쓸 수 있습니다. defaults/main.yml은 그대로 두고 각 그룹의 사용 데이터를 만듭니다.
cat > group_vars/canary.yml <<'YAML'
site_environment: development
site_port: 8081
site_maintenance: true
YAML
cat > group_vars/stable.yml <<'YAML'
site_environment: production
site_port: 8082
site_maintenance: false
YAML
사용 플레이북을 같은 managed_site 역할을 호출하는 두 플레이로 대체합니다. 각 그룹은 자신의 해석된 입력을 받습니다. 환경마다 역할 디렉터리를 중복하지 마세요.
cat > site.yml <<'YAML'
- name: Apply the shared role to canary
hosts: canary
gather_facts: true
become: true
roles:
- managed_site
- name: Apply the shared role to stable
hosts: stable
gather_facts: true
become: true
roles:
- managed_site
YAML
두 컨텍스트를 검증하고 적용합니다.
ansible-playbook site.yml --syntax-check
ansible-playbook site.yml
두 환경은 역할 내부 핸들러를 통해 변경 구성을 로드해야 합니다. 새로 구성한 포트의 실제 엔드포인트를 확인합니다.
ansible canary -m ansible.builtin.command -a 'curl --fail --silent --show-error -i http://127.0.0.1:8081/'
ansible stable -m ansible.builtin.command -a 'curl --fail --silent --show-error -i http://127.0.0.1:8082/'
canary는 web1과 development 및 DEVELOPMENT/enabled 헤더를 식별해야 합니다. stable은 web2와 production 및 PRODUCTION/disabled 헤더를 식별해야 합니다. 이 차이는 그룹 입력에서 나오며 하나의 공통 역할이 여전히 기본값, 태스크, 템플릿, 핸들러를 관리합니다.
같은 사용 플레이북을 반복합니다.
ansible-playbook site.yml
두 요약 행 모두 핸들러 예약 없이 changed=0, unreachable=0, failed=0을 보고해야 합니다. 재사용 가능한 역할은 호출되어 올바르게 수렴된 관리 상태를 생성해야 합니다. 디렉터리 뼈대만으로는 배포가 아닙니다.
요약
기본값, 태스크, 템플릿, 핸들러를 하나의 호출되는 역할로 구성했습니다. 낮은 우선순위 기본값은 사용자 덮어쓰기를 지원했고 두 인벤토리 그룹은 같은 구현을 재사용하여 서로 다른 실제 서비스를 생성했습니다. 후보 검증, 변경 기반 재로드, 변경 없는 반복 실행도 재사용 단위 안에 유지되었습니다.


