안녕!

값이 host인 host라는 변수를 정의하고 있기 때문에 이것은 저를 위해 설계된 대로 정확하게 작동하는 것 같습니다.

   vars:
        host: "{{ host }}"

그렇게 하지 않는 것이 _NOT_ 권장합니다.

농담으로 해석하자면 "의사님, 이렇게 하면 팔이 아파요"와 같은 것입니다. :)

나는 이것을 설계된 대로 작동하도록 닫을 것이지만, 더 논의하고 싶다면 자유롭게 sible-project에 들르십시오. 우리는 그것에 열려 있습니다.

다른 구성에도 불구하고 동일한 오류가 발생합니다. 이것은 플레이북에서 재현하기에 충분합니다.

 vars:
    app:
      user:    rails
      home:    "/home/{{ app.user }}"

변수를 app_user 및 app_home 로 평면화하면 모든 것이 복숭아색이지만 특히 app 접두사가 붙은 변수가 많을 때 계층 구조를 유지하는 것이 좋다고 생각했습니다. 앤서블 사용하기 1.8.3.

나는 톰닉과 같은 배에 있다. 곰곰이 생각해보면 당연한 일이지만. 할당되기 전에 변수를 참조하려고 합니다.

파이썬에서 같은 것을 시도하십시오.

>>> app = {"user": "rails", "home": "/home/" + app['user']}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'app' is not defined

그것은 좋은 깔끔한 구성을 만들기 때문에 부끄럽습니다.
내 해결 방법은 재사용 변수를 별도로 정의하는 것입니다. 즉, 귀하의 경우:

app_user: "rails"
app:
   user: "{{ app_user }}"
   home: /home/{{ app_user }}

약간 못생겼지만 지금까지는 괜찮은 수준입니다.

1.6.X에서 1.8.4로 이동한 후 비슷한 것이 있습니다. 이전에는 작동했지만 이제 재귀 문제가 발생합니다.

다음과 같은 플레이북이 있습니다.

- role: rsyslog
      tags: ['rsyslog']
      rsyslog:
        reception:
          tcp:
            enabled: True
        transmission:
          tcp:
            enabled: True
            hosts: "{{rsyslog.producers}}"

그런 다음 특정 환경의 group_vars에서 rsyslog를 정의합니다.

rsyslog:
  producers: "{% set hosts = ['localhost:5544'] %}{% for host in groups['logmaster'] %}{% do hosts.append(host + ':5140') %}{% endfor %}

rsyslog 역할이 실행되면 오류가 발생합니다.
=> 템플릿 문자열에서 감지된 재귀 루프: {{rsyslog.producers}}

이것이 수정된 버그가 아니었기를 진심으로 바랍니다. 이제 우리는 이 버그를 이용할 수 없습니다. 내 직감은 변수가 구축되는 방식의 순서 변경이라고 생각합니다. hash_behaviour가 가능한 구성에서 병합되도록 했습니다.

더 깊이 파고들거나 우리가 사물을 정의하는 방법을 재작업하기 전에 모든 생각이나 제안을 환영합니다.

동일한 문제:-1:

동일한 문제는 "충돌하는" 변수를 이동하고 이름을 변경하여 해결했습니다.

여기도 마찬가지입니다... "변수"를 추가 인수로 큰 소리로 전달하기 때문에 전달된 값을 사용해야 하는 경우가 있습니다. 그렇지 않으면 기본값을 사용합니다.

ansible-playbook playbook.yml -e "my_var=1"

# playbook.yml
vars:
  my_var: "{{ my_var | default(my_default_var) }}"

@thom-nic이 한 일을 방금 만났습니다. 왜 오류가 발생하는지 완전히 확신할 수 없습니다. 그것을 보면 완벽하게 잘 작동해야 하는 것처럼 보입니다.

예. 역할 종속성을 중첩하면 이런 일이 발생합니다.

동일한 문제가 여기에 있습니다. 더 멋진 형식을 사용하고 싶었습니다.

소프트웨어는 모든 종류의 문제를 해결할 수 있으며 확실히 이것도 해결할 수 있습니다. 그러나 정의되는 동안 자체를 호출하는 사전의 형식은 자체 도메인에 있습니다. 1년 전 누군가가 이 질문을 했습니다. 형식이 제안된 곳에서는 다음과 같이 할 수 있습니다.

https://stackoverflow.com/questions/22989401/using-a-relative-path-to-reference-another-element-in-a-multi-dimensional-array

나는 또한 같은 오류가 발생하고 있습니다. 누군가 내가 그것에 대해 어떻게해야하는지 말해 줄 수 있습니까? 아래 변수를 사용하고 있는데 재귀 루프 오류가 발생합니다.

maxHeapSizeAnsi: "{{(hostvars[inventory_hostname]['ansible_memtotal_mb'] * 3 / 4)|int}}"

나도 거기에 빠진다. 고쳐질까요? 다시 열어야 하나?

+1

+1

+1

+1

+1

+1

+1

어리석은 것처럼 보이지만 사전 자체가 아직 완전히 초기화되지 않았을 때 사전이 스스로 키를 재귀적으로 요청하려고 하기 때문에 이것이 작동하지 않아야 하는 이유는 이치에 맞습니다.
이것이 내가 역할을 통해 해결한 방법입니다.

재귀 오류로 깨짐

이것은 내가 한 곳에서 버전을 변경할 수 있도록 미리 하려고 했던 것입니다.

application:
  params:
    state: present
    version: "0.6.3"
    download_url: "https://releases.hashicorp.com/consul/{{ consul.params.version }}/consul_{{ consul.params.version }}_linux_amd64.zip"

  agent:
    ...

고치다

vars를 평평하게 유지하면 강제로 초기화되기 때문에 기본값 폴더를 사용하고 거기에 임의의 것들을 채우기로 결정했습니다. 그런 다음 vars/main.yml의 '아름다운' 구조로 가져올 수 있습니다.

   .
   |-roles
   |---Application
   |-----defaults
   |-------main.yml
   |-----files
   |-----handlers
   |-----meta
   |-----tasks
   |-----templates
   |-----vars
   |-------main.yml

defaults/main.yml에는 다음이 있습니다.

_version: "0.6.3"
_download_url: "https://releases.hashicorp.com/consul/{{ _version }}/consul_{{ _version }}_linux_amd64.zip"

defaults/vars.yml에는 다음이 있습니다.

consul:
  params:
    state: present
    version: "{{ _version }}"
    download_url: "{{ _download_url }}"

  is_agent: false
  agent:
    ...

이렇게 하면 변수를 더 높은 곳에서 변경할 수 있지만 '기본 변수'를 변경할 수 있는 단일 소스도 허용합니다. ;)

편집하다

테스트 후, (관례를 통해) '비공개'로 표시하기 때문에 밑줄이 있는 기본 변수를 변경했습니다. 또한 이 방법으로 변수를 읽고 있는 파일을 정확히 알 수 있습니다. 헤.

+1

+1

다음과 같은 구성을 사용할 수 있기를 바랍니다.

myapp:
  version: 1.6.3
  download_url: http://example.org/download/myapp-{{ myapp.version }}.tgz

나는 그렇게하지 않는 것이 좋습니다.

농담으로 해석하자면 "의사님, 이렇게 하면 팔이 아파요"와 같은 것입니다. :)

@mpdehaan , 내가 전에 사용한 것을 대체하기 위해 가능한 은하계의 다른 모듈을 방금 설치했다고 상상해보십시오. mysql_version 라는 기본 변수를 설정했다고 상상해보십시오. 방금 설치한 모듈에 대한 메타 종속성이 있는 정확히 동일한 이름의 변수가 내 모듈에 있다고 상상해 보십시오.

내 모듈 내에서 변수 이름을 변경하고 싶지 않습니다. 그 자체로 니모닉이기 때문에 모든 변수의 이름은 동일한 규칙, 즉 service_name_version 에 따라 명명되며 mysql_version_another_stupid_name_because_ansible_cannot_do_that_properly 와 같은 것으로 팀을 구성하고 싶지 않습니다. 특수 변수 이름은 팀 구성원이 기억해야 하는 또 다른 뉘앙스이므로 오류가 발생할 가능성이 더 높습니다. 그리고 모듈은 공유 가능해야 하므로 인벤토리에서 가져올 수 없습니다.

그 흔한 사용 사례에 대한 조언은 무엇입니까?

+1

+1

이것이 없으면 구식 접두사 방식으로 수행해야 하기 때문에 멋지고 깨끗한 변수 계층 구조를 가질 수 없습니다. 고려하다:

mysql:
  version: 5.5
  install_path: "/var/lib/mysql/{{ mysql.version }}"
  user: mysql
  group: mysql

대

mysql_version: 5.5
mysql_install_path: "/var/lib/mysql/{{ mysql_version }}"
mysql_user: mysql
mysql_group: mysql

이것은 (적어도 저에게는) 실제 사례가 아닌 예일 뿐이지만 문제가 무엇인지 보여줍니다. IMO, 후자의 정의는 단지 불쾌합니다. 전자는 일종의 DRY'아웃을 적용합니다.

+1

위의 @bn0 답변 참조:

곰곰이 생각해보면 당연한 일이지만. 할당되기 전에 변수를 참조하려고 합니다.

또한 이 기능은 논리적으로 넌센스가 될 것이라고 말하는 모든 사람을 언급합니다.

이 기능은 실제로 정확히 한 가지 의미로 잘 정의되어 있습니다. 구문과 의미론(논리적 측면에서)은 이러한 종류의 "역참조"에 대해 모두 잘 정의되어 있습니다.
여기서 문제는 실제로 구현이 어떻게 생겼는지에 관한 것입니다.

1. 구현 문제

하지만 잠깐: 해시 맵 값이 아직 정의되지 않은 해시 맵을 어떻게 참조할 수 있습니까?

여기의 가정은 부분적으로 잘못되었습니다. 여기에서 두 가지 구문을 처리하기 때문입니다. YAML 및 가능한 변수. 변수 {{ some_var_name_here }} 의 ansible 개념은 YAML에서 의미가 없다는 것을 알아야 합니다(이 섹션 2 참조). 실제로 그 문자열에 의미를 부여하는 자체가 가능합니다. 따라서 이를 처리하기 위해 파서를 구현하는 방법에 대해서는 자유가 있습니다. 다음 YAML 설정 문서가 있는 경우 빠른 예를 살펴보겠습니다.

1. hash_map:
2.    version: ab
3.    path: "/somepath/{{hash_map.version}}"

hash_map 변수는 언제 정의됩니까? 이미 _라인 1_에 있습니까? 아니면 _라인 3_ 이후에만 있습니까?

두 가지 다른 구현

이 결정이 구현에 어떤 영향을 미치는지 봅시다.

주의: 이러한 예제는 실제로 단순화되었으며 실제로는 이 모든 것이 파서에서 다르게 처리됩니다.

구현 #1 은 데이터 구조가 위의 예에서 _line 3_ 이후에만 정의된다는 것을 의미합니다.

variables = {}
variables["hash_map"] = {"version": "ab", "path": "/somepath/{{hash_map.version}}" }
# We cannot do this!!!
variables["hash_map"] = {"version": "ab", "path": "/somepath/%s" % variables["hash_map"]["version"] }

구현 #2 는 위의 _line 1_이 데이터 구조를 할당하기에 완전히 충분하다는 것을 의미합니다.

variables = {}
variables["hash_map"] = {}
variables["hash_map"]["version"] = "ab"
# This is totally possible
variables["hash_map"]["path"] = "/somepath/%s" % variables["hash_map"]["version"]

둘 다 같은 것을 나타내지만 보시다시피 후자가 좀 더 강력합니다.

2. 그렇다면 문제는 어디에 있습니까?

표준은 무엇을 말합니까?

일반 YAML로 무엇을 달성할 수 있는지 봅시다.

표준에 따른 YAML 표현

YAML 표준 은 YAML의 의미 체계를 루트 방향 그래프로 설명합니다. 노드는 섹션 3.2.1.1에 설명되어 있습니다.

_standard_ 값에 따르면 노드로도 표시됩니다. 그러나 - 그리고 여기 요점이 있습니다 - 내가 아는 한 노드 유형이 없습니다. 이는 의미론적으로 위의 기능을 하나의 노드 로 올바르게(우리가 원하는 방식으로) 나타낼 수 있습니다. 여기서 유일한 실제 옵션은 sequence 노드(YAML의 목록이라고도 함)를 사용하는 것입니다.

이것의 결과

위의 YAML 예는 표준에 대한 나의 이해에 따라 다음 그래프로 표시됩니다.

{{hash_map.version}} 에 의미를 부여하려면 다음과 같이 anchor 및 별칭 노드를 사용해야 합니다.

참고: 이 기능은 6.2.9에 설명되어 있습니다.

1. hash_map:
2.    version: &anchor "ab"  #setting the anchor
3.    path:
4.        - "/somepath/"
5.        - *anchor          # referring to the anchor, yields ab

이 YAML 온라인 파서 로 이것을 확인하십시오

다음 그래프를 생성합니다.

이것의 다음은 무엇입니까?

위에서 우리는 두 노드를 결합할 수 없음을 알 수 있습니다. 따라서 YAML 전용 구문을 사용하여 이 기능을 달성할 방법이 없습니다.
그러나 {{ some_var_name_here }} 는 단지 가능한 표기법이며 YAML에서는 의미가 없음을 알 수 있습니다. 따라서 우리는 원하는 대로 그 의미를 자유롭게 정의할 수 있습니다!

TLDR

YAML은 마크업 언어이며(약칭으로 가정할 수 있음에도 불구하고) 마크업 언어는 "어떻게"가 아니라 "무엇"이라는 질문에 답할 뿐입니다. 그리고 참조가 의미하는 바가 완전히 명확하므로 이 기능을 구현하는 것이 완전히 가능합니다.

이 기능은 현재 YAML 표준 v.1.2 ( Wikipedia 에 따른 최신 릴리스)를 준수하지 않지만 가능한 변수 {{ some_var_name_here }} 에 대한 개념이 아닙니다.

편집:

• 2018-04-15 21:11:
  
  
  
  • 인트로를 재구성합니다.
  
  
  • 철자가 틀린 단어를 수정하십시오(지금 -> 알고 있음).
  
  

그래서 결론은? {{ some_var_name_here }}는 ansible 표기법일 뿐이고 "deffer resolve"를 처리하도록 의미 체계가 변경될 수 있으므로 비슷한 것을 구현할 계획입니까(예: groovy의 클로저 바인딩)? 문제가 아직 종료되었습니다.

이 기능을 구현하고 싶습니다! 하지만 그렇게 쉬운 일이 아닙니다. 이 기능은 더 큰 영향을 미치기 때문에 혼자 하려면 시간이 필요합니다. 도움을 줄 의향이 있는 한 두 명의 다른 기여자가 있는 것이 좋으며 이 경우 작업 속도가 빨라질 것입니다.

나에게 이 행동은 정말 예상치 못한 일이었고 이상하게 느껴졌다. 현재 동작이 작업하기에 그다지 유쾌하지 않은 많은 시나리오가 있습니다.

~~~

• set_fact:
  호스트: "some.host.com"

• 포함: task.yml
  변수:
  호스트: "{{ 호스트 }}"
  ~~~

이것은 한 역할/작업에서 다른 역할/작업으로 데이터를 전달할 때마다 발생할 수 있습니다. 특히 외부에서 개발한 역할(갤럭시)의 경우 이는 주요 PITA가 될 수 있습니다. 중간 사실을 설정하거나 중간 더미 작업을 사용하는 해결 방법은 매우 추악합니다.

~~~

• set_fact:
  not_host: "{{ 호스트 }}"

• 포함: task.yml
  변수:
  호스트: "{{ not_host }}"
  ~~~

이것은 매우 예상치 못한 동작입니다. 적절한 언어를 사용하면 dict 키를 같은 이름의 변수와 동일하게 설정할 수 있습니다. 예를 들어 파이썬에서:

{'host': host}

전달하기 위해 변수 이름을 해킹해야 한다면 정말 문제가 될 것입니다.

{'host': _host}

현재 내가 찾은 가장 좋은 해결 방법은 변수에 역할 이름을 접두어로 붙이도록 하는 것입니다. 예:

nginx_domain: '{{ myapp_domain }}'

작동하지만 좀 번거롭지 않나요?

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

이것은 YAML 구현 버그입니다.

+1

+1

+1

+1

+1

나도 이거 때렸다. 이것을 다시 여는 것에 대해 생각해 주시겠습니까?

@everybody , 그리고 말 그대로 모두를 의미합니다 :-).

이것은 전에 나를 쳤습니다. 당신이 할 수있는 유일한 일은 변수를 재구성하는 것입니다. 아직 정의되지 않은 변수는 참조할 수 없습니다.

진짜 '문제'는 Ansible이 아니라 Jinja2에 있습니다. 당신이 이것을 고칠 수 있다고 생각한다면, 내 손님이 되십시오. 그러나 현재 jinja2 아키텍처/프로젝트 내에서 불가능하지 않다면 수정하기가 쉽지 않다고 생각합니다.

다음과 같은 것이 있을 때(예를 들어 @rqelibari 에 대한 크레딧):

hash_map:
  version: ab
  path: "/somepath/{{hash_map.version}}"

또한 깨끗하고 멋진 가능한 변수 파일 및/또는 디렉토리를 원합니다. 다른 아키텍처를 고려하면 다른 파일에 변수를 추가할 수 있으며 main.yml 파일이나 all.yml 파일에 국한되지 않습니다. Ansible은 유연하므로 똑똑하다면 이동하고 플레이하세요 :-D.

예를 들어 group_vars의 ' all ' 디렉토리에 'hash_map'이라는 파일을 생성하고 이 파일에 필요한 변수를 생성할 수 있습니다.

예, 동일한 키 저장소에서 메모한 키를 참조할 수 있다면 좋을 것입니다. 현재는 불가능합니다. 나는 그것이 지금과 몇 개월 안에 일어날 것이라고 보지 않습니다 ...

이 문제를 해결하고 창의력을 발휘하고 가능한 스크립트를 엉망으로 만들지 마십시오. 개인적으로 나는 가능한 변수로 모든 것을 구성 가능하게 만들고 싶었습니다. 내가 얻은 유일한 보상은 다루기 힘든 플레이북과 퍼지 변수 구조였습니다 :-).

좋아, 이것을 가능에서 +1하지 말고 jinja2 프로젝트에서 수정하십시오.

이 문제는 yaml 파서의 ansibles 사용의 직접적인 결과입니다.
yaml 개체를 로드하고 두 번째 작업을 수행하는 대신 보간 기능
보간을 위해 전달합니다. 이것은 단순한 jinja 버그가 아닙니다. 이것은
구현 버그. 점검해 주십시오. 원시 문자열로 로드하고
그런 다음 두 번째 패스에서 초기화된 개체 멤버를 처리하면 수정됩니다.
이것.

+1

+1

+1

+1