- PVSM.RU - https://www.pvsm.ru -
За последний месяц я слушал интервью с разработчиками на всех трех продуктах и слышал утверждение «считайте [Ansible / Salt / StackStorm] клеем». А теперь я, как самоделкин-любитель, с удовольствием скажу, что у меня в гараже отнюдь не единственный горшок с клеем. У меня 6 разных типов клея для разного применения, различных склеиваемых материалов и условий среды. Все эти 3 продукта находятся в одном и том же лагере, и каждый может быть с успехом использован для достижения совершенно разных целей. Недавно произошел большой перехлест функционала, состоящий в том, что все они проникают в область сетевой автоматизации. Мнения, приведенные ниже, принадлежат мне, а не моему работодателю (который продает продуктов сетевой инфраструктуры и развертывания на миллиарды долларов).
Я пользовался всеми тремя продуктами, в развитие двух из них (Salt и StackStorm) внес значительный вклад и частично способствовал развитию Ansible. Говоря откровенно, продукт, с которым я менее всего знаком, — это Ansible, но я беседовал с коллегами и собирал информацию, чтобы заполнить пробелы.
Если вы собираетесь пролистать текст до конца и узнать, какой продукт я объявил победителем, вы будете разочарованы. Обдумайте свои требования и попробуйте более одного продукта.
Использовать под присмотром взрослых
Задайте себе несколько вопросов:
Уделите этому внимание, это действительно важно. В этой статье я собираюсь сосредоточиться на вопросах автоматизации устройств и их оркестрации. Этими устройствами могут быть маршрутизаторы, коммутаторы, межсетевые экраны, излучающие электромагнитные волны следующего поколения циркулятроны — не имеет значения. Что действительно важно — в их операционной системе не будет установлен агент. У Ansible было совместимое решение — использование SSH в качестве транспорта, поэтому он хорошо вписывается в мир конфигураций конечных устройств, для которых SSH является наименьшим общим знаменателем. SaltStack создавался как шина для высокоскоростного и безопасного миньона (агента), управляющего коммуникацией, но он также имеет режим использования без агента. StackStorm вышел на игровое поле последним и по своей архитектуре не отдает предпочтения какой-либо из работ. Он поддерживает инструменты на основе агентов посредством пакетов для Chef, Puppet, Salt, а также собственные SSH-средства дистанционного управления и встроенную поддержку для вызова сборников сценариев — плейбуков Ansible.
Другое ключевое отличие — API:
Ansible — детище Майкла ДеХаана. Продукт был разработан для автоматизации однообразных задач администрирования серверов в крупных средах. Майкл был в новообразованной технологической группе RedHat, где основал разные проекты (такие как Cobbler [1]), а после ухода из RedHat основал Ansible (хотя теперь Ansible и принадлежит RedHat). Выдержка [2] из блога Майкла, посвященного основам 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.
Раздел о поддержке сетей [3] в Ansible — наиболее полный среди всех трех продуктов и охватывает всех основных вендоров сетевого оборудования и платформы. В Ansible возможно:
Ansible поддерживает Arista, Cisco (все программируемые платформы), F5, Juniper и других производителей. Только в Ansible поддержка в основном предоставляется и осуществляется вендорами, а не сообществом. На данный момент это лучшие интерфейсы API, наибольшая функциональность и работа с самыми последними платформами (поскольку поддерживаются более новые версии).
Я пользовался StackStorm начиная с версии v0.11 (ранняя предварительная бета-версия) вплоть до последней версии v2.2. Это сложная платформа широкого применения, как и Salt. Хотя рассказ о ней требует времени, но все же часто у слушателя создается неправильное впечатление о системе. Я вижу в этом и силу, и слабость. Слабость, потому что сложность системы может заставить отказаться от развертывания совсем или использовать более простое, но неправильное решение там, где StackStorm была бы хорошей альтернативой (часто в таких случаях даже пишется собственное решение «с нуля»). Сила в том, что, как только станет понятно, как использовать сильные стороны, система становится действительно гибкой.
Интерфейс StackStorm
Ядром StackStorm является исполняемый движок с подключаемыми правилами, спроектированный как глубоко настраиваемая служба IFTTT (if-this-then-that, «если это, тогда то»). Можно настроить StackStorm реагировать на произошедшие события запуском простого «действия» (команды) или сложного рабочего процесса. Рабочие процессы доступны в двух вариантах: в виде ActionChain — цепочки действий (проприетарный рабочий процесс DSL) или в виде рабочего процесса на OpenStack Mistral, движок которого основан на YAML.
StackStorm также включает службу для «chatops», с помощью которой можно инициировать рабочие процессы из событий или сообщений платформы чата (например, Slack).
Перечень основных составляющих StackStorm:
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 называются пакетами [5]. Они являются автономными, могут храниться в 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, так как они хорошо поддерживаются [6], чего и следовало ожидать.
В апреле 2017 года они объединили поддержку библиотеки NAPALM и кроссплатформенного пакета абстракции Python для Cisco, Juniper, Arista и других вендоров. Теперь можно использовать функционал NAPALM в части маршрутизации, интерфейсов, пиринга BGP и некоторых других отличных возможностей. Мэтт Освальт (соавтор книги O'Reilly по сетевой автоматизации) написал хороший блог [7] о прогрессе в этом направлении.
Демонстрация NAPALM для StackStorm
Прежде всего Salt — это продукт, SaltStack — это компания. Поэтому, когда я говорю о Salt, я говорю о Salt Open — версии с открытым исходным кодом.
Salt имеет массивный перечень составляющих, поначалу (и когда я говорю «поначалу», я имею в виду «первый год»), это может быть действительно потрясающим. Salt выполняет множество функций, поэтому, как правило, сравнивая Salt с Ansible, Salt-фанаты говорят «да, но он делает намноооооого больше». Как и в случае со StackStorm, это работает и за, и против Salt. Если бы я просто сказал вам принести grains (кристаллы) из шахты, вы бы подумали, что я имею в виду роман Толкиена, но как только вы узнаете, что такое Salt mine (соляная шахта) в терминологии Salt, все станет очевидным.
Salt родилась как распределенная система для удаленного исполнения команд и данных запросов на удаленных узлах или «миньонах». Удаленное исполнение возможно либо на отдельных узлах, либо на группах по произвольным критериям выбора — «таргетинг».
Salt была расширена до системы управления конфигурациями, способной поддерживать удаленные узлы в заданных состояниях (например, гарантируя, что на них установлены определенные пакеты и запущены определенные службы). В Salt есть множество компонентов [8], и я попросту уверен, что пропустил что-то!
Движки — они же Salt Engines (солевые двигатели) — это внешние процессы, исполняемые в течение продолжительного времени, которые работают с Salt.
Миньоны (прокси или обычные) могут быть адресованы с использованием grains (крупинки, кристаллы), pillars (столбов, колонн) или идентификаторов. Существуют и другие плагины для таргетинга [9], а также возможность создавать собственные, основанные на чем-то вроде SQL-запроса или KVP-хранилища.
Grains — Salt содержит интерфейс для получения информации о нижерасположенной системе. Он называется интерфейс «крупинок», потому что представляет собой «соль», состоящую из «крупинок» информации. Grains собираются для операционной системы, имени домена, IP-адреса, ядра, типа ОС, памяти и многих других свойств системы. Интерфейс grains доступен для модулей и компонентов Salt, так что нужные команды миньонов автоматически становятся доступными в соответствующих системах.
Для извлечения данных можно также использовать данные от миньонов и хранить их в Salt mine [11] (соляной шахте). В дальнейшем эти данные можно использовать в других задачах, таких как конфигурация состояний на основе шаблонов. В отличие от Ansible (который поддерживает только YAML), это может быть реализовано в разных форматах.
Архитектура Salt основана на принципе ступицы колеса и спицы (веерная структура). В некоторых очень больших развертываниях используется несколько мастеров, но это случается довольно редко. Мастера можно легко масштабировать до многих тысяч узлов отчасти из-за облегченной шины сообщений ZeroMQ. Другие модели развертывания:
Мастер содержит файлы состояния, которые обычно помещаются в общий том хранения. Они настроены в виде дерева для возможности использования таргетинга, чтобы определять группы серверов для настройки и сред/приложений для развертывания.
Основанная на событиях система Salt использует маяки (beacons). Подобно системе сенсоров и триггеров StackStorm, маяки Salt запускают события в шину сообщений, которые затем могут быть обработаны в реакторе (на мастере). Механизм правил в реакторе довольно сырой по сравнению со StackStorm, поскольку обычно команда состояния или выполнения активируется позади маяка, запускающего событие. Тем не менее, маяки работают на миньонах, поэтому, если события обнаруживаются на серверах, все предельно ясно. Поскольку StackStorm и Ansible не имеют агентов, это будет уникальной функцией Salt.
Thorium [12] (торий) — комплексный реактор для Salt, был включен в прошлый релиз в качестве эксперимента и, может быть, будет поддерживаться в будущих выпусках. Thorium добавляет поддержку более сложных правил и сбора событий.
Все в Salt является расширяемым, вплоть до модулей, отображающих результаты выполнения в CLI. Это большой плюс Salt, так как можно легко внедрять собственные изменения без необходимости поддерживать параллельный fork в главном проекте. Каждая функция в Salt также является подключаемой.
Наиболее распространенными сценариями для расширения могут быть разработка модуля состояния (для описания того, как должна быть сконфигурирована часть программного обеспечения или службы) или модуля исполнения (код для взаимодействия с API или системой). Оба типа модулей могут быть написаны по относительно небольшому шаблону, оба хорошо задокументированы и могут быть проверены с помощью неплохой встроенной тестовой среды. Выполнить узловую проверку модулей можно c помощью PyTest, даже не находясь на мастере или совсем без работающего мастера. Для тестирования интеграций требуется система Linux, хотя с небольшими навыками хакера модули можно запустить и на OSX (о Windows не может идти и речи, как и в случае StackStorm с Ansible).
Возможно либо поддерживать свой автономный пакет, либо вносить непосредственный вклад в проект Salt на GitHub. Самым большим недостатком при внесении кода в основной проект является то, что пользователям для легкой установки ваших модулей может потребоваться подождать целый цикл обновлений. Это занимает примерно 3-5 месяцев при их текущем темпе работы, поэтому, хотя система Salt и «поставляется с батарейками», она имеет недостатки.
У Salt также есть менеджер пакетов, SPM [13], который в основном нацелен на группировку формул управления конфигурацией (state files). Его можно использовать для упаковки модулей, чтобы обойти медленный цикл релизов, о котором я упомяну в слабых сторонах (хотя это и не очень хорошо задокументировано).
Salt развивается очень быстро в течение последних нескольких лет и претерпела некоторые большие изменения. Из-за этого может наблюдаться несовместимость между разработанными сообществом модулями. Я также считаю (хотя это и не уникально для Salt), что модули, представленные сообществом, плохо тестируются.
«Salt Open» — это версия системы с открытым исходным кодом, но можно лицензировать и "Salt Enterprise", которая поставляется с некоторыми приятными функциями, такими как:
Поскольку Salt полагается на шину сообщений, а ZeroMQ имеет ряд зависимостей, для которых обычно требуется полная настройка сети на уровне ОС, то управление сетевыми устройствами не является очевидным при использовании Salt. В последнем релизе Salt значительно улучшена поддержка «прокси миньонов». Прокси-миньоны — виртуальные миньоны — это процесс, который может где угодно работать для удаленного управления устройствами по SSH, HTTP или с помощью другого транспортного механизма. Он использует ту же функциональность, что и обычный миньон, но у него есть и некоторые особенности. Чтобы избежать путаницы с прокси в Puppet (прокси там является центральной машиной, через которую проходят все запросы), скажу, что это всего лишь процесс, связанный с устройством, к которому вы обращаетесь. Таким образом, это отдельный процесс на каждом миньоне. Он обычно легкий и потребляет около 40 МБ ОЗУ. Можно создавать прокси-миньоны, разрабатывая модули Python, которые могут выполняться на миньоне. Команда Salt демонстрировала это в прошлые годы на SaltConf.
Поддерживаемые в настоящее время сетевые платформы:
Поддержка NAPALM в демонстрации Salt
salt-ssh
).Это самое большое различие между этими тремя продуктами. 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, идеями и людьми.
Автор: Southbridge
Источник [16]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/networking/257522
Ссылки в тексте:
[1] Cobbler: http://www.cobblerd.org
[2] Выдержка: https://www.ansible.com/blog/2013/12/08/the-origins-of-ansible
[3] поддержке сетей: https://www.ansible.com/network-automation
[4] StackStorm Exchange: https://exchange.stackstorm.org/
[5] пакетами: https://docs.stackstorm.com/packs.html
[6] хорошо поддерживаются: https://bwc-docs.brocade.com/latest/solutions/essentials/overview.html#overview
[7] хороший блог: https://stackstorm.com/2017/04/11/ensuring-network-configuration-consistency-stackstorm-napalm/
[8] компонентов: https://docs.saltstack.com/en/getstarted/overview.html
[9] плагины для таргетинга: https://docs.saltstack.com/en/latest/topics/targeting/
[10] внешне: https://docs.saltstack.com/en/latest/topics/development/external_pillars.html
[11] mine: https://docs.saltstack.com/en/latest/topics/mine/
[12] Thorium: https://docs.saltstack.com/en/latest/topics/thorium/index.html
[13] менеджер пакетов, SPM: https://docs.saltstack.com/en/latest/topics/spm/
[14] присоединилась к поддержке: https://docs.saltstack.com/en/latest/ref/proxy/all/salt.proxy.napalm.html
[15] Ansible v.s. Salt (SaltStack) v.s. StackStorm: https://medium.com/@anthonypjshaw/ansible-v-s-salt-saltstack-v-s-stackstorm-3d8f57149368
[16] Источник: https://habrahabr.ru/post/330594/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.