Comments 16
Но ведь действительно, инструменты похожи, но используются для разных целей - тогда становится неуместно их сравнивать
Так и не увидел внятных аргументов почему нужно использовать Ansible вместо Terraform. Только и увидел, хотел поиграться с API. Заголовок кликбейтный
А где кликбейт? Была конкретная ситуация, для которой в провайдере от Яндекса не нашлось инструмента. Решилась задача через создание собственного модуля для Ansible (поскольку нужно было работать с Lockbox через Ansible). Это случай дал материал для статьи.
ну похоже всё упирается в то, что
у провайдера для Terraform от Яндекса нет нужного функционала.
и поэтому пришлось танцевать с бубном.
Но да, имхо стоило бы отправить запрос к разработчикам провайдера, тогда в будущем можно было бы не городить свой модуль.
Очень интересный опыт, спасибо за статью и за сами модули, будем внимательно изучать!
Многие облачные провайдеры предоставляют свои инструменты командной строки для управления инфраструктурой. Поэтому даже от Ansible можно отказаться))) Только Terraform (и Pulumi) это про декларативность описания инфраструктуры, когда в любой момент времени можно посмотреть код и по нему точно понять описание инфраструктуры в облаке. Все последующие изменения можно делать без выяснения текущего положения дел с инфраструктурой: надо увеличить число нод в кластере, просто указали нужное и не надо смотреть какое было до этого; надо удалить инстанс, убрали его из описания (к примеру) манифеста; надо докинуть памяти/ядер/диска, просто указали нужное число; пришло время снести весь стенд (и такое бывает, причём, нередко) - terraform destroy. При использовании инструментов с императивным описанием (например Ansible), прежде чем вносить измнения, надо уточнять текущее положение дел в инфре ну и момент с откатом к предыдущему состоянию инфры не так прост.
для тех действий, которые требуются от DevOps-инженеров на проекте, Terraform не предлагает нужной функциональности.
Очень интересно какой функциональности не хватило?
Регулярные операции по обслуживанию, которые мы обернули в плейбуки Ansible, часто используют чувствительную информацию. Но в силу специфики проекта мы не могли использовать Vault или аналогичное хранилище секретов и до недавнего времени передавали секреты, используя комбинацию из утилит SOPS и Age. Не очень удобно и потенциально небезопасно.
Для Ansible есть утилита ansible-vault. Работает замечательно. Про некоторое неудобство SOPS согласен, про потенциальную небезапосность хотел бы узнать по подробнее.
Дело в том, что продукт Hashicorp декларативен. Это, безусловно, плюс для работы с облачной инфраструктурой в целом, но для тонкой настройки определённых сервисов этого недостаточно.
Возможности userdata в Terraform довольно большие, можно запихнуть много чего.
Кроме этого, есть ещё минусы: необходимо держать отдельный репозиторий с кодом для Terraform, хранить и передавать его state, каждый раз использовать модули shell, terraform, потом обрабатывать их вывод… Лучше уж использовать Bash.
В чём проблема от отдельного репозитория для Terraform? Даже когда в него закидывать кучу модулей, ключей и немного кода на bash, он совсем немного места занимает как и state. И его назначение (репозитория) основное - источник правды. Можно сказать, это документ, по которому другие инженеры должны понимать и принимать вашу инфраструктуру.
В командах terraform нет ничего сложного и вывод может быть куда более понятный чем дебаг от Ansible.
В дальнейших планах — собственная коллекция Ansible, в которой хочется охватить те аспекты работы с облачными сервисами, где terraform’у не хватает гибкости
С помощью terraform описывается инфраструктура, с помощью Ansible выполняются задачи администрирования (12-й пункт 12 factors). Довольно распространённый подход.
Коллега, давайте по пунктам.
Прекрасно знаю, для чего нужен terraform и как работать с инфраструктурой, но в данном случае мы работаем с облачным хранилищем секретов, а это более тонкая сущность нежели виртуальная машина или meneged service. Давайте посмотрим на то, как в провайдере terraform для Lockbox реализована работа с секретами и применим к реальной ситуации. Представьте, у вас несколько сотен записей, которые периодически надо менять, и, чаще всего, читать в самых разных сценариях, для которых у вас уже написаны плейбуки и роли. И вот вы пишете кучу однотипных манифестов с ресурсами по документации https://terraform-provider.yandexcloud.net/resources/lockbox_secret.html, складываете в отдельный репозиторий, а когда вам надо изменить секрет, пишете ещё манифест, который создаст версию секрета с нужными изменениями по документации https://terraform-provider.yandexcloud.net/resources/lockbox_secret_version.html. А секреты изменяются часто.
Итого, имеем обширный инфраструктурный код, который будет неизбежно дрейфовать (человеческий фактор). Поступившись декларативностью и добавив в модуль простую проверку https://github.com/krang404/ycm/blob/26195a909b3dfea87aeb88b545049cb9c97fe5c4/plugins/modules/yc_lockbox.py#L330 , мы можем подавать на вход только данные для секрета и не городить большую кучу инфрового кода. И да, читать из секрета через data удобно только внутри терраформа, а реализовать чтение "на лету" при выполнении плейбука ansible - это отдельный квест, и параметр "скорость выполнения сценария" при реализации возрастёт в разы.
Далее, вы спрашиваете, почему передавать секреты через репозиторий, шифруя их c помощью ansible-vault или sops+age, небезопасно. Отвечаю кратко: человеческий фактор. Сюда входит и невозможность предоставить разделённый доступ к секретам (вы даёте доступ всей команде сразу и никак не можете гранулировано его распределить), и отсутствие контроля за безопасностью хранения секретов на локальных хостах разработчиков, ну и просто безалаберность коллеги (кто-нибудь обязательно коммитнет в репо незашифованный файл). Безусловно, все проблемы можно нивелировать, но вопрос: какой ценой? Проще всего - не хранить секреты в репозитории (даже зашифрованные). Одним махом избавите себя от постоянной головной боли.
Добавлю ещё ремарку про ваше высказывание о том, что код терраформа сам себя документирует, и напомню, что Ansible тоже прекрасно справляется с этой задачей.
Ну и, напоследок, выскажусь касательно жёсткого декларирования по цветовой дифференциации штанов инструментов. Можно сколько угодно твердить "мы должны использовать Terraform только для работы с инфраструктурой!", но, если молоток не не приспособлен под задачу вкручивания шурупов, не лучше ли взять шуруповёрт?
мы работаем с облачным хранилищем секретов, а это более тонкая сущность нежели виртуальная машина или meneged service
В чём именно тонкость сущности облачного хранилища секретов? Там вроде нет ничего такого по сравнению с аппаратным HSM.
Представьте, у вас несколько сотен записей, которые периодически надо менять, и, чаще всего, читать в самых разных сценариях, для которых у вас уже написаны плейбуки и роли.
Давайте всё же будем честны. Периодическое обновление записей никак не кореллирует с чтением. Операция чтения идемподентна и нас никак не должна волновать нас. Поэтому это нельзя никак считать в качестве аргумента.
И вот вы пишете кучу однотипных манифестов с ресурсами по документации ..... складываете в отдельный репозиторий, а когда вам надо изменить секрет, пишете ещё манифест
Могу только заметить, что измнение переменной или добавление новой не должно приводить к написаню нового манифеста. У вас где-то рекурсия, с которой надо разобраться. Потому что это совсем не декларативный стиль описания. Должно быть: вы изменили переменную в коде, она автоматически изменилась в инфраструктуре (у вас для этого должны быть pipeline)
И да, читать из секрета через data удобно только внутри терраформа, а реализовать чтение "на лету" при выполнении плейбука ansible - это отдельный квест, и параметр "скорость выполнения сценария" при реализации возрастёт в разы
Но вы сами выбрали инструменты и неподходящую парадигму. Параметр "скорость выполнения сценария" больше зависит от правильности выбранного алгоритма, оценки его сложности и правильной реализиции. Поэтому сложность реализации процедуры "чтение переменных из терраформа" при выполнении плейбука ansible целиком и полностью на плечах задумавшего такое.
Далее, вы спрашиваете, почему передавать секреты через репозиторий, шифруя их c помощью ansible-vault или sops+age, небезопасно. Отвечаю кратко: человеческий фактор.
Тогда под этот критерий попадает практически любая реализация криптографии. Это не ответ на вопрос небезопасности касаемо криптографических инструментов таких как ansible-vault или sops+age. Таким образом ваша реализация аналогично никак не застрахована от человеческого фактора. Тем более для реализации безопасного взаимодействия между командой разработки и командой девопс вам необходим защищённый канал, когда разработчику надо передать переменную команде девопс, которую надо добавить в секреты, либо команде девопс надо передать переменную команде разработки, чтобы выполнить тесты.
Добавлю ещё ремарку про ваше высказывание о том, что код терраформа сам себя документирует
Не писал такого, что код (любое приложение) сам себя документирует. Документация к коду и сам код немного разные вещи. Иногда совсем.
Можно сколько угодно твердить "мы должны использовать Terraform только для работы с инфраструктурой!", но, если молоток не не приспособлен под задачу вкручивания шурупов, не лучше ли взять шуруповёрт?
Хороший вопрос. Часто его приходится задавать людям, которые решили засунуть всё в кубернетес, тем самым (по их мнению) решив все проблемы. Приходилось встречаться с различными применениями Terraform от управления доменными учётными записями и развёртыванием приложений в k8s, до управления дашбордами мониторинга. Но вы сами сказали что молоток (ansible) изначально не предназначен для управления облачной инфраструктурой (даже в документации ЯОблака нет ни одного примера работы с инфраструктурой при помощи ansible), поэтому правильнее воспользоваться шуруповёртом (в документации ЯОблака практически каждый пример работы с инфраструктурой описывается при помощи Terraform). Тем более ЯОблако постоянно обновляет драйвера TF для своего облака и приводит для него примеры в своей документации.
Прекрасный пример того, как нужно подходить к автоматизации инфраструктуры! В нашей организации мы тоже постепенно отказываемся от Terraform в пользу Ansible для определенных задач. Автор четко показал, когда это оправдано. Особенно ценно описание процесса создания кастомных модулей и это экономит массу времени. Жаль, что в статье не упомянули про безопасность такого подхода, но в целом статья заслуживает высшей оценки.
Спасибо за лестный отзыв. Аспекты безопасности использования кастомных модулей - это отдельная тема, раскрыть которую в рамках одной статьи, мне кажется, будет сложно. Тем более, что текст посвящён конкретной точке приложения такого подхода, а вопрос безопасности собственных модулей для Ansible надо рассматривать шире.
Выбор между связкой Ansible + Python и Terraform для Yandex Cloud - это не вопрос абсолютного превосходства, а поиск оптимального решения под конкретные задачи.
Таким образом связка Ansible + Python становится предпочтительным выбором для Yandex Cloud, когда требуется глубокая интеграция провиженинга и конфигурационного управления в одном инструменте, необходима реализация сложной, нестандартной логики, выходящей за рамки HCL и требующей мощи Python, а команда уже имеет экспертизу в Ansible и Python и стремится к унификации инструментов, или управляемая среда требует высокой адаптивности и сложного динамического инвентори.
Terraform же лидирует в сценариях масштабного провиженинга стандартных ресурсов, где критичны предсказуемость плана и централизованное управление состоянием, а сложная конфигурация ВМ вынесена за его пределы.
В любом случае, окончательное решение должно базироваться на конкретных требованиях проекта, существующем стеке, экспертизе и оценке, где сосредоточена основная операционная сложность - в создании ресурсов или их последующей настройке и дальнейшем жизненном цикле.
Очень познавательная статья! Информация изложена ясно и по делу. Спасибо автору за интересный материал.
Когда Terraform не нужен: работаем с инфраструктурой через Ansible