如果您只想更改 NGINX 用户,同时保留其他变量的默认值,您仍然需要在nginx_main_template
dict 下定义所有变量。
使用这些变量:
nginx_main_template_enable: true
nginx_main_template:
user: www-data
它会导致以下错误:
TASK [nginxinc.nginx : (Setup: All NGINX) Dynamically Generate NGINX Main Configuration File] ************************
fatal: [sandbox]: FAILED! => {"changed": false, "msg": "AnsibleUndefinedVariable: 'dict object' has no attribute 'worker_processes'"}
我们应该被允许只定义一些变量,并为其他变量保留默认值。
完全同意@alexsegura。 定义单个参数的选项在积压中。 这个角色的发展速度比我最近想要的要慢一些,但在接下来的几个月里,事情应该会开始好转。 话虽如此,如果您愿意,请随时提交 PR 😄
感谢您的留言。
是的,我可以贡献一个拉取请求🙂
我在这里和那里看到的这个角色的问题是默认值是硬编码的。
因此,如果默认值更改,您必须记住在defaults/main.yml
和模板中更改它们。
我想这是因为当使用 dicts 作为默认值时,它们会被替换。 有一个hash_behavior设置,但我认为它是全局的。
您知道一种检索角色的“未触及”默认变量的方法吗?
像role_defaults['var_name']
?
@alexsegura我不知道完成这种行为的好方法。 理想情况下,您需要一个设置,角色可以在不使用defaults/main.yml
任何值的情况下部署有用的配置。
想到的主要想法是使用vars/main.yml
对一些默认值进行硬编码,然后执行诸如| default(var_main_upload_src)
,但我不确定这是最好的前进道路。
可能唯一的方法是在模板本身中使用默认过滤器。
是的,这是模板相关参数的一个很好的解决方案(如果你查看模板文件,默认过滤器已经在几个地方使用了)。 诚然,这将解决最初的问题。 这将是一项非常耗时的任务,但它是可行的。
但是,问题仍然是非模板相关变量的最佳方法是什么,此外,是否有最佳方法?
从我在这里和那里看到的,默认值的最佳方法是避免使用字典,例如
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已经指出的那样,问题在于您需要保持值同步,而这在本质上并不总是如此(人类容易出错)。
如果您觉得必须提供默认配置,我建议将子部分保存在单独的目录中,如果用户指定了值,则将它们组合在最低级别,然后将它们合并到配置中。
但即便如此,imo 也不在角色的范围内——它应该将配置复制到目标,而不是确保它的值是正确的; 最多,如果软件由于配置错误而无法启动(或使用软件的验证功能,如果可用),我会给出一个错误。
有趣的是,我目前正在研究如何改进模板在角色中的工作方式。 这是一个非常缓慢的过程(我目前用于该角色的带宽相当有限),但我认为我已经提出了一个可以解决这些问题的可行解决方案。 希望在最多几个月内将更改保存在单独的分支中 😉
这个问题有什么进展吗?
不。 仍有计划在“不久的”将来回到这一点,但其他几项任务已成为优先事项。
最有用的评论
或者您可以为默认和用户配置使用单独的字典,并将它们与
combine
过滤器合并。 我一直在使用角色来部署使用此方法的气流:airflow_config: "{{ airflow_defaults_config | combine(airflow_user_config, recursive=True) }}"
我想这也将消除在模板中使用硬编码默认值的需要?
我所指的角色可以在这里查看。