Ansible: 역할의 기본 디렉토리에 있는 여러 파일

main.yml in tasks , 다른 파일을 포함하는 tasks 하위 디렉토리에도 있는 main.yml 를 가질 수 있습니다.

- include: foo/main.yml
- include: bar/main.yml

기본 역할 변수에 include_vars 모듈을 사용하면 기본 변수가 애초에 존재하는 이유, 즉 역할/플레이북의 다른 부분에서 쉽게 덮어쓸 수 있는 "최후의 수단 기본값"을 제공하는 데 사용되는 것을 무효화합니다.

defaults/ 디렉토리에 여러 파일이 있다는 아이디어는 이전에 IRC에서 논의되었으며 inventory/group_vars/ 및 inventory/host_vars/ 디렉토리와 유사하게 defaults/ 디렉토리를 구문 분석하는 것이 가져서 좋다. 필요한 코드가 이미 존재하며 역할 기본값에 쉽게 적용할 수 있기를 바랍니다.

+1

+1

있으면 좋을텐데!

+1

예, 위에서 언급한 것처럼 defaults/*가 자동으로 발견되고 로드된다고 가정했습니다. 제안된 해결 방법(작업의 추가 기본 파일 포함)은 변수 우선 순위 로 인해 인벤토리 변수를 무시하므로 해결될 때까지 이 문제를 피하기 위해 1개의 파일로 묶어야 할 수도 있습니다.

Ansible 2.x 변수 우선 순위

    role defaults [1] (loading all role defaults here critical)
    inventory vars [2]
    inventory group_vars
    inventory host_vars
    playbook group_vars
    playbook host_vars
    host facts
    registered vars
    set_facts
    play vars
    play vars_prompt
    play vars_files
    role and include vars (hack coming in here will override everything above)
    block vars (only for tasks in block)
    task vars (only for the task)
    extra vars (always win precedence)

이것은 #8121과 관련이 있을 수 있습니다.

+1

+1

가변 우선 순위 제약으로 인해 반드시 기능이 있어야 합니다.
이것은 또한 변수 클래스별로 기본 파일을 정의하고 깨끗한 분리를 유지하도록 합니다. 예를 들어 네트워킹에서 IPv4용 기본 파일 하나, IPv6용 하나, SNMP용 하나 등을 정의할 수 있습니다.
마지막으로 이 파일을 "기본값" 아래의 다른 폴더에 넣을 수 있어야 하는 것 같습니다.

이걸 직접 치면 확실히 +1

이것은 정말로 PITA입니다.
솔루션을 제안할 수 있다면 include_vars 와 유사하지만 meta/main.yml 에 로드 순서를 지정하는 옵션을 추가하는 것입니다.

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

이렇게 하면 옵션이 기본적으로 ["main.yml"] 되고 기존 코드가 손상되지 않고 개발자가 선택한 컨텍스트를 기반으로 세분화된 변수를 정의할 수 있습니다.

기이 한. 나는 이것이 즉시 작동 할 것이라고 완전히 의심했습니다. 가능한 몇 안되는 경우 중 하나는 실제로 최소한의 놀라움의 원칙을 약간 위반합니다 ...

확실히 +1

vars/ 대해 동일하지만 #2958이 이에 대해 결정한 것 같습니다.

@cornfeedhobo 의 예는 내 사용 사례와 정확히 일치합니다. include_vars를 사용하여 연극에 의한 개별 변수의 쉬운 재정의를 방지하고 있습니다.

다른 인터페이스 옵션은 다음과 같습니다.

• 포함된 파일을 기본값인 것처럼 처리하는 옵션을 include_vars 모듈 'as_default'에 추가합니다.

저에게는 단일 파일이 있는 "기본값" 디렉토리가 있다는 것이 정말 이상하고 직관적이지 않게 보입니다.
내 말은, 단일 __main__.py 파일이 있는 파이썬 모듈을 본 적이 있습니까?

이것이 바로 이 티켓에 대해 이야기한 기능이 이미 존재한다고 직관적으로 생각한 이유입니다. "물론 여러 개의 기본 파일을 가질 수 있습니다. 디렉토리가 있습니다."

include_role 사용하면 defaults_from 옵션을 통해 이제 '대체' 파일을 지정할 수 있습니다. http://docs.ansible.com/ansible/include_role_module.html

defaults/main.yml 분할이 필요한 상황에 처했습니다. 문제에 내 👍를 추가했습니다.

여기도 마찬가지야, 나도 필요해
+1

+1

@bcoca 는 훌륭한 추가 기능이며 유연성을 추가하지만 여기서는 문제를 다루지 않으며 정상적인 기본값을 쉽게 설정할 수 있는 역할을 부여하려는 의도가 있는 경우 플레이북 작성자에게 책임이 있습니다.

위의 내 의견을 검토하십시오

예, 이것은 2k 라인의 파일을 피하는 데 매우 유용한 기능입니다.
+1

+1

+1

👍

+1

+1

+1
동일한 문제가 여기에 있습니다. main.yml이 너무 커서 여러 파일로 분할됩니다. 우리는 그것이 "그냥 작동"하고 dir이기 때문에 defaults/ 아래에 있는 파일의 모든 vars를 로드할 것이라고 가정했습니다. 즐겁지 않다.

+1

+1

+1

👍

+1

+1

👍

여러분은 모든 +1 댓글을 싫어할 수 있지만 구독자 수를 추적할 수 있는지 의심스럽습니다. 따라서 +1을 추가하는 것은 여전히 ​​원하는 지원을 표시하는 적절한 방법입니다.

이슈 관심이 이슈 구독자 수와 명확하게 연결될 때까지 +1 댓글을 볼 수 있을 것으로 기대합니다.

예상할 수 있는 것은 가능한 팀이 대신 문제 댓글을 잠그는 것이므로 스팸 발송자가 되지 말고 옹호하지 마십시오.

예상할 수 있는 것은 가능한 팀이 대신 문제 댓글을 잠그는 것이므로 스팸 발송자가 되지 말고 옹호하지 마십시오.

그들은 그렇게 할 수 있지만 이것은 특히 이전 roles 포함 메소드와 함께 2.x에 include_role 를 도입한 이후로 역할을 적절하게 개발할 수 있는 핵심 문제입니다. include_role 와 호환되도록 역할을 설계하면 이전 roles 방법만 사용하는 것보다 개발을 훨씬 더 모듈화하고 유연하게 만들기 때문에 더 좋습니다. 플레이북의 작업으로 기본값을 포함하여 추적하거나, 역할이 제대로 작동하기 위해 이 작업을 수행하는 방법을 알 필요가 없는 최종 사용자에게 책임을 전가하거나, 플랫폼/배포/릴리스를 중첩된 수준으로 추적합니다. 개발을 복잡하게 만드는 역할 변수(Ive가 여기에서 20개의 서로 다른 플랫폼 버전을 지원할 수 있는 역할을 생성할 때 작동하지만). 실제로 여러 플랫폼을 실제로 지원하는 역할을 작성해 보셨습니까? Ansible Galaxy의 대부분의 역할이 없는 이유는 놀라운 일이 아닙니다. 이 문제는 아마도 IMO 목록에서 1위일 것입니다.

따라서 그들이 이것을 잠그고 1년 된 문제에 전혀 응답하지 않고 사람들이 실제 솔루션을 만드는 것을 방해하는 중요한 문제에 대해 논의하는 데 관심이 없다고 커뮤니티에 신호를 보낸다면 사람들이 고수하지 않을 것이라고 확실히 기대할 수 있습니다. 주위를 둘러보고 제품을 계속 사용하십시오. 그들이 답장을 하고 문제에 동의하는지 여부를 알린다면 사람들은 문제에 대한 관심을 끌기 위해 +1을 중단할 것입니다.

실제로 실제로 사용하면 기본값에 어떤 영향을 미칠지 생각하지 않고 include_role 를 출시했기 때문에 이것은 문제일 뿐입니다. 역할을 제대로 수행하기 위해 누군가에게 roles 와 include_role 중 하나를 선택하도록 강요하거나 둘 다 동시에 작동할 수 있도록 추가 작업을 추가하는 것이 여기서 문제의 핵심입니다.

내 2센트.

추신 알림을 원하지 않기 때문에 +1을 다운보팅하는 경우.... 오른쪽 상단의 구독 취소 버튼을 누르면 더 이상 알림을 받지 않습니다.

네, 이 문제는 당신에게 중요합니다. 나는 요점을 이해한다. 나도. 그것이 내가 구독한 이유입니다. BTW, 그래서 구독을 취소하고 싶지 않습니다. 그래서 스팸 발송자를 반대합니다. 그래서 원래 댓글 에 찬성 투표를 합니다. 이는 _게으른_ 지원을 보여주는 문명화된 방법 입니다.

이 기능에 대한 요청에 제 목소리를 추가하고 제 사용 사례를 자세히 설명하고 싶습니다. 큰 main.yml을 분해하는 간단한 기능 외에도 다음과 같은 작업을 수행할 수 있습니다.

- name: Some name
  include_default_vars:
  with_first_found:
    - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"
   - main.yml

이것으로 달성하고자 하는 것은 [예를 들어] 모든 ssh_config 및 sshd_config 옵션을 지원하고 여러 OS 및 버전을 지원하는 openssh 역할입니다. Debian 8/9, EL6/7 등] 그러나 사용자가 vars를 설정하지 않고 호출하면 구성을 OS_majorversion 기본 설정으로 안전하게 빌드하지만 사용 가능한 모든 옵션을 사용자가 재정의할 수 있습니다.

현재 상태에서 해당 OS 기본값을 include_vars에 넣으면 우선 순위가 너무 높아 사용자가 인벤토리, group_vars/all 또는 group_vars/groupname 또는 host_vars 등에서 해당 설정을 재정의할 수 없습니다.

나는 지금 이것을 할 수 있는 방법 이 있다고 확신하지만, 내가 생각할 수 있는 모든 것은 격렬하게 우아하지 않고 추하고 유지하기 어려울 것입니다. 또한 적어도 이 시점까지 내가 만난 #ansible은 우아하고 유지 관리 가능한 방식으로 이 작업을 수행하는 방법에 대해 더 나은 아이디어를 가지고 있지 않습니다.

이 기능을 추가하면 이를 허용하고 github/galaxy에서 더 높은 품질의 역할을 사용할 수 있게 됩니다.

@ralphie02 아니요, 이 스레드가 무엇인지에 대한 솔루션 근처에는 없습니다. 이는 다중 플랫폼 역할에 대한 기본값 설정 요구 사항과 다른 일반적인 호스트 기반 변수입니다.

유사한 vars / feature_idea: https://github.com/ansible/ansible/issues/11639

이것은 정말로 PITA입니다.
솔루션을 제안할 수 있다면 include_vars 와 유사하지만 meta/main.yml 에 로드 순서를 지정하는 옵션을 추가하는 것입니다.

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

이렇게 하면 옵션이 기본적으로 ["main.yml"] 되고 기존 코드가 손상되지 않고 개발자가 선택한 컨텍스트를 기반으로 세분화된 변수를 정의할 수 있습니다.

나는 이것이 좋은 해결책이라고 생각합니다. 지금 당장은 os/version/etc에서 다른 기본값 세트를 가질 수 있는 쉬운 방법이 없습니다. 이 구현은 또한 이전 버전과의 호환성을 유지하므로 좋은 선택이기도 합니다.

@abedwardsw (앞에 주석)에 따라:
@cornfeedhobo (15 :+1: !) (또는 @doubletwist13 의 조금 더 최근)의 >2년 된 제안은 내가 아는 많은 역할, 특히 충분히 복잡한 역할에 정말 유용할 것입니다.
https://github.com/hortonworks/ansible-hortonworks

그들의 의견에 대한 직접적인 참조:

• https://github.com/ansible/ansible/issues/14248#issuecomment -254059046
• https://github.com/ansible/ansible/issues/14248#issuecomment -329027052

@geerlingguy 의 제안(2016년부터!)과 내 의견(관련 문제를 수집하려고 함)도 참조하십시오 .