Комментарии 28
Все роли у вас выполняют конфигурацию конечных хостов?
не всегда так. есть базовые/generic роли: поставить java, application сервер, solr. Есть роли которые комбинирует эти кирпичики вместе строя полноценную конфигурацию сервера. Это уже больше похоже на конфиг конечного хоста. но все равно потом в host_vars, например, может приехать кастомизация.
то есть тестирование = запуск ВМ и раскатка ролей последовательно, зависимо от типа ОС накатывая конфиги и все что требуется для работы хоста я так понял?
зависит от. в большинстве проектов прижилась схема:
- линтуем все что можно
- если все ок, проверяем каждую роль по отдельности в docker
- если все ок, проверяем на виртуалках выборочно что-то
идея в том, что бы укоротить feed back loop.
теперь вопрос — представьте я решил написать роль для автоматизации задачи «ежедневного резервного копирования»
Как тестировать через Molecule такую роль? добавить check_mode не вариант же теряется смысл в тестировании. Может есть дельный совет?
я бы тут задал вопрос почему ansible для такой задачи? Поясню: сложно положить такую задачу на декларативную парадигму ansible если честно, т.к. это скорей всего потянет за собой написание модуля со сложной логикой какой-то и у этого модуля будет какой-то другой процесс тестирования. в ансибловом коде народ так вобще мокает какая команда в консоли должна запуститься. с тестированием модулей я пока в творческом поиске.
почему ansible для такой задачи?
Почему-то все вкладывают в IaC только задачи разворачивания и обновления инфраструктуры. Но в моем понимании у инфраструктуры есть еще и регулярные задачи, которые неплохо бы тоже хранить как код: резервное копирование, обновление правил фаервола, блокировка/изменение пользователей на машинах (там где нет SSO) и т.д.
Ну в моем конкретном примере есть какой-то простой инструмент для создания ежедневной копии (к примеру borg), и я вместо создания на каждом хосте скрипта с кроном решил описать все на ansible и выполнять эту задачу с одной точки. Плюсы: секрет в одном месте и простая конфигурация из одной точки. В какую парадигму это вписать, это скорее филосовский вопрос, но пока что мне не пришлось использовать модули со сложной логикой, все максимально просто.
звучит логично и ризонно. а можно где-то глянуть пример?
я вместо создания на каждом хосте скрипта с кроном решил описать все на ansible и выполнять эту задачу с одной точки
???
Лишняя централизация — это зло. На самом деле надо подбирать инструмент под задачи и соответственно — вариант systemd-timer + скрипт, который разливается ансиблом может быть сильно лучше, чем полный бекап в виде отдельного плейбука.
Почему-то все вкладывают в IaC только задачи разворачивания и обновления инфраструктуры. Но в моем понимании у инфраструктуры есть еще и регулярные задачи, которые неплохо бы тоже хранить как код: резервное копирование, обновление правил фаервола, блокировка/изменение пользователей на машинах (там где нет SSO) и т.д.
Несомненно. Но тут надо разграничить — мы храним это все как условные настройки в репозитории с кодом IaC, которые разливаются на машины, или мы используем отдельные скрипты вне этого процесса, но в рамках более широкого понимания инфры как живого организма.
Поделюсь болью. В рамках, например, salt это все реализуется при помощи встроенной шины сообщений и встроенных примитивов для этого, но сложность их отладки и проверки на порядок выше, чем просто "давайте накатим плейбук или стейт" и "посмотрим молекулой или кухней, что там получилось" — т.к. надо либо писать юнит-тесты, либо поднимать полную копию инфру и на ней отлаживать эту событийную модель :-/
а это теоретические выкладки как тестить или были попытки реализовать? есть примеры куда можно глянуть?
Это вы мне ответьте — зачем излишне централизовать то же создание бекапов? И делать некий контроллер для запуска ансибла?
Вы же ведь наверняка не используете AWX / Tower? Или пускалкой бекапов становится Дженкинс?
Про бэкапы это в соседний трэд. Касательно централизованности запуска ансибла:
- Логирование действий
- Воспроизводимость окружения и версий что запускаем
2-я проблема решается путем засовывания ансибла в докер образ :-) и написанием четкой инструкции как его применять.
1-я проблема — согласен. Но тогда теряется вся прелесть ансибла, т.к. он не умеет в сервер-клиент (в отличие от настоящих паппетов-chef'ов-salt'ов) — коли уж централизоваться, так по полной.
Мое мнение — ансибл прекрасен для первоначальной настройки или использования в пайпах. Управлять же им флотом машин, изменениями в конфигурации. Брррр
???
Лишняя централизация — это зло. На самом деле надо подбирать инструмент под задачи и соответственно — вариант systemd-timer + скрипт, который разливается ансиблом может быть сильно лучше, чем полный бекап в виде отдельного плейбука.
Зачем усложнять крон? В случае с одной точкой у вас есть сразу результат вашего бэкапа, в случае с отдельными скриптами у вас куча скриптов и наверное в случае фейла вы с каждым хостом будете разбираться отдельно. И важный момент у меня шифруется хранилище — ключ в одном месте а не на каждом хосте. Я могу менять свой ключ каждые 2 минуты.
Несомненно. Но тут надо разграничить — мы храним это все как условные настройки в репозитории с кодом IaC, которые разливаются на машины, или мы используем отдельные скрипты вне этого процесса, но в рамках более широкого понимания инфры как живого организма.
IaC это подход для управления и описания инфраструктуры ЦОД через конфигурационные файлы
То есть и управления тоже
Поделюсь болью. В рамках, например, salt это все реализуется при помощи встроенной шины сообщений и встроенных примитивов для этого, но сложность их отладки и проверки на порядок выше, чем просто «давайте накатим плейбук или стейт» и «посмотрим молекулой или кухней, что там получилось» — т.к. надо либо писать юнит-тесты, либо поднимать полную копию инфру и на ней отлаживать эту событийную модель :-/
Может тут как раз неверно выбран инструмент? если нельзя мокать или тестить без моков хотя бы часть функционала, то эти конфиги превратятся в legacy скорее — к ним все будут бояться подойти и тем более изменить. но это мое мнение
Мое мнение — ансибл прекрасен для первоначальной настройки или использования в пайпах. Управлять же им флотом машин, изменениями в конфигурации. Брррр
Вы серъезно считаете что ансибл используется ТОЛЬКО для первоначальной настройки? зачем тогда ансибл? пишите файлы-ответы! как управлять парком в 50 серверов без централицазии? я могу получить состояние обновление всего парка в течении 10 минут. А вы?
Вы же ведь наверняка не используете AWX / Tower? Или пускалкой бекапов становится Дженкинс?
Использую AWX, командная строка чаще, иммел проблемы при его обновлении — руками приходилось править миграции он свободный сейчас лучше чем раньше
Вы серъезно считаете что ансибл используется ТОЛЬКО для первоначальной настройки?
нет, но это, что у него получается лучше всего (в packer, например, или в terraform). Иначе у нас извините не иммьютейбл инфра, а черти-знает-что.
пишите файлы-ответы!
LOL
я могу получить состояние обновление всего парка в течении 10 минут. А вы?
если инфра имьютейбл — это есть на стороне провайдера. Ну, в своей легаси инфре — да, я могу это сделать за 10 минут. И еще — ансибл у вас на сколько узлов скейлится — 100-1000-10000?
В случае с одной точкой у вас есть сразу результат вашего бэкапа, в случае с отдельными скриптами у вас куча скриптов и наверное в случае фейла вы с каждым хостом будете разбираться отдельно.
зато отдельная проблема — обеспечить отказоустойчивость этой самой точки + доступ ко всем узлам (они не смогут теперь автономном функционировать) + идемпотентность алгоритма и устойчивость его к перезапускам и локи на повторные запуски на всякий случай. Ну, что ж — каждому по велосипеду. Своему. Лучшему. Который ты лучше всего знаешь и можешь саппортить.
нет, но это, что у него получается лучше всего (в packer, например, или в terraform). Иначе у нас извините не иммьютейбл инфра, а черти-знает-что.
Вы как-то все в одну кучу) Причем здесь иммьютейбл, как этот подход связан с IaC? каждый раз при обновлении к примеру nginx — сносите все и разворачиваете новую инфру с одним измененным компонентом?
И еще — ансибл у вас на сколько узлов скейлится — 100-1000-10000?
да на любое количество, под любой тип ОС все верно у ансибл это неплохо получается.
зато отдельная проблема — обеспечить отказоустойчивость этой самой точки + доступ ко всем узлам (они не смогут теперь автономном функционировать) + идемпотентность алгоритма и устойчивость его к перезапускам и локи на повторные запуски на всякий случай.
нет проблемы в отказоустойчивости — нужна любая машина с ansible все. Доступ ко всем узлам с одного узла а не с 1000 машин, не вижу проблем — машина в DMZ. Повторяемость и локи решаются правильным написанием роли. Может я и не прав, так укажите где, в чем это Велосипед? я попытаюсь понять, в чем я не прав. Какой подход использовать?
каждый раз при обновлении к примеру nginx — сносите все и разворачиваете новую инфру с одним измененным компонентом?
если надо обновить версию пакета — почему нет. Можно пересобрать "золотой образ" и перелить сервера. Потому что иначе вы получаете почти наверняка "хвосты" в системе + configuration drift. Понятно, что такое можно проворачивать дешево только в случае, если среда построена на ВМках. На bare metal полностью делать провижионинг — больно и дорого.
А конфиги… Ну, с конфигами ПО все интереснее. Есть разные подходы к их доставке в зависимости от того, как часто они меняются.
В общем — все зависит от того, что уже есть, какие требования выдвигаются и прочее-прочее. Универсального решения нет.
Провокационный вопрос — Вы в своих ролях четко обрабатываете ситуации обновления пакета с произвольной версии на произвольную версию и миграции между самими версиями ролей? Честно — вот почти наверняка нет. И в целом при иммутабельном подходе это и не нужно в общем.
нет проблемы в отказоустойчивости — нужна любая машина с ansible все.
а я утверждаю, что есть. У вас сдохла машина с запущенным ансибл — дальше что будет происходить? Все плейбуки поотваливаются в процессе работы? Статусы play'ев сможете получить? Я что-то очень сомневаюсь.
Повторяемость и локи решаются правильным написанием роли.
с этим я согласен. И строго за это агитирую. Но это уже выходит за рамки большинства ролей, которые свободно доступны с гитхаба.
у меня хорошо для ansible заходит:
- packer + ansible
- конфигурирование вм
- конфигурирование клиентских инсталляций когда нет админских прав на целевой системе и air gap до кастомеров
не очень заходит:
- создание вм на винде, ну и фиг
- создание вм на vmware, не очень удобное и долго, но зато в одном месте все.
- создание контейнеров ansible-container пробовал — не зашел. хочу попробовать ansible bender. не идет но очень бы хоетлось
Спасибо, это хороший список. Никаких возражений по нему у меня нет.
Могу добавить, что ещё заходит
- Разнообразная автоматизация, но без фанатизма.
- Пайплайны разработки — развернуть что-либо на разных целевых платформах — от вм до кубернетеса. В каком-то смысле для этой цели ансибл лучше подходит, чем специализированные решения вроде helm. В том числе и благодаря широкому спектру модулей и встроенного шаблонизатора.
- Как вырожденный вариант #2 — как замена docker-compose (собрать, запустить контейнеры, потушить их после тестов или цикла разработки).
создание вм на vmware, не очень удобное и долго, но зато в одном месте все.
А что Вы используете — нативные штуки от вмвари или terraform?
Vra пока будем смотреть. С терраформ вопросы есть: не понятно где Стэйт хранить нам, пс вариантов конфигов вм ну очень много и все их выпекать тяжко будет. Плюс обсуждается переезд большинства линуксовых вм в k8s
кстати, насчет кейсов, еще был один который не очень полетел — ansible как шаблонизатор для k8s/openshift. работать работает, но есть чувство создания велосипедов
пока вместо докера:
- ansible роль как настроить окружение
- модули какие есть сложили в мета-роли и они лежат в репе инклюдаясь в нужных ролях
для визуализации есть https://github.com/ansible-community/ara но у нас не пошло как то
Секреты, если они критичны, лучше чтобы были хост-персональны. Это, конечно, требует доп. усилий, но тут уж «шашечки или ехать».
В целом, так делать никто не запрещает, но у разработчиков такое называется «протекание абстракций». Лучше когда полезная нагрузка выполняется хостами, без участия Ansible. А Ansible используется только по назначению: изменение конфигурации.
Ansible запускает задачи подготовки копирования и задачи пуша бэкапа. Полезную нагрузку выполняют хосты, а не машина с ansible. Я в данном случае могу контролировать полностью какой архив бэкапа, в каком порядке и на какой скорости ложить в хранилище, а по завершению копирования получить статус по каждой машине. Поясните, что в данном случае является абстракцией и почему она течет?
Секреты, если они критичны, лучше чтобы были хост-персональны. Это, конечно, требует доп. усилий, но тут уж «шашечки или ехать».
Они хост-персональны, но хранятся не на хостах.
Задача конструктора автобуса сделать удобный и практичный автобус.
Задача водителя регулярно перевозить людей из одной точки в другую.
Если вдруг так получилось, что вышел водитель на работу или нет, целиком и полностью зависит от конструктора, то что-то в этом не так.
При этом зависимость водителя от конструктора все таки есть. От конструктора напрямую зависит каким будет автобус. Но в поле все зависит только от водителя. Что делает в этот момент конструктор — неважно.
Если вернуться к нашему кейсу с бекапами, то если ansible-хост недоступен, и из-за этого бекапы не пишутся, это уязвимая схема. Ansible нужен только в момент настройки, чтобы донести до целевого хоста нужные секреты, поднять кроны, положить скрипты, убедиться что все ок. А дальше все зависит только от самого целевого хоста.
Все напрашивается картинка "троллейбус из буханки".
Касательно IaC. У нас разный подход. И такое ощущение, что у Вас происходит подмена понятия. Описание того, как разложить скрипт бекапа по машинам — IaC? Скорее да. А вот сам скрипт бекапа является ли элементом IaC?? Ну, это явно код. Только вот он не совсем инфраструктурный. Так какой же? Прикладной? Да вроде бы и нет тоже. Где-то посерединке. Такой вот клей между слоями. И, конечно, он может быть в основной инфраструктурной репе. Точно так же как там могут лежать деб пакеты, целиковые скрипты и прочее, что обычно считается "артефактами". Только вот удобно ли использовать Ваш подход и является ли он "чистым" с идеологической точки зрения — это отдельный вопрос.
А по поводу «артефакты» — это файл-результат сборки или этапа сборки, деб пакет будет результатом сборки, к примеру, репа с исходниками и debian инструкциями. Не вижу аналогии с сохранением в репозитории ansible-playbook, задача которого — выполнять регулярные задания.
Я к чему — не нужно пытаться видеть во всем ансибл. А то это похоже на хирурга — а чего — у пациента болит рука — давайте ее отрежем.
Давайте абстрагируемся от резервной копии и попробуем на примере ИБ. Разложить и сконфигурить правила фаерволла тогда для вас — IaC? скорее да. Только вы это делаете 1 раз? при разворачивании ОС? — скорее нет. Я не вижу необходимости разворачивать занаво хост после изменения 1 правила в netfilter. IaC — описание и управление инфраструтктурой.
настройка файрволла — управление
запуск РК — нет (это не является изменением в конфигурации)
окей — вы хотите оркестрировать, т.е. быть дирижером по сути — но это задача ортогональная к IaC.
А вот и Английская версия
Как начать тестировать Ansible, отрефакторить проект за год и не слететь с катушек