Инструменты DevOps: Чем хорош SaltStack, и какие задачи с его помощью можно решить


    В нашем блоге на Хабре мы продолжаем рассказывать о построении 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. Мы им не пользовались, если у вас есть советы\предостережения по нему, рады будем увидеть их в комментариях.

    image

    Здесь и далее изображения взяты из официальной документации SALTSTACK COMPONENTS

    Grains — единица информации о системе, например IP-адрес. Местный аналог facts у Ansible и Puppet.

    image

    Стейты (state files) — аналог playbooks в Ansible. В них с помощью state.modules, описывается, к какому состоянию нужно привести миньона.

    image

    Кроме того в SaltStack существует понятие top-файла. Это, по сути, словарь, который помогает удобно группировать миньонов по некоторым атрибутам и указать, какие стейты или роли (если вы пользуетесь ролевой моделью) исполнить. Для каждой среды (dev, test, prod) может быть свой top-файл.

    image

    Также в системе есть хранилище защищенных с точки зрения передачи данных (Pillar) и секретной информации вроде паролей — использование этого механизма предотвращает ошибки, при которых информация о логинах и паролях может быть случайно «залита» не туда. В роли источника информации может выступать любой из модулей. Для каждой среды (dev, test, prod) может быть свой pillar-файл.

    image

    Execution Modules — можно сравнить с Ansible в режиме ad-hoc. Нужны для ручной работы с агентами.

    image

    Часто вниманием обделяют Salt Mine, который, в отличии от «грейнов», может обновляться в произвольный интервал. Инструмент позволяет использовать grains одного миньона в момент исполнения стейта на другом. В статье SaltStack: Создание зависимых или ссылающихся конфигураций сервисов, хорошо описан кейс. У автора (@eugenechepurniy), есть и другие статьи по SaltStack.

    Salt Returners — по-умолчанию результат исполнения на миньонах возвращается к «мастеру». Returner позволяют переопределить этот output. Полный список «ретернеров».

    image

    Еще одна полезная возможность, отсутствующая в других популярных SCM-системах — это Reactor. Этот модуль выступает в качестве «слушателя», который фильтрует тегированные сообщения и инициализирует какие-то действия по этому поводу.

    image

    SaltStack может работать и без агента — по SSH. Недавно на хабре выходила статья с примерами его использования.

    В официальной документации есть прекрасные step-by-step уроки по использованию системы. Рекомендую начать с SaltStack Fundamentals

    Где мы используем SaltStack


    Мы в Positive Technologies решаем с помощью SaltStack следующие задачи:

    • настройка build-агентов;
    • настройка мониторинга;
    • подготовка тестового окружения;
    • управление контейнерами;
    • доставка лицензий (продуктов компании);
    • доставка обновлений (продуктов компании);
    • управление циклом жизни VM.

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

    Выбор SCM подобен выбору редактора. У каждой компании свои потребности.
    Рекомендуем попробовать несколько вариантов и выбрать “свой”, который будет покрывать ваши хотелки.

    P. S. Рассказ о нашем опыте использования SaltStack был представлен в рамках DevOps-митапа, который состоялся недавно в Москве.



    По ссылке представлены презентации 16 докладов, представленных в ходе мероприятия. Все презентации и видео выступлений будут добавлены в таблицу в конце этого топика-анонса.

    Автор: Дмитрий Мирошниченко
    Метки:
    Positive Technologies 169,96
    Компания
    Поделиться публикацией
    Комментарии 23
    • –2
      > у нас в компании есть значительная экспертиза в области Python

      Вы ведь знаете, что экспертиза — это такая процедура, да?
      • +3
        А функционал — это математический термин, в курсе, конечно.
        • 0
          Но исправлять ошибку не будете?
          • 0
            Кстати, а как это сказать по-русски одним словом с сохранением значения? «Опыт» не подходит, expertise это опыт + знания. «Мастерство» как-то слишком пафосно.
            • 0
              Слово «опыт» прекрасно описывает то, что тут имеется в виду.
            • +2
              Это не ошибка, а устоявшееся в индустрии слово, так что нет.
              • –2
                Не устоявшееся. Это некая новомодная фишка у некоторых товарищей. Не надо потакать этому.
        • 0
          Странно, что в тех редких статьях, где упоминается salt, ни разу не видел упоминания reclass, при этом с ним все, что завязано на pillar (наследование) гораздо лучше
          • 0
            Благодарю, почитал про reclass (не слашыл про него). На первый взгляд похоже на hiera.
            А какую проблему он решает?
            • 0
              Как минимум наследование pillar (его нет в saltstack)
              Ну и вообще с его внедрением получилось уменьшить сложность/сократить кол-во костылей (как мне кажется).

              (под контролем ~сотни машин, и куча разных сервисов (т.е. далеко не все однотипные))
          • +1
            Вот мои впечатления от использования salt: https://habrahabr.ru/post/315012/#comment_9905944
            • +1
              Справедливости комментарий.

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

              Во-первых, меня смутило, что в описании «что и почему» в пользу Salt указаны фичи, имеющие прямые аналоги у Ansible.

              Во-вторых, если уж говорить о коммерческих решениях, то утверждение про якобы несуществующего клиента для Ansible оказывается на поверку весьма слабым: клиент очень даже существует и называется Ansible Tower .

              В-третьих, Ansible тоже написан на Python.

              В-четвёртых, совсем не был упомянут Ansible Galaxy — открытый свободный репозиторий ролей для Ansible, где очень часто можно найти необходимую роль, и она будет работать «из коробки», либо с минимальной подгонкой под ваш конкретный проект.

              Ну и в-пятых — документацию к Salt, по ощущениям, действительно писала парочка — Шляпник и Мартовский Заяц, так что она явно проигрывает официальной документации Ansible.

              P.S. Стаж использования Ansible — больше 2-х лет.
              • 0
                «в комплект» к Ansible Galaxy: https://github.com/saltstack-formulas
                • 0
                  Эммм, Ansible Tower — это GUI для Ansible. Причем здесь клиент?
                • 0
                  А почему Вы не рассматривали «Chef»?
                  Помимо того, что он тоже не «на питоне» были еще какие-то аргументы?

                  Мы сейчас задумываемся о внедрении системы управления окружением, но больше смотрим в сторону Chef.
                  Chef кажется довольно продвинутым и гибким решением.
                  • 0
                    Chef — на Ruby: https://github.com/chef/chef
                    • 0
                      Chef — на Ruby: https://github.com/chef/chef

                      Поэтому я и написал:
                      Помимо того, что он тоже не «на питоне» были еще какие-то аргументы?

                      Насчет Puppet хотябы был аргумент:
                      входной порог для старта работы с продуктом был достаточно высоким из-за сложной логики описания сценариев развертывания окружения.

                      а про Chef ничего не сказано.
                  • 0
                    Обращаю ваше внимание на эти слова:

                    Выбор SCM подобен выбору редактора. У каждой компании свои потребности.
                    Рекомендуем попробовать несколько вариантов и выбрать “свой”, который будет покрывать ваши хотелки.


                    В момент выбора решения, прежде всего я руководствуюсь требованиями, но обращаю внимание на восприятие продукта — нравится\не нравится, которое сновано на эмоциях, т.к. дальше с этим работать, развивать и поддерживать.

                    Chef и CFEngine не стал смотреть, причина — язык и вышеупомянутое ощущение — «не того».
                    Выбор был между Ansible и Salt. Остановились на том что устраивало по функционалу и понравилось :)
                    Мне было с Salt'ом проще, т.к. до этого поработал с Ansible.
                    • 0

                      В Ansible действительно не pull- а push-топология. Не клиенты «тянут» конфигурацию с мастера, а мастер «проталкивает» её на клиенты. Но это само по себе не плохо — это просто одна из двух топологий, у которых есть свои достоинства, недостатки и область применения. Что Saltstack может так и так — отлично.


                      Предполагаю, что вам было необходимо или просто более эффективно использовать топологию с мастером и клиентами. Расскажите, для каких именно задач? (Ничуть не сарказм, искренне интересуюсь).


                      [Ansible] Не подошел из-за отсутствия клиента — пробовали его до выхода второй версии

                      Клиент, о котором вы говорите, это ansible-pull?

                      • 0

                        ansible-pull очень простой, по сути это git pull && ansible-playbook local.yml. Насколько я понимаю, у salt minion возможностей гораздо больше.

                        • 0

                          Верно, но я не вижу в ansible ничего более похожего на миньона saltstack. И всё-таки хотелось бы увидеть пример задачи, которая сложно решается через ansible и легко — через saltstack.

                          • 0

                            В тред призываются мастера salt кун-фу, я больше по ansible.

                      • 0

                        Кстати, ссылка на топик-анонс в конце наверняка неправильная, т.к. в том посте такая же ссылка на вот этот топик: https://habrahabr.ru/company/pt/blog/310584/

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

                        Самое читаемое