Используйте несколько файлов var в роли ansible

Одна из моих ролей имеет два разных типа переменных. Один из них является общедоступным (например, версии пакетов и другая полезная информация). Их можно без проблем передать в SCM. Также требуется некоторая личная информация (например, ключи API и другая секретная информация). Я использую ansible-vault для шифрования секретной информации. Мое решение состояло в том, чтобы иметь vars/main.yaml для публичной информации и vars/vault.yml для зашифрованной частной информации.

Я столкнулся с проблемой и не уверен, что здесь наилучшая практика или реальное решение. Кажется, что ansible загружает только файл vars/main.yml. Естественно, я не хочу шифровать общедоступную информацию, поэтому я искал решение. Пока что единственное решение, которое я придумал (предложено на IRC), — это создать group_vars/all/vault.yml и префикс всех переменных с именем роли. Это работает, потому что кажется, что ansible рекурсивно загружает все под group_vars. Это работает, но кажется неверным с организационной точки зрения, потому что переменные предназначены для конкретной роли, а не "универсально истинны в глобальном масштабе". Я также пытался поместить include: vars/vault.yml в vars/main.yml, но это не сработало.

Есть ли правильный способ сделать это?


ansible ansible-vault
person ahawkins    schedule 21.03.2016    source источник

Ответы (3)


arrow_upward
11
arrow_downward

В качестве самой первой задачи в вашей роли у вас может быть include_vars задача.

- include_vars: vault.yml

Я никогда не пробовал, но согласно документации Зашифрованные файлы хранилища можно использовать с модулем include_vars.

Функция хранилища может шифровать любой файл структурированных данных, используемый Ansible. Это могут быть переменные инвентаризации «group_vars/» или «host_vars/», переменные, загруженные с помощью «include_vars» или «vars_files» [...]

person udondan    schedule 21.03.2016
comment
Согласны ли вы с ответом el_whictels ниже о том, что такие вещи не должны быть включены в саму роль? - person ahawkins; 24.03.2016
comment
Не обязательно, это зависит от того, какова цель вашей роли. Если вы просто используете его для структурирования своих правил, я думаю, все в порядке. Скорее всего, этот ключ API не изменится, и другие люди (например, за пределами вашего проекта или компании) не будут использовать эту роль. Если бы это была общая роль для использования другими, то, конечно, не имело бы смысла жестко кодировать ключ API в роли. Но тогда также не имеет смысла иметь файл хранилища в роли, потому что любой, кто его запускает, в любом случае должен знать пароль, поэтому может его расшифровать. - person udondan; 25.03.2016
comment
Тем не менее, можно возразить, что роль вообще не должна содержать никакой конфигурации реализации. Я тоже в основном на этом поезде. Но опять же, если ваша главная цель — придать вашим правилам Ansible структуру, это тоже хороший аргумент. - person udondan; 25.03.2016
comment
@udondan Если роль управляет пользователями, естественно поместить определения пользователей в роль, а не где-то еще. Кроме того, Ansible делает практически невозможным размещение универсальных переменных в другом месте, поскольку group_vars перекрывает друг друга. serverfault.com/q/816126/92706 - person ceving; 25.01.2017
comment
@ceving Я абсолютно не согласен с этим. Роль есть роль и не должна содержать никаких деталей реализации. Определения пользователей должны каким-то образом передаваться роли. Это можно сделать с помощью параметров ролей или, да, group_vars — просто идеальный пример для небольших проектов. Если ваша роль свободна от пользовательских определений, я не понимаю, почему с этим связан приоритет переменных. Вы должны определить своих пользователей в одном месте (group_vars, host_vars, загруженные из какого-то внешнего источника, такого как LDAP, через плагин vars,...), и ничего не будет переопределено. - person udondan; 25.01.2017
comment
@udondan Попробуй понять Ansible. Он не соответствует ни одному из изученных вами объектно-ориентированных шаблонов. Прочитайте ссылку, которую я привел, разберитесь в проблеме и удалите свой комментарий. - person ceving; 25.01.2017
comment
@ceing, за исключением того факта, что udondan является постоянным участником номер 1 для тега Ansible на SO ... пожалуйста, подумайте о том, чтобы в целом принять возможность того, что другие могут иметь более глубокое понимание, чем вы. Это правда, что вам следует избегать объявления одной и той же переменной для групп с перекрывающимся членством, но это просто означает, что вам нужно быть осторожным при разработке своего инвентаря (включая групповые переменные). - person um-FelixFrank; 31.05.2017

arrow_upward
6
arrow_downward

В случае, если кто-то все еще пытается это сделать, вместо следующей структуры:

vars/main.yml
vars/vault.yml

что не будет работать так, как вы видели, вместо этого вы можете организовать свою роль следующим образом:

vars/main/vars.yml
vars/main/vault.yml

Каждый файл vars в «основном» каталоге будет загружен вашей ролью, и вы можете зашифровать только свой файл «vault.yml».

person Chadys    schedule 18.01.2021
comment
Спасибо, это помогло! - person Kevin; 24.03.2021

arrow_upward
5
arrow_downward

Использование Vault — хорошая идея. Но не стоит этого делать в роли.

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

Одним из решений запроса требуемой переменной является простое условие:

- fail: msg="Variable foo is required"
  when: foo is not defined

Таким образом, обработка зашифрованных переменных хранилища находится на уровне учебника. Это деталь реализации, которая не должна быть в роли.

person flxPeters    schedule 21.03.2016