После создания и подготовки инфраструктуры 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. Открыть пользовательский интерфейс Automation 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 установлена с помощью Onedir, путь к исполняемому файлу следующий: /opt/saltstack/salt/extras-3.10/bin/sseapi-config.
  3. Откройте в редакторе сгенерированный файл raas.conf и измените следующие значения.
    Значение Описание

    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 в пользовательском интерфейсе Automation Config.

    В некоторых средах может требоваться, чтобы главный сервер Salt отключался от Интернета на длительное время, а затем выполнял все задания, поставленные в очередь, при возобновлении подключения к Интернету. Если это применимо к вашей среде, установите для этого параметра значение 0.
    sseapi_windows_minion_deploy_delay Укажите задержку для активации всех необходимых служб Windows. Значение по умолчанию — 180 секунд.
    sseapi_linux_minion_deploy_delay Укажите задержку для активации всех необходимых служб Linux. Значение по умолчанию — 90 секунд. 
    sseapi_local_cache
     load: 3600
     tgt: 86400
     pillar: 3600
     exprmatch: 86400
     tgtmatch: 86400

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

    • load — полезные данные salt save_load()

    • tgt — целевые группы SSE

    • pillar — данные хранилища pillar SSE (зашифрованные)

    • exprmatch — данные о сопоставлении выражений для целевых объектов SSE

    • tgtmatch — данные о сопоставлении целевых групп SSE

  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 и Automation Config можно улучшить с помощью следующих параметров.
    • Настройте модули подключаемого модуля Master.

      Модули eventqueue и rpcqueue в подключаемом модуле Master передают некоторые взаимодействия с Automation Config специализированным процессам, освобождая программные механизмы, напрямую влияющие на производительность. Пока модули ожидают взаимодействия с Automation Config, полезные данные находятся в локальной файловой системе главного сервера Salt, поэтому при его перезапуске данные будут сохраняться. Модуль tgtmatch перемещает процесс расчета совпадений целевой группы служебных серверов с сервера RaaS на главные серверы Salt.

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

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

      Чтобы настроить модуль 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

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

      Чтобы настроить модуль rpcqueue, в файле raas.conf должны быть заданы следующие параметры:

      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
      Чтобы настроить модуль tgtmatch, убедитесь в наличии этих параметров в файле конфигурации подключаемого модуля Master (/etc/salt/master.d/raas.conf) 
      engines: 
    - sseapi: {} 
    - eventqueue: {} 
    - rpcqueue: {} 
    - jobcompletion: {} 
    - keyauth: {} 
    - tgtmatch: {} 

sseapi_local_cache:     
    load: 3600 
    tgt: 86400 
    pillar: 3600 
    exprmatch: 86400 
    tgtmatch: 86400 

sseapi_tgt_match: 
    poll_interval: 60     
    workers: 0 
    nice: 19
      Примечание: Чтобы использовать сопоставление целевых объектов на главных серверах Salt, в конфигурации RaaS также должен быть задан следующий параметр конфигурации: target_groups_from_master_only: true.
    • Ограничьте размер полезных данных в параметрах grain служебных серверов.
      sseapi_max_minion_grains_payload: 2000
    • Включите пропуск заданий, которые созданы раньше определенного времени (в секундах). Например, чтобы пропустить задания старше одного дня, используйте значение 86400. Если установлено значение 0, эта функция отключена.
      sseapi_command_age_limit:0
      Примечание:

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

    Используя очередь событий в Salt вместе с модулями формирования очереди, сопоставлением целевых объектов на главных серверах Salt, ограничением размера полезных данных в параметрах grain служебных серверов и предельным сроком хранения команд в подключаемом модуле Master системы Salt, можно увеличить пропускную способность и уменьшить задержку при взаимодействии главного сервера Salt и Automation 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. В Automation 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. Отслеживайте выполнение в Automation Config. Примите идентификаторы служебных серверов Salt, когда они появятся в полях пользовательского интерфейса.
  7. После миграции всех систем выполните задание test.ping, чтобы убедиться, что связь везде установлена правильно.

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

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

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

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

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

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

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

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

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

В этом примере использования файлы Automation 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