Tag Archives: Ansible

Ansible Playbook 정리

ansible_logo

플레이북은 Ansible의 설정, 배포, 통합 언어입니다. 이것들을 통해 당신이 원격 시스템에 적용하고자 하는 정책이나 IT 프로세스하에 단계별로 설정 작업을 할 수 있습니다.

Ansible 모듈이 당신의 작업상에서의 툴이라면 플레이북은 설계 계획에 해당합니다. 기본적으로 플레이북은 원격 서버들에 대한 설정과 배포를 관리하는데 사용됩니다. 좀 더 깊이 알아보면 그것들을 통해 순차적인 다양한 계층별 배포를 롤링 업데이트를 통해 실현할 수 있으며 다른 호스트들에게 작업을 위임하거나 모니터링 서버와 로드 밸런싱 서버들과 상호 작용을 할 수 있습니다.

이것들에 대한 많은 정보들에 대해서 다루겠지만 여기서 한번에 습득해야 할 필요는 없습니다. 우선 작게 시작한 뒤에 나중에 필요로 할때마다 필요한 기능을 추가하면 될 것입니다.

플레이북은 사람이 읽기 쉽게 만들어져 있으며 기본적인 텍스트 언어로 만들어져 있습니다. 플레이북과 포함된 파일들을 관리하는 방법은 다양하며 Ansible을 사용하는 많은 사람들이 선호하는 방식을 몇가지 제안할 것입니다.

우선 플레이북 예제[Example Playbooks]을 함께 확인해 보길 권장합니다. 이 예제에서는 다양한 개념을 넣는 방법에 대한 모범 사례를 보여줍니다.

플레이북에 대해

플레이북은 애드혹 테스트 실행 모드와는 완벽하게 다른 사용방법이며 특히 강력한 사용 방법입니다. 간단히 말해 플레이북은 정말 간단하게 설정을 관리하고 다수의 머신에 대한 배포 시스템에 대한 기본적인 단위입니다. 기존에 존재해왔던것과 달리 복잡한 어플리케이션 형태의 배포에 매우 적합합니다.

플레이북은 설정을 정의할 수 있으며 특정 머신의 집합을 오가며 다른 작업을 수행하도록 수동으로 작업 순서를 설정하는것도 가능합니다. 이때에 작업은 동기 또는 비동기로 수행할 수 있습니다.

/usr/bin/ansible 명령을 통한 애드혹 테스크를 실행하는것에 반해 플레이북은 소스 컨트롤을 통해 보관하거나 당신의 설정을 내보내거나 원격 시스템을 구성하는데 보장되는데 더욱 적합합니다.

플레이북을 통해 이러한 기술들을 구현하는 방법은 [Ansible-Example 저장소]에 정리가 되어있습니다. 이것들을 함께 확인해보길 추천합니다.

풀레이북 언어 예제

플레이북은 YAML 포맷으로 표현되며 프로그래밍 언어나 스크립트가 아닌 설정이나 프로세스에 대한 모델에 대한 정의를 표현한 최소한의 문법으로 구성되어있습니다. 각각의 플레이북은 리스트안의 한개 이상의 “플레이”로 구성됩니다.

이 플레이의 목표는 호스트의 그룹을 잘 정의된 Ansible내에서 테스크로 불리는 역할(Role)에 매핑해주는 것입니다. 기본적으로 각 테스크는 Ansible의 모듈을 호출하는것에 지나지 않습니다.

플레이북의 다수의 플레이들을 구성하는것을 통해, 다수의 머신들에 대한 통합 배포를 하고 웹서버 그룹의 모든 머신에 특정 작업을 수행하고 데이터베이스 서버 그룹에 특정 작업을 수행하고 다음에 추가로 웹서버 그룹에 또다른 작업을 수행하는식의 수행이 가능합니다.

“플레이”는 스포츠에 비유해 볼 수 있습니다. 당신은 당신의 시스템들에 대해 각기 다른 굉장히 많은 플레이를 가질 수 있으며 각기 다른 플레이를 각각 다른 시간에 수행할 수 있습니다.

시작하시는 분들을 위해 하나의 플레이를 보도록 하겠습니다.

---
- hosts: webservers
  vars:
    http_port: 80
    max_clients: 200
  remote_user: root
  tasks:
  - name: ensure apache is at the latest version
    yum: name=httpd state=latest
  - name: write the apache config file
    template: src=/srv/httpd.j2 dest=/etc/httpd.conf
    notify:
    - restart apache
  - name: ensure apache is running (and enable it at boot)
    service: name=httpd state=started enabled=yes
  handlers:
    - name: restart apache
      service: name=httpd state=restarted

우리는 물론 YAML의 딕셔너리 타입을 사용하여 각 모듈의 인자들을 여러 라인으로 분리해 정의하는것도 가능합니다. 이것은 정말 긴 파라미터를 가지고 있거나 많은 파라미터를 가지는 경우 구조적으로 보기 좋게 정리해주는 장점이 있습니다. 다음은 YAML 딕셔너리를 적용하여 기존의 key=value 형태를 분리해본 예제입니다.

---
- hosts: webservers
  vars:
    http_port: 80
    max_clients: 200
  remote_user: root
  tasks:
  - name: ensure apache is at the latest version
    yum:
      name: httpd
      state: latest
  - name: write the apache config file
    template:
      src: /srv/httpd.j2
      dest: /etc/httpd.conf
    notify:
    - restart apache
  - name: ensure apache is running
    service:
      name: httpd
      state: started
  handlers:
    - name: restart apache
      service:
        name: httpd
        state: restarted

플레이북은 다수의 플레이를 포함할 수 있습니다. 만약 당신이 첫번째로 웹서버를 타겟으로 작업을 수행하고 이후에 데이터베이스 서버의 작업을 수행한다면 다음과 같은 모습이 될 것입니다.

---
- hosts: webservers
  remote_user: root

  tasks:
  - name: ensure apache is at the latest version
    yum: name=httpd state=latest
  - name: write the apache config file
    template: src=/srv/httpd.j2 dest=/etc/httpd.conf

- hosts: databases
  remote_user: root

  tasks:
  - name: ensure postgresql is at the latest version
    yum: name=postgresql state=latest
  - name: ensure that postgresql is started
    service: name=postgresql state=running

당신은 각 호스트 그룹간에 전환을 할 때 어떤 유저로 로그인할 지 sudo 를 수행할지 말지 이런것들을 결정할 수 있습니다. 플레이는 플레이북에 정의되어있는데로 위에서 아래의 순서로 수행이 됩니다. 다음은 플레이북의 다양한 기능들에 대해 자세히 알아보도록 하겠습니다.

기본

호스트와 유저

플레이북의 각각의 플레이를 통해서 당신의 인프라스트럭쳐중에 원하는 타겟에 대한 머신을 선택할 수 있고 어떤 원격 유저로 해당 작업을 수행할지 선택할 수 있습니다.

이 hosts 라인은 [Patterns] 문서에 설명했듯이 하나 이상의 그룹이나 호스트 패턴을 콜론(:)으로 분리하여 정의한 리스트입니다. remote_user는 유저 계정의 이름입니다.

---
- hosts: webservers
  remote_user: root

각각의 테스크별로 작업을 수행할 유저를 따로 정의할 수 있습니다.

---
- hosts: webservers
  remote_user: root
  tasks:
    - name: test connection
      ping:
      remote_user: yourname

다른 유저의 권한으로 작업을 수행하는 것도 가능합니다. [Become/Privilege Escalation]을 참고해주세요.

---
- hosts: webservers
  remote_user: yourname
  sudo: yes

물론 모든 플레이 대신에 특정 테스크에 한해 sudo를 수행할 수도 있습니다.

---
- hosts: webservers
  remote_user: yourname
  tasks:
    - service: name=nginx state=started
      become: yes
      become_method: sudo

당신의 계정으로 로그인 한 뒤 root 대신에 원하는 다른 계정으로 전환해서 작업을 수행하는것도 가능합니다.

---
- hosts: webservers
  remote_user: yourname
  become: yes
  become_user: postgres

또한 기존의 sudo 대신에 su와 같은 다른 권한 상승 명령을 지정할수도 있습니다.

---
- hosts: webservers
  remote_user: yourname
  become: yes
  become_method: su

만약 sudo를 수행하는데 다른 비밀번호가 필요하다면 ansible-playbook을 실행할 때 –ask-become-pass 옵션을 사용하거나 기존에 사용되던 –ask-sudo-pass를 사용할 수 있습니다. 만약 플레이북을 수행중에 행 걸린상태로 보여질 때 확인해 보면 대부분이 권한 상승을 위한 비밀번호 입력을 기다리는 상태일 경우가 많습니다. 이때엔 컨트롤 C를 눌러 일단 종료시킨 뒤에 다시 적절한 비밀번호와 함께 수행하시면 됩니다.

테스트 목록

각각의 플레이는 테스크의 목록을 가집니다. 테스크는 다음의 테크스로 이동하기 전에 호스트 패턴에 매칭되는 모든 머신들에 대해서 한번에 하나씩 수행됩니다. 플레이를 구동함과 동시에 여기서 반드시 이해해야 할 부분은 모든 호스트가 동일한 테스크를 명령받게 된다는 것입니다. 이것이 플레이가 특정 선택된 호스트를 테스크에 매핑하는 목적입니다.

위에서 아래로 플레이북이 실행될 때, 전체 플레이북의 작업을 호스트에 수행중에 실패가 발생한다면 간단히 플레이북의 문제가 되는 부분을 수정한 뒤 다시 실행하면 됩니다.

각 테스크의 목적은 특별히 지정한 인자들을 사용하여 모듈을 실행하는 것입니다. 위에서 언급했듯이 변수들은 인자를 통해 각 모듈에 전달 될 수 있습니다.

모듈들을 “멱등”으로 동작합니다. 이게 무슨 말이냐면 당신이 플레이북을 여러번 실행하게 될 때 시스템의 상태를 가져와서 변화된 부분만을 다시 수행하도록 합니다. 이것은 플레이북을 반복 실행해도 매우 안전하게 만들어줍니다. 이들은 당신이 원하지 않는 변화를 일으키지 않을 것입니다.

commandshell 모듈은 일반적으로 chmod, setsebool과 같은 문제가 되지 않을 명령을 재실행 하게 됩니다. 하지만 creates 플래그를 사용하여 이러한 모듈들이 멱등으로 동작하도록 할 수 있습니다.

모든 테스크는 플레이북이 실행될 때 외부에 노출될 name을 가집니다. 이러한 출력 메시지는 사람을 위해 출력되는것이므로 각각의 단계를 설명하는 좋은 문구여야 합니다. 이 name이 지정되지 않는다면 작업을 수행중에 출력되는 메시지가 사용됩니다.

테스크는 예전에 사용되던 action: module options 형태로 정의가 가능하지만 좀 더 사용하기 편리한 module: options 형태로 정의하시기를 추천합니다.

다음은 가장 많이 사용되는 key=value 인자를 사용한 서비스 모듈의 기본적인 테스크 형태입니다.

tasks:
  - name: make sure apache is running
    service: name=httpd state=running

commandshell 모듈은 유일하게 key=value 형태로 사용하지 않고 명령어를 그대로 사용하는 모듈들입니다. 이 명령들은 당신이 예상하는데로 사용이 간단합니다.

tasks:
  - name: disable selinux
    command: /sbin/setenforce 0

command 와 shell 모듈은 명령의 실행결과 반환 코드를 통해 명령의 성공/실패 여부를 판단하게 됩니다. 만약 당신의 명령이 적절한 종료 코드를 구현하고 있지 않다면 다음과 같은 방법을 취할 수 있습니다.

tasks:
  - name: run this command and ignore the result
    shell: /usr/bin/somecommand || /bin/true

또는 다음과 같은 방법이 있습니다.

tasks:
  - name: run this command and ignore the result
    shell: /usr/bin/somecommand
    ignore_errors: True

이 액션 라인이 너무 길다면 당신이 편한데로 띄어쓰기와 들여쓰기를 사용하여 줄나눔을 할 수 있습니다.

tasks:
  - name: Copy ansible inventory file to client
    copy: src=/etc/ansible/hosts dest=/etc/ansible/hosts
            owner=root group=root mode=0644

당신이 vars 섹션에서 정의해 두었던 vhost 변수를 액션 라인들에 다음과 같은 형태로 사용가능합니다.

tasks:
  - name: create a virtual host file for {{ vhost }}
    template: src=somefile.j2 dest=/etc/httpd/conf.d/{{ vhost }}

이러한 변수들을 뒤에서 설명할 템플릿 안에서도 사용 가능합니다. 지금까지 플레이를 통해 모든 테스크를 플레이북에 정의하는 기초적인 방법을 알아보았습니다만 include 문법을 사용해서 테스크별로 쪼개는것이 더 좋은 방법입니다. 해당 부분은 뒤에서 다시 설명드리겠습니다.

액션 단축 표기법

Ansible은 0.8 이후의 버전부터 다음과 같은 표기법을 선호합니다.

template: src=templates/foo.j2 dest=/etc/foo.conf

만약 이전 버전을 사용해야만 한다면 다음과 같은 표기법만이 사용 가능합니다.

action: template src=templates/foo.j2 dest=/etc/foo.conf

하지만 이 예전 표기법은 현재까지 Deprecated 되지 않고 지원되고 있습니다.

핸들러: 변경에 대한 작업을 수행

우리가 언급했다시피 모듈들은 멱등으로 쓰여지게 되며 원격 시스템에 변화가 일어났는지 여부에 따라 작업을 진행할지 말지 결정하게 됩니다. 플레이북은 이러한 것을 식별할 수 있으며 변화에 대한 결과를 사용할 수 있는 기본적인 이벤트 시스템을 갖추고 있습니다.

이 “통지” 액션은 플레이북의 테스크 블록중에 마지막에서 실행되며 많은 다른 테스크들이 실행될 때 한번만 실행됩니다. 예를 들어 다수의 리스소들이 적용하는 경우가 있다고 할 때 그중에 변경된 아파치 웹서버의 설정 파일이 존재하고 아파치가 재실행되어야 적용될 수 있습니다. 하지만 이 설정 파일이 변경되지 않았다면 아파치는 불필요한 재시작을 수행하지 않을것입니다.

다음은 컨텐츠 파일이 변경되었을 경우에만 두 서비스를 재시작 하는 예제입니다.

- name: template configuration file
  template: src=template.j2 dest=/etc/foo.conf
  notify:
     - restart memcached
     - restart apache

테스크의 notify 섹션은 작업 수행후에 실행할 핸들러를 호출합니다.

핸들러는 실제로는 글로벌하게 유니크한 이름을 갖는 일반적인 테스크와 다른게 없는 테스크의 목록입니다. 핸들러는 통지가 무엇을 통지해야 하는지를 정의합니다. 아무것도 핸들러를 통지하지 않는 경우 아무것도 실행되지 않습니다. 특정 플레이의 테스크가 완료된 후에 한번만 실행됩니다.

다음은 핸들러 섹션의 예제입니다.

handlers:
    - name: restart memcached
      service: name=memcached state=restarted
    - name: restart apache
      service: name=apache state=restarted

핸들러는 서비스를 재시작하거나 리부팅 하는 작업을 수행하는데 최적입니다. 아마 이러한 경우가 아닌 이상 사용할 일이 없을 것입니다.

역할은 나중에 다시 이야기 하겠지만 여기서 언급할 필요가 있는 부분이 있습니다.

  • pre_tasks, tasks, post_tasks 섹션을 통해 통지되는 핸들러는 그들이 통지된 섹션의 마지막에 자동으로 큐의 핸들러들은 플러시됩니다.
  • roles 섹션을 통해 통지되는 핸들러들은 다른 어떤 tasks 이전에 수행되지 않고 tasks 섹션의 마지막에 자동으로 플러시 됩니다.

만약 지금까지의 모든 핸들러들을 즉시 플러시 하고 싶다면 1.2 부터는 다음과 같은 방법을 사용할 수 있습니다.

tasks:
   - shell: some tasks go here
   - meta: flush_handlers
   - shell: some other tasks

위의 예제는 meta 구문에 도달하는 순간 지금까지 큐에 쌓인 핸들러들을 곧바로 수행합니다. 이것은 조금 특이한 경우지만 때때로 매우 유용하게 사용될 수 있습니다.

플레이북을 실행하기

지금까지 플레이북의 문법에 대해 알아보았습니다. 그럼 어떻게 이 플레이북을 실행할까요? 간단합니다. 다음의 병렬로 레벨 10의 설정으로 플레이북을 실행하는 방법입니다.

ansible-playbook playbook.yml -f 10

Ansible-Pull

Ansible의 아키텍쳐를 뒤집어서 설정을 밀어넣어주는 방식 말고 노드들이 중앙에 위치한 서버로부터 설정을 끌어가도록 할 수 있습니다.

ansible-pull은 git로부터 설정 명령들이 저장된 저장소를 체크아웃하고 해당 컨텐츠에 적절한 ansible-playbook을 실행하는 작업 스크립트입니다. 이 체크아웃을 할 저장소의 위치를 적절히 분산하여 ansible-pull의 스케일을 무한대로 키울 수 있습니다. ansible-pull –help 명령을 사용하여 자세한 사용방법을 확인하시길 바랍니다.

[Clever Playbook]을 보시면 푸시 모드를 사용하여 ansible-pull을 crontab에 등록하는 과정을 확인할 수 있습니다.

팁과 트릭

플레이북의 실행 결과를 보시면 마지막에 정리된 결과가 출력되고 몇개의 타겟에 실행이 되었고 일반적인 실패와 치명적인 “unreached” 통신 실패가 함께 표기가 됩니다. 만약 성공한 모듈뿐만 아니라 실패한 모듈의 상세한 출력을 보고 싶다면 –verbose 플래그를 사용하시면 됩니다. 이 플래그는 0.5 이후의 버전부터 지원되고 있습니다.

cowsay 패키지가 설치되어있다면 Ansible 플레이북의 실행결과가 크게 업그레이드 됩니다. 한번 시도해 보시기 바랍니다. 플레이북을 실행하기 전에 어떤 호스트들에 영향을 끼치게 될지 확인 하고 싶다면 다음의 명령을 사용하시면 됩니다.

ansible-playbook playbook.yml --list-hosts

참고 : http://docs.ansible.com/ansible/playbooks_intro.html

 

Ansible Inventory 알아보기

ansible_logo

Ansible은 당신의 인프라스트럭쳐에 포함된 다수의 시스템들에 대하여 한번에 작업들을 수행할 수 있게 해줍니다. 이것은 Ansible의 인벤토리 파일에 정의되어있는 시스템 목록들의 부분을 선택하여 수행할 수 있습니다. 이 인벤토리 설정 파일은 기본적으로 /etc/ansible/hosts에 정의되어있습니다.

이 하나의 인벤토리 설정파일 뿐 아니라 다수의 설정파일을 한번에 사용하는것도 가능하며(아래에서 설명할 예정) 인벤토리를 동적으로 또는 클라우드 소스를 통해 땡겨서 사용하는 것도 가능합니다. 자세한 내용은 [Dynamic Inventory]를 참고해주세요.

호스트와 그룹

/etc/ansible/hosts 파일의 포맵은 마치 INI 파일의 설정과 동일한 형태를 띄고 있습니다.

mail.example.com

[webservers]
foo.example.com
bar.example.com

[dbservers]
one.example.com
two.example.com
three.example.com

여기서 어떤 시점에 어떤 목적을 수행할지에 따라 결정되어진 시스템의 묶음 단위로 나누어 대괄호로 지정된 그룹 이름별로 나누는것이 가능합니다. 시스템들을 웹서버 또는 디비서버가 될수 있는 시스템이 존재할 수 있듯이 하나 이상의 그룹에 넣는것도 가능합니다. 만약 이렇게 할 경우 이 시스템은 모든 모든그룹에 포함될수 있을 것이며 우선순위 설정에 대해서는 다음 챕터에서 다루도록 하겠습니다.

만약 당신의 시스템이 일반적으로 쓰이는 SSH 포트를 사용하지 않고 다른 포트를 사용할 경우 호스트 이름 뒤에 콜론을 사용하여 다른 포트를 지정할 수 있습니다. SSH 설정파일안의 포트 목록은 paramiko 연결에서는 사용되지 않겠지만 openssh 연결에서는 사용될 것입니다.

이것을 명시적으로 지정하기 위해서는 기본포트를 사용하지 않는 시스템들에 대해 다음과 같이 지정해주길 권장합니다.

badwolf.example.com:5309

만약 당신의 서버가 정적 IP만을 가지고 있고 이 서버에 hosts파일에 지정해둔 별칭과 동일하게 지정하여 사용하고 싶거나 혹은 SSH 터널을 통해 통신하고 싶을 때 다음과 같이 설정할 수 있습니다.

jumper ansible_port=5555 ansible_host=192.168.1.50

위의 예시는 Ansible이 호스트 별칭 jumper(심지어 실제 호스트 이름이 아니어도 상관없음)를 192.168.1.50에 포트 5555로 다루도록 합니다. 이는 특정 변수로 지정하기 위한 인벤토리 파일의 기능이기도 합니다. 일반적으로 말해 이는 당신의 시스템 정책을 나타내는 변수들을 지정하는 최선의 방법은 아닙니다. 이부분은 뒤에서 다시 다루도록 하겠습니다.

다수의 서버를 지정하려면 어떻게 할까요? 만약 비슷한 패턴을 가진 다수의 호스트가 있다면 각각의 호스트 이름을 적어주는것보다 다음의 방법을 사용할 수 있습니다.

[webservers]
www[01:50].example.com

당신이 원하는데로 범위를 포함하여 앞자리는 0으로 채우거나 제거하는 숫자로 된 패턴을 지정할 수 있습니다. 또한 알파벳 형태의 범위 지정도 가능합니다.

[databases]
db-[a:f].example.com

또한 각각의 연결에 대해 호스트별로 접속할 유저를 지정하는것도 가능합니다.

[targets]
localhost              ansible_connection=local
other1.example.com     ansible_connection=ssh        ansible_user=mpdehaan
other2.example.com     ansible_connection=ssh        ansible_user=mdehaan

위에서 언급했듯이 이러한 인벤토리 파일을 지정하는것은 짧고 단순합니다. 이제 이것들을 어떻게 “host_vars” 디렉토리에 각각의 파일로 저장할 수 있는지 알아보겠습니다.

호스트 변수

위에서 언급했던것처럼 뒤에 나올 플레이북에서 사용될 호스트에 변수를 지정하는것은 쉽습니다.

[atlanta]
host1 http_port=80 maxRequestsPerChild=808
host2 http_port=303 maxRequestsPerChild=909

그룹 변수

변수들을 하나의 그룹에 한번에 적용하는것도 가능합니다.

[atlanta]
host1
host2

[atlanta:vars]
ntp_server=ntp.atlanta.example.com
proxy=proxy.atlanta.example.com

그룹의 그룹, 그리고 그룹 변수

:children 접미사를 사용하여 그룹의 하위 그룹을 만드는것도 가능합니다. 또한 이렇게 정의한 그룹에 위에서 언급한것과 같이 :vars 를 이용하여 변수를 지정해주는것 역시 가능합니다.

[atlanta]
host1
host2

[raleigh]
host2
host3

[southeast:children]
atlanta
raleigh

[southeast:vars]
some_server=foo.southeast.example.com
halon_system_timeout=30
self_destruct_countdown=60
escape_pods=2

[usa:children]
southeast
northeast
southwest
northwest

만약 리스트나 해시 데이터 형태로 보관하고 싶거나, 그룹별로 다른 인벤토리 파일을 사용하고 싶을 경우 다음 섹션을 참고해주시기 바랍니다.

호스트 그룹 데이터에 맞춰 설정파일 쪼개기

Ansible을 실무에 사용하면서 추천되는 방법중에 변수들을 메인 인벤토리 파일에 저장하지 않는것이 있습니다. INI 파일에 직접 변수를 지정하는것 외에도 호스트와 그룹 변수를 인벤토리 파일의 상대적인 위치에 개별 파일로 저장하는 방법도 가능합니다.

이러한 변수 파일은 YAML 포맷으로 되어있습니다. 사용가능한 확장자로는 “.yml”, “.yaml”, “.json” 또는 확장자를 지정하지 않는 방법이 있습니다. YAML의 자세한 문법은 [YAML Syntax]를 참고해 주세요.

인벤토리 파일의 경로가 다음과 같다고 가정 해보겠습니다.

/etc/ansible/hosts

만약 “foosball”이라는 이름의 호스트가 있고 “raleigh”와 “webservers”라는 그룹이 존재한다면 다음과 같은 위치에 YAML 파일을 생성하여 원하는 변수를 선별하여 지정할 수 있습니다.

/etc/ansible/group_vars/raleigh
/etc/ansible/group_vars/webservers
/etc/ansible/host_vars/foosball

예를 들어 데이터센터의 특정 호스트들이 그룹으로 묶여있고 각각의 데이터센터별로 조금씩 다른 서버가 사용되고 있다고 할 때 이러한 정보를 그룹파일을 통해서 정의할 수 있습니다. 예로 “raleigh” 그룹 설정인 /etc/ansible/group_vars/raleigh”의 내용은 다음과 같습니다.

---
ntp_server: acme.example.org
database_server: storage.example.org

이 파일은 선택 기능이기 때문에 이 파일이 존재하지 않더라도 문제가 되지 않습니다.

좀더 심화된 이용방법으로 당신의 그룹이나 호스트 뒤에 추가로 디렉토리를 생성하여 변수의 단위별로 한번 더 쪼개는것이 가능합니다. 예를 들어 “raleigh” 그룹의 경우 다음과 같은 것이 가능합니다.

/etc/ansible/group_vars/raleigh/db_settings
/etc/ansible/group_vars/raleigh/cluster_settings

Ansible은 해당 그룹 및 호스트의 하위디렉토리를 모두 읽기 때문에 위의 방식도 사용에 문제가 없습니다. 만약에 하나의 설정 파일이 너무 클 경우나 Ansible Vault를 특정 그룹의 일부분에 적용할 경우 이렇게 분리하는것은 관리차원에서도 용의할 것입니다. 이러한 기능은 Ansible 1.4 이상의 버전에서 사용 가능합니다.

TIP: Ansible 1.2 이상 버전에서는 group_vars/ 와 host_vars/ 디렉토리가 플레이북 디렉토리와 인벤토리 디렉토리 양쪽에 존재할 경우 플레이북 디렉토리의 변수들이 인벤토리 디렉토리의 값을 오버라이드하게 됩니다.

TIP: 당신의 인벤토리 파일과 변수 파일들을 git 저장소에 보관하는것은 인벤토리와 호스트 변수의 변화를 추적할 수 있는 좋은 방법입니다.

인벤토리 파라미터 목록

지금까지 언급했던것과 같이 Ansible이 원격 호스트들과 어떻게 연결할 것이며 관리할것인지에 대한 다음과 같은 파라미터가 있습니다.

호스트 연결

  • ansible_connection : 호스트의 연결 타입, local, smart, ssh, paramiko를 사용가능. 기본은 smart임

SSH 연결

  • ansible_host : 연결할 호스트의 이름. 당신이 원하는 호스트 별칭과 다를 경우 사용하여 임의 지정 가능
  • ansible_port : SSH 포트 번호. 기본값인 22가 아닐 경우 사용
  • ansible_user : SSH 접속에 사용할 유저 이름
  • ansible_ssh_pass : SSH 연결시 사용할 비밀번호. 이것은 보안에 취약하므로 –ask-pass 또는 SSH Keys 방식을 사용할 것은 권장
  • ansible_ssh_private_key_file : SSH 연결시에 사용할 SSH 비밀키 파일
  • ansible_ssh_common_args : sftp, scp, ssh와 같은 기본 명력을 사용할 때 항상 추가할 설정을 지정가능
// 예시
ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q user@gateway.example.com"'
  • ansible_sftp_extra_args : sftp 연결에 기본으로 추가할 설정을 지정
  • ansible_scp_extra_args : scp 연결에 기본으로 추가할 설정을 지정
  • ansible_ssh_extra_args : ssh 연결에 기본으로 추가할 설정을 지정
  • ansible_ssh_pipelining : SSH 파이프라이닝을 사용할지 말지 결정, ansible.cfg의 pipelining 설정을 오버라이딩함

권한 상승 (자세한 내용은 Ansible Privileges Escalation 참고)

  • ansible_become : ansible_sudo 또는 ansible_su와 동일, 강제로 권한 상승을 수행
  • ansible_become_method : 권한 상승 메소드를 지정 가능
  • ansible_become_user : ansible_sudo_user 또는 ansible_su_user와 동일, 원하는 유저로 권한 변경 가능
  • ansible_become_pass : ansible_sudo_pass 또는 ansible_su_pass와 동일, 권한 상승시에 사용할 비밀번호 지정 가능

원격 호스트 환경 파라미터

  • ansible_shell_type : 목표 시스템의 쉘 타입을 지정할 수 있음. “sh”가 기본이며 “csh” 또는 “fish”와 같은 쉘 사용 가능
  • ansible_python_interpreter : 목표 시스템의 파이썬 인터프리터의 경로를 지정 가능.
  • ansible\_\*\_interpreter : ruby, perl과 같은 다른 언어의 인터프리터 경로를 지정 가능.

위의 파라미터를 적용한 호스트 환경 설정 예시는 다음과 같습니다.

some_host         ansible_port=2222     ansible_user=manager
aws_host          ansible_ssh_private_key_file=/home/example/.ssh/aws.pem
freebsd_host      ansible_python_interpreter=/usr/local/bin/python
ruby_module_host  ansible_ruby_interpreter=/usr/bin/ruby.1.9.3

참고 : http://docs.ansible.com/ansible/intro_inventory.html