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) }}"
Я думаю, это также устранило бы необходимость в жестко заданных значениях по умолчанию в шаблонах?

Роль, о которой я говорю, можно посмотреть здесь .

Хм, это интересный подход, и я вижу, что он работает. Возможно, стоит создать небольшой PoC с одним из словарей меньшего размера (я думаю о шаблонах main или stream ), чтобы увидеть, насколько хорошо он будет работать на практике.

Я уже пробовал это для основного шаблона, и он работал, как ожидалось. Однако, поскольку я пошел по пути наименьших усилий, я объединил два словаря nginx_default_main_template из значений по умолчанию и nginx_user_main_template из учебника для пользователей в nginx_main_template .
Это внесет критическое изменение, поэтому я реорганизую роль, чтобы использовать объединенный словарь под новым именем и отправить PR.

Шаблон http намного сложнее, потому что, возможно, нужно объединить несколько пользовательских словарей. Альтернативой могут быть якоря и псевдонимы в сочетании с оператором слияния, но тогда за слияние отвечает пользователь.
Я тоже проведу некоторое время на этом фронте.

BTW: есть ли причина, по которой вы решили использовать словарь вместо списка для определения нескольких шаблонов http? Судя по тому, что я обнаружил, ключ на самом деле никогда не используется.

BTW: есть ли причина, по которой вы решили использовать словарь вместо списка для определения нескольких шаблонов http? Судя по тому, что я обнаружил, ключ на самом деле никогда не используется.

Нет, не совсем. Оглядываясь назад, я думаю, что наличие ключа для каждого определяемого вами HTTP-шаблона может улучшить читаемость, но я не против изменения его на список, если это упрощает задачу.

Я столкнулся с аналогичной проблемой, а затем и с этой проблемой. Я хотел бы предложить альтернативную точку зрения:

Значения по умолчанию для конфигурации вообще не должны быть жестко запрограммированы и оставлены на усмотрение устанавливаемого программного обеспечения.

Как уже указывал @alexsegura , проблема в том, что вам нужно поддерживать синхронизацию значений, что по своей природе не всегда так (люди подвержены ошибкам).

Если вы чувствуете, что должны предоставить конфигурацию по умолчанию, я бы предложил сохранить подразделы в отдельных каталогах и объединить их на самом низком уровне, если пользователь указывает значение, а затем объединить их в конфигурацию.

Но даже это, imo, выходит за рамки роли - он должен копировать конфигурацию в цель, а не проверять, что ее значения в порядке; В лучшем случае я выдал бы ошибку, если бы программное обеспечение не могло запуститься из-за ошибки конфигурации (или использовать функцию проверки программного обеспечения, если она доступна).

Как ни странно, в настоящее время я работаю над способами улучшения работы шаблонов в этой роли. Это был очень медленный процесс (на данный момент у меня довольно ограниченная пропускная способность, которую я могу выделить для этой роли), но я думаю, что нашел подходящее решение, которое решило бы эти проблемы. Надеемся, что изменения будут внесены в отдельную ветку максимум через пару месяцев 😉

Есть ли прогресс в решении этой проблемы?

Неа. Есть еще планы вернуться к этому в «ближайшем» будущем, но пара других задач стала приоритетной.