2016-03-21 3 views
8

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

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

Есть ли способ для этого?

ответ

4

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

- include_vars: vault.yml 

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

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

+0

Согласны ли вы с el_whictels ниже, о таких вещах не следует включать в эту роль? – ahawkins

+0

Не обязательно, это зависит от цели вашей роли. Если вы просто используете его для структурирования правил, я думаю, что все в порядке. Скорее всего, этот ключ API не изменится, и другие люди (как вне вашего проекта или компании) не будут использовать эту роль. Если бы это была общая роль для других, то, конечно, было бы нецелесообразно жестко программировать ключ API в роли. Но тогда также было бы бессмысленно иметь файл хранилища в роли, потому что любой, кто его запустил, все равно должен знать пароль, поэтому может его декодировать. – udondan

+0

Тем не менее, можно утверждать, что роль не должна содержать никакой конфигурации реализации вообще. В основном я тоже на этом поезде. Но опять же, если ваша главная цель - дать вашим правилам Ansible структуру, это тоже хороший аргумент. – udondan

4

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

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

Одно решение попросить необходимой переменной является простым условием:

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

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

Смежные вопросы