Миграция на RHEL 8/9

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

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

Остановите службу RaaS в системах RHEL 7 и RHEL 8/9.
Скопируйте файл резервной копии gz со старого сервера на новый. Файл gz должен храниться в каталоге /var/lib/pgsql, где ownership=postgres:postgres.
От имени пользователя Postgres выполните следующие команды, чтобы удалить каталог базы данных:
```
su - postgres
psql -U postgres
drop database raas_43cab1f4de604ab185b51d883c5c5d09
```

Создайте пустую базу данных и подтвердите пользователя:

create database raas_43cab1f4de604ab185b51d883c5c5d09
\du – should display users for postgres and salteapi

Скопируйте файлы /etc/raas/pki/.raas.key и /etc/raas/pki/.instance_id со старого сервера RaaS на новый.
Выполните команды обновления для новой базы данных PostgreSQL:
```
su – raas
raas -l debug upgrade
```

Теперь службу RaaS можно запустить на новом сервере rhel9-raas. Открыть пользовательский интерфейс SaltStack Config можно также в браузере. Затем необходимо настроить подключаемый модуль Master на новом главном сервере Salt в RHEL 8/9.

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

Выполните следующие действия на новом узле rhel9-master.

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

Отредактируйте сгенерированный файл 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 минут).

НЕОБЯЗАТЕЛЬНО. Этот шаг необходимо выполнять только для установок, осуществленных вручную. Чтобы проверить подключение к 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`	Закомментируйте эту строку, добавив `#` в ее начало. Выполнять это действие необязательно.

НЕОБЯЗАТЕЛЬНО. Обновите параметры, связанные с производительностью. В крупных и высоконагруженных средах эффективность обмена данными между главным сервером 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, осуществляемом программными механизмами, которые напрямую влияют на производительность.
Перезапустите службу Master главного сервера.
```
sudo systemctl restart salt-master
```
НЕОБЯЗАТЕЛЬНО. При желании можно выполнить тестовое задание и убедиться, что подключаемый модуль Master обеспечивает связь между главным сервером и узлом RaaS.
```
salt -v '*' test.ping
```

Теперь модуль Master в RHEL 8/9 отображается на странице Ключи главного узла.

Осторожно!: Не принимайте ключ главного узла на этом этапе.

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

Чтобы настроить агент служебных серверов на узле rhel9-master, выполните следующие действия.

Подключитесь к rhel9-master по протоколу SSH и перейдите в каталог /etc/salt/minion.d.
В файле minion.conf измените параметр главного сервера на master:localhost.
Перейдите в каталог /etc/salt/pk/minion и удалите файл minion_master.pub.
Перезапустите службу salt-minion с помощью команды
```
systemctl restart salt-minion
```
Просмотрите и примите ключ служебного узла в rhel9-master, выполнив следующие действия.
```
salt-key
salt-key -A
```
В SaltStack Config перейдите в раздел Администрирование > Ключи главного узла и примите ключ главного узла.
Главный сервер RHEL 8/9 должен отображаться на странице Целевые объекты.
Подключитесь по SSH к главному серверу RHEL7 и удалите ключ служебного узла rhel9-master.

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

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

Примечание: Эти шаги не применяются к системам с несколькими главными серверами.

Создайте файл оркестрации. Например:

# 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

Создайте файл map.yaml (см. пример кода выше):
1. а.<старый главный сервер salt> IP-адрес/FQDN
2. б.<новый главный сервер salt> IP-адрес/FQDN
3. в.Список идентификаторов служебных серверов salt для перемещения.
Создайте файл состояния (см. пример кода выше) для обработки миграции. Например, move_minions_map.sls.
Добавьте эти файлы в каталог (например: /srv/salt/switch_masters) на главном сервере Salt в RHEL7.
Запустите файл оркестрации на главном сервере Salt в RHEL7. Это приведет к некоторым ошибкам, так как служба Salt Minion перезапускается, и ее подключение к главному серверу Salt в RHEL7 не восстанавливается.
Отслеживайте выполнение в SaltStack Config. Примите идентификаторы служебных серверов Salt, когда они появятся в полях пользовательского интерфейса.
После миграции всех систем выполните задание 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.

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