Дисклеймер

За последний месяц я слушал интервью с разработчиками на всех трех продуктах и слышал утверждение «считайте [Ansible / Salt / StackStorm] клеем». А теперь я, как самоделкин-любитель, с удовольствием скажу, что у меня в гараже отнюдь не единственный горшок с клеем. У меня 6 разных типов клея для разного применения, различных склеиваемых материалов и условий среды. Все эти 3 продукта находятся в одном и том же лагере, и каждый может быть с успехом использован для достижения совершенно разных целей. Недавно произошел большой перехлест функционала, состоящий в том, что все они проникают в область сетевой автоматизации. Мнения, приведенные ниже, принадлежат мне, а не моему работодателю (который продает продуктов сетевой инфраструктуры и развертывания на миллиарды долларов).

Я пользовался всеми тремя продуктами, в развитие двух из них (Salt и StackStorm) внес значительный вклад и частично способствовал развитию Ansible. Говоря откровенно, продукт, с которым я менее всего знаком, — это Ansible, но я беседовал с коллегами и собирал информацию, чтобы заполнить пробелы.

---

Если вы собираетесь пролистать текст до конца и узнать, какой продукт я объявил победителем, вы будете разочарованы. Обдумайте свои требования и попробуйте более одного продукта.

---

Использовать под присмотром взрослых

Задайте себе несколько вопросов:

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

С агентом или без агента?

Уделите этому внимание, это действительно важно. В этой статье я собираюсь сосредоточиться на вопросах автоматизации устройств и их оркестрации. Этими устройствами могут быть маршрутизаторы, коммутаторы, межсетевые экраны, излучающие электромагнитные волны следующего поколения циркулятроны — не имеет значения. Что действительно важно — в их операционной системе не будет установлен агент. У Ansible было совместимое решение — использование SSH в качестве транспорта, поэтому он хорошо вписывается в мир конфигураций конечных устройств, для которых SSH является наименьшим общим знаменателем. SaltStack создавался как шина для высокоскоростного и безопасного миньона (агента), управляющего коммуникацией, но он также имеет режим использования без агента. StackStorm вышел на игровое поле последним и по своей архитектуре не отдает предпочтения какой-либо из работ. Он поддерживает инструменты на основе агентов посредством пакетов для Chef, Puppet, Salt, а также собственные SSH-средства дистанционного управления и встроенную поддержку для вызова сборников сценариев — плейбуков Ansible.

API

Другое ключевое отличие — API:

• Ansible предоставляет интерфейс CLI, Ansible Tower (корпоративная версия) имеет API;
• StackStorm имеет CLI, но также имеет REST API для всех компонентов и сервисов в бесплатной версии;
• у Salt есть как CLI, так и REST API (по умолчанию он не включен), также возможно использование «Enterprise API» в составе продукта Enterprise, который включает в себя такие функции, как RBAC.

Ansible

Ansible — детище Майкла ДеХаана. Продукт был разработан для автоматизации однообразных задач администрирования серверов в крупных средах. Майкл был в новообразованной технологической группе RedHat, где основал разные проекты (такие как Cobbler), а после ухода из RedHat основал Ansible (хотя теперь Ansible и принадлежит RedHat). Выдержка из блога Майкла, посвященного основам Ansible, объясняющая цель проекта:

«Мы хотели создать еще один очень демократичный проект для решения новых проблем с открытым исходным кодом в Red Hat, в который мог быть вовлечен широкий круг разработчиков. Мы вспомнили о busrpc. Этот проект существовал для заполнения пробелов между Cobbler и Puppet. Cobbler может подготовить систему, а Puppet может сложить файлы конфигурации. Но, поскольку Puppet слишком описательный, его невозможно использовать для выполнения таких операций, как перезагрузка серверов или выполнение в промежуточное время всех задач «по требованию».

Эти задачи «по требованию» эволюционировали в плейбуки Ansible, а затем появилась и начала свое развитие экосистема модулей Ansible.

Дизайн

Ansible прост, что является его главным качеством (это сразу станет ясным, если посмотреть на другие 2 качества). В нем нет ни демонов, ни баз данных, а требования для установки минимальны. Ansible просто устанавливается на Linux-машине и всё. Можно определить целевые серверы в статическом файле, сгруппировать их в содержательные разделы или использовать некий динамический модуль обнаружения хостов (такой как Amazon EC2 или OpenStack) для поиска виртуальных машин на основе вызова API. После того как была проведена инвентаризация, можно выделить специфичные для хоста или группы переменные для использования в плейбуках. Они, опять же, хранятся в статических текстовых файлах.

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

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

Ansible работает по следующему алгоритму: подключение к серверу по SSH (или WS-Man/WinRM для Windows), копирование кода на языке Python, исполнение и удаление самого себя.

Архитектура

Архитектура Ansible прямолинейна: существует приложение, выполняющееся на локальном компьютере, и выполняемые на удаленном хосте задачи, которые поддерживают между собой связь по SSH и через файлы, передаваемые по SCP/SFTP. У Ansible нет архитектуры «сервер-клиент», в отличие от двух других продуктов, поэтому распараллеливание задач происходит на локальной машине, но не масштабируется на несколько серверов (если не использовать Tower).

Ansible при управлении удаленными машинами не оставляет на них своего кода, поэтому вопрос, как обновить Ansible при переходе на новую версию, в действительности не стоит.

Расширяемость

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

#!/usr/bin/python
import datetime
import json
date = str(datetime.datetime.now())
print json.dumps({
    "time" : date
})

ansible/hacking/test-module -m ./timetest.py

Вы должны увидеть примерно следующий результат:

{"time": "2012-03-14 22:13:48.539183"}

В модулях можно определить свой код для формирования «фактов» об удаленном хосте на стадии «сбора», которые могут быть использованы собственными или сторонними модулями. Это может быть реализовано в виде просмотра как установленных файлов, так и конфигурации для определения способа настройки сервиса.

Корпоративная поддержка

Ansible Tower — это корпоративная версия (Enterprise), которая превращает командную строку Ansible в сервис с веб-интерфейсом, планировщиком и системой уведомлений.

Планировщик задач

Он также имеет пользовательский интерфейс для плейбуков, посредством которого можно автоматизировать развертывание облачной инфраструктуры, а затем автоматически добавить виртуальные машины в перечень.
Стоит отметить, что планировщик задач, облачные развертывания и сервер — это функции бесплатных версий как Salt, так и StackStorm.

Поддержка сетей

Раздел о поддержке сетей в Ansible — наиболее полный среди всех трех продуктов и охватывает всех основных вендоров сетевого оборудования и платформы. В Ansible возможно:

• Автоматизировать настройку всего, что связано с сетевым оборудованием, — от указания систем для подключения до конфигурации основных сервисов, и всё это с помощью модулей и плейбуков для конкретной сетевой платформы.
• Тестировать и проверять текущее состояние сети, выполнять или откладывать процесс сбора фактов о существующей конфигурации.
• Непрерывно проверять соответствие изменений сетевым настройкам.

Ansible поддерживает Arista, Cisco (все программируемые платформы), F5, Juniper и других производителей. Только в Ansible поддержка в основном предоставляется и осуществляется вендорами, а не сообществом. На данный момент это лучшие интерфейсы API, наибольшая функциональность и работа с самыми последними платформами (поскольку поддерживаются более новые версии).

Сильные стороны

• Очень быстро и просто начать работу.
• Множество примеров, документации и модулей от сообщества.
• Ansible Tower реализует функции для крупных корпоративных внедрений.
• Сетевые модули, поддерживаемые вендорами.

Слабые стороны

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

StackStorm

Я пользовался StackStorm начиная с версии v0.11 (ранняя предварительная бета-версия) вплоть до последней версии v2.2. Это сложная платформа широкого применения, как и Salt. Хотя рассказ о ней требует времени, но все же часто у слушателя создается неправильное впечатление о системе. Я вижу в этом и силу, и слабость. Слабость, потому что сложность системы может заставить отказаться от развертывания совсем или использовать более простое, но неправильное решение там, где StackStorm была бы хорошей альтернативой (часто в таких случаях даже пишется собственное решение «с нуля»). Сила в том, что, как только станет понятно, как использовать сильные стороны, система становится действительно гибкой.

Интерфейс StackStorm

Дизайн

Ядром StackStorm является исполняемый движок с подключаемыми правилами, спроектированный как глубоко настраиваемая служба IFTTT (if-this-then-that, «если это, тогда то»). Можно настроить StackStorm реагировать на произошедшие события запуском простого «действия» (команды) или сложного рабочего процесса. Рабочие процессы доступны в двух вариантах: в виде ActionChain — цепочки действий (проприетарный рабочий процесс DSL) или в виде рабочего процесса на OpenStack Mistral, движок которого основан на YAML.

StackStorm также включает службу для «chatops», с помощью которой можно инициировать рабочие процессы из событий или сообщений платформы чата (например, Slack).

Перечень основных составляющих StackStorm:

• Сенсоры — плагины Python для входящей или исходящей интеграции, получающие или наблюдающие события. Когда произошедшее во внешней системе событие обрабатывается датчиком, сработает триггер StackStorm.
• Триггеры — представления внешних событий в StackStorm. Существуют триггеры общие (например, таймеры и вэбхуки) и триггеры интеграции (например, тревога в Sensu или обновление задачи в JIRA). Новый тип триггера можно определить, написав плагин сенсора.
• Действия — это исходящая интеграция StackStorm. Существуют общие действия (ssh, вызов REST), интеграции (OpenStack, Docker, Puppet) или настраиваемые действия. Действиями являются либо плагины Python, либо прочие сценарии, интегрируемые в StackStorm путем добавления нескольких строк метаданных. Действия могут быть вызваны непосредственно пользователем через CLI или API или использоваться и вызываться как часть правил и рабочих процессов.
• Правила привязывают триггеры к действиям (или к рабочим процессам), применяя критерии соответствия и привязывая полученную из триггера информацию на вход действий.
• Рабочие процессы объединяют действия в «uber-действия», определяя порядок, условия перехода и передачу данных между ними. Большинство решений автоматизации содержат более одного шага и, следовательно, требуют наличия более одного действия. Рабочие процессы, как и «атомарные» действия, доступны в библиотеке действий, могут вызываться вручную или запускаться по правилам.
• Пакеты — это единицы размещения контента для развертывания. Они упрощают управление и совместное использование подключаемого в StackStorm содержимого путем группирования инструментов интеграции (триггеров и действий) и автоматизации (правил и рабочих процессов). Растущее количество пакетов доступно в сообществе StackStorm. Пользователь может создавать свои пакеты, выкладывать их на Github или отправлять в StackStorm Exchange.
• Журнал аудита с полной информацией о запуске контекста и результатах выполнения действий, запущенных вручную или автоматически.

Дизайн

StackStorm состоит из ряда сервисов, использующих очередь сообщений (rabbit) и хранилище данных (mongo) для сохранения своего состояния и обмена данными между собой. StackStorm также имеет web-интерфейс (да, даже в бесплатной версии!), который позволяет настраивать правила, выполнять действия «по требованию» и проверять журнал аудита.

Архитектура

В отличие от Ansible и Salt, StackStorm не был предназначен для настройки рабочих станций или коммуникаций. StackStorm включает пакеты для Salt, Chef, Puppet и Ansible, поэтому при необходимости использования Chef для системы управления агентами и конфигурациями воспользуйтесь StackStorm для вызова сервисов на базе API, таких как Sensu или Kubernetes. Это является легко достижимым и очевидным решением. В Salt все еще существует концепция выполнения на конечной машине или на мастере (на выбор). Если требуется вызвать API Kubernetes, то вопрос о том, какой компьютер вызвал API, становится спорным. То же самое касается конфигурации сетевых устройств.

MongoDB можно масштабировать, используя хорошо документированные шаблоны, то же касается и RabbitMQ. Сами службы разрабатывались с API HTTP/RESTful и могут использовать балансировку нагрузки для масштабирования. Роли могут быть развернуты на одном сервере или распределены по нескольким серверам в зависимости от потребностей.

Мне действительно нравится расширяемость StackStorm, это определенно ключевое преимущество над другими двумя продуктами. Точки расширения StackStorm называются пакетами. Они являются автономными, могут храниться в Git и управляют своими зависимостями через виртуальные среды уровня пакета на языке Python. При установке пакета указывается URL-адрес Git или URL-адрес HTTP, (необязательные) учетные данные, а StackStorm уже загружает, настраивает и устанавливает пакет.

Если бы StackStorm был языком программирования, он был бы сильно типизирован. Для действий указываются типы всех входных данных, для триггеров указываются поля и типы. Это позволяет легко предугадать, что будет возвращено сторонним расширением, и является уникальной особенностью StackStorm.

В отличие от Salt и Ansible, StackStorm не содержит никаких расширений при поставке, все они должны устанавливаться индивидуально. Это облегчает развертывание и упрощает зависимости.
При разработке механизма интеграции для StackStorm можно создавать сенсоры, действия и рабочие процессы в одном определении. Модули Salt и Ansible являются автономными. Таким образом, если расширение (например, Salt) включает Beacons, «Модули исполнения» и «Модули состояния», то у них нет ничего общего, за исключением названия и автора. Это может создать проблемы при управлении зависимостями pip.

Решение этой проблемы в StackStorm заключается в том, что каждый пакет имеет как свой файл requirements.txt, так и файл YAML, описывающий назначение, требования и версию пакета. Можно обновить пакет линейно и при этом сохранить существующую конфигурацию. Пакеты также содержат шаблонную конфигурацию, в отличие от Ansible и Salt, в которых формат конфигурации модулей хранится только в документации, делая их более подверженными ошибкам пользователя. Кроме того, часто приходится просматривать код модуля, если разработчик не удосужился задокументировать параметры конфигурации должным образом.

Еще одной уникальной особенностью является то, что «ChatOps-псевдонимы» (команды чата) встроены в пакеты. Поэтому при установке, например, пакета NAPALM установятся также все команды чата для NAPALM.

Корпоративная поддержка

StackStorm — это продукт с открытым исходным кодом по лицензии Apache-2, размещенный на GitHub. StackStorm принадлежит компании Brocade (которая недавно распродала часть активов, и часть StackStorm теперь принадлежит Extreme Networks).

При лицензировании StackStorm покупается продукт под названием «Brocade Workflow Composer», и владелец лицензии получает дополнительный функционал, а также Enterprise-level-поддержку. Развернутая в производственной среде система, с которой я работал, была лицензирована, и их группа поддержки оставила у меня впечатление отзывчивой и знающей. Вы также получаете RBAC, в котором можете указать для каждого уровня действий, у кого и к каким действиям есть доступ.

Brocade Workflow Composer

Поддержка сетей

Вам повезло, если вы используете Brocade VLX или SDX, так как они хорошо поддерживаются, чего и следовало ожидать.

В апреле 2017 года они объединили поддержку библиотеки NAPALM и кроссплатформенного пакета абстракции Python для Cisco, Juniper, Arista и других вендоров. Теперь можно использовать функционал NAPALM в части маршрутизации, интерфейсов, пиринга BGP и некоторых других отличных возможностей. Мэтт Освальт (соавтор книги O'Reilly по сетевой автоматизации) написал хороший блог о прогрессе в этом направлении.

Демонстрация NAPALM для StackStorm

Сильные стороны

• Бесплатный web-интерфейс по умолчанию прост в использовании и не требует глубоких знаний Python или DevOps.
• Интеграция ChatOps встроена, работает «из коробки» (с помощью Slack, просто развертывается ключ API) и поддерживает многие другие чат-платформы.
• OpenStack Mistral действительно мощный, и, если его освоить, станет возможным сразу охватывать несколько инструментов DevOps, легко создавать ветви и циклы.
• Brocade Workflow Composer — отличный способ заставить «не-разработчиков» использовать систему.

Слабые стороны

• Не имеет такого количества доступных пакетов расширения, как Salt и Ansible. Вначале проверьте, доступны ли пакеты для ваших систем и API и какие функции входят в них входят.
• Система OpenStack Mistral все еще довольно плохо документирована, в синтаксисе запросов YAQL существует множество проб и ошибок.

Salt

Прежде всего Salt — это продукт, SaltStack — это компания. Поэтому, когда я говорю о Salt, я говорю о Salt Open — версии с открытым исходным кодом.

Salt имеет массивный перечень составляющих, поначалу (и когда я говорю «поначалу», я имею в виду «первый год»), это может быть действительно потрясающим. Salt выполняет множество функций, поэтому, как правило, сравнивая Salt с Ansible, Salt-фанаты говорят «да, но он делает намноооооого больше». Как и в случае со StackStorm, это работает и за, и против Salt. Если бы я просто сказал вам принести grains (кристаллы) из шахты, вы бы подумали, что я имею в виду роман Толкиена, но как только вы узнаете, что такое Salt mine (соляная шахта) в терминологии Salt, все станет очевидным.

Дизайн

Salt родилась как распределенная система для удаленного исполнения команд и данных запросов на удаленных узлах или «миньонах». Удаленное исполнение возможно либо на отдельных узлах, либо на группах по произвольным критериям выбора — «таргетинг».

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

• Мастер — сервер, который запускает основные службы для общения с миньонами Salt. Он также содержит хранилище ключей для шифрования между ним и миньонами.
• Миньоны — агенты, которые используют микро-версию Salt для локального исполнения и связи с мастером.

• Движки — они же Salt Engines (солевые двигатели) — это внешние процессы, исполняемые в течение продолжительного времени, которые работают с Salt.

• Состояния или формулы — файлы, содержащие YAML и шаблонные данные для настройки миньонов. Механизм шаблонов также очень гибок. Он не ограничивается поддержкой Jinja, но также поддерживает и chetah, genshi, mako (очень важно для тех, кто имеет опыт с Puppet), wempy или даже чистый Python.

Миньоны (прокси или обычные) могут быть адресованы с использованием grains (крупинки, кристаллы), pillars (столбов, колонн) или идентификаторов. Существуют и другие плагины для таргетинга, а также возможность создавать собственные, основанные на чем-то вроде SQL-запроса или KVP-хранилища.

• Grains — Salt содержит интерфейс для получения информации о нижерасположенной системе. Он называется интерфейс «крупинок», потому что представляет собой «соль», состоящую из «крупинок» информации. Grains собираются для операционной системы, имени домена, IP-адреса, ядра, типа ОС, памяти и многих других свойств системы. Интерфейс grains доступен для модулей и компонентов Salt, так что нужные команды миньонов автоматически становятся доступными в соответствующих системах.

• Pillars — это интерфейс Salt, предназначенный для обеспечения глобальных значений, распределяемых среди миньонов. Pillar — это ресурс свободной формы данных, который может быть JSON, YAML либо другим требующимся и может храниться в файлах или внешне. Это уникальное свойство Salt, позволяющее интегрировать его с другими системами, в которых общее хранилище данных было бы полезно (например, ITSM или реестр ресурсов).

Для извлечения данных можно также использовать данные от миньонов и хранить их в Salt mine (соляной шахте). В дальнейшем эти данные можно использовать в других задачах, таких как конфигурация состояний на основе шаблонов. В отличие от Ansible (который поддерживает только YAML), это может быть реализовано в разных форматах.

Архитектура

Архитектура Salt основана на принципе ступицы колеса и спицы (веерная структура). В некоторых очень больших развертываниях используется несколько мастеров, но это случается довольно редко. Мастера можно легко масштабировать до многих тысяч узлов отчасти из-за облегченной шины сообщений ZeroMQ. Другие модели развертывания:

1. Установка без мастера.
2. Иерархические мастера, связанные между собой с помощью синдика.

Мастер содержит файлы состояния, которые обычно помещаются в общий том хранения. Они настроены в виде дерева для возможности использования таргетинга, чтобы определять группы серверов для настройки и сред/приложений для развертывания.

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

Thorium (торий) — комплексный реактор для Salt, был включен в прошлый релиз в качестве эксперимента и, может быть, будет поддерживаться в будущих выпусках. Thorium добавляет поддержку более сложных правил и сбора событий.

Расширяемость

Все в Salt является расширяемым, вплоть до модулей, отображающих результаты выполнения в CLI. Это большой плюс Salt, так как можно легко внедрять собственные изменения без необходимости поддерживать параллельный fork в главном проекте. Каждая функция в Salt также является подключаемой.

Наиболее распространенными сценариями для расширения могут быть разработка модуля состояния (для описания того, как должна быть сконфигурирована часть программного обеспечения или службы) или модуля исполнения (код для взаимодействия с API или системой). Оба типа модулей могут быть написаны по относительно небольшому шаблону, оба хорошо задокументированы и могут быть проверены с помощью неплохой встроенной тестовой среды. Выполнить узловую проверку модулей можно c помощью PyTest, даже не находясь на мастере или совсем без работающего мастера. Для тестирования интеграций требуется система Linux, хотя с небольшими навыками хакера модули можно запустить и на OSX (о Windows не может идти и речи, как и в случае StackStorm с Ansible).

Возможно либо поддерживать свой автономный пакет, либо вносить непосредственный вклад в проект Salt на GitHub. Самым большим недостатком при внесении кода в основной проект является то, что пользователям для легкой установки ваших модулей может потребоваться подождать целый цикл обновлений. Это занимает примерно 3-5 месяцев при их текущем темпе работы, поэтому, хотя система Salt и «поставляется с батарейками», она имеет недостатки.

У Salt также есть менеджер пакетов, SPM, который в основном нацелен на группировку формул управления конфигурацией (state files). Его можно использовать для упаковки модулей, чтобы обойти медленный цикл релизов, о котором я упомяну в слабых сторонах (хотя это и не очень хорошо задокументировано).

Salt развивается очень быстро в течение последних нескольких лет и претерпела некоторые большие изменения. Из-за этого может наблюдаться несовместимость между разработанными сообществом модулями. Я также считаю (хотя это и не уникально для Salt), что модули, представленные сообществом, плохо тестируются.

Корпоративная поддержка

«Salt Open» — это версия системы с открытым исходным кодом, но можно лицензировать и "Salt Enterprise", которая поставляется с некоторыми приятными функциями, такими как:

• веб-интерфейс для таргетинга, исполнения кода, контроля соответствия состоянию и интеграции с LDAP;
• интеграция с ServiceNow, позволяющая разворачивать новые серверы и применять состояния из интеграции ServiceNow ITSM;
• RBAC с интеграцией LDAP (естественно);
• «Enterprise API», который транслирует функции версии Enterprise в REST API.

Поддержка сетей

Поскольку Salt полагается на шину сообщений, а ZeroMQ имеет ряд зависимостей, для которых обычно требуется полная настройка сети на уровне ОС, то управление сетевыми устройствами не является очевидным при использовании Salt. В последнем релизе Salt значительно улучшена поддержка «прокси миньонов». Прокси-миньоны — виртуальные миньоны — это процесс, который может где угодно работать для удаленного управления устройствами по SSH, HTTP или с помощью другого транспортного механизма. Он использует ту же функциональность, что и обычный миньон, но у него есть и некоторые особенности. Чтобы избежать путаницы с прокси в Puppet (прокси там является центральной машиной, через которую проходят все запросы), скажу, что это всего лишь процесс, связанный с устройством, к которому вы обращаетесь. Таким образом, это отдельный процесс на каждом миньоне. Он обычно легкий и потребляет около 40 МБ ОЗУ. Можно создавать прокси-миньоны, разрабатывая модули Python, которые могут выполняться на миньоне. Команда Salt демонстрировала это в прошлые годы на SaltConf.

Поддерживаемые в настоящее время сетевые платформы:

• JunOS (Juniper);
• NXOS (Cisco);
• Cisco NSO (оркестратор NETCONF от Cisco);
• NAPALM.
  
  Компания Salt недавно присоединилась к поддержке NAPALM благодаря очень умным инженерам из Cloudflare. NSO и NAPALM имеют схожие черты, но NSO несет лицензионные издержки от Cisco, и вам нужно будет решить, каким путем следовать на раннем этапе.

Поддержка NAPALM в демонстрации Salt

Сильные стороны

• Salt может работать как с агентом, так и без агента (salt-ssh).
• Ультравысокая производительность для крупных развертываний благодаря ZeroMQ.
• Архитектура на основе агентов позволяет развертывать маяки на хостах под управлением как Windows, так и Linux и даже обнаруживать события локально.
• Широко использует некоторые очень большие развертывания (например, LinkedIn) .
• Salt легко может быть объединена с существующим набором баз данных или API-интерфейсов благодаря своей сильной расширяемости.

Слабые стороны

• Расширения, встроенные в ядро, выпускаются слишком редко для быстро меняющихся сред.
• Модули не могут чисто декларировать свои зависимости, т. е. требуется управлять единой виртуальной средой и pip-зависимостями.

Заключение

Основанный на событиях или нет?

Это самое большое различие между этими тремя продуктами. Salt и StackStorm имеют такой функционал. StackStorm имеет службы, которые можно написать (сенсоры), и строго типизированные события, которые могут быть вызваны, как и сложный механизм правил. Salt имеет маяки — службы, которые могут быть запущены как на агентах, так на центральном мастере для обнаружения событий на локальных машинах. Это уникальная возможность. Версия Ansible с открытым исходным кодом не позволяет (и не пытается) реагировать на события.

Поддержка сообщества

Я видел, что производители сетей специально разрабатывали модули для Ansible, тогда как в случае с другими платформами (за исключением Brocade для StackStorm) модули были внесены сообществом. Несомненно, Ansible имеет самую широкую поддержку сетевых платформ. Хотя с внедрением NAPALM и NSO как в StackStorm, так и в Salt это меняет ситуацию, поскольку обе системы поддерживают Arista, JunOS (Juniper), Cisco APIC-EM, NXOS и т.д.

Время начинать

Сила Ansible — это минимальное количество настроек (их, в принципе, нет). Популярность в сетевых задачах может быть обусловлена простотой и знакомством сетевых администраторов с CLI для управления удаленными устройствами без необходимости развертывания каких-либо дополнительных серверов для запуска программного обеспечения. Если у вас много небольших изолированных сайтов (например, коммерческих филиалов), следует подумать, не разделить ли архитектуру. Мой работодатель управляет сетями передачи данных в некоторых крупных сетевых супермаркетах, и я бы не решился иметь мастера в центре, в то время как магазины в сельских районах могут иметь ненадежную связь.

Хранилища данных конфигураций

Salt уникальна тем, что ее ключевые хранилища подключаемы. Если вы хотите хранить пароли или ключи из Hashicorp Vault, это как два пальца. Если вы хотите хранить крупицы данных в базе SQL, все, опять же, работает «из коробки». Подумайте, каким другим системам и платформам могут потребоваться для доступа или ввода данные, которые вы таргетируете.

Безопасность

Если сравнивать Ansible и Salt, Salt имеет собственное хранилище ключей для связи с агентами, а Ansible использует SSH для транспорта. Плохо управляемая среда Ansible, как правило, представляет собой набор закрытых ключей, хранящихся на ноутбуке администраторов (пожалуйста, не делайте этого). Salt предлагает уникальную функцию для защиты данных. Шаблоны, состояния или grains могут быть сохранены во внешнем безопасном хранилище данных. StackStorm хранит данные в MongoDB, которые ваша группа информационной безопасности, безусловно, должна проверить перед тем, как выпускать систему в производственную среду.

Обучение

Если вы не хотите быть единственным специалистом, поддерживающим эту платформу, нужно будет обучить некоторых коллег. Salt и Ansible имеют опубликованные подробные книги, StackStorm — нет. Salt и (RedHat) Ansible предлагают решения для обучения почти исключительно в США, StackStorm — нет (пока). Salt и Ansible имеют курсы по PluralSight, но они действительно базовые.

Лицензирование

И Salt, и StackStorm имеют лицензию Apache-2, Ansible — GPLv3. Если вы не слишком хорошо знакомы с лицензированием OSS, я рекомендую веб-сайт «TLDR Legal». Salt в качестве примера была использована SuSE для создания продукта системного управления (отчасти из-за гибкости их лицензии OSS).

Навыки

Анекдотично (я очень внимательно слежу за этим), но Ansible пользуется вниманием сетевых администраторов и инженеров DevOps по всему миру. Вы наверняка убедитесь, что нанять инженера Ansible намного проще, чем Salt или StackStorm. Но инженеры DevOps так же редки, как и зубы у куриц, поэтому вы будете платить много долларов независимо от платформы.

Какой клей мне выбрать?

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

Вы не должны как ребенок, который впервые попробовал шоколад, запросто верить, что краткий миг радости — это заслуга Кэдберри.

Благодарность: спасибо за отзывы и вклад в развитие от Salt, StackStorm, Ansible и членов сообщества.

Энтони Шоу

Директор группы по инновациям и техническому развитию Dimension Data, отец, христианин, фанат Python, решает проблемы с opensource, идеями и людьми.

Ссылки

1. Ansible v.s. Salt (SaltStack) v.s. StackStorm.

Автор: Southbridge

Источник