Comments 13
Есть. Как минимум — habr.com/ru/company/oleg-bunin/blog/431542
И еще — а Вы точно уверены, что все роли должны быть идемпотентными?
А если ансибль у нас используется как просто способ описания для каких-то задач (например, бекап, или изменения в инфраструктуре) — очевидно, что могут быть разные сценарии.
И еще — а Вы точно уверены, что все роли должны быть идемпотентными?
А если ансибль у нас используется как просто способ описания для каких-то задач (например, бекап, или изменения в инфраструктуре) — очевидно, что могут быть разные сценарии.
Да, все роли должны быть идемпотентными. Потому что иначе будет больше геморроя, чем пользы.
НЕ НАДО использовать ansible для бекапа. Тут справится и bash скрипт.
Изменение в инфраструктуре ОБЯЗАНО быть идемпотентным, потому что плейбук описывает состояние К которому надо привести систему, а не действия которые надо выполнить.
НЕ НАДО использовать ansible для бекапа. Тут справится и bash скрипт.
Изменение в инфраструктуре ОБЯЗАНО быть идемпотентным, потому что плейбук описывает состояние К которому надо привести систему, а не действия которые надо выполнить.
Я сам сильно агитирую за то, что Вы пишете, но, к сожалению, у многих альтернативное мнение.
К тому же это реально удобно (что, видимо, и приводит к описанному мной) иметь один инструмент для решения задач (а не тащить 100500 разных тулингов).
Еще момент, что идемпотентность в сложных случаях будет все равно реализована путем написания своих императивных модулей (условно — мы хотим удалить файл, то тогда нам все равно нужно две вещи: проверить, что он существует, и потом уже его удалить — обе, очевидно, императивщина).
К тому же это реально удобно (что, видимо, и приводит к описанному мной) иметь один инструмент для решения задач (а не тащить 100500 разных тулингов).
Еще момент, что идемпотентность в сложных случаях будет все равно реализована путем написания своих императивных модулей (условно — мы хотим удалить файл, то тогда нам все равно нужно две вещи: проверить, что он существует, и потом уже его удалить — обе, очевидно, императивщина).
Альтернативное мнение, как и мнение альтернативно одаренных не стоит учитывать, себе доорже выйдет.
Мое мнение, что инструмент под задачу, а не растить монстра из одного инстнумента. Приведем тот же пример с бекапами. Бекап нужно
а) Создать. Скопировать файл, сделать дамп базы, etc.
б) Перенести в место, где он будет хранится. Иметь возможность настроить правила типа «Хранить Х бекапов за срок Y», удалять старые бекапы и далее.
в) Проверить бекап. А не нулевой ли у нас дамп? А не побился ли файл при сохранении? И далее, далее. Gitlab учит нас этому :)
г) Как-то восстановить бекап.
Это мои базовые требования к системе, которая делает бекапы. Все на основе личнгого опыта и опыта коллег. Что-то меньшее — не имеет смысла, потому что я просто не буду ему верить. Делать все это на ansible? Ну… каждый развлекается как хочет. Но вот в продакшене я бы за такое бил по рукам :)
Да, надо писать свои модули. А как иначе? :)
Касательно удаленного файла, у вас небольшая ошибка. Мы описываем состояние, а не действия. То есть мы не хотим удалить файл. Для нас важно, что файла нету. То есть это по факту один модуль, который в самом простом случае выполняет команду rm -rf path || true.
Мое мнение, что инструмент под задачу, а не растить монстра из одного инстнумента. Приведем тот же пример с бекапами. Бекап нужно
а) Создать. Скопировать файл, сделать дамп базы, etc.
б) Перенести в место, где он будет хранится. Иметь возможность настроить правила типа «Хранить Х бекапов за срок Y», удалять старые бекапы и далее.
в) Проверить бекап. А не нулевой ли у нас дамп? А не побился ли файл при сохранении? И далее, далее. Gitlab учит нас этому :)
г) Как-то восстановить бекап.
Это мои базовые требования к системе, которая делает бекапы. Все на основе личнгого опыта и опыта коллег. Что-то меньшее — не имеет смысла, потому что я просто не буду ему верить. Делать все это на ansible? Ну… каждый развлекается как хочет. Но вот в продакшене я бы за такое бил по рукам :)
Да, надо писать свои модули. А как иначе? :)
Касательно удаленного файла, у вас небольшая ошибка. Мы описываем состояние, а не действия. То есть мы не хотим удалить файл. Для нас важно, что файла нету. То есть это по факту один модуль, который в самом простом случае выполняет команду rm -rf path || true.
Кого бы вы там по рукам били? :-D Развели тут джигитовку!
Есть три вопроса к вашему высказыванию:
1. Где указано, что Ansible — это инструмент деплоймента состояний? Я лично видел определение «инструмент автоматизации».
2. Почему вы считаете, что ваши требования к бэкапам на Ansible реализуются сложнее, чем на bash?
3. Вы серьёзно используете Ansible для описания состояний? Я бы вас за это на продакшене бил по рукам.
Вы бы только руку на продакшене занесли, а любой толковый специалист вам задаст первый вопрос, потом — второй, потом — третий. И вот уже не понятно кто кому по рукам надаёт.
Как бы, Ansible автоматизирует некоторые действия и проверяет состояния. В любом случае, если общение с сервером построено на плэйбуках Ansible, никто вам не даст писать левые скрипты или делать работу вручную. Мне лично приходилось описывать бэкап на Ansible. Требования к нему были особые, и он производил несколько действий с различными сущностями: БД, файлы, индексы поиска. И переходили мы на этот формат — с баша. И баш с задачей не справлялся. Сейчас я уверен в том, что запуск роли Ансибл не создаст непредвиденных ситуаций и пустой бэкап. И если какой-то альтернативно-одарённый миддл полезет ко мне с утверждениями, что Ансибл не подходит для автоматизации бэкапа, я ему не только по рукам, но и по голове настучу.
Есть три вопроса к вашему высказыванию:
1. Где указано, что Ansible — это инструмент деплоймента состояний? Я лично видел определение «инструмент автоматизации».
2. Почему вы считаете, что ваши требования к бэкапам на Ansible реализуются сложнее, чем на bash?
3. Вы серьёзно используете Ansible для описания состояний? Я бы вас за это на продакшене бил по рукам.
Вы бы только руку на продакшене занесли, а любой толковый специалист вам задаст первый вопрос, потом — второй, потом — третий. И вот уже не понятно кто кому по рукам надаёт.
Как бы, Ansible автоматизирует некоторые действия и проверяет состояния. В любом случае, если общение с сервером построено на плэйбуках Ansible, никто вам не даст писать левые скрипты или делать работу вручную. Мне лично приходилось описывать бэкап на Ansible. Требования к нему были особые, и он производил несколько действий с различными сущностями: БД, файлы, индексы поиска. И переходили мы на этот формат — с баша. И баш с задачей не справлялся. Сейчас я уверен в том, что запуск роли Ансибл не создаст непредвиденных ситуаций и пустой бэкап. И если какой-то альтернативно-одарённый миддл полезет ко мне с утверждениями, что Ансибл не подходит для автоматизации бэкапа, я ему не только по рукам, но и по голове настучу.
Лучше расскажите, чем ансибл лучше как инструмент для автоматизации бекапа, чем самописный скрипт на python (это не для меня, а для тех неверующих, которые считают, что все можно корректно написать на баш/python/подставить что угодно)
Вас бы тоже по рукам бил :-D
Что вы, что urtow неверно ставите вопрос. Ансибл прекрасно подходит для автоматизации запуска бэкапа и для восстановления из бэкапа. Но только тогда, когда все методы общения с сервером или запуск всех служебных скриптов на сервере завязаны на Ansible. То есть, я автоматизирую 100500 процессов на сервере через Ансибл. я пишу скрипт бэкапа на нём и я же его укладываю в крон, допустим. Но, если у меня отдельное решение для backup automation, то оно будет написано на другом скрипте, а Ансибл его запустит в связке, допустим, с другими процедурами. Например, мне нужно поставить сайт на сервисное обслуживание: нджинкс вешает service страницу, wsgi отключается, делается бэкап. Мне не всралось писать это отдельными баш-скриптами: я сделаю ансибл-плэйбук и запущу его.
Другой кейс: мне нужно, чтобы сервер регулярно делал бэкап и складывал его в папку. Не факт, что я буду использовать Ансибл. Скорее-всего, это будет отдельный скрипт на баш, python или в рамках какого-то бэкап-фрэймворка. Тут я задамся вопросом: а этот скрипт будет подтягивать некоторые роли Ансибл во время работы? У него будут меняться переменные? У него будет какая-то логика? Эту логику можно описать на Ansible? Или она слишком сложная? После решения этих вопросов, я приму решение о создании системы бэкапов. Но я не буду однозначно утверждать, что ansible чем-то хуже для бэкапа или лучше, чем bash скрипт. Всё зависит от того, насколько этот бэкап интегрируется в мои скрипты автоматизации. Если никак, то ОК, пусть будет на баше! Если он тянет за собой какие-то уже описанные в Ансибл действия, то это однозначно будет роль ansible. Причём, ничто мне не помешает написать, допустим, python скрипт для бэкапа и запускать его через ansible.
Сам вопрос стоит неверно: Ансибл не лучше. Ансибл — это выбранное средство автоматизации! Я пробовал часть функций описывать в Ансибл, а часть в баше — это явный зоопарк. Наиболее оптимальный вариант — обслуживать роли Ансибла, если ты его выбрал своим инструментом. Фактически, я и сам верю, что на баш и python можно всё описать. Но это не нужно делать, если ты выбираешь красивый путь реализации через инструмент.
Что вы, что urtow неверно ставите вопрос. Ансибл прекрасно подходит для автоматизации запуска бэкапа и для восстановления из бэкапа. Но только тогда, когда все методы общения с сервером или запуск всех служебных скриптов на сервере завязаны на Ansible. То есть, я автоматизирую 100500 процессов на сервере через Ансибл. я пишу скрипт бэкапа на нём и я же его укладываю в крон, допустим. Но, если у меня отдельное решение для backup automation, то оно будет написано на другом скрипте, а Ансибл его запустит в связке, допустим, с другими процедурами. Например, мне нужно поставить сайт на сервисное обслуживание: нджинкс вешает service страницу, wsgi отключается, делается бэкап. Мне не всралось писать это отдельными баш-скриптами: я сделаю ансибл-плэйбук и запущу его.
Другой кейс: мне нужно, чтобы сервер регулярно делал бэкап и складывал его в папку. Не факт, что я буду использовать Ансибл. Скорее-всего, это будет отдельный скрипт на баш, python или в рамках какого-то бэкап-фрэймворка. Тут я задамся вопросом: а этот скрипт будет подтягивать некоторые роли Ансибл во время работы? У него будут меняться переменные? У него будет какая-то логика? Эту логику можно описать на Ansible? Или она слишком сложная? После решения этих вопросов, я приму решение о создании системы бэкапов. Но я не буду однозначно утверждать, что ansible чем-то хуже для бэкапа или лучше, чем bash скрипт. Всё зависит от того, насколько этот бэкап интегрируется в мои скрипты автоматизации. Если никак, то ОК, пусть будет на баше! Если он тянет за собой какие-то уже описанные в Ансибл действия, то это однозначно будет роль ansible. Причём, ничто мне не помешает написать, допустим, python скрипт для бэкапа и запускать его через ansible.
Сам вопрос стоит неверно: Ансибл не лучше. Ансибл — это выбранное средство автоматизации! Я пробовал часть функций описывать в Ансибл, а часть в баше — это явный зоопарк. Наиболее оптимальный вариант — обслуживать роли Ансибла, если ты его выбрал своим инструментом. Фактически, я и сам верю, что на баш и python можно всё описать. Но это не нужно делать, если ты выбираешь красивый путь реализации через инструмент.
Есть. Как минимум — habr.com/ru/company/oleg-bunin/blog/431542
Должен добавить, что это пост из песочницы. Пост мной был написан в ~ мае 2017 и на тот момент каких-либо упоминаний molecul'ы на хабре мной обнаружено не было.
В остальном полностью согласен с urtow
при повторном запуске роли не должно произведено каких-либо изменений.
К сожалению, на практике это не всегда возможно в том числе из-за багов самого Ansible. Например, модуль pip почти всегда выдаёт changed, даже если на деле ничего не изменилось. Из-за подобных косяков мне не удаётся добиться полной идемпотентности (если понимать под этим changed=0) своих ролей, как бы я этого ни желал
всегда же можно исправить баг в ансибле
Тогда очень странно, что за год с лишним его так никто не исправил, это же так легко
Значит это никому не мешало, ну не настолько что бы взять и исправить.
По поводу легко — сейчас в ансибле открыто болешь чем 1.5к пулл-реквестов, нужно ещё как-то пробится через эту всю толщь
Опенсурс такой опенсурс. Все пользуются, мирятся с багами, а когда доходит до дела — фиксить некому. Шикарно. Я уж не говорю о том, что наверняка есть фиксы на указанные баги, но тут уже включается бюрократическая машина, которая попросту не может завалидировать 1.5к пулл реквестов. Просто отлично!
Второй момент. В других SCM (puppet, salt, chef) я не видел аналогичных проблем в аналогичных модулях, что показывает ansible 100% не с лучшей стороны.
Второй момент. В других SCM (puppet, salt, chef) я не видел аналогичных проблем в аналогичных модулях, что показывает ansible 100% не с лучшей стороны.
Sign up to leave a comment.
Molecule — тестируем роли Ansible