Playbook 을 작성한 상태 입력되는 값에 따라 동작을 변경하여 반복적인 사용이 가능하도록 설계하기 위해선 변수를 정의하고 사용할 수 있어야 한다. 변수를 어디에 정의하느냐에 따라서 그룹, 호스트, 플레이 변수가 되며 각 변수들이 적용되는 우선순위가 정해져 있다.
그 외에 플레이북이 실행되면서 결과 값을 저장하는 변수 등도 사용할 수 있다.
이러한 변수를 사용하면 플레이북을 재사용할 수 있고 사용자로부터 받은 값도 적용하기 쉬워진다. 이에 대한 내용을 정리하고자 한다.
그룹 변수
그룹 변수는 인벤토리에 정의된 호스트 그룹에 적용하는 변수를 의미한다.
즉 인벤토리에 선언되었으며, 선언하고자 하는 그룹명과 함께 :vars 라는 문자열을 추가하여 변수를 선언하면 그룹변수가 된다.
[backend-api]
backend-api-01.wookkong.net
backend-api-02.wookkong.net
[backend-gateway]
backend-gateway-01.wookkong.net
backend-gateway-02.wookkong.net
[all:children]
backend-api
backend-gateway
[all:vars]
user=ansible
위와 같은 인벤토리 구조가 있다고 가정해보자. backend-api, backend-gateway 에 각각 2개의 호스트를 가지고 있으며, 각 그룹은 all 이라는 그룹에 속하게 된다. (:children 을 사용하면 그룹들을 포함 시킬 수 있다.)
all 그룹에 :vars 라는 문자열을 추가하여 모든 그룹에서 user 변수는 ansible 의 값을 가지고 있도록 인벤토리에서 선언해주었다.
이는 그룹 변수가 된다.
위와 같이 그룹 변수로 선언했다면 플레이북에서는 겹 중괄호 를 사용하여 user 변수를 사용할 수 있다.
해당 user 변수를 사용하여 user 를 생성하려면 아래와 같이 플레이북을 작성한다.
---
- hosts: all
tasks:
- name: create_user {{ user }}
ansible.builtin.user:
name: "{{ user }}"
state: present
ansible.builtin.user 내장 모듈을 사용하여 선언했던 user 변수의 이름을 가진 user 를 생성하는 방식이다. 주의할 점은 겹 중괄호 사이에 한 칸씩 띄어서 작성해주어야 한다.
hosts 는 all 을 선언해주었기 때문에 all 그룹의 :vars 를 가진 해당 변수가 플레이북 실행 시 적용되어 실행이 된다.
호스트 변수
그룹 변수가 :vars 를 사용했던 그룹 전체가 사용할 수 있었다면 호스트 변수는 변수를 해당 호스트에서만 사용할 수 있다.
앞에서 작성했던 inventory 에서 호스트 변수를 추가해보면 아래와 같다.
[backend-api]
backend-api-01.wookkong.net
backend-api-02.wookkong.net
[backend-gateway]
backend-gateway-01.wookkong.net user=ansible1
backend-gateway-02.wookkong.net
[all:children]
backend-api
backend-gateway
[all:vars]
user=ansible
마찬가지로 호스트변수가 잘 적용되는지 확인하기 위해선 위에서 작성했던 플레이북의 hosts 를 변경하여 확인해볼 수 있다.
---
- hosts: backend-gateway-01.wookkong.net
tasks:
- name: create_user {{ user }}
ansible.builtin.user:
name: "{{ user }}"
state: present
호스트 변수를 지정한 호스트만 플레이북을 실행하도록 hosts 를 지정하였다. 해당 플레이북을 실행하면 user 는 ansible1로 실행된다.
all:vars 를 통해 user 변수의 값이 ansible 로 설정되었음에도 호스트변수인 ansible1 로 플레이북이 실행되는 것을 볼 때 그룹변수 보다 호스트변수의 우선순위가 더 높음을 알 수 있다.
플레이 변수
플레이 변수는 말 그대로 플레이북 내에서 선언되는 변수이다. 앞에서 확인했던 그룹변수, 호스트변수는 모두 인벤토리 내에서 작성되었지만 플레이 변수는 플레이북에서 작성 된다.
---
- hosts: all
vars:
user: ansible2
tasks:
- name: create_user {{ user }}
ansible.builtin.user:
name: "{{ user }}"
state: present
이런 식으로 hosts 밑에 vars 라는 문단이 추가되고 user: ansible2 라는 변수 선언이 추가되었다.
마찬가지로 inventory 에는 그룹변수와 호스트변수가 작성되어 있지만 해당 플레이북을 실행시키면 user 의 값은 ansible2 로 실행된다.
즉 플레이 변수의 우선순위는 그룹 변수, 호스트 변수보다 높은 것을 알 수 있다.
만약 변수의 양이 많아지고 플레이북도 길어진다면 우리가 프로그래밍을 할 때 처럼 코드가 길어지고 복잡하게 될 것이다.
그렇기 때문에 플레이북에서도 별도로 파일을 분리하여 import 할 수 있다.
해당 플레이북이 저장된 디렉토리에서 vars 라는 디렉토리 생성, users.yml 이라는 파일을 만든다. 그 후 user: ansible4 라는 내용으로 저장한다면 vars/users.yml 파일을 사용할 수 있게 된다.
---
- hosts: all
vars_files:
- vars/users.yml
tasks:
- name: create_user {{ user }}
ansible.builtin.user:
name: "{{ user }}"
state: present
vars 대신에 vars_files 를 추가하고 해당 경로를 입력해주면 된다. 만약 호스트 마다 변수의 값이 달라지는 분기가 필요하다면 각 변수를 담은 파일을 분리하는 등 다양하게 활용이 가능할 것이다.
추가 변수
추가 변수는 외부에서 플레이북을 실행할 때 파라미터로 넘겨주는 변수이다. 즉 inventory 나 playbook 에 작성해놓는 것이 아닌 실행할 때 즉석에서 넘겨주는 파라미터라고 볼 수 있다.
커맨드로 실행한다면 아래와 같다.
ansible-playbook -e user=ansible5 create-user.yml
-e (--extra_vars) 옵션은 추가 변수를 사용하겠다는 옵션이며 해당 커맨드에서는 user=ansible5 라는 추가 변수를 작성해주었다.
해당 명령어로 실행하게 되면 ansible5 라는 user 가 생성되는 것을 확인할 수 있으며, 앞에서 작성했던 그룹 변수, 호스트 변수, 플레이 변수를 모두 무시하며 실행되기 때문에 우선순위가 가장 높다고 볼 수 있다.
정리하자면
추가 변수 > 플레이 변수 > 호스트 변수 > 그룹 변수
우선순위를 가지고 있으며 해당 우선순위에 의해 변수 값이 결정되고 실행된다. 상황에 맞게 변수를 사용하면 하나의 플레이북을 계속해서 재사용하여 편리하게 자동화를 구축할 수 있을 것 같다.