Ansible-role-nginx-config: 缺少 nginx_main_template.* 的默认值

创建于 2019-09-07  ·  15评论  ·  资料来源: nginxinc/ansible-role-nginx-config

如果您只想更改 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'"}

我们应该被允许只定义一些变量,并为其他变量保留默认值。

最有用的评论

或者您可以为默认和用户配置使用单独的字典,并将它们与combine过滤器合并。 我一直在使用角色来部署使用此方法的气流:
airflow_config: "{{ airflow_defaults_config | combine(airflow_user_config, recursive=True) }}"
我想这也将消除在模板中使用硬编码默认值的需要?

我所指的角色可以在这里查看

所有15条评论

完全同意@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) ,但我不确定这是最好的前进道路。

可能唯一的方法是在模板本身中使用默认过滤器。

是的,这是模板相关参数的一个很好的解决方案(如果你查看模板文件,默认过滤器已经在几个地方使用了)。 诚然,这将解决最初的问题。 这将是一项非常耗时的任务,但它是可行的。

但是,问题仍然是非模板相关变量的最佳方法是什么,此外,是否有最佳方法?

从我在这里和那里看到的,默认值的最佳方法是避免使用字典,例如

nginx_main_template_user: www-data

代替

nginx_main_template:
  user: www-data

这将部分解决这个问题,最初这就是角色的结构。 但是当我开始引入更复杂的模板选项(例如多个位置块)时,字典和列表开始变得更有意义。

或者您可以为默认和用户配置使用单独的字典,并将它们与combine过滤器合并。 我一直在使用角色来部署使用此方法的气流:
airflow_config: "{{ airflow_defaults_config | combine(airflow_user_config, recursive=True) }}"
我想这也将消除在模板中使用硬编码默认值的需要?

我所指的角色可以在这里查看

嗯,这是一个有趣的方法,我可以看到它的工作。 也许值得用其中一个较小的词典(我正在考虑mainstream模板)创建一个小型 PoC,以了解它在实践中的效果如何。

我已经为主模板尝试过这个,它按预期工作。 但是,因为我走的是最省力的道路,所以我将默认值中的两个字典nginx_default_main_template和用户手册中的nginx_user_main_template合并到nginx_main_template
这将引入一个重大更改,因此我将重构角色以使用新名称下的合并字典并提交 PR。

http 模板要困难得多,因为可能有多个用户词典要合并。 锚点和别名合并运算符相结合可能是一种替代方法,但随后用户负责进行合并。
我也会花一些时间在那个前沿。

BTW:您选择使用字典而不是列表来定义多个 http 模板有什么原因吗? 从我发现的密钥来看,从未真正使用过。

BTW:您选择使用字典而不是列表来定义多个 http 模板有什么原因吗? 从我发现的密钥来看,从未真正使用过。

不,不是真的。 事后看来,我认为为您定义的每个 HTTP 模板设置一个键可能会提高可读性,但如果它使事情变得更容易,我不反对将其更改为列表。

我遇到了类似的问题,随后遇到了这个问题。 我想提供另一种观点:

配置的默认值根本不应该是硬编码的,而是留给正在安装的软件。

正如@alexsegura已经指出的那样,问题在于您需要保持值同步,而这在本质上并不总是如此(人类容易出错)。

如果您觉得必须提供默认配置,我建议将子部分保存在单独的目录中,如果用户指定了值,则将它们组合在最低级别,然后将它们合并到配置中。

但即便如此,imo 也不在角色的范围内——它应该将配置复制到目标,而不是确保它的值是正确的; 最多,如果软件由于配置错误而无法启动(或使用软件的验证功能,如果可用),我会给出一个错误。

有趣的是,我目前正在研究如何改进模板在角色中的工作方式。 这是一个非常缓慢的过程(我目前用于该角色的带宽相当有限),但我认为我已经提出了一个可以解决这些问题的可行解决方案。 希望在最多几个月内将更改保存在单独的分支中 😉

这个问题有什么进展吗?

不。 仍有计划在“不久的”将来回到这一点,但其他几项任务已成为优先事项。

此页面是否有帮助?
0 / 5 - 0 等级