В нашем блоге на Хабре мы продолжаем рассказывать о построении DevOps-культуры в компании — ранее мы описывали созданную нами систему Continuous Integration, а также механизм публикации и лицензирования софта. Сегодня же речь пойдет о выборе системы управления окружением, а также доставкой и развертыванием софта на серверах.
В чем проблема
Для лучшего понимания используемой нами иерархии, можно представить ее как микс type3 и type5 по этой классификации. У нас своя разработка, свои сервисы, мы предоставляем их другим, командам, а «железную» часть нам поставляют OPS.
Исторически в нашей компании подход к автоматизации процессов носил несколько хаотичный характер. При возникновении потребности автоматизировать то или иное типовое действие на свет часто рождались костыли, то есть мы писали множество собственных скриптов для выполнения действий вроде клонирования виртуальных машин и установки на них софта.
Так не могло продолжаться вечно — с ростом компании и количества ее продуктов мы встали перед необходимостью создания более надежного решения по автоматизации типовых действий и подготовки окружения к работе используемых сервисов.
Стало ясно, что нам понадобится специализированная платформа автоматизации, с помощью которой можно будет решить поставленные задачи. Мы выбирали из трех вариантов — Puppet, Ansible и SaltStack.
Что и почему мы выбрали
В итоге предпочтения распределились следующим образом:
- Puppet, несмотря на всю свою популярность, у нас «не пошел» — главная причина в использовании Ruby, тогда как мы в компании предпочитаем Python. Кроме того, входной порог для старта работы с продуктом был достаточно высоким из-за сложной логики описания сценариев развертывания окружения.
- Ansible был не таким монструозным, как Puppet, с ним было гораздо легче разобраться. Не подошел из-за отсутствия клиента — пробовали его до выхода второй версии).
- SaltStack — стал самым удобным для нас вариантом. Возможность выбирать между режимами работы (master-minion, masterless, ssh), возможность хранения истории произведенных операций в удобном формате. И благодаря тому, что у нас в компании есть значительная экспертиза в области Python, мы можем быстро писать свои собственные модули, это значительно расширяет возможности системы.
Рассмотрим архитектуру системы. В терминологии SaltStack сервер системы называется мастером (master), а клиент — миньоном (minion).
В качестве транспортного протокола система использует технологию постоянного шифруемого соединения ZeroMQ — при исполнении большого количества сценариев это дает ощутимый прирост в скорости. В стадии разработки находится альтернативный транспорт RAET. Мы им не пользовались, если у вас есть советыпредостережения по нему, рады будем увидеть их в комментариях.
Здесь и далее изображения взяты из официальной документации SALTSTACK COMPONENTS
Grains — единица информации о системе, например IP-адрес. Местный аналог facts у Ansible и Puppet.
Стейты (state files) — аналог playbooks в Ansible. В них с помощью state.modules, описывается, к какому состоянию нужно привести миньона.
Кроме того в SaltStack существует понятие top-файла. Это, по сути, словарь, который помогает удобно группировать миньонов по некоторым атрибутам и указать, какие стейты или роли (если вы пользуетесь ролевой моделью) исполнить. Для каждой среды (dev, test, prod) может быть свой top-файл.
Также в системе есть хранилище защищенных с точки зрения передачи данных (Pillar) и секретной информации вроде паролей — использование этого механизма предотвращает ошибки, при которых информация о логинах и паролях может быть случайно «залита» не туда. В роли источника информации может выступать любой из модулей. Для каждой среды (dev, test, prod) может быть свой pillar-файл.
Execution Modules — можно сравнить с Ansible в режиме ad-hoc. Нужны для ручной работы с агентами.
Часто вниманием обделяют Salt Mine, который, в отличии от «грейнов», может обновляться в произвольный интервал. Инструмент позволяет использовать grains одного миньона в момент исполнения стейта на другом. В статье SaltStack: Создание зависимых или ссылающихся конфигураций сервисов, хорошо описан кейс. У автора (@eugenechepurniy), есть и другие статьи по SaltStack.
Salt Returners — по-умолчанию результат исполнения на миньонах возвращается к «мастеру». Returner позволяют переопределить этот output. Полный список «ретернеров».
Еще одна полезная возможность, отсутствующая в других популярных SCM-системах — это Reactor. Этот модуль выступает в качестве «слушателя», который фильтрует тегированные сообщения и инициализирует какие-то действия по этому поводу.
SaltStack может работать и без агента — по SSH. Недавно на хабре выходила статья с примерами его использования.
В официальной документации есть прекрасные step-by-step уроки по использованию системы. Рекомендую начать с SaltStack Fundamentals
Где мы используем SaltStack
Мы в Positive Technologies решаем с помощью SaltStack следующие задачи:
- настройка build-агентов;
- настройка мониторинга;
- подготовка тестового окружения;
- управление контейнерами;
- доставка лицензий (продуктов компании);
- доставка обновлений (продуктов компании);
- управление циклом жизни VM.
Конечно, есть у SaltStack и некоторые минусы. Например, очень тяжелая документация, в которой трудно сходу разобраться, а также любовь разработчиков к созданию совершенно новых терминов-аналогов для привычных в других системах вещей (те же миньоны вместо клиентов).
Выбор SCM подобен выбору редактора. У каждой компании свои потребности.
Рекомендуем попробовать несколько вариантов и выбрать “свой”, который будет покрывать ваши хотелки.
P. S. Рассказ о нашем опыте использования SaltStack был представлен в рамках DevOps-митапа, который состоялся недавно в Москве.
По ссылке представлены презентации 16 докладов, представленных в ходе мероприятия. Все презентации и видео выступлений будут добавлены в таблицу в конце этого топика-анонса.
Автор: Дмитрий Мирошниченко
Автор: Positive Technologies
