После создания и подготовки инфраструктуры Salt для новых систем RHEL 8/9 нужно выполнить следующие действия, чтобы завершить обновление до RHEL 8/9.

Подготовка и выполнение миграции

  1. Остановите службу RaaS в системах RHEL 7 и RHEL 8/9.
  2. Скопируйте файл резервной копии gz со старого сервера на новый. Файл gz должен храниться в каталоге /var/lib/pgsql, где ownership=postgres:postgres.
  3. От имени пользователя Postgres выполните следующие команды, чтобы удалить каталог базы данных:
    su - postgres
psql -U postgres
drop database raas_43cab1f4de604ab185b51d883c5c5d09
  4. Создайте пустую базу данных и подтвердите пользователя:
    create database raas_43cab1f4de604ab185b51d883c5c5d09
\du – should display users for postgres and salteapi
  5. Скопируйте файлы /etc/raas/pki/.raas.key и /etc/raas/pki/.instance_id со старого сервера RaaS на новый.
  6. Выполните команды обновления для новой базы данных PostgreSQL:
    su – raas
raas -l debug upgrade
Теперь службу RaaS можно запустить на новом сервере rhel9-raas. Открыть пользовательский интерфейс SaltStack Config можно также в браузере. Затем необходимо настроить подключаемый модуль Master на новом главном сервере Salt в RHEL 8/9.

Настройка подключаемого модуля Master на новом главном сервере Salt

Выполните следующие действия на новом узле rhel9-master.
  1. Войдите в учетную запись на главном сервере Salt и убедитесь в наличии каталога /etc/salt/master.d. Если его еще нет, создайте его.
  2. Сгенерируйте настройки конфигурации главного сервера.
    Осторожно!: Если настройки требуется сохранить при модернизации установки, перед выполнением этого шага создайте резервную копию существующего файла конфигурации подключаемого модуля Master. Затем скопируйте соответствующие настройки из существующей конфигурации в новый сгенерированный файл. 
    sudo sseapi-config --all > /etc/salt/master.d/raas.conf

    Если при выполнении этой команды произошла ошибка, это может быть связано с методом, который использовался при первоначальной установке Salt. Если система Salt была установлена с помощью установщика SaltStack Config, то эта установка, скорее всего, содержит автономный пакет, называемый Salt Crystal, для обновления которого нужно выполнить особую процедуру. Дополнительные сведения см. в разделе Устранение неполадок.

  3. Отредактируйте сгенерированный файл raas.conf и обновите значения следующим образом, чтобы проверить сертификат, используемый API-интерфейсом (RaaS), и указать его IP-адрес.
    Значение Описание

    sseapi_ssl_validate_cert

    Проверяет сертификат, используемый API-интерфейсом (RaaS). Значение по умолчанию — True.

    При использовании сертификатов, выданных вашим собственным ЦС, установите значение True и настройте параметры sseapi_ssl_ca, sseapi_ssl_cert и sseapi_ssl_cert:.

    В противном случае установите значение False, чтобы не проверять сертификат.

    sseapi_ssl_validate_cert:False

    sseapi_server

    IP-адрес HTTP-узла RaaS, например http://example.com (или https://example.com, если включен протокол SSL).

    sseapi_command_age_limit

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

    sseapi_command_age_limit:86400

    Пропущенные задания остаются в базе данных и отображаются с состоянием Completed в пользовательском интерфейсе SaltStack Config.

    В некоторых средах может требоваться, чтобы главный сервер Salt отключался от Интернета на длительное время, а затем выполнял все задания, поставленные в очередь, при возобновлении подключения к Интернету. Если это применимо к вашей среде, установите для этого параметра значение 0.
    sseapi_windows_minion_deploy_delay Укажите задержку для активации всех необходимых служб Windows. Значение по умолчанию — 180 секунд.
    sseapi_linux_minion_deploy_delay Укажите задержку для активации всех необходимых служб Linux. Значение по умолчанию — 90 секунд.
    sseapi_local_cache Укажите период времени, в течение которого определенные данные локально кешируются на каждом главном сервере Salt. Значение по умолчанию — 300 секунд (5 минут).
  4. НЕОБЯЗАТЕЛЬНО. Этот шаг необходимо выполнять только для установок, осуществленных вручную. Чтобы проверить подключение к SSL перед установкой связи с подключаемым модулем Master, отредактируйте сгенерированный файл raas.conf для обновления следующих значений. Если эти значения не обновить, то в подключаемом модуле Master будет использоваться сертификат, созданный по умолчанию.
    Значение Описание
    sseapi_ssl_ca Путь к файлу ЦС.
    sseapi_ssl_cert Путь к сертификату. Значение, заданное по умолчанию, — /etc/pki/raas/certs/localhost.crt.
    sseapi_ssl_key Путь к закрытому ключу сертификата. Значение, заданное по умолчанию, — /etc/pki/raas/certs/localhost.key.
    id Закомментируйте эту строку, добавив # в ее начало. Выполнять это действие необязательно.
  5. НЕОБЯЗАТЕЛЬНО. Обновите параметры, связанные с производительностью. В крупных и высоконагруженных средах эффективность обмена данными между главным сервером Salt и SaltStack Config можно улучшить с помощью следующих параметров.
    • Включите очередь событий (доступно в системе Salt версии 2019.2.2 и более поздних). На главном сервере Salt события можно записывать в очередь и передавать модулям возврата по несколько событий в пакете в рамках одной транзакции. По умолчанию механизм формирования очереди отключен. Чтобы включить очередь событий, в файле конфигурации подключаемого модуля Master системы Salt выполните следующие настройки.
      event_return_queue:2500
event_return_queue_max_seconds:5

      Рекомендуемый максимальный размер очереди — 2500 событий (как показано ниже). При заполнении очереди события отправляются в модуль возврата, а очередь сбрасывается. Для небольших или менее загруженных сред рекомендуется более низкое значение.

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

    • Включите и настройте модули eventqueue и rpcqueue.

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

      Чтобы включить эти модули, раскомментируйте следующие параметры в файле конфигурации подключаемого модуля Master системы Salt (raas.conf).

      engines:
  - sseapi: {}
  - eventqueue: {}
  - rpcqueue: {}
  - jobcompletion: {}
  - keyauth: {}

      Чтобы настроить модуль eventqueue, раскомментируйте и обновите следующие параметры.

      sseapi_event_queue:
  name: sseapi-events
  strategy: always
  push_interval: 5
  batch_limit: 2000
  age_limit: 86400
  size_limit: 35000000
  vacuum_interval: 86400
  vacuum_limit: 350000
  forward: []

      При корректировке параметров очереди следует учитывать их совместное действие. Например, если принять среднюю скорость шины событий Salt равной 400 событиям в секунду, то при использовании приведенных выше настроек события в очереди главного сервера Salt будут накапливаться в течение примерно 24 часов, прежде чем самые ранние из них будут удалены из-за ограничений по размеру очереди или сроку хранения.

      Чтобы настроить модуль rpcqueue, раскомментируйте и обновите следующие параметры.

      sseapi_rpc_queue:
    name: sseapi-rpc
    strategy: always
    push_interval: 5
    batch_limit: 500
    age_limit: 3600
    size_limit: 360000
    vacuum_interval: 86400
    vacuum_limit: 100000
    • Включите кэширование нагрузки.
      sseapi_local_cache:
    load:3600
      Примечание: Если включен модуль rpcqueue, необходимо также включить кэширование нагрузки, чтобы главный сервер Salt правильно обрабатывал задания.
    • Ограничьте размер полезных данных в параметрах grain служебных серверов.
      sseapi_max_minion_grains_payload:2000
    • Включите пропуск заданий, которые созданы раньше определенного времени (в секундах). Например, чтобы пропустить задания старше одного дня, используйте значение 86400. Если установлено значение 0, эта функция отключена.
      sseapi_command_age_limit:0
      Примечание:

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

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

  6. Перезапустите службу Master главного сервера.
    sudo systemctl restart salt-master
  7. НЕОБЯЗАТЕЛЬНО. При желании можно выполнить тестовое задание и убедиться, что подключаемый модуль Master обеспечивает связь между главным сервером и узлом RaaS.
    salt -v '*' test.ping
Теперь модуль Master в RHEL 8/9 отображается на странице Ключи главного узла.
Осторожно!: Не принимайте ключ главного узла на этом этапе.

Настройка агента служебных серверов

Чтобы настроить агент служебных серверов на узле rhel9-master, выполните следующие действия.
  1. Подключитесь к rhel9-master по протоколу SSH и перейдите в каталог /etc/salt/minion.d.
  2. В файле minion.conf измените параметр главного сервера на master:localhost.
  3. Перейдите в каталог /etc/salt/pk/minion и удалите файл minion_master.pub.
  4. Перезапустите службу salt-minion с помощью команды
    systemctl restart salt-minion
  5. Просмотрите и примите ключ служебного узла в rhel9-master, выполнив следующие действия. 
    salt-key
salt-key -A
  6. В SaltStack Config перейдите в раздел Администрирование > Ключи главного узла и примите ключ главного узла.

    Главный сервер RHEL 8/9 должен отображаться на странице Целевые объекты.

  7. Подключитесь по SSH к главному серверу RHEL7 и удалите ключ служебного узла rhel9-master.

Миграция систем Salt-Minion

Выполнить миграцию управляемых систем можно несколькими способами. Если уже есть настроенный процесс, используйте его. В противном случае следуйте этим инструкциям для переноса служебных серверов Salt со старого главного сервера Salt на новый.
Примечание: Эти шаги не применяются к системам с несколькими главными серверами.
  1. Создайте файл оркестрации. Например: 
    # Orchestration to move Minions from one master to another
# file: /srv/salt/switch_masters/init.sls
{% import_yaml 'switch_masters/map.yaml' as mm %}
{% set minions = mm['minionids'] %}

{% if minions %}
{% for minion in minions %}
move_minions_{{ minion }}:
  salt.state:
    - tgt: {{ minion }}
    - sls:
      - switch_masters.move_minions_map

{% endfor %}    
{% else %}
no_minions:
  test.configurable_test_state:
    - name: No minions to move
    - result: True 
    - changes: False 
    - comment: No minions to move
{% endif %}

remove_minions:
  salt.runner:
    - name: manage.down
    - removekeys: True 

# map file for moving minions
# file: /srv/salt/switch_masters/map.yaml
newsaltmaster: <new_ip_address>
oldsaltmaster: <old_ip_address>
minionids:
  - minion01
  - minion02
  - minion03
state to switch minions from one master to another
# file: /srv/salt/swith_masters/move_minions_map.sls
{% set minion = salt['grains.get']('os') %}
# name old master and set new master ip address
{% import_yaml 'switch_masters/map.yaml' as mm %}
{% set oldmaster = mm['oldsaltmaster'] %}
{% set newmaster = mm['newsaltmaster'] %}

# remove minion_master.pub key
{% if minion == 'Windows' %}
remove_master_key:
  file.absent:
    - name: c:\ProgramData\Salt Project\Salt\conf\pki\minion\minion_master.pub

change_master_assignment:
  file.replace:
    - name: c:\ProgramData\Salt Project\Salt\conf\minion.d\minion.conf 
    - pattern: 'master: {{oldmaster}}'
    - repl: 'master: {{newmaster}}'
    - require:
      - remove_master_key
{% else %}
remove_master_key:
  file.absent:
    - name: /etc/salt/pki/minion/minion_master.pub

# modify minion config file
change_master_assignment:
  file.replace:
    - name: /etc/salt/minion.d/minion.conf 
    - pattern: 'master: {{oldmaster}}'
    - repl: 'master: {{newmaster}}'
    - require:
      - remove_master_key
{% endif %}
# restart salt-minion
restart_salt_minion:
  service.running:
    - name: salt-minion 
    - require:
      - change_master_assignment
    - watch:
      - change_master_assignment
  2. Создайте файл map.yaml (см. пример кода выше):
    1. а.<старый главный сервер salt> IP-адрес/FQDN
    2. б.<новый главный сервер salt> IP-адрес/FQDN
    3. в.Список идентификаторов служебных серверов salt для перемещения.
  3. Создайте файл состояния (см. пример кода выше) для обработки миграции. Например, move_minions_map.sls.
  4. Добавьте эти файлы в каталог (например: /srv/salt/switch_masters) на главном сервере Salt в RHEL7.
  5. Запустите файл оркестрации на главном сервере Salt в RHEL7. Это приведет к некоторым ошибкам, так как служба Salt Minion перезапускается, и ее подключение к главному серверу Salt в RHEL7 не восстанавливается.
  6. Отслеживайте выполнение в SaltStack Config. Примите идентификаторы служебных серверов Salt, когда они появятся в полях пользовательского интерфейса.
  7. После миграции всех систем выполните задание test.ping, чтобы убедиться, что связь везде установлена правильно.

Перенос существующих файлов

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

Пример использования № 1: файловый сервер SaltStack Config

В этом примере использования файлы SaltStack Config хранятся в базе данных Postgres и отображаются в пользовательском интерфейсе SaltStack Config.

Во время восстановления базы данных Postgres эти файлы восстанавливаются и переносятся. Для переноса этих файлов в среду RHEL8/9 никаких дополнительных действий не требуется.

Пример использования № 2: файловый сервер Github/Gitlab

В этом примере использования файлы состояния и конфигурации SaltStack Config хранятся в Github/Gitlab/Bitbucket или другой системе управления версиями кода.

Так как эти файлы хранятся в стороннем инструменте, необходимо настроить новый главный сервер RHEL 8/9 для подключения к системе репозиториев. Эта конфигурация будет зеркалом конфигурации репозитория RHEL7.

Пример использования № 3: локальные корневые каталоги главного сервера Salt

В этом примере использования файлы SaltStack Config хранятся в локальном каталоге файлового сервера на главном сервере Salt.

Чтобы перенести эти файлы на главный сервер RHEL 8/9, скопируйте соответствующие каталоги с главного сервера RHEL7 на главный сервер RHEL8/9.
  1. Файлы состояний и файлы хранилища pillar находятся в каталогах /srv/salt и /srv/pillar соответственно.
  2. Выполните защищенное копирование этих каталогов с главного сервера RHEL7 на главный сервер RHEL8/9, используя средство защищенного копирования, например winscp или командную строку.
  3. Обновите данные хранилища pillar с помощью Salt \* saltutil.refresh_pillar