В нашем блоге на Хабре мы продолжаем рассказывать о построении 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 докладов, представленных в ходе мероприятия. Все презентации и видео выступлений будут добавлены в таблицу в конце этого топика-анонса.
Автор: Дмитрий Мирошниченко
Комментарии (23)
anonymouz
21.12.2016 18:28Странно, что в тех редких статьях, где упоминается salt, ни разу не видел упоминания reclass, при этом с ним все, что завязано на pillar (наследование) гораздо лучше
fishhead
22.12.2016 17:11Благодарю, почитал про reclass (не слашыл про него). На первый взгляд похоже на hiera.
А какую проблему он решает?anonymouz
22.12.2016 20:00Как минимум наследование pillar (его нет в saltstack)
Ну и вообще с его внедрением получилось уменьшить сложность/сократить кол-во костылей (как мне кажется).
(под контролем ~сотни машин, и куча разных сервисов (т.е. далеко не все однотипные))
kt97679
21.12.2016 21:37+1Вот мои впечатления от использования salt: https://habrahabr.ru/post/315012/#comment_9905944
tnt4brain
21.12.2016 22:41+1Справедливости комментарий.
Прочитал статью, удивился некоторой путанице. Я не беру на себя смелость решать, что именно должно использоваться вами, другое дело, что факты поданы, гхм, своеобразно. Вот по порядку:
Во-первых, меня смутило, что в описании «что и почему» в пользу Salt указаны фичи, имеющие прямые аналоги у Ansible.
Во-вторых, если уж говорить о коммерческих решениях, то утверждение про якобы несуществующего клиента для Ansible оказывается на поверку весьма слабым: клиент очень даже существует и называется Ansible Tower .
В-третьих, Ansible тоже написан на Python.
В-четвёртых, совсем не был упомянут Ansible Galaxy — открытый свободный репозиторий ролей для Ansible, где очень часто можно найти необходимую роль, и она будет работать «из коробки», либо с минимальной подгонкой под ваш конкретный проект.
Ну и в-пятых — документацию к Salt, по ощущениям, действительно писала парочка — Шляпник и Мартовский Заяц, так что она явно проигрывает официальной документации Ansible.
P.S. Стаж использования Ansible — больше 2-х лет.
prowwid
22.12.2016 17:12А почему Вы не рассматривали «Chef»?
Помимо того, что он тоже не «на питоне» были еще какие-то аргументы?
Мы сейчас задумываемся о внедрении системы управления окружением, но больше смотрим в сторону Chef.
Chef кажется довольно продвинутым и гибким решением.
bormotov
23.12.2016 13:54Chef — на Ruby: https://github.com/chef/chef
prowwid
23.12.2016 14:41Chef — на Ruby: https://github.com/chef/chef
Поэтому я и написал:
Помимо того, что он тоже не «на питоне» были еще какие-то аргументы?
Насчет Puppet хотябы был аргумент:
входной порог для старта работы с продуктом был достаточно высоким из-за сложной логики описания сценариев развертывания окружения.
а про Chef ничего не сказано.
fishhead
24.12.2016 14:17Обращаю ваше внимание на эти слова:
Выбор SCM подобен выбору редактора. У каждой компании свои потребности.
Рекомендуем попробовать несколько вариантов и выбрать “свой”, который будет покрывать ваши хотелки.
В момент выбора решения, прежде всего я руководствуюсь требованиями, но обращаю внимание на восприятие продукта — нравится\не нравится, которое сновано на эмоциях, т.к. дальше с этим работать, развивать и поддерживать.
Chef и CFEngine не стал смотреть, причина — язык и вышеупомянутое ощущение — «не того».
Выбор был между Ansible и Salt. Остановились на том что устраивало по функционалу и понравилось :)
Мне было с Salt'ом проще, т.к. до этого поработал с Ansible.
nick_volynkin
26.12.2016 18:24В Ansible действительно не pull- а push-топология. Не клиенты «тянут» конфигурацию с мастера, а мастер «проталкивает» её на клиенты. Но это само по себе не плохо — это просто одна из двух топологий, у которых есть свои достоинства, недостатки и область применения. Что Saltstack может так и так — отлично.
Предполагаю, что вам было необходимо или просто более эффективно использовать топологию с мастером и клиентами. Расскажите, для каких именно задач? (Ничуть не сарказм, искренне интересуюсь).
[Ansible] Не подошел из-за отсутствия клиента — пробовали его до выхода второй версии
Клиент, о котором вы говорите, это ansible-pull?
selivanov_pavel
26.12.2016 18:59ansible-pull очень простой, по сути это
git pull && ansible-playbook local.yml. Насколько я понимаю, у salt minion возможностей гораздо больше.nick_volynkin
26.12.2016 22:17Верно, но я не вижу в ansible ничего более похожего на миньона saltstack. И всё-таки хотелось бы увидеть пример задачи, которая сложно решается через ansible и легко — через saltstack.
nick_volynkin
26.12.2016 18:27Кстати, ссылка на топик-анонс в конце наверняка неправильная, т.к. в том посте такая же ссылка на вот этот топик: https://habrahabr.ru/company/pt/blog/310584/
ivanych
> у нас в компании есть значительная экспертиза в области Python
Вы ведь знаете, что экспертиза — это такая процедура, да?
ptsecurity
А функционал — это математический термин, в курсе, конечно.
ivanych
Но исправлять ошибку не будете?
selivanov_pavel
Кстати, а как это сказать по-русски одним словом с сохранением значения? «Опыт» не подходит, expertise это опыт + знания. «Мастерство» как-то слишком пафосно.
ivanych
Слово «опыт» прекрасно описывает то, что тут имеется в виду.
ptsecurity
Это не ошибка, а устоявшееся в индустрии слово, так что нет.
ivanych
Не устоявшееся. Это некая новомодная фишка у некоторых товарищей. Не надо потакать этому.