Ansible: Несколько файлов в каталоге значений по умолчанию для роли

у вас может быть main.yml в tasks , который включает другие файлы, даже в подкаталогах tasks , например, для настройки двух основных компонентов foo и bar этой большой роли:

- include: foo/main.yml
- include: bar/main.yml

Использование модуля include_vars для переменных ролей по умолчанию устраняет причину, по которой переменные по умолчанию существуют в первую очередь, а именно используются для предоставления «крайних значений по умолчанию», которые могут быть легко перезаписаны другими частями ролей / сценария.

Идея нескольких файлов в каталоге defaults/ ранее обсуждалась в IRC, мы пришли к выводу, что анализ каталога defaults/ аналогично каталогам inventory/group_vars/ и inventory/host_vars/ будет приятно иметь. Необходимый код уже существует и, надеюсь, может быть легко адаптирован для значений ролей по умолчанию.

+1

+1

Было бы неплохо его иметь!

+1

Да просто предположил, что значения по умолчанию / * были найдены и загружены автоматически, как упоминалось выше. Кажется, что предлагаемый обходной путь (включая дополнительные файлы значений по умолчанию в задачах) переопределит инвентарные переменные из-за приоритета переменных , поэтому кажется, что нам, возможно, придется объединить в 1 файл, чтобы избежать этой проблемы, пока она не будет решена.

Приоритет переменной Ansible 2.x

    role defaults [1] (loading all role defaults here critical)
    inventory vars [2]
    inventory group_vars
    inventory host_vars
    playbook group_vars
    playbook host_vars
    host facts
    registered vars
    set_facts
    play vars
    play vars_prompt
    play vars_files
    role and include vars (hack coming in here will override everything above)
    block vars (only for tasks in block)
    task vars (only for the task)
    extra vars (always win precedence)

Это может быть связано с # 8121.

+1

+1

Определенно обязательная функция из-за ограничений приоритета переменных.
Это также позволяет определить файл значений по умолчанию для каждого класса переменных и сохранить четкое разделение; например, в сети это позволило бы мне определить один файл по умолчанию для IPv4, один для IPv6, один для SNMP и так далее ...
Наконец, кажется необходимым иметь возможность помещать эти файлы в разные папки по умолчанию.

Просто ударил его сам, так что определенно +1

Это действительно PITA.
Если бы я мог предложить решение, я бы добавил опцию, аналогичную include_vars , но в meta/main.yml , чтобы указать порядок загрузки.

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

Это позволит установить значение по умолчанию ["main.yml"] и не нарушить существующий код, а разработчикам будет предоставлена ​​возможность определять гранулярные переменные на основе выбранных ими контекстов.

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

Определенно +1

Для vars/ то же самое, но похоже, что # 2958 отказался от этого

Пример @cornfeedhobo точно соответствует моему

Другой вариант интерфейса:

• Добавьте в модуль include_vars параметр as_default, который обрабатывает включенный файл, как если бы он был по умолчанию.

Для меня это действительно выглядит странно / нелогично, что есть каталог "defaults" с единственным файлом в нем.
Я имею в виду, вы когда-нибудь видели модуль Python с одним файлом __main__.py в нем?

Именно поэтому я интуитивно подумал, что функциональность, о которой говорилось в этой заявке, уже присутствовала. «Конечно, у меня может быть несколько файлов по умолчанию, для этого есть каталог»

include_role позволяет вам теперь указать 'альтернативные' файлы http://docs.ansible.com/ansible/include_role_module.html через параметр defaults_from

Просто попал в ситуацию, когда желательно defaults/main.yml split. Добавил мой 👍 к проблеме.

То же самое здесь, мне это тоже нужно
+1

+1

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

Пожалуйста, просмотрите мой комментарий выше

Да, это очень полезная функция, позволяющая избежать файлов с 2К строками.
+1

+1

+1

👍

+1

+1

+1
Здесь та же проблема. main.yml слишком большой, разбит на несколько файлов. Мы предположили, что он будет «просто работать» и загрузит все вары в файлы по умолчанию /, поскольку это каталог. nojoy.

+1

+1

+1

👍

+1

+1

👍

Вы, ребята, можете ставить отметку "Нравится" каждый комментарий +1, но я очень сомневаюсь, что вы можете отслеживать количество подписчиков, поэтому добавление +1 по-прежнему является достойным способом продемонстрировать желаемую поддержку.

До тех пор, пока внимание к проблеме не будет четко привязано к количеству подписчиков на проблему, всегда ожидайте увидеть +1 комментарий.

Что вы можете ожидать, так это то, что команда ansible вместо этого заблокирует комментарии к проблеме, поэтому не будьте спамером и не защищайте их, пожалуйста.

Что вы можете ожидать, так это то, что команда ansible вместо этого заблокирует комментарии к проблеме, поэтому не будьте спамером и не защищайте их, пожалуйста.

Они могли это сделать, но это основная проблема для правильной разработки ролей, особенно после введения include_role в 2.x вместе со старым методом roles include. Если вы проектируете свою роль так, чтобы она была совместима с include_role , что предпочтительнее, так как это делает разработку намного более модульной и гибкой, чем с одним старым методом roles , тогда вам останется для отслеживания либо включения значений по умолчанию в качестве задач в ваших сценариях, либо передачи ответственности конечному пользователю, который не должен знать, как это сделать, чтобы ваша роль работала должным образом, либо отслеживать платформу / дистрибутив / выпуск как вложенный уровень вашего роль переменные, осложняют чертик развития (хотя он работает как Ive создал роль , которая может поддерживать 20 различные версии платформы здесь ). Вы действительно пробовали написать роль, которая поддерживает больше, чем несколько платформ? Неудивительно, почему большинство ролей в Ansible Galaxy этого не делают, эта проблема, вероятно, номер один в этом списке, ИМО.

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

Это проблема только потому, что они выпустили include_role не задумываясь о том, как его практическое использование повлияет на значения по умолчанию. Принуждение кого-то выбирать между использованием roles и include_role , чтобы роль работала должным образом, или добавлением дополнительной работы для одновременной работы обоих, является основной проблемой здесь.

Мои 2 цента.

PS Если вы голосуете против +1, потому что вам не нужны уведомления ... нажмите кнопку отказа от подписки в правом верхнем углу, и вы больше их не получите.

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

Я хотел бы добавить свой голос к запросу об этой способности и подробно рассказать о моем сценарии использования. Помимо простой возможности разбивать большой файл main.yml, было бы здорово сделать что-то вроде этого:

- name: Some name
  include_default_vars:
  with_first_found:
    - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"
   - main.yml

Я надеюсь достичь этим [в качестве примера] роли openssh, которая поддерживает все параметры ssh_config и sshd_config, а также поддерживает несколько ОС и версий [т.е. Debian 8/9, EL6 / 7 и т. Д.], Но который при вызове без переменных, установленных пользователем, безопасно построит конфигурацию с настройками OS_majorversion по умолчанию, но у которых может быть ЛЮБАЯ доступная опция, переопределенная пользователем.

В нынешнем виде, если я помещу эти параметры ОС по умолчанию в include_vars, приоритет будет слишком высоким, и пользователь не сможет переопределить эти настройки в инвентаре, или в group_vars / all, или в group_vars / groupname, или в host_vars и т. Д.

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

Добавление этой функции позволит это сделать и может помочь сделать более качественные роли доступными в github / galaxy.

@ ralphie02 нет, это далеко не решение того, о чем идет речь. Это обычные переменные на основе хоста, которые отличаются от требований установки значений по умолчанию для многоплатформенной роли.

Подобные vars / feature_idea: https://github.com/ansible/ansible/issues/11639

Это действительно PITA.
Если бы я мог предложить решение, я бы добавил опцию, аналогичную include_vars , но в meta/main.yml , чтобы указать порядок загрузки.

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

Это позволит установить значение по умолчанию ["main.yml"] и не нарушить существующий код, а разработчикам будет предоставлена ​​возможность определять гранулярные переменные на основе выбранных ими контекстов.

Я действительно думаю, что это хорошее решение, сейчас нет простого способа установить другой набор значений по умолчанию для os / version / etc. Эта реализация также поддерживает обратную совместимость, так что это тоже хороший выбор.

В соответствии с @abedwardsw (комментарий перед):
Более двухлетнее предложение от @cornfeedhobo (15: +1:!) (Или немного более новое от @ doubletwist13 ) действительно было бы полезно для многих известных мне ролей, в частности для достаточно сложных:
https://github.com/hortonworks/ansible-hortonworks

Прямые ссылки на их комментарии:

• https://github.com/ansible/ansible/issues/14248#issuecomment -254059046
• https://github.com/ansible/ansible/issues/14248#issuecomment -329027052

См. Также предложение @geerlingguy (с 2016 года!) И мой комментарий (который пытается собрать связанные проблемы): https://github.com/ansible/proposals/pull/21#issuecomment -470048538