Ansible-role-nginx-config: nginx_main_template.*에 대한 기본값이 없습니다.

@alexsegura에 전적으로 동의합니다. 단일 매개변수를 정의하는 옵션은 백로그에 있습니다. 역할에 대한 개발은 내가 최근에 원하는 것보다 조금 더 느렸지만 앞으로 몇 달 안에 상황이 다시 좋아지기 시작할 것입니다. 즉, 원하는 경우 자유롭게 PR을 제출하십시오 😄

메시지를 보내주셔서 감사합니다.
예, 풀 리퀘스트에 기여할 수 있습니다 🙂

이 역할에서 여기저기서 볼 수 있는 문제는 기본값이 하드코딩되어 있다는 것입니다.
따라서 기본값이 변경되면 defaults/main.yml 및 템플릿에서 모두 변경해야 한다는 것을 기억해야 합니다.

https://github.com/nginxinc/ansible-role-nginx/blob/a92d424bdb5dc51b143c702754bed761e919a576/tasks/conf/upload-config.yml#L8 -L14

dicts를 기본값으로 사용할 때 대체되기 때문이라고 생각합니다. hash_behavior 설정이 있지만 전역적이라고 생각합니다.

역할에 대해 "손대지 않은" 기본 변수를 검색하는 방법을 알고 있습니까?
role_defaults['var_name'] 와 같은 것 ?

@alexsegura 이 동작을 수행하는 좋은 방법을 모르겠습니다. 이상적으로는 defaults/main.yml 의 값을 사용하지 않고 역할이 유용한 구성을 배포할 수 있는 설정을 원할 것입니다.

마음에 떠오르는 주요 생각은 vars/main.yml 를 사용하여 일부 기본값을 하드코딩한 다음 | default(var_main_upload_src) 와 같은 작업을 수행하는 것이지만 이것이 최선의 경로인지 확신할 수 없습니다.

아마도 이를 수행하는 유일한 방법은 기본 필터가 있는 템플릿 자체에서일 것입니다.

맞습니다. 이것은 템플릿 관련 매개변수에 대한 좋은 솔루션입니다(템플릿 파일을 보면 기본 필터가 이미 몇 곳에서 사용됨). 그리고 그것이 원래의 문제를 해결할 것이라는 점은 인정합니다. 꽤 시간이 많이 걸리는 작업이지만 할 수 있습니다.

그러나 템플릿과 관련되지 않은 변수에 대한 최선의 접근 방식이 무엇인지에 대한 질문이 남아 있으며, 더 나아가 최선의 접근 방식이 있습니까?

여기 저기에서 본 것에서 기본값에 대한 가장 좋은 접근 방식은 dicts를 사용하지 않는 것입니다.

nginx_main_template_user: www-data

대신에

nginx_main_template:
  user: www-data

그렇게 하면 문제가 부분적으로 해결되며 처음에는 역할이 그렇게 구성되었습니다. 그러나 내가 더 복잡한 템플릿 옵션(예: 다중 위치 블록)을 도입하기 시작했을 때 사전과 목록이 더 이해하기 시작했습니다.

또는 기본 및 사용자 구성에 대해 별도의 사전을 사용하고 combine 필터와 병합할 수 있습니다. 이 방법이 사용되는 기류를 배포하는 역할을 사용하고 있습니다.
airflow_config: "{{ airflow_defaults_config | combine(airflow_user_config, recursive=True) }}"
이것은 또한 템플릿에 하드코딩된 기본값을 가질 필요를 제거할 것이라고 생각합니다.

내가 언급한 역할은 여기에서 확인할 수

흠, 그것은 흥미로운 접근 방식이며 작동하는 것을 볼 수 있습니다. 실제로 얼마나 잘 작동하는지 보기 위해 더 작은 사전( main 또는 stream 템플릿을 생각하고 있음) 중 하나를 사용하여 작은 PoC를 만드는 것이 좋습니다.

나는 이미 기본 템플릿에 대해 이것을 시도했고 예상대로 작동했습니다. 그러나 최소한의 노력을 기울였기 때문에 두 개의 사전 nginx_default_main_template 과 사용자 플레이북의 nginx_user_main_template 를 nginx_main_template 로 병합했습니다.
이렇게 하면 주요 변경 사항이 발생하므로 병합된 사전을 새 이름으로 사용하고 PR을 제출하도록 역할을 리팩토링합니다.

http 템플릿은 병합할 사용자 사전이 여러 개 있을 수 있으므로 훨씬 더 어렵습니다. 병합 연산자 와 결합된 앵커 및 별칭 이 대안이 될 수 있지만 사용자는 병합을 수행할 책임이 있습니다.
나도 그 앞에서 시간을 보낼 것이다.

BTW: 여러 http 템플릿을 정의하기 위해 목록 대신 사전을 사용하기로 선택한 이유가 있습니까? 내가 찾은 것에서 열쇠는 실제로 사용되지 않습니다.

BTW: 여러 http 템플릿을 정의하기 위해 목록 대신 사전을 사용하기로 선택한 이유가 있습니까? 내가 찾은 것에서 열쇠는 실제로 사용되지 않습니다.

아니 정말. 돌이켜 생각해보면 정의한 각 HTTP 템플릿에 대한 키를 갖는 것이 가독성을 향상시킬 수 있다고 생각하지만, 작업이 더 쉬워진다면 목록으로 변경하는 것을 반대하지는 않습니다.

나는 비슷한 문제에 부딪쳤고 이후에이 문제가 발생했습니다. 저는 다음과 같은 대안적 관점을 제시하고 싶습니다.

구성의 기본값은 하드 코딩되어서는 안 되며 설치 중인 소프트웨어에 맡겨야 합니다.

@alexsegura가 이미 지적했듯이 문제는 값을 동기화된 상태로 유지해야 한다는 것입니다. 이는 본질적으로 항상 그렇지는 않습니다(인간은 오류가 발생하기 쉽습니다).

기본 구성을 제공해야 한다고 생각되면 하위 섹션을 별도의 디렉토리에 유지하고 사용자가 값을 지정하면 가장 낮은 수준에서 결합한 다음 구성에 병합하는 것이 좋습니다.

그러나 그마저도 역할 범위 내에 있지 않습니다. 구성을 대상에 복사해야 하며 해당 값이 올바른지 확인하지 않아야 합니다. 기껏해야 구성 오류로 인해 소프트웨어를 시작할 수 없는 경우 오류가 발생합니다(또는 사용 가능한 경우 소프트웨어의 유효성 검사 기능 사용).

재미있게도 저는 현재 해당 역할에서 템플릿이 작동하는 방식을 개선하는 방법을 연구하고 있습니다. 매우 느린 프로세스였습니다(현재 역할에 전념할 수 있는 대역폭이 다소 제한되어 있음). 하지만 저는 이러한 문제를 해결할 수 있는 괜찮은 솔루션을 생각해 냈다고 생각합니다. 최대 몇 달 안에 변경 사항이 별도의 분기에 적용되기를 바랍니다 😉

이 문제에 진전이 있습니까?

아니요. "가까운" 미래에 이 문제로 돌아갈 계획이 여전히 있지만 몇 가지 다른 작업이 우선 순위에 있습니다.