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

Примечание: В рамках инициативы корпорации VMware по удалению сомнительных терминов термин «master» (мастер) будет заменен более подходящим термином в системе SaltStack Config, в связанных продуктах и документации. Для обновления терминологии может потребоваться несколько этапов, прежде чем этот процесс будет полностью завершен.

Что такое Salt?

SaltStack Config выполняется в системе Salt, которая представляет собой платформу удаленного выполнения на основе Python с открытым исходным кодом и используется для следующих задач.

  • Управление конфигурацией
  • Автоматизация
  • Подготовка
  • Оркестрация

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

На рисунке ниже показаны основные компоненты базовой архитектуры Salt.


Архитектура Salt

В следующих разделах описаны некоторые основные компоненты архитектуры Salt, участвующие в установке SaltStack Config.

Главные и служебные серверы Salt

В Salt используется модель «мастер-клиент», в рамках которой главный сервер Salt (мастер) отправляет команды клиенту, а клиент эти команды выполняет. В экосистеме Salt роль главного сервера Salt играет сервер, на котором выполняется служба Salt Master. Он отправляет команды на один или несколько служебных серверов Salt, являющихся узлами, на которых выполняется служба Minion и которые назначены данному главному серверу Salt.

Систему Salt также можно представить в виде модели «издатель-подписчик». Главный сервер Salt публикует задания, которые требуется выполнить, а служебные серверы подписаны на такие задания. Когда определенное задание применяется к такому служебному серверу, он выполняет это задание.

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

Целевые объекты и параметры grains

Главный сервер Salt указывает, какие служебные серверы должны выполнить задание, путем определения целевого объекта. Целевым объектом является группа служебных серверов, относящихся к одному или нескольким главным серверам Salt, для которой предназначена команда задания Salt.

Примечание:

Главным сервером Salt тоже можно управлять, как служебным сервером. Он может быть целевым объектом, если на нем выполняется служба Minion.

Ниже приведен пример одного из типов команд, которые главный сервер Salt может отправлять служебному серверу. Эта команда указывает, что все служебные серверы должны установить приложение Vim.

salt -v '*' pkg.install vim

В данном случае стандартная маска '*' является целевым объектом, который указывает, что эту команду должны выполнить все служебные серверы. Доступно много других вариантов определения целевых объектов, в том числе выбор конкретного служебного сервера по его идентификатору или выбор служебных серверов по их совместно используемым признакам или характеристикам (в Salt они называются параметрами grains).

Salt поставляется с интерфейсом для выдачи информации о базовой системе. Это так называемый интерфейс параметров grains. Он отправляет в Salt определенные фрагменты (grains) информации. Собираемые параметры grains относятся к таким свойствам системы, как операционная система, имя домена, IP-адрес, ядро, тип ОС, память и многие другие. Кроме того, можно создать свои собственные данные grains.

Данные grains являются относительно статичными. Однако данные grains обновляются, если происходит изменение системной информации (например, параметров сети), а также в случае назначения нового значения настраиваемому параметру grains.

Открытая система событий (шина событий)

Система событий используется для передачи данных между процессами, осуществляемыми между главным сервером Salt и служебными серверами. Система событий имеет следующие свойства.

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

Шина событий является основой для оркестрации и мониторинга в реальном времени.

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

  • ZeroMQ (0MQ). Текущая библиотека на уровне сокетов по умолчанию, создающая гибкий транспортный уровень.
  • Tornado. Законченная система событий транспортного уровня на основе TCP.

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

Состояния Salt

Помимо удаленного выполнения, Salt поддерживает еще один метод настройки служебных серверов путем объявления состояния, в котором должен находиться служебный сервер. Такие состояния называются состояниями Salt. Состояния Salt позволяют управлять конфигурацией. Благодаря состояниям Salt можно развертывать инфраструктуру и управлять ею, используя простые файлы YAML. С помощью состояний можно автоматизировать рекурсивные и предсказуемые задачи путем создания очереди заданий для выполнения в Salt без вмешательства пользователя. В файлы состояний также можно добавлять более сложную условную логику, используя Jinja.

Чтобы проиллюстрировать небольшие различия между удаленным выполнением и управлением конфигурацией, рассмотрим команду, упомянутую в предыдущем разделе о целевых объектах и параметрах grains, где система Salt установила приложение Vim на всех служебных серверах.

Методология

Реализация

Результат

Удаленное выполнение

  • Запуск salt-v'*'pkg.installvim из терминала
  • Удаленная установка Vim на целевых служебных серверах

Управление конфигурацией

  • Запись файла состояния YAML, который проверяет, установлено ли приложение Vim
  • Применение файла состояния к целевым служебным серверам
  • Проверка того, что Vim всегда устанавливается на целевых служебных серверах
  • Salt анализирует файл состояния и определяет действия, которые нужно выполнить, чтобы убедиться, что служебный сервер соответствует объявлениям состояния
  • Если приложение Vim не установлено, система автоматизирует процессы для установки Vim на целевых служебных серверах

Файл состояния, проверяющий факт установки Vim, может иметь примерно следующий вид.

# File:/srv/salt/vim_install.sls
install_vim_now:
  pkg.installed:
     -pkgs:
         -vim

Чтобы применить это состояние к служебному серверу, необходимо использовать модуль state.apply, как в следующем примере.

salt '*' state.apply vim_install

Эта команда применяет состояние vim_install ко всем служебным серверам.

Формулы — это коллекции состояний, которые работают совместно для настройки служебного сервера или приложения. Например, одно состояние может запускать другое состояние.

Top-файл

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

Для решения этой задачи масштабирования в Salt реализованы две функции.

  • Файл top.sls. Сопоставляет состояния Salt с применимыми служебными серверами.
  • Выполнение процессов highstate. Запускает все состояния Salt, указанные в файле top.sls, в виде отдельного цикла выполнения.

Top-файл указывает состояния, которые должны быть применены к тем или иным служебным серверам в определенных средах. Ниже приведен пример простого top-файла.

# File: /srv/salt/top.sls
base:
  '*':
    - all_server_setup
  
  '01webserver':
    - web_server_setup

В этом примере base указывает на среду Salt, которая является средой по умолчанию. При необходимости можно указать несколько сред, например prod, dev, QA и т. д.

Группы служебных серверов указываются для конкретной среды, а состояния перечисляются для каждой группы служебных серверов. Данный top-файл указывает, что состояние all_server_setup должно быть применено ко всем служебным серверам ('*'), а состояние web_server_setup должно быть применено к служебному серверу 01webserver.

Чтобы выполнить команду Salt, следует использовать функцию state.highstate.

salt \* state.highstate

Эта команда применяет top-файл к целевым служебным серверам.

Хранилище pillar системы Salt

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

Хранилище pillar системы Salt передает данные в кластер в направлении, противоположном направлению для параметров grains. Если параметры grains представляют собой данные, генерируемыми на служебном сервере, то хранилище pillar содержит данные, генерируемыми на главном сервере Salt.

Хранилища pillar организованы аналогично состояниям в дереве состояний хранилища pillar, где файл top.sls координирует данные хранилища pillar по средам и служебным серверам, которым предназначены эти данные. Информация, передаваемая с помощью хранилища pillar, содержит словарь, генерируемый для целевого служебного сервера и шифруемый с помощью ключа этого служебного сервера для защищенной передачи данных. Данные хранилища pillar шифруются для каждого служебного сервера по отдельности, что позволяет использовать их для хранения конфиденциальных данных, относящихся к конкретному служебному серверу.

Маячки и реакторы

Система маячков представляет собой средство мониторинга, которое может прослушивать различные системные процессы на служебных серверах. Маячки могут запускать реакторы, которые впоследствии могут участвовать во внесении изменений или устранении проблем. Например, если истек срок ожидания ответа от той или иной службы, реактор может перезапустить эту службу.

Маячки используются для разных целей, в том числе для следующих.

  • Автоматизированная отчетность
  • Доставка журнала ошибок
  • Мониторинг микрослужб
  • Действия оболочки пользователя
  • Мониторинг ресурсов

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

Реакторы могут применяться в разных сценариях, в том числе в следующих.

  • Масштабирование инфраструктуры
  • Уведомление администраторов
  • Перезапуск приложений, работающих со сбоями
  • Автоматический откат

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

Модули runner и оркестрация в системе Salt

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

Salt позволяет оркестрировать задачи администрирования системы в рамках целого предприятия. Оркестрация позволяет централизованно координировать действия различных компьютеров из одного места. Это позволяет в том числе контролировать последовательность заданных событий настройки с точки зрения времени их появления. Состояния оркестрации выполняются на главном сервере Salt с помощью модуля state runner.

Выполняя установку с несколькими узлами, вы на самом деле запускаете оркестрацию, чтобы установить SaltStack Config. В сценарии установки с несколькими узлами запускается процесс highstate оркестрации, разработанный корпорацией VMware. Процесс highstate выполняется на главном сервере Salt для настройки среды, содержащей несколько узлов. Он устанавливает базовую архитектуру SaltStack Config на трех других узлах, где будут размещены PostgreSQL, Redis и служба RaaS.