Ansible-role-nginx-config: Faltan valores predeterminados para nginx_main_template. *

Totalmente de acuerdo @alexsegura. La opción para definir parámetros individuales está en la lista de trabajos pendientes. El desarrollo del rol ha sido un poco más lento de lo que me gustaría últimamente, pero las cosas deberían comenzar a recuperarse nuevamente en los próximos meses. Dicho esto, siéntase libre de enviar un PR si lo desea 😄

Gracias por tu mensaje.
Sí, puedo contribuir con una solicitud de extracción 🙂

El problema que veo aquí y allá en este rol es que los valores predeterminados están codificados.
Entonces, si los valores predeterminados cambian, debe recordar cambiarlos tanto en defaults/main.yml como en las plantillas.

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

Supongo que es porque cuando se usan dictados por defecto, se reemplazan. Hay una configuración hash_behavior pero creo que es global.

¿Conoce una forma de recuperar las variables predeterminadas "intactas" para un rol?
¿Algo como role_defaults['var_name'] ?

@alexsegura No conozco una buena manera de lograr este comportamiento. Idealmente, querrá una configuración en la que el rol pueda implementar una configuración útil sin usar ninguno de los valores en defaults/main.yml .

El pensamiento principal que me viene a la mente sería usar vars/main.yml para codificar algunos de los valores predeterminados y luego hacer algo como | default(var_main_upload_src) , pero no estoy seguro de que ese sea el mejor camino a seguir.

Probablemente la única forma de hacerlo sea en la propia plantilla con el filtro predeterminado.

Correcto, esa es una buena solución para los parámetros relacionados con la plantilla (y si observa los archivos de la plantilla, el filtro predeterminado ya se usa en un par de lugares). Y es cierto que eso abordaría el problema original. Sería una tarea que consumiría bastante tiempo, pero es factible.

Sin embargo, la pregunta sigue siendo cuál es el mejor enfoque para las variables no relacionadas con la plantilla y, además, ¿existe un mejor enfoque?

Por lo que veo aquí y allá, el mejor enfoque para los valores predeterminados es evitar el uso de dictados, por ejemplo

nginx_main_template_user: www-data

en lugar de

nginx_main_template:
  user: www-data

Eso abordaría parcialmente el problema, e inicialmente así fue como se estructuró el rol. Pero cuando comencé a introducir opciones de plantillas más complejas (por ejemplo, múltiples bloques de ubicación), los diccionarios y las listas comenzaron a tener más sentido.

O puede usar diccionarios separados para la configuración predeterminada y de usuario y combinarlos con el filtro combine . He estado usando un rol para implementar el flujo de aire donde se usa este método:
airflow_config: "{{ airflow_defaults_config | combine(airflow_user_config, recursive=True) }}"
Supongo que esto también eliminaría la necesidad de tener valores predeterminados codificados en las plantillas.

El rol al que me refiero se puede consultar aquí .

Hm, ese es un enfoque interesante y puedo verlo funcionando. Tal vez valdría la pena crear una pequeña PoC con uno de los diccionarios más pequeños (estoy pensando en las plantillas main o stream ) para ver qué tan bien funcionaría en la práctica.

Ya probé esto para la plantilla principal y estaba funcionando como se esperaba. Sin embargo, debido a que tomé el camino del menor esfuerzo, fusioné dos diccionarios nginx_default_main_template de los valores predeterminados y nginx_user_main_template del libro de jugadas del usuario en nginx_main_template .
Esto introduciría un cambio importante, por lo que refactorizaré el rol para usar el diccionario combinado con un nuevo nombre y enviaré un PR.

La plantilla http es mucho más difícil porque posiblemente haya varios diccionarios de usuario para fusionar. Los anclajes y alias combinados con el operador de combinación podrían ser una alternativa, pero el usuario es responsable de realizar la combinación.
Pasaré algún tiempo en ese frente también.

Por cierto: ¿Hay alguna razón por la que eligió usar un diccionario en lugar de una lista para definir múltiples plantillas http? Por lo que he encontrado, la clave nunca se usa realmente.

Por cierto: ¿Hay alguna razón por la que eligió usar un diccionario en lugar de una lista para definir múltiples plantillas http? Por lo que he encontrado, la clave nunca se usa realmente.

No en realidad no. En retrospectiva, creo que puede mejorar la legibilidad tener una clave para cada plantilla HTTP que defina, pero no me opongo a cambiarla a una lista si facilita las cosas.

Me encontré con un problema similar y posteriormente con este problema. Me gustaría ofrecer una perspectiva alternativa:

Los valores predeterminados para una configuración no deben codificarse en absoluto y dejarse en manos del software que se está instalando.

Como ya señaló @alexsegura , el problema es que debe mantener los valores sincronizados, lo que, por naturaleza, no siempre será el caso (los humanos son propensos a errores).

Si cree que debe proporcionar una configuración predeterminada, sugeriría mantener las subsecciones en directorios separados y combinarlas en el nivel más bajo si el usuario especifica un valor, y luego combinarlas en la configuración.

Pero incluso eso, en mi opinión, no está dentro del alcance de un rol: debería copiar la configuración al objetivo y no asegurarse de que sus valores estén bien; A lo sumo, daría un error si el software no pudiera iniciarse debido a un error de configuración (o usar la función de validación del software, si está disponible).

Curiosamente, actualmente estoy trabajando en formas de mejorar el funcionamiento de las plantillas en el puesto. Ha sido un proceso muy lento (tengo un ancho de banda bastante limitado para dedicarlo al rol en este momento), pero creo que he encontrado una solución correcta que abordaría estos problemas. Esperando tener los cambios en vivo en una sucursal separada en un par de meses como máximo 😉

¿Algún progreso con este problema?

No. Todavía hay planes para volver a esto en un futuro "cercano", pero un par de tareas más han tenido prioridad.