Ansible 역할에서 기본값과 vars의 차이점은 무엇입니까?

새로운 Ansible 역할을 만들 때 템플릿은 빈 파일을 가진 a vars와 defaults디렉토리를 모두 만듭니다 main.yml. 역할을 정의 할 때이 중 하나에 변수 정의를 배치 할 수 있으며 내 작업에서 사용할 수 있습니다.

로 정의 퍼팅의 차이 무엇 defaults과 vars? 무엇이 들어가야하고 defaults, 어떻게해야 vars합니까? 동일한 데이터에 둘 다 사용하는 것이 합리적입니까?

나는 둘 사이의 우선 순위 / 우선 순위에 차이가 있다는 것을 알고 있지만 어디로 가야하는지 이해하고 싶습니다.

내 역할이 대상 시스템에 디렉토리 목록을 작성한다고 가정 해 봅시다. 작성할 기본 디렉토리 목록을 제공하고 싶지만 역할을 사용할 때 사용자가 해당 디렉토리를 대체 할 수 있도록하려고합니다.

이것은 다음과 같습니다.

---
- directories:
  - foo
  - bar
  - baz

나는 이것을 실행 관점에서 defaults/main.yml또는 안에 넣을 수 vars/main.yml있지만 아무런 차이가 없을 것입니다-그러나 어디로 가야합니까?

변수 우선 순위 에 대한 Ansible 설명서에는 이 niceley가 요약되어 있습니다.

동일한 이름의 여러 변수가 다른 위치에 정의되어 있으면 특정 순서로 이깁니다.

• 여분의 vars (-e는 명령 행에서) 항상 이깁니다
• 그런 다음 인벤토리에 정의 된 연결 변수 (ansible_ssh_user 등)가 제공됩니다.
• 그런 다음 "대부분의 모든 것"(명령 줄 스위치, 사용중인 var, vars, role vars 등 포함)
• 그런 다음 인벤토리에 정의 된 나머지 변수가옵니다.
• 시스템에 대해 발견 된 사실이 온다
• "role defaults"는 가장 "defaulty"이며 모든 것보다 우선 순위를 잃습니다.

따라서 Tomcat을 여러 웹 호스트에 설치하는 데 사용하는 "tomcat"역할이 있지만 몇 개의 호스트에 다른 버전의 tomcat이 필요하고 다른 경우 다른 사용자로 실행해야하는 등의 defaults/main.yml파일이있을 수 있습니다. 이 같은:

tomcat_version: 7.0.56
tomcat_user: tomcat

이것들은 단지 기본값이기 때문에 해당 변수가 문제의 호스트에 대해 다른 곳에서 정의되지 않은 경우 사용됩니다. 추가 변수, 인벤토리 파일의 사실 등을 통해 이러한 변수를 재정 의하여 이러한 변수에 다른 값을 지정할 수 있습니다.

편집 : 위 목록은 Ansible 1.x 용입니다. Ansible 2.x에서는 목록이 확장되었습니다. 항상 그렇듯이 Ansible Documentation 은 2.x의 변수 우선 순위에 대한 자세한 설명을 제공합니다.

에 정의 된 역할 변수 var는 우선 순위가 매우 높습니다. 명령 줄, 특정 작업 또는 블록에 전달하여 덮어 쓸 수 있습니다. 따라서 거의 모든 변수가에 정의되어 있어야합니다 defaults.

" 변수 우선 순위-역할 변수를 넣을 위치 "기사 에서 저자는 무엇을 넣을지에 대한 한 가지 예를 제시합니다 vars. 크게 변하지 않는 시스템 특정 상수. 당신은 할 수 vars/debian.yml와 vars/centos.yml같은 변수 이름하지만 서로 다른 값으로하고 조건부로 포함한다.

이럴이 비실용적이고 분별없는 점에서 구성에 대한 Ansible 장소 높은 우선 순위 바르 의 역할은 . 의 구성 vars/main.yml및 defaults/main.yml낮은 아마도 동일한 우선 순위해야합니다.

이러한 유형의 행동을 원하는 실제 사례가 있습니까?

우리가 이것을 원하지 않는 예가 있습니다.

여기서 중요한 것은 구성을 defaults/main.yml동적 으로 할 수 없다는 것입니다. vars/main.yml캔 구성 . 예를 들어 geerlingguy.postgresql에 표시된대로 특정 OS 및 버전에 대한 구성을 동적으로 포함 할 수 있습니다.

그러나 Ansible geerlingguy에서는 우선 순위가 너무 이상하고 실용적이지 않기 때문에 변수 에서 볼 수있는 의사 변수 를 도입해야 합니다.

- name: Define postgresql_packages.
  set_fact:
    postgresql_packages: "{{ __postgresql_packages | list }}"
  when: postgresql_packages is not defined

이것은 우선 순위가 비실용적임을 보여주는 구체적인 실제 사례입니다.

여기서해야 할 또 다른 요점은 역할을 구성 할 수 있기를 원한다는 것입니다. 역할은 외부 사람 일 수 있으며 다른 사람이 관리 할 수 ​​있습니다. 일반적으로 역할의 구성이 우선 순위를 갖기를 원하지 않습니다.

기본적으로 "역할 기본값"(역할 내부의 기본 폴더)에 들어가는 것은 가장 가볍고 쉽게 재정의됩니다. 역할의 vars 디렉토리에있는 모든 것은 네임 스페이스에서 해당 변수의 이전 버전을 대체합니다. 여기에 따르는 아이디어는 범위가 명확 해지면 명령 줄보다 우선 순위가 높아진다는 것입니다. 호스트 및 / 또는 인벤토리 변수는 역할 기본값보다 우선 할 수 있지만 vars 디렉토리 나 include_vars 작업과 같은 명시적인 포함은 아닙니다. 문서

변수와 기본값은 서로 밀접한 관련이 있습니다. 여기에 예가 있습니다

-name: install package
 yum: name=xyz{{package_version}} state=present

기본 파일에는 다음과 같은 것이 있습니다.

package_version: 123

가능한 것은 패키지의 값을 가져 와서 package_version패키지 이름 옆에 놓아 다음과 같이 읽을 수 있다는 것입니다.

-name: install package
 yum: name=xyz123 state=present

이 방법 으로 xyz의 큰 저장소에 설치 되거나 설치 xyz123되지 않습니다 xyz123.4.

결국 그것은 할 것입니다 yum install -y xyz123

따라서 기본적으로 기본값은 존재하는 값입니다. 변수에 특정 값을 설정하지 않으면 공간을 비워 둘 수 없습니다.