Comments 31
Отличная статья, большое спасибо! Узнал еще пару интересных нюансов об инструменте
smart gathering ничего не ускоряет, потому что в хороших плейбуках сказано gather_facts: false пока не нужно и правильный subset, если нужно.
Насчёт tranfer_method я прочитал тут первый раз и это пойдёт в мой список для экспериментов. ControlMaster мы не используем, потому что залипающие соединения, к сожалению, портят жизнь, и преизрядно. Любые ребуты или манипуляции с сетью на целевых хостах, и ControlMaster из ускорителя превращается в замедлитель отладки.
Ну просто не смог удержаться от вставки этого видео.
netplan apply.
Плюс, это же автоматизация и CI, если оно в этом месте сломается, значит код сломан, надо фиксить. Если же код не сломан, то операция проходит без особых проблем.
netplan фу-фу-фу. Посмотрел я на это поделие убунтоводов и выпилил от греха подальше
При работе с дистрибутивом глупо бороться с дистрибутивом. Либо меняйте дистрибутив, либо используйте, что дали.
Для базовых задач настройки сети его хватает, если нужно странного, то нужны альтернативные методы. Это совершенно не отменяет романтику с перезапуском сети с новыми настройками (топик-то по ControlMaster у ssh для ansible).
ЗЫ Я обычно для странных сетевых штук использую systemd-юниты. Очень, очень удобно в контексте зависимостей и порядка исполнения.
При работе с дистрибутивом глупо бороться с дистрибутивом
почему бороться? Во-первых, нетплан — это хоть и навязываемый, но не единственный метод настройки сети. Во-вторых, убунту прекрасно работает с другими способами, которых достаточно много — и с systemd-networkd, и c NetworkManager, и с ifup.
Я обычно для странных сетевых штук использую systemd-юниты. Очень, очень удобно в контексте зависимостей и порядка исполнения.
несомненно верно, что systemd прекрасен, учитывая, что с ним реально можно творить много интересных штук. Да и контейнеризацию в него завезли.
Немного попиарю незнакомого чувака из интернета, вот вполне хорошая и работающая роль ansible-netplan
IMHO: для серверной/облачной 20.04 вполне жизнеспособен один самостоятельный netplan, для десктопа уж лучше network-manager с плагинами и «огромным гуищем»
Проблемы с ним автор, кмк _сильно_ преувеличил, за несколько лет моей эксплуатации ничего особо серьезного с ним не было, а ускорение он дает в разы.
Оно на крае сознания плавало, но когда я его смотрел он был слишком молодым. Посмотреть пристальнее, наверное, стоит. Записал в нашу research queue.
за несколько лет моей эксплуатации ничего особо серьезного с ним не было, а ускорение он дает в разы.очень сильно зависит от задач. Например, если у вас 90% занимает скачивание и восстановление дампа БД, то митоген ничем не поможет
То есть чем сложнее _конфигурация_ — тем лучше она им оптимизируется.
Дампы сливать/вливать, имхо, не самый типичный сценарий для ансибла.
Дампы сливать/вливать, имхо, не самый типичный сценарий для ансибла.
а какой тогда типичный? Если мы говорим про классическое использование ансибла в терраформ и пакере для подготовки машин к работе, то там даже ssh не нужен, не говоря уже о митогене :-/
Для локальной работы из tf/packer механики из статьи тоже неприменимы так то.
Ansible, cluster… Выглядит своеобразно. Объясню почему — потому что мои коллеги, которые разворачивали ту же Кафку ансиблом, не носили написать нормальные плейбуки с последовательным рестартом нод кластера, чтобы обеспечить непрерывность работы сервиса. Но вот deploy A/B уже мы на ансибл писали, без downtime… И по факту это получается не просто один плейбук на все, а коллекция плейбуков под каждую конкретную задачу.
Я уж не говорю о том, что приходит кубернетес и берет эти проблемы на себя.
Мой типичный кластер это консул/постгрес/редис/номад/зукипер/кликхауз/прометей с графаной/опять же кафка, всякая более мелкая обвязка вокруг.
Тот же кубик ведь тоже забутстрапить чем-то надо, и ускорить kubespray — милейшее дело.
Тот же кубик ведь тоже забутстрапить чем-то надо, и ускорить kubespray — милейшее дело.
зачем kubespray? не нужен он ) кластер сетапит себя сам — rke up или terraform, или решения вроде https://github.com/kvaps/kubefarm
В целом те техники про которые собсно статья написана, все равно ни с локальными конфигами, ни с заливкой дампов не помогут.
А там где будут эффективны эти настройки, будет эффективен и митоген.
То, кстати, и описанные в статье методы тоже не помогут.
Пока плейбуки простые — всё будет работать. Я так и написал. Это, кстати, тоже по результатам чтения исходников
Mitogen: одно перекрытие штатных загрузчиков чего стоит.
Точнее на каком уровне начинается сложность, на которой все должно сломаться?
Мне кажется у меня далеко не простые плейбуки, куча ролей как своих так и из гелекси.
Есть свои плагины для переменных и сторонный vault плагин.
Все работает без проблем.
А что митоген поддерживает ансибл2.9 ?? И питон 3.8 ???
Митоген на каких-то тестах реально показывает ускорение в 6+ раз быстрее…
Но иногда валится в самый не подходящий момент… и приходится разбираться " кто виноват и что делать "… проект идея супер… но пока сыроват.
да
> питон 3.8 ???
да
Валится чрезвычайно редко, единственный кейс который у меня возникал — смесь машин с 2 и 3 питоном в инвентаре, не работает автоопределение версии питона. Но все работает, если обозначить ansible_python_interpreter в явном виде.
Адовая экономия времени провижнинга которую он (мне лично) дает, вполне стоит затраченных на дебаг пары часов в год.
Взял толстючую job'у на 50 минут (80% — анисбл, остальное тесты через testinfra и инфраструктурное). Было 51 minutes and 27 seconds, поменял transfer_method = piped стало 51 minutes and 56 seconds. В пределах погрешности — не поменялось.
Было бы интересно увидеть сравнения времени выполнения одного и того же плейбука на разных версиях python, например, 2.7 и 3.8. Будет ли хоть какая то заметная разница?
UPD. Исправил пару очепяток. @ajijiadduh, благодарю!
Ускоряем Ansible