Каков наилучший способ для формулы для предоставления атрибутов по умолчанию?

Question

У шеф-повара есть очень сложная (возможно, слишком большая) схема для кулинарных книг, чтобы предоставлять значения атрибутов по умолчанию. Я думаю, что Puppet делает что-то подобное с параметрами класса, где значения по умолчанию обычно идут в params.pp. С Солью, я видел:

1. указание значения по умолчанию в словаре/поиск столбцов.
2. grains.filter_by объединения по умолчанию значений атрибутов с пользовательскими данными столба (например, map.jinja в apache-formula)
3. в вызове file.managed состояния, с указанием по умолчанию значения в качестве параметра defaults и заданного пользователь данных столба атрибутов, как context.

Вариант 1 представляется наиболее распространенным, но имеет недостаток, что файл шаблона становится очень трудным для чтения. Он также требует повторения значения по умолчанию всякий раз, когда выполняется поиск, что позволяет сделать ошибку.

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

Вариант 3 не плохо, но ставит атрибут по умолчанию в файле состояния, вместо того, чтобы отделить их в свой собственный файл, как они с опцией 2.

Saltstack-х best practices doc поддерживает вариант 2, за исключением того, что она не адрес, как объединить значения по умолчанию с указанными пользователем значениями без использования grains.filter_by. Есть ли способ обойти это?

Answer 1

Поведение defaults.get изменилось в 2015 году.8, возможно, из-за ошибки. В этом ответе описывается совместимый метод получения тех же результатов (минимум) 2015.8 и более поздних.

Предположим, ваша формула дерева выглядит следующим образом:

something/ 
    files/ 
     template.jinja 
    init.sls 
    defaults.yaml 

# defaults.yaml 
conf_location: /etc/something.conf 
conf_source: salt://something/files/template.jinja 

# pillar/something.sls 
something: 
    conf_location: /etc/something/something.conf 

Идея заключается в том, что формула по умолчанию в defaults.yaml, но могут быть переопределены в стойке. Все, что не указано в столбце, должно использовать значение в значениях по умолчанию. Вы можете сделать это с помощью нескольких строк в верхней части любого данного .sls:

# something/init.sls 
{%- set pget = salt['pillar.get'] %} # Convenience alias 
{%- import_yaml slspath + "/defaults.yaml" as defaults %} 
{%- set something = pget('something', defaults, merge=True) %} 

something-conf-file: 
    file.managed: 
    - name: {{ something.conf_location }} 
    - source: {{ something.conf_source }} 
    - template: jinja 
    - context: 
     slspath: {{ slspath }} 
    ... and so on. 

Что это делает: Содержание defaults.yaml загружаются в виде вложенного словаря. Этот вложенный словарь затем объединяется с содержимым ключа столба something с конфликтами, вызывающими столпы. Результатом является вложенный словарь, содержащий как значения по умолчанию, так и любые переопределения столбцов, которые затем могут использоваться непосредственно без учета того, откуда взялось конкретное значение.

slspath не является обязательным условием для этого; это волшебная переменная, содержащая путь каталога к текущим sls. Мне нравится использовать его, потому что он отделяет формулу от любого конкретного места в дереве каталогов. Обычно он не доступен из управляемых шаблонов, поэтому я передаю его как явный контекст выше. Он может работать не так, как ожидалось, в более старых версиях, и в этом случае вам придется предоставить путь относительно корня дерева солей.

Недостатком этого метода является то, что, насколько я знаю, вы не можете получить доступ к окончательному словарю с синтаксисом вложенных ключей на основе двоеточия на основе соли; вам нужно спуститься через него на один уровень за раз. У меня не было проблем с этим (синтаксис точки легче набирать в любом случае), но это недостаток. Другим недостатком является необходимость в нескольких строках шаблона в верхней части любого .sls или шаблона с использованием этой техники.

Есть несколько сторон. Один из них заключается в том, что вы можете прокручивать финальный словарь или его подкоманды с .items(), и произойдет правильная вещь, чего не было в случае с defaults.get, и это повлекло меня с ума. Другим является то, что если и когда команда соли восстановит старую функциональность defaults.get, предложенная здесь конструкция по умолчанию/столбца уже совместима, и они будут работать отлично друг от друга.

Answer 2

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

defaults.get в сочетании с файлом defaults.yaml должен делать то, что вы хотите. Предположим, ваша формула дерева выглядит следующим образом:

my-formula/ 
    files/ 
     template.jinja 
    init.sls 
    defaults.yaml 

# my-formula/init.sls 
my-formula-conf-file: 
    file.managed: 
    - name: {{ salt['defaults.get']('conf_location') }} 
    - source: {{ salt['defaults.get']('conf_source') }} 
    ... and so on. 

# defaults.yaml 
conf_location: /etc/my-formula.conf 
conf_source: salt://my-formula/files/template.jinja 

# pillar/my-formula.sls 
my-formula: 
    conf_location: /etc/my-formula/something.conf 

Это закончится конфигурационный файл размещается в /etc/my-formula/something.conf (значение столба) с использованием salt://my-formula/files/template.jinja в качестве источника (по умолчанию, для которых не подавался не столп внахлест).

Обратите внимание на неинтуитивную структуру столбцов и файлов по умолчанию; defaults.get ожидает, что defaults.yaml будет иметь свои значения в корне файла, но ожидает, что столп переопределит быть в словаре, названном по формуле, потому что согласованность для слабых.

documentation для defaults.get дает свой пример, используя defaults.json вместо defaults.yaml. Это работает, но я считаю, что ямль гораздо читабельнее. И доступен для записи.

Существует bug, используя defaults.get внутри управляемого шаблона, а не внутри файла состояния, и насколько я знаю, он все еще открыт. Его все еще можно заставить работать; обходной путь находится за ссылкой.