Как мы широко используем Ansible в ExpressVPN

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

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

Чтобы упростить обмен знаниями и правильное использование инструментов, мы решили стандартизировать использование Ansible для управления конфигурацией и операций на сервере..

В этом блоге рассматриваются уроки, которые мы извлекли, работая в нашем масштабе, размышления о том, как мы работаем, и как мы управляем Ansible в таком контексте..

Ansible документация

Давайте прямо в это! Документация для Ansible оставляет желать лучшего, особенно когда речь идет о сквозной документации (например, как добраться из пункта А в пункт Z?).

Некоторые вопросы, с которыми мы регулярно сталкиваемся: «Как работает переменный приоритет?» И «Как вписывается Ansible Vault?»

Обе проблемы хорошо документированы независимо друг от друга (здесь и здесь), и на странице Ansible Variables есть очень хороший раздел о приоритете в явном виде, но пересечение двух получает лишь краткое упоминание. Проблема в том, что между документацией о переменных и хранилищах нет ссылок, что создает впечатление, что пользователь должен выяснить, как они пересекаются друг с другом..

Итак, сегодня мы попытаемся охватить пересечение переменных и хранилищ и лучшие практики.

Для чего вы можете использовать файлы Ansible Vault

В итоге: документация Vault гласит, что вы можете зашифровать что-нибудь внутри вашей папки Ansible в файл Vault, и Ansible будет пытаться «умно» расшифровать его, если в игру включены эти файлы. Да. здорово!

В документации о переменных вообще ничего не говорится о файлах Vault, что странно, поскольку Vault был разработан для файлов переменных. Так как они сочетаются друг с другом? Важно отметить, что Сами файлы хранилища не имеют особого значения для обработки переменных или их приоритета., так что есть большая гибкость. Но потенциально это не оставляет вам достаточно информации о том, как правильно его использовать.

Ты делаешь это неправильно.

Возьмите этот пример простой папки Ansible:

.
Group── group_vars
All ├── все
Production ├── производство
│ └── постановка
Ible── ansible.cfg
Inventory── инвентарь
Play── playbook.yml

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

Теперь файл «all» не может быть файлом Vault, так как вы (будем надеяться) зашифровали файлы промежуточного и производственного Vault с разными паролями. Но это также означает, что ваш файл group_vars для сред должен содержать сочетание секретов и не секретов, так как вы ограничены одним файлом на среду.

Из-за этого – и если вы немного экстраполировали после прочтения вступления в хранилища в документации Ansible – вы, вероятно, создали производственные / промежуточные хранилища, сначала скопировав содержимое «all», а затем изменив их..

Это означает, что ваш файл «all» может выглядеть так:

база данных:
имя пользователя: default_user
пароль: ложь

super_important_var_that_should_be_one: 1

И ваш производственный Vault-файл может выглядеть так:

база данных:
имя пользователя: продюсер
пароль: supersecretpasswordnoonecansee

super_important_var_that_should_be_one: 1

(Не волнуйтесь, это не наш действительный производственный пароль! Мы дважды проверили.)

Вышесказанное опасно по причинам, которые могут быть неочевидными. Например, вы можете пропустить изменение по умолчанию для производства, и / или ваш файл «all» может даже быть назван неправильно и вообще не включен! (Это основная причина сбоя, произошедшего на прошлой неделе.)

Рекомендации: как безопасно использовать файлы Ansible Vault

Как указано на странице рекомендаций, превращение файла в файл Vault скрывает его содержимое, поэтому у него есть большой недостаток: вы не можете искать, какие переменные находятся в файле Vault, без явного их дешифрования. Эта система означает, что тот, кто просматривает вашу конфигурацию Ansible, не знает, что находится внутри этих файлов, не зная пароля Vault (ужасно для проверок кода!). Следовательно, мы рекомендуем помещать как можно меньше переменных в файлы Vault. (Другими словами, только помещайте секреты в файлы Vault!)

Итак, давайте посмотрим на конструкцию, которая облегчила бы, чтобы вы не застрелились в ноге:

.
Group── group_vars
All ├── все
│ │ └── vars.yml
Production ├── производство
│ │ ├── vars.yml
Ault │ └── vault.yml
│ └── постановка
Ault └── vault.yml
Ible── ansible.cfg
Inventory── инвентарь
Play── playbook.yml

В документации по передовому опыту также рекомендуется использовать «слой косвенности», означающий, что во всех Переменных в файле Vault вы должны создавать шаблоны в Переменные, на которые есть ссылки в ваших книгах. Он также рекомендует префикс ваших переменных хранилища «vault_», что означает, что ваш all / vars.yml может выглядеть примерно так:

база данных:
имя пользователя: default_user
пароль: «{{vault_database_password}}»

super_important_var_that_should_be_one: 1

Ваша продукция / vars.yml выглядит примерно так:

база данных:
имя пользователя: продюсер

И ваш файл production / vault.yml должен содержать только следующее:

vault_database_password: supersecretpasswordnoonecansee

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

И, что более важно, Ansible не сможет даже отрендерить переменные, если ему не хватает vault_database_password Переменная в Vault, которая избавит вас от как минимум ряда проблем, с которыми вы можете столкнуться, если не будете закрывать вкладки в файлах Vault.

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

Это все на данный момент, мы надеемся, что это было полезно для вас!