ansible

Ansible как панацея. Почему это не оптимальный подход, куда сейчас движется Ansible, и как работает Molecule

Тимур Гадиев, Senior Systems Engineer в Epam, 5 лет изучает, работает и консультирует по Ansible. Мы попросили рассказать его о тенденциях использования Ansible и Molecule на сегодняшний день и проблемах, связанных с ними. Также поговорим о том, куда будет развиваться Ansible в ближайшем будущем.

Почему Ansible – это не универсальная пилюля, в каких областях его применение не оптимально и зачем люди пытаются “заново изобрести велосипед”: все эти вопросы разберем в этой статье. Stay tuned!

– Можно ли использовать Ansible как универсальный инструмент для всех случаев?

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

Ansible гибкий инструмент, и позволяет автоматизировать много вещей и процессов. Есть такое понятие в английском – “золотой молоток”. И некоторые люди используют Ansible именно так, пытаются сделать им все: и создание пользователей, и установку системы, и авторизацию настраивать, и даже scheduling.
Это не оптимальный подход, потому что у Ansible есть свои ограничения и недостатки.

– Какие ограничения?

– Нет ограничений по количеству серверов или размеру инфраструктуры. Но при масштабировании могут возникнуть вопросы. Впрочем, это вопросы к архитектуре.

Пример:
Если есть куча спец. инструментов автоматизации и оркестрации в среде, полностью построенной на Kubernetes, и все делается, например, с помощью Gitopts, то Ansible тоже можно использовать для управления Kuber. Но это будет не нативный способ и будет не тот результат, который может ожидаться. Придется внедрять костыли итд.

Вот еще один пример:
Для облаков часто применяются инструменты, для создания облачной инфраструктуры и ресурсов. Есть инструменты, которые базируются непосредственно на интерфейсах этих облаков. Для AWC, например, есть CloudFormation. Для Microsoft Azure – свои фреймворки. Для Terraform – Cloud Agnostic. Все они хорошо подходят именно для развертывания ресурсов, они хорошо парализуют эти задачи, хранят стейты, обеспечивают идемпотентность.

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

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

– Почему и кто использует Ansible в таком виде?

– Есть два типа людей, и они пересекаются:

Новички. Необязательно в разработке, именно в Ansible. Такие приходят в наш чат в телеграм с вопросами, мы помогаем и консультируем их.
Люди, которые используют Ansible эпизодически. Обычно им нужно решить по-быстрому определенную задачу и забыть, особо не вникая. Поэтому складывается ситуация, что такой человек/коллектив будет действовать по одному и тому же шаблону, в то время, когда ситуации и задачи меняются. Вот один из таких шаблонов, если надо запускать модули: “Здесь bush-код запустим, здесь его куда-нибудь сохраним, здесь вот этот модуль возьмем, там отпарсим…”

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

Важное замечание!
Еще раз проговорю: нет такого понятия “нельзя” с Ansible. Если вернуться к примеру про облачную инфраструктуру, то можно реализовать в небольших средах тестовые окружения, IoT-системы идр. В таких случаях у Ansible есть модули управления облаками.
И в небольших кейсах, где несложная инфраструктура и немного ресурсов, Ansible вполне справляется с деплоем облачных ресурсов, управлением, менеджментом, и даже может в каком-то виде стейт организовывать, хранить и мейнтейнить.

Но. Если порог сложности выше, то предпочтительнее использовать спец. инструменты. Просто нужно понять важную мысль: Ansible можно использовать почти везде, но не везде его использование будет оптимальным.

– Как сочетается Ansible с другими инструментами?

– Возьмем классический пример с Terraform. Этот способ применяют для разворачивания образов, инстансов в облаке.

Образы подготавливаются Ansible с помощью Packer и др. средств.
Устанавливается софт, настраиваются все сеттинги и конфиги, и этот образ сохраняется.
Когда развертывается среда, поднимаются сами виртуалки, включаются кластера, автоскейлинг-группы, все это подключается к интерфейсам, стыкуется со всеми клауд-ресурсами. Это делает Terraform. При этом Terraform не тратит время на настройку виртуальных машин, на настройки конфигураций итд.

Кроме того, Terraform может вызвать уже отдельно Ansible Playbook для финальной конфигурации кластера, например, настройки синхронизации, разворачивания базы данных и т.д. То есть, все это может работать в комплексе.

Это лишь один кейс, а все это можно сочетать в разных инфраструктурах, с разными инструментами и в разной степени интеграции. Возможности Ansible огромны, и вариантов множество.

– Почему говорят, что Ansible удобнее и проще, чем другие похожие платформы автоматизации? Правда ли это?

– Абсолютно, да. Он действительно удобнее и проще для решения 90% стандартных задач, в том числе и при внедрении, если ранее ничего подобного не использовалось.

На это есть аргументы:

Безагентность, декларативность, большое количество модулей из коробки.

Следствие этого – низкий порог входа. Это позволяет не очень подготовленному в плане разработки и написания кода быстро освоить Ansible и начать выполнять базовые задачи. Чтобы начать делать что-то более осмысленное на Chef или Puppet, нужно потратить значительно больше времени на освоение, на погружение в объектную модель, в архитектуру инструмента, потратить время на подготовку среды (для chef, например, настраивать сервер и агенты). Это непросто и требует дополнительных усилий для поддержки.

Ansible написан и обслуживается на питоне – одним из самых осваиваемых языков с большим и развитым комьюнити. Поэтому получить помощь в чате, обратиться за консультацией или нанять/обучить специалиста, который будет работать с Ansible, можно дешевле и быстрее, чем на Ruby.

Ansible в простейшем случае может быть просто в виде Playbook, который можно написать на своей машине и запустить на серверах. Требуется только подключение по ssh.

– Если Ansible настолько простой и удобный и требует меньше ресурсов для его использования, зачем использовать тот же Chef?

– Недостатки — это продолжение достоинств. Это относится и к Chef.

Агентная модель тоже имеет свои преимущества.
Мы непосредственно отслеживаем состояние агентов, управляем их системой, можем их мониторить, можем в реальном времени отслеживать их конфигурации и непосредственно управлять с сервера.
Команде может быть выгоднее внедрить и обслуживать инструмент именно на Ruby. Выбор платформы автоматизации или полноценной системы управления в большинстве зависит именно от того, насколько легко и выгодно по бюджету будет это обходиться.

Это вопрос компетенции команды.
Вполне может быть, что в штате у организации есть достаточно людей со знанием Ruby, разработки ведутся в основном на Ruby итд. И если руководство понимает, что дешевле и удобнее обслуживать будет тот инструмент, для которого уже есть специалисты и среда, тогда можно использовать Chef, без проблем.

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

– Ансибл дает чуть большую свободу действий?

– Да, и это несет как преимущества, так и недостатки.

Поговорим про недостатки. Большая свобода действий приводит к тому, что Ansible начинают использовать не по назначению (вспоминаем “золотой молоток” aka панацея). Т.е. там, где есть более эффективные средства, используют Ansible. Или начинают использовать не оптимальные способы: например, не писать свой модуль, а городить последовательность bash-команд.

Вопрос к читателям: какая главная философия Ansible?

Многие люди просто направляют свои усилия не туда. Они не держат в голове, что нужно стремиться к декларативности, обеспечивать идемпотентность, отслеживать состояния итд. Это и есть главная философия!

– Про декларативность и идемпотентность. Почему свобода действий может сыграть злую шутку?

– Ansible был написан для упрощения написания сценариев автоматизации (по сравнению с bash и питон-сприптами и т.д). Мы уже говорили о том, что некоторые люди пытаются упростить, но по сути собирают вундервафлю из всего, что было под рукой. Смотрите чуть ниже.

Простым языком для “простых” людей:
Если нам нужно собрать полностью велосипед с нуля, то Ansible для этого дает заготовки: готовые модели рамы, втулки, колеса, передачи с кассетой и пр. Также приветствуется и создание своего уникального “колеса”. А кто-то из тех 2-х типов людей вместо готового конструктора начинает сам варить раму, спицевать колесо, менять тормозную систему (совершенно не умея этого делать).

Что сейчас дает Ansible: возможности для всех людей, которые не обладают развернутыми и богатыми навыками разработки, быстро делать эффективно работающий код и получать отличный результат.
То же, что дает Ansible можно реализовать на bash? Можно. Но вопрос: за какое время и какими усилиями?

В Ansible уже вложено достаточно много труда разработчиков, написаны модули, написан весь engine, написана вся схема работы плагинов друг с другом, все отлично стыкуется, протестировано и дает предсказуемый результат.

Чтобы то же сделать вручную, понадобиться гораздо больше человеко-часов. Скорее всего — человеко-лет.

– Почему люди все равно используют ручной, медленный и менее эффективный способ, а не взять готовое?

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

– На примерах: где использование Ansible оптимально, а где лучше найти другое решение?

– Эта граница хорошо видна на классическом примере: Ansible как средство централизованной авторизации.

Что позволяет делать Ansible:

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

Но. У Ansible нет средств для того, чтобы это все эффективно хранить, отслеживать, синхронизировать, мониторить итд. Для этого есть спец. инструменты вроде LDAP, active directory и другие. Управление пользователями, хранение информации и синхронизацию осуществлять спец. инструментами, а настройку непосредственно у end user можно делать Ansible. Главное — не подменять инструмент.

Часто люди, у которых нет СЦА, но которые хотят улучшить управление пользователями, пытаются из Ansible сделать такой своеобразный велосипед, постоянно усложняя его, все больше и больше накидывая на него “логики”, чтобы реализовать функционал, который уже давно реализован в спец. средствах. При этом получается хуже, усилий тратится больше.

Поправка:
Ansible можно использовать для настройки авторизации. Но если есть требования к уже развернутому управлению пользователями, которое за пределами нескольких машин и 2-3 простейших пользователей, то это не в его компетенции.

– Molecule. Что с ней сейчас? Какие проблемы она закрывает?

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

Например, мы тестируем участок кода, который ставит одно приложение, но оно требует для себя установленного другого приложения (базу данных, к примеру). Молекула может развернуть тестовую среду, поднять базу данных, настроить ее, и уже после этого разворачивать наше приложение, которое подразумевает использование базы данных. После этого молекула протестирует это приложение: что оно корректно работает с БД, получает нужные результаты, проверит на идемпотентность (при повторной накатке не должно что-то ломаться). Также может проверить на сайд-эффекты (например, мы можем проверить, что у нас не сломались другие приложения, после деплоя нашего приложения) + может дополнительные тесты запустить (не ломаются права, стандартный функционал и др).

И после этого молекула может всю тестовую среду очистить, ресурсы в облаке убить и привести все в первоначальное состояние. Получается полноценное управление тестовой средой, для которой нужен только Ansible.

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

– Какие фреймворки поддерживает Molecule и насколько просто работать с ними?

Действительно просто. Это встроенный функционал. Подключаются нужные участки кода, запускается питоновский скрипт на определенном этапе и все это интегрируется. А в более поздних версиях Молекулы это даже не основные инструменты. Да, они остаются, но основной инструмент — Ansible. Т.е. вместо Testinfra и Goss используется Ansible-код по-умолчанию. То есть, все инфраструктурные тесты реализуются на том же Ansible.

– Финальное: Что сейчас происходит с Ansible?

– Сейчас Ансибл движется в сторону модульности и расширяемости. Начиная с версии 2.9, было принято решение о разделении веток разработки: комьюнити-модули были вынесены в отдельные коллекции, а сам подход с коллекциями стал расширен. И сейчас collection-base подход для модулей и плагинов является основным в Ansible. Т.е. выделяется ветка Ansible-core и встроенные базовые модули. Все остальное выносится в отдельные коллекции, которые непосредственно в Ansible не включаются и имеют свой отдельный релизный цикл.

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

Такой подход неплох, хотя многие олдскулы не признают его и топят за ветку 2.9. Мне в целом нравятся новые версии, они стабильны, я действительно вижу пользу от того, что модульные коллекции эффективно используются и обновляются, можно гибко подключать и добавлять свои собственные коллекции. Это довольно интересный и эффективный подход.

– Что сейчас активно развивается и как ведет себя комьюнити?

– Из последнего, что я вижу, быстро развиваются облачные и сетевые модули. Постоянно совершенствуется документация, добавляется много образцов кода, примеры, наборы обучающих материалов и пр.

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