변수 사용하기

변수 사용하기 (Using variables)

Ansible은 변수로 시스템 간의 차이를 관리해요. 단일 명령으로 여러 시스템에서 작업·플레이북을 실행할 수 있기 때문에, 서로 다른 시스템의 차이를 변수(variable)로 표현해야 해요. 목록과 딕셔너리를 포함한 표준 YAML 문법으로 변수를 만들 수 있어요. 변수는 플레이북, 인벤토리, 재사용 가능한 파일이나 역할(roles), 또는 명령줄에서 정의할 수 있고, 작업의 반환값을 register로 새 변수로 만들어 플레이북 실행 중에도 만들 수 있어요.

변수를 만든 뒤에는 모듈 인자, 조건부 'when' 문, 템플릿, 그리고 루프에서 사용할 수 있어요. 이 페이지의 개념과 예시를 이해한 뒤에는 Ansible facts(원격 시스템에서 가져오는 변수)에 대해 읽어 보세요.

출처: 문서

본문

유효한 변수 이름 만들기

모든 문자열이 유효한 Ansible 변수 이름은 아니에요. 변수 이름은 문자, 숫자, 밑줄(_)만 포함할 수 있어요. 파이썬 키워드나 플레이북 키워드는 변수 이름이 될 수 없고, 변수 이름은 숫자로 시작할 수 없어요.

변수 이름은 밑줄로 시작할 수 있어요. 많은 프로그래밍 언어에서 밑줄로 시작하는 변수는 '비공개'를 의미하는데, Ansible에서는 그렇지 않아요. Ansible은 밑줄로 시작하는 변수를 다른 변수와 똑같이 취급하기 때문에, 이 관례를 비공개나 보안 목적으로 의존하면 안 돼요.

유효한 변수 이름과 유효하지 않은 변수 이름의 예시는 이 표를 봐요.

| Valid variable names | Not valid | | foo | *foo , 파이썬 키워드 async, lambda | | foo_env | environment 같은 플레이북 키워드 | | foo_port | foo-port , foo port , foo.port | | foo5 , _foo | 5foo , 12 |

Ansible은 특정 변수를 내부적으로 정의해요. 이런 변수들은 정의할 수 없어요. 또 Working with playbooks에 나열된 Jinja2 전역 함수(lookup, query, q, now, undef 등)를 덮어쓰는 변수 이름은 피하세요.

단순 변수

단순 변수는 변수 이름 하나와 값 하나를 결합한 거예요. 이 문법(아래에 나오는 목록·딕셔너리 문법 포함)은 여러 곳에서 쓸 수 있어요. 인벤토리·플레이북·재사용 파일·역할·명령줄에서 변수를 설정하는 자세한 내용은 "Where to set variables"를 보세요.

단순 변수 정의하기

표준 YAML 문법으로 단순 변수를 정의할 수 있어요.

remote_install_path: /opt/my_app_config

단순 변수 참조하기

변수를 정의한 뒤에는 Jinja2 문법으로 참조해요. Jinja2 변수는 이중 중괄호를 사용해요. 예를 들어 My amp goes to {{ max_amp_value }}라는 표현은 가장 기본적인 변수 치환 형태를 보여줘요. Jinja2 문법은 플레이북에서 쓸 수 있어요. 다음 예시는 시스템마다 달라질 수 있는 파일 위치를 정의하는 변수를 보여줘요.

ansible.builtin.template:
  src: foo.cfg.j2
  dest: '{{ remote_install_path }}/foo.cfg'

Ansible은 템플릿에서는 Jinja2 루프와 조건문을 허용하지만, 플레이북에서는 허용하지 않아요. 작업의 루프를 만들 수는 없어요. Ansible 플레이북은 순수하게 머신이 파싱 가능한 YAML이에요.

변수를 인용하는 시점 (YAML 함정)

값을 {{ foo }}로 시작하면 전체 표현식을 인용해야 유효한 YAML 문법이 돼요. 전체를 인용하지 않으면 YAML 파서가 문법을 해석하지 못해요. 파서는 그것이 변수인지 YAML 딕셔너리의 시작인지 판단할 수 없게 되죠. YAML 작성 지침은 YAML Syntax 문서를 참고하세요.

인용 없이 변수를 쓰면,

- hosts: app_servers
  vars:
    app_path: {{ base_path }}/22

다음 에러가 나요. ERROR! Syntax Error while loading YAML. 인용을 추가하면 Ansible이 올바르게 동작해요.

- hosts: app_servers
  vars:
    app_path: "{{ base_path }}/22"

목록 변수

목록 변수는 변수 이름 하나에 여러 값을 결합한 거예요. 여러 값을 항목별 목록으로 저장하거나, 쉼표로 구분해 대괄호 []에 저장할 수 있어요.

변수를 목록으로 정의하기

YAML 목록으로 여러 값을 가진 변수를 정의할 수 있어요.

region:
  - northeast
  - southeast
  - midwest

목록 변수 참조하기

목록(배열이라고도 불러요)으로 정의된 변수를 쓸 때는 그 목록에서 개별 항목을 사용할 수 있어요. 목록의 첫 번째 항목은 항목 0, 두 번째는 항목 1... 이런 식이에요.

region: "{{ region[0] }}"

이 표현식의 값은 "northeast"예요.

딕셔너리 변수

딕셔너리는 키-값 쌍으로 데이터를 저장해요. 보통 ID나 사용자 프로필에 담긴 정보처럼 서로 관련된 데이터를 저장할 때 딕셔너리를 써요.

변수를 키-값 딕셔너리로 정의하기

YAML 딕셔너리로 더 복잡한 변수를 정의할 수 있어요. YAML 딕셔너리는 키를 값에 매핑해요.

foo:
  field1: one
  field2: two

키-값 딕셔너리 변수 참조하기

키-값 딕셔너리(해시라고도 불러요)로 정의된 변수를 쓸 때는 대괄호 표기법(bracket notation)이나 점 표기법(dot notation)으로 개별 항목을 사용할 수 있어요.

foo['field1']
foo.field1

두 예시 모두 같은 값("one")을 참조해요. 대괄호 표기법은 항상 동작해요. 점 표기법은 일부 키가 파이썬 딕셔너리의 속성·메서드와 충돌해서 문제를 일으킬 수 있어요. 파이썬에서 특별한 의미로 예약된 양끝에 밑줄 두 개로 시작·끝나는 키, 또는 알려진 공개 속성(add, append, clear, get, items, keys, values, pop 등)을 키로 쓴다면 대괄호 표기법을 사용하세요.

변수 결합하기

목록이나 딕셔너리를 담은 변수를 병합하려면 다음 방법을 쓸 수 있어요.

목록 변수 결합하기

set_fact 모듈로 목록을 새 merged_list 변수로 결합할 수 있어요.

vars:
  list1:
  - apple
  - banana
  - fig

  list2:
  - peach
  - plum
  - pear

tasks:
- name: Combine list1 and list2 into a merged_list var
  ansible.builtin.set_fact:
    merged_list: "{{ list1 + list2 }}"

딕셔너리 변수 결합하기

딕셔너리를 병합하려면 combine 필터를 써요.

vars:
  dict1:
    name: Leeroy Jenkins
    age: 25
    occupation: Astronaut

  dict2:
    location: Galway
    country: Ireland
    postcode: H71 1234

tasks:
- name: Combine dict1 and dict2 into a merged_dict var
  ansible.builtin.set_fact:
    merged_dict: "{{ dict1 | ansible.builtin.combine(dict2) }}"

자세한 내용은 ansible.builtin.combine을 참고하세요.

merge_variables lookup 사용하기

주어진 접두사·접미사·정규식과 일치하는 변수를 병합하려면 community.general.merge_variables lookup을 써요.

merged_variable: "{{ lookup('community.general.merge_variables', '__my_pattern', pattern_type='suffix') }}"

자세한 내용과 사용 예시는 community.general.merge_variables lookup 문서를 참고하세요.

변수 등록하기 (register)

register 작업 키워드로 Ansible 작업의 출력에서 변수를 만들 수 있어요. 등록된 변수는 플레이에서 이후의 어떤 작업에서도 쓸 수 있어요.

- hosts: web_servers

  tasks:

     - name: Run a shell command and register its output as a variable
       ansible.builtin.shell: /usr/bin/foo
       register: foo_result
       ignore_errors: true

     - name: Run a shell command using output of the previous task
       ansible.builtin.shell: /usr/bin/bar
       when: foo_result.rc == 5

이후 작업의 조건에서 등록 변수를 쓰는 더 많은 예시는 Conditionals를 보세요. 등록 변수는 단순 변수, 목록 변수, 딕셔너리 변수, 또는 복잡한 중첩 데이터 구조일 수 있어요. 각 모듈의 문서에는 해당 모듈의 반환값을 설명하는 RETURN 섹션이 있어요. 특정 작업의 값을 보려면 -v로 플레이북을 실행하세요.

2.21 버전에 새로 추가됐어요.

register를 variable: expression 쌍의 딕셔너리로 사용해 여러 변수를 한 번에 등록하고, jinja 표현식으로 작업 출력을 조작할 수도 있어요. Ansible은 작업 출력에 result 속성으로 접근할 수 있는 암묵적 작업 변수 _task를 제공해요.

참고: _task는 예약된 이름이고 내부 용도로 쓰여요. 작업 결과를 등록하거나 변수를 정의하는 데 이 이름을 쓰지 마세요.

- hosts: web_servers

  tasks:
    - name: Run a shell command and register multiple variables
      ansible.builtin.shell: /usr/bin/foo
      register:
        command_result: _task.result  # this is equivalent to register: command_result
        command_duration: (command_end - command_start).total_seconds()
        command_start: _task.result.start | to_datetime(time_format)
        command_end: _task.result.end | to_datetime(time_format)
      vars:
        time_format: '%Y-%m-%d %H:%M:%S.%f'

이 형태의 register는 항상 jinja 표현식이므로 템플릿 구분자 {{ }}가 필요 없어요. register 투영(projection) 표현식에는 {{ }}를 쓰지 마세요.

# Wrong - do not use template delimiters
register:
  foo: "{{ _task.result }}"

# Correct
register:
  foo: _task.result

이 등록 방식은 같은 register 맵에서 정의된 다른 변수에 연결해서 접근할 수 있어요. 같은 단계에서 만든 다른 변수를 기반으로 변수를 정의할 수 있고, 정의 순서는 상관없어요.

- hosts: web_servers

  tasks:
    - name: Run a shell command and register multiple variables
      ansible.builtin.shell: /usr/bin/foo
      register:
        capitalized_command_output: command_result.stdout | capitalize  # This works even though command_result is defined after capitalized_command_output
        command_result: _task.result  # this is equivalent to register: command_result

register 투영은 작업 실행 중이 아니라 작업 완료 후에 평가돼요. 루프가 아닌 작업의 경우, register 맵에서 정의된 변수는 작업 자체 내에서는 사용할 수 없고, _task.result나 다른 투영 변수에 대한 참조는 최종 작업 상태를 반영해요. 이 지연 평가 덕분에 변수 정의 순서에 관계가 없어져요. 루프가 있는 작업에서는 이전 루프 항목의 register 투영을 사용할 수 있지만, 첫 번째 반복에서는 _task.result가 아직 정의되지 않았으므로 default 필터가 필요해요.

루프와 함께 register 투영을 쓰는 예시(_task.loop_result 접근, until·break_when 조건에서 투영 사용 포함)는 Loops를 보세요.

등록 변수는 메모리에 저장돼요. 등록 변수를 캐시해서 이후 플레이북 실행에서 사용할 수는 없어요. 등록 변수는 이번 플레이북 실행이 끝날 때까지(같은 실행 안의 이후 플레이 포함) 해당 호스트에서만 유효해요.

등록 변수는 호스트 수준 변수예요. 루프가 있는 작업에서 변수를 등록하면 등록 변수는 루프의 각 항목에 대한 값을 포함해요. 루프 중에 변수에 들어가는 데이터 구조는 results 속성을 담는데, 이는 모듈의 모든 응답 목록이에요. 자세한 예시는 루프와 함께 register를 쓰는 Loops 섹션을 보세요.

작업이 실패하거나 건너뛰어도, 태그에 따라 건너뛰는 경우가 아니라면 Ansible은 여전히 실패·건너뜀 상태의 변수를 등록해요. 태그 추가·사용 정보는 Tags를 보세요.

중첩 변수 참조하기

많은 등록 변수와 facts는 중첩된 YAML 또는 JSON 데이터 구조예요. 이런 중첩 데이터 구조의 값은 단순한 {{ foo }} 문법으로 접근할 수 없어요. 반드시 대괄호 표기법이나 점 표기법을 써야 해요.

facts에서 IP 주소를 대괄호 표기법으로 참조하려면,

'{{ ansible_facts["eth0"]["ipv4"]["address"] }}'

점 표기법으로 참조하려면,

{{ ansible_facts.eth0.ipv4.address }}

Jinja2 필터로 변수 변환하기

Jinja2 필터는 템플릿 표현식 안에서 변수의 값을 변환하게 해 줘요. 예를 들어 capitalize 필터는 전달된 값을 대문자로 시작하게 만들고, to_yaml·to_json 필터는 변수 값의 형식을 바꿔요. Jinja2에는 많은 내장 필터가 있고, Ansible은 더 많은 필터를 제공해요. 필터 예시를 더 보려면 "Using filters to manipulate data"를 참고하세요.

변수를 설정하는 위치

변수는 인벤토리, 플레이북, 재사용 파일, 역할, 명령줄 등 다양한 곳에서 정의할 수 있어요. Ansible은 찾을 수 있는 모든 가능한 변수를 로드한 다음, 변수 우선순위 규칙에 따라 적용할 변수를 골라요.

인벤토리에서 변수 정의하기

각 호스트마다 다른 변수를 개별적으로 정의하거나, 인벤토리에서 호스트 그룹의 공유 변수를 설정할 수 있어요. 예를 들어 [boston] 그룹의 모든 머신이 NTP 서버로 'boston.ntp.example.com'을 쓴다면 그룹 변수를 설정할 수 있어요. 인벤토리에서 호스트 변수와 그룹 변수를 설정하는 자세한 내용은 "How to build your inventory" 페이지에 있어요.

플레이에서 변수 정의하기

플레이북의 플레이에서 직접 변수를 정의할 수 있어요.

- hosts: webservers
  vars:
    http_port: 80

플레이에서 변수를 정의하면, 그 변수는 그 플레이에서 실행되는 작업에만 보여요.

포함 파일과 역할에서 변수 정의하기

재사용 가능한 변수 파일이나 재사용 가능한 역할에서 변수를 정의할 수 있어요. 재사용 가능한 변수 파일에 변수를 정의하면 민감한 변수가 플레이북에서 분리돼요. 이 분리 덕분에 비밀번호나 기타 민감한 개인 데이터가 노출될 위험 없이 플레이북을 형상관리(소스 컨트롤)에 저장하고 공유할 수 있어요. 재사용 파일과 역할 만들기에 대한 정보는 "Reusing Ansible artifacts"를 보세요.

외부 파일에 정의된 변수를 포함하는 예시:

---

- hosts: all
  remote_user: root
  vars:
    favcolor: blue
  vars_files:
    - /vars/external_vars.yml

  tasks:

  - name: This is just a placeholder
    ansible.builtin.command: /bin/echo foo

각 변수 파일의 내용은 단순한 YAML 딕셔너리예요. 예를 들면,

---
# in the above example, this would be vars/external_vars.yml
somevar: somevalue
password: magic

호스트별·그룹별 변수도 비슷한 파일에 둘 수 있어요. 변수 구성 방법은 "Organizing host and group variables"를 참고하세요.

런타임에 변수 정의하기

--extra-vars(또는 -e) 인자를 사용해 명령줄에서 변수를 넘겨 플레이북을 실행할 때 변수를 정의할 수 있어요. vars_prompt로 사용자 입력을 요청할 수도 있어요(Interactive input: prompts 참고). 명령줄에서 변수를 넘길 때는 아래 형식 중 하나로 변수 하나 이상을 담은 작은따옴표로 감싼 문자열을 사용하세요.

키-값 형식

key=value 문법으로 전달된 값은 문자열로 해석돼요. 불리언·정수·실수·목록 같은 비문자열 값을 전달해야 한다면 JSON 형식을 사용하세요.

ansible-playbook release.yml --extra-vars "version=1.23.45 other_variable=foo"
JSON 문자열 형식
ansible-playbook release.yml --extra-vars '{"version":"1.23.45","other_variable":"foo"}'
ansible-playbook arcade.yml --extra-vars '{"pacman":"mrs","ghosts":["inky","pinky","clyde","sue"]}'

--extra-vars로 변수를 전달할 때는 마크업(예: JSON)과 셸 양쪽에 맞게 따옴표와 기타 특수 문자를 이스케이프해야 해요.

ansible-playbook arcade.yml --extra-vars "{\"name\":\"Conan O\'Brien\"}"
ansible-playbook arcade.yml --extra-vars '{"name":"Conan O'\\''Brien"}'
ansible-playbook script.yml --extra-vars "{\"dialog\":\"He said \"I just can\'t get enough of those single and double-quotes\"!\"}"
JSON 또는 YAML 파일의 변수

특수 문자가 많다면 변수 정의를 담은 JSON 또는 YAML 파일을 사용하세요. JSON과 YAML 파일 이름 앞에 @를 붙여요.

ansible-playbook release.yml --extra-vars "@some_file.json"
ansible-playbook release.yml --extra-vars "@some_file.yaml"

변수 우선순위: 변수를 어디에 둬야 할까?

같은 이름의 변수 여러 개를 여러 곳에 설정할 수 있어요. 그렇게 하면 Ansible은 찾을 수 있는 모든 가능한 변수를 로드한 다음, 변수 우선순위에 따라 적용할 변수를 골라요. 즉 서로 다른 변수들이 특정 순서로 서로를 재정의해요.

변수 정의에 대한 가이드라인(특정 유형의 변수를 어디에 정의할지)에 합의한 팀·프로젝트는 대개 변수 우선순위 문제를 피해요. 각 변수는 한 곳에 정의해야 해요. 변수를 정의할 위치를 정하고 단순하게 유지하세요. 예시는 "Tips on where to set variables"를 보세요.

변수로 설정할 수 있는 일부 동작 매개변수는 Ansible 구성, 명령줄 옵션, 플레이북 키워드로도 설정할 수 있어요. 예를 들어 원격 장치에 연결할 때 Ansible이 쓰는 사용자는 변수로는 ansible_user, 구성 파일로는 DEFAULT_REMOTE_USER, 명령줄 옵션으로는 -u, 플레이북 키워드로는 remote_user로 정의할 수 있어요. 변수와 다른 방법으로 같은 매개변수를 정의하면 변수가 다른 설정을 재정의해요. 이 접근 방식으로 호스트별 설정이 더 일반적인 설정을 재정의하게 해 줘요. 이 다양한 설정들의 우선순위 예시와 세부 사항은 "Controlling how Ansible behaves: precedence rules"를 보세요.

변수 우선순위 이해하기

Ansible은 변수 우선순위를 적용해요. 우선순위를 낮은 순에서 높은 순(마지막에 나열된 변수가 다른 모든 변수를 재정의)으로 나열하면 다음과 같아요.

  • 명령줄 값(예: -u my_user. 변수는 아님)
  • 역할 기본값(Role directory structure에 정의)
  • 인벤토리 파일 또는 스크립트 그룹 변수
  • 인벤토리 group_vars/all
  • 플레이북 group_vars/all
  • 인벤토리 group_vars/*
  • 플레이북 group_vars/*
  • 인벤토리 파일 또는 스크립트 호스트 변수
  • 인벤토리 host_vars/*
  • 플레이북 host_vars/*
  • 호스트 facts와 캐시된 set_facts
  • 플레이 변수
  • 플레이 vars_prompt
  • 플레이 vars_files
  • 역할 변수(Role directory structure에 정의)
  • 블록 변수(블록 안 작업만)
  • 작업 변수(해당 작업만)
  • include_vars
  • 등록 변수와 set_facts
  • 역할(및 include_role) 매개변수
  • include 매개변수
  • Extra vars(예: -e "user=my_user")(항상 최우선)

일반적으로 Ansible은 더 최근에, 더 적극적으로, 더 명시적인 범위로 정의된 변수에 우선순위를 줘요. 역할 안 defaults 폴더의 변수는 쉽게 재정의돼요. 역할의 vars 디렉터리 안의 모든 것은 네임스페이스에서 그 변수의 이전 버전을 재정의해요. 호스트·인벤토리 변수는 역할 기본값을 재정의하지만, vars 디렉터리나 include_vars 작업 같은 명시적 include는 인벤토리 변수를 재정의해요.

Ansible은 인벤토리에 설정된 다른 변수들을 병합해서 더 구체적인 설정이 더 일반적인 설정을 재정의하게 해요. 예를 들어 그룹 변수로 지정된 ansible_ssh_user는 호스트 변수로 지정된 ansible_user에 의해 재정의돼요. 인벤토리에 설정된 변수의 우선순위 세부 사항은 "How variables are merged"를 보세요.

참고: 섹션 내에서 변수를 재정의하면 이전 인스턴스를 덮어써요. 여러 그룹이 같은 변수를 가지면 마지막에 로드된 것이 이깁니다. 플레이의 vars: 섹션에서 변수를 두 번 정의하면 두 번째 것이 이겨요.

위 텍스트는 기본 구성 hash_behavior=replace를 설명해요. 부분적으로만 덮어쓰려면 merge로 전환하세요.

변수 범위 지정

값에 원하는 범위에 따라 변수를 설정할 위치를 정할 수 있어요. Ansible에는 세 가지 주요 범위가 있어요.

  • Global(전역): 구성, 환경 변수, 명령줄로 설정
  • Play: 각 플레이와 포함된 구조, vars 항목(vars, vars_files, vars_prompt), 역할 기본값과 vars
  • Host(호스트): 인벤토리, include_vars, facts, 등록된 작업 출력처럼 호스트에 직접 연결된 변수

템플릿 안에서는 호스트에 범위가 있는 모든 변수와 등록 변수, facts, 매직 변수에 자동으로 접근할 수 있어요.

변수를 설정할 위치에 대한 팁

변수를 정의할 위치는 값에 대해 원하는 제어 수준에 따라 정해야 해요.

  • 지리·행동과 관련된 변수는 인벤토리에서 설정해요. 그룹이 역할을 호스트에 매핑하는 엔티티인 경우가 많으니, 역할에 정의하기보다 그룹에 변수를 설정할 수 있어요. 자식 그룹이 부모 그룹을 재정의하고, 호스트 변수가 그룹 변수를 재정의한다는 점을 기억하세요.

  • 공통 기본값은 group_vars/all 파일에 설정해요. 인벤토리에서 호스트·그룹 변수를 구성하는 방법은 "Organizing host and group variables"를 참고하세요. 그룹 변수는 일반적으로 인벤토리 파일 옆에 두지만, 동적 인벤토리가 반환하거나(Working with dynamic inventory) AWX 또는 Red Hat Ansible Automation Platform에서 UI·API로 정의할 수도 있어요.

---
# file: /etc/ansible/group_vars/all
# this is the site wide default
ntp_server: default-time.example.com
  • 위치별 변수는 group_vars/my_location 파일에 설정해요. 모든 그룹은 all 그룹의 자식이므로, 여기 설정된 변수는 group_vars/all에 설정된 것을 재정의해요.
---
# file: /etc/ansible/group_vars/boston
ntp_server: boston-time.example.com
  • 한 호스트가 다른 NTP 서버를 쓴다면 host_vars 파일에 설정할 수 있고, 그게 그룹 변수를 재정의해요.
---
# file: /etc/ansible/host_vars/xyz.boston.example.com
ntp_server: override.example.com
  • 정의되지 않은 변수 에러를 피하려면 역할에서 기본값을 설정해요. 역할을 공유하면 다른 사용자가 roles/x/defaults/main.yml에 추가한 합리적인 기본값에 의존할 수 있고, 인벤토리나 명령줄에서 쉽게 재정의할 수도 있어요. 예:
---
# file: roles/x/defaults/main.yml
# if no other value is supplied in inventory or as a parameter, this value will be used
http_port: 80
  • 값이 그 역할에서 반드시 쓰이고 인벤토리 변수에 재정의되지 않도록 역할에서 변수를 설정해요. 역할을 다른 사람과 공유하지 않는다면 포트 같은 앱별 동작을 roles/x/vars/main.yml에 이렇게 정의할 수 있어요. 역할을 공유한다면 여기에 변수를 두는 게 재정의를 더 어렵게 만들지만, 역할에 매개변수를 넘기거나 -e로 변수를 설정하면 여전히 재정의할 수 있어요.
---
# file: roles/x/vars/main.yml
# this will absolutely be used in this role
http_port: 80
  • 최대한의 명확성·유연성·가시성을 위해 역할을 호출할 때 변수를 매개변수로 전달해요. 이 접근 방식은 역할에 존재하는 기본값을 재정의해요. 예:
roles:
   - role: apache
     vars:
        http_port: 8080

이 플레이북을 읽으면 변수를 설정하거나 기본값을 재정의하기로 선택했음이 분명해져요. 여러 값을 전달할 수도 있고, 같은 역할을 여러 번 실행할 수 있어요("Running a role multiple times in one play" 참고).

roles:
   - role: app_user
     vars:
        myname: Ian
   - role: app_user
     vars:
       myname: Terry
   - role: app_user
     vars:
       myname: Graham
   - role: app_user
     vars:
       myname: John
  • 한 역할에서 설정한 변수는 이후 역할에서도 사용할 수 있어요. 역할의 vars 디렉터리(Role directory structure에 정의)에서 변수를 설정하고 다른 역할이나 플레이북의 다른 곳에서 쓸 수 있어요.
roles:
   - role: common_settings
   - role: something
     vars:
       foo: 12
   - role: something_else

변수 네임스페이스를 피하기 위한 몇 가지 보호 장치가 있어요. 이 예시에서 'common_settings'에 정의된 변수는 'something'과 'something_else' 작업에 사용할 수 있지만, 'something'의 작업은 'common_settings'가 foo를 20으로 설정하더라도 foo가 12로 설정돼 있어요.

변수 우선순위를 걱정하는 대신, 변수를 어디에 설정할지 정할 때 얼마나 쉽게·얼마나 자주 재정의하고 싶은지를 생각해 보세요. 어떤 다른 변수가 정의돼 있는지 확실하지 않고 특정 값이 필요하다면 --extra-vars(-e)를 써서 다른 모든 변수를 재정의하세요.

고급 변수 문법 사용하기

변수를 선언하고 Ansible이 쓰는 YAML 파일에 들어가는 데이터를 더 잘 제어하는 고급 YAML 문법에 대한 정보는 "Advanced playbook syntax"를 보세요.

더 알아보기 (Learn more)

  • Ansible playbooks — 플레이북 소개
  • Conditionals — 플레이북의 조건문
  • Using filters to manipulate data — Jinja2 필터와 그 용도
  • Loops — 플레이북에서 반복하기
  • Roles — 역할로 플레이북 구성하기
  • General tips — 플레이북 팁과 요령
  • Special Variables — 특수 변수 목록
  • Communication — 질문·도움이 필요하면 Ansible 커뮤니케이션 가이드 방문