Puppet, Chef, Ansible, Salt – что попробовать для начала?

Рано или поздно любой развивающийся юниксоид сталкивается с необходимостью освоить Configuration Management and Remote Execution Application. Работа с инфраструктурой используя такие системы – топовый уровень системного подхода для IT операций.

Вот недавно созрел и я.

Сразу же столкнулся с необходимостью выбора между четырьмя самыми популярными системами: Puppet, Chef, Ansible и Salt. Каждая система сама по себе, если изучать её более чем поверхностно, потребует слишком много времени на освоение, поэтому захотелось посмотреть туториалы и видео по каждой из них, и на основании этого уже выбрать одну, которую начинать досконально изучать.

Лично для меня использование такой системы интересно с точки зрения возможности, во-первых, инвентаризации (описания) таких сущностей как:

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

Во-вторых, используя описанные выше данные необходимо автоматизировано управлять:

  • системой мониторинга
    • состояние сервера
    • проверка выполнения резервного копирования
    • мониторинг безопасности
  • установкой типичных окружений
    • утилиты
    • модули статистики
  • резервным копированием

И так далее. Итак:

  • Читаем http://habrahabr.ru/post/211306/ – неплохо для начала.
    • Ключевой тезис статьи: вы можете запросить информацию о конфигурации – такую как версия ядра или детальную информацию о сетевом интерфейсе – напрямую от агентов через командную строку. Агенты могут также задаваться через использование элементов инвентаря, называемых «зернами» (grain). Вообще единственное упоминание инвентаря только в Salt. Лично я не понимаю, как можно качественно управлять чем либо досконально это не проинвентаризировав.
    • Тогда как Puppet и Chef ориентированы на разработчиков, Salt и Ansible больше подходят для нужд системных администраторов. Я, естественно, себя отношу ко вторым.
  • В этой же статье автор ссылается на 4 хороших обзора этих систем от одного автора:
    • Ansible http://www.infoworld.com/article/2612397/data-center/review–ansible-orchestration-is-a-veteran-unix-admin-s-dream.html
      • Ничего нормального про учет не нашел.
    • Chef http://www.infoworld.com/article/2611249/data-center/review–chef-cooks-up-configuration-management.html?nsdr=true&page=3
      • Например, установка NTP: knife cookbook site install ntp
      • А вот это уже интересно: To continue with our example, the NTP Cookbook includes an attributes directory that contains a file named default.rb. This is where we would make changes to the default NTP servers. In this case, that’s as simple as changing the default[‘ntp’][‘servers’] variable by adding our NTP servers: default[‘ntp’][‘servers’] = %w{ 192.168.32.10, 192.168.16.16 }. То есть описан способ описания.
    • Puppet http://www.infoworld.com/d/data-center/review-puppet-enterprise-30-pulls-more-strings-222737.
    • Salt http://www.infoworld.com/article/2612536/data-center/review–salt-keeps-server-automation-simple.html.
      • Salt сразу же подкупает:
        • Работа через SSH или через агента.
        • Есть и push и pull.
        • Работает асинхронно.
      • Grains – собираются автоматом со всех миньонов, и можно выполнять команды на основании фильтра по ним.
      • Так же их можно назначать вручную: Grains can be specified within the minion configuration on each host, either in the main configuration file or in a static file that can be managed via Salt. Это очень удобно – можно задавать переменные описания как на самих хостах, так и на сервере управления.
      • Так же у Salt есть распределенная файловая система-репозиторий, на которую можно ссылаться на миньонах.
      • Сразу же экзампл скрипта на питоне.
      • Further, the peer system allows minions to ask questions of a Salt master that may require data collection from other servers. For instance, a minion may need to populate data in a configuration derived from a database residing on another server. This system allows the minion to query the master to retrieve that data, which is then used for the configuration. Minions can send out flags when they are back in operation after some manual changes, and trigger events such as being added to a list of available database servers or being re-added to a load-balancer configuration.
  • Далее интересная статья http://blog.smartbear.com/devops/a-taste-of-salt-like-puppet-except-it-doesnt-suck/.
    • Salt started life as a remote execution system: a class of software applications written to address concerns of the form, “I have this command I want to run across 1,000 servers. I want the command to run on all of those systems within a five second window. It failed on three of them, and I need to know which three.”
    • Other systems were designed to do this, of course, but they failed in several ways. MCollective (which Puppet Labs acquired several years ago) was (and remains!) fiendishly complex to set up. Chef works atop ssh, which – while the gold standard for cryptographically secure systems management – is computationally expensive to the point where most master servers fall over under the weight of 700-1500 clients. Salt’s approach was far simpler.
    • Salt leverages the ZeroMQ message bus, a lightweight library that serves as a concurrency framework. It establishes persistent TCP connections between the Salt master and the various clients, over which communication takes place. Messages are serialized using msgpack, (a more lightweight serialization protocol than JSON or Protocol Buffers), resulting in severe speed and bandwidth gains over traditional transport layers, resulting in in the ability to fit far more data quickly through a given pipe. This translates into a non-technical statement of, “Salt establishes a persistent data pipe between servers in your environment that’s extremely fast and low-bandwidth.”
  • Вскользь смотрим http://docs.saltstack.com/en/latest/topics/tutorials/walkthrough.html.
  • У Salt даже есть свой мониторинг:
    • Salt-monitor is also in the works as one of the next major milestones. This is intended to serve as a soup-to-nuts monitoring solution that scales well, by replacing serial checks iterating through an environment with broadcast conversations, such as, “All servers: Tell me if you don’t have enough free disk space.”

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

На момент написания этого поста на блог уже попробовал установить мастер сервер и по одному миньону на Linux и Windows. Все красиво, из пакетов, без костылей и глюков. Пока что. Сейчас читаю документацию, и она не маленькая:

Есть предчувствие, что придется выучить Python 🙂 .

Update: в результате с Salt все получилось.

3 thoughts on “Puppet, Chef, Ansible, Salt – что попробовать для начала?

  1. Дня доброго.
    Ну и как вам в конечном счёте salt?
    Тоже сейчас стою перед аналогичным выбором

  2. До продакшина, к сожалению, пока не дошёл. Но все, что пробовал в процессе прохождения туториала – нравилось.
    Выбор системы, думаю, дело вкуса, но с него точно можно начинать.

  3. Pingback: Статьи по Salt и впечатления от использования | Журнал Жетмэна

Оставить комментарий