迁移到 RHEL 8/9

为新的 RHEL 8/9 系统创建并准备 Salt 基础架构后，可以执行以下迁移步骤来完成到 RHEL 8/9 的升级。

准备并执行迁移

在 RHEL 7 和 RHEL 8/9 系统上停止 RaaS 服务。
将 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 服务器复制到新的 RaaS 服务器。
对新的 Postgresql 数据库运行升级命令：
```
su – raas
raas -l debug upgrade
```

现在，您可以在新的 rhel9-raas 服务器上启动 raas 服务。您还可以在浏览器中访问 Automation Config UI。接下来，必须在新的 RHEL 8/9 Salt 主节点上配置主节点插件。

在新的 Salt 主节点上配置主节点插件

在新的 rhel9-master 节点上执行这些步骤。

登录到 Salt 主节点并验证 /etc/salt/master.d 目录是否存在，如果不存在，则创建该目录。
生成主配置设置。
小心：如果要在升级安装时保留设置，请备份现有的主节点插件配置文件，然后再运行此步骤。之后，将相关设置从现有配置复制到新生成的文件中。
```
sudo sseapi-config --all > /etc/salt/master.d/raas.conf
```
重要说明：如果使用 onedir 安装的 Salt，则此可执行文件的路径为 /opt/saltstack/salt/extras-3.10/bin/sseapi-config。

编辑生成的 raas.conf 文件，并按以下方式更新值：


值	说明
`sseapi_ssl_validate_cert`	验证 API (RaaS) 使用的证书。默认值为 `True`。如果使用自己 CA 颁发的证书，请将此值设置为 `True` 并配置 `sseapi_ssl_ca`、`sseapi_ssl_cert` 和 `sseapi_ssl_cert:` 设置。否则，请将此值设置为 `False`，不验证证书。 sseapi_ssl_validate_cert:False
`sseapi_server`	RaaS 节点的 HTTP IP 地址，例如，`http://example.com` 或 `https://example.com`（如果启用了 SSL）。
`sseapi_command_age_limit`	设置跳过可能失效的旧作业的期限（以秒为单位）。例如，要跳过一天前的作业，请设置为： sseapi_command_age_limit:86400 跳过的作业将继续存在于数据库中，并在 Automation Config 用户界面中显示状态 `Completed`。某些环境可能需要 Salt 主节点长时间脱机，并且需要 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 - SSE pillar 数据（已加密） exprmatch - SSE 目标表达式匹配数据 tgtmatch- SSE 目标组匹配数据

可选：仅手动安装需要执行此步骤。要验证是否可以在连接主节点插件之前连接到 SSL，请编辑生成的 raas.conf 文件，更新以下值。如果不更新这些值，则主节点插件将使用默认生成的证书。


值	说明
`sseapi_ssl_ca`	CA 文件的路径。
`sseapi_ssl_cert`	证书的路径。默认值为 `/etc/pki/raas/certs/localhost.crt`。
`sseapi_ssl_key`	证书私钥的路径。默认值为 `/etc/pki/raas/certs/localhost.key`。
`id`	在开头添加 `#`，注释掉此行。不需要此项。

可选：更新与性能相关的设置。对于大型或繁忙环境，可以通过调整以下设置提高 Salt 主节点与 Automation Config 之间通信的性能。
- 配置主插件引擎：
  主节点插件 eventqueue 和 rpcqueue 引擎会将与 Automation Config 的某些通信从性能关键型代码路径卸载到专用进程。当这些引擎正在等待与 Automation Config 通信时，负载会存储在 Salt 主节点的本地文件系统中，以便数据可以在 Salt 主节点重新启动后持久保留。tgtmatch 引擎会将工作节点目标组匹配的计算从 RaaS 服务器移至 Salt 主节点。
  要启用引擎，请确保 Salt 主节点插件配置文件（raas.conf）中存在以下设置：
```
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 引擎，请确保主节点插件配置文件 (/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。
- 限制工作节点颗粒负载大小：
```
sseapi_max_minion_grains_payload: 2000
```
- 启用跳过早于定义时间（以秒为单位）的作业。例如，使用 86400 会将其设置为跳过一天前的作业。如果设置为 0，将禁用此功能：
```
sseapi_command_age_limit:0
```
  注：
  在系统升级过程中，启用此设置有助于防止数据库中存储的旧命令意外运行。
Salt 中的事件队列以及 Salt 主节点插件中的队列引擎、Salt 主节点目标匹配、Grain 负载大小限制和命令期限限制协同工作，不仅增加了吞吐量，而且减少了在对性能最敏感的代码路径中 Salt 主节点与 Automation Config 之间的通信延迟。
重新启动主服务。
```
sudo systemctl restart salt-master
```
可选：可能希望运行测试作业以确保主节点插件现在支持在主节点与 RaaS 节点之间进行通信。
```
salt -v '*' test.ping
```

RHEL 8/9 主节点现在会显示在主节点密钥页面中。

小心：此时不要接受主节点密钥。

配置工作节点代理

按照以下步骤将 rhel9-master 节点上的工作节点代理配置为指向自身。

通过 SSH 登录到 rhel9-master 节点，然后浏览到 /etc/salt/minion.d 目录。
编辑 minion.conf 文件，并将主节点设置更改为 master:localhost。
浏览到 /etc/salt/pki/minion 目录，然后删除 minion_master.pub 文件。
使用重新启动 salt-minion 服务
```
systemctl restart salt-minion
```
通过运行以下命令查看并接受 rhel9-master 上的工作节点密钥：
```
salt-key
salt-key -A
```
在 Automation Config 中，导航到管理 > 主节点密钥，然后接受主节点密钥。
RHEL8/9 主节点现在应显示在目标页面中。
通过 SSH 登录到 RHEL7 主节点，然后删除 rhel9-master 工作节点的密钥。

迁移 Salt-Minion 系统

迁移受管系统的方法有很多种。如果您已设置某个流程，请遵循该流程。如果未设置流程，请按照以下说明将 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 工作节点 ID 的列表。
创建状态文件（请参见上述代码示例）以处理迁移。例如，move_minions_map.sls。
将这些文件添加到 RHEL7 Salt 主节点上的某个目录（例如，/srv/salt/switch_masters）。
在 RHEL7 Salt 主节点上运行编排文件。这会导致 Salt 工作节点服务重新启动时出现一些错误，并且无法为 RHEL7 Salt 主节点恢复联机。
在 Automation Config 中监控进度。接受 UI 中填充的已迁移 Salt 工作节点 ID。
迁移所有系统后，针对这些系统运行 test.ping 作业，以验证所有服务是否都正常通信。

迁移现有文件

此过程完全取决于您的组织创建、存储和管理状态文件及配置文件的方式。下面概述了最常见的用例以供参考。

用例 1：Automation Config 文件服务器

在此用例中，Automation Config 文件存储在 Postgres 数据库中，并显示在 Automation Config UI 中。

在还原 Postgres 数据库期间，将恢复并迁移这些文件。您无需执行任何额外步骤来将这些文件迁移到 RHEL8/9 环境。

用例 2：Github/Gitlab 文件服务器

在此用例中，Automation Config 状态文件和配置文件存储在 Github/Gitlab/Bitbucket 或某种其他代码版本控制系统中。

由于这些文件存储在第三方工具中，因此您需要配置新的 RHEL8/9 主节点以连接到存储库系统。此配置将镜像 RHEL7 存储库配置。

用例 3：Salt 主节点的本地文件根目录

在此用例中，Automation Config 存储在 Salt 主节点上的本地文件服务器目录中。

要将这些文件迁移到 RHEL8/9 主节点，请从 RHEL7 主节点将相应的目录复制到 RHEL8/9 主节点。

状态文件和 pillar 文件分别存储在 /srv/salt 和 /srv/pillar 中。
使用安全复制工具（例如 wincp 或命令行）从 RHEL7 主节点将这些目录安全复制到 RHEL8/9 主节点。
使用 Salt \* saltutil.refresh_pillar 刷新 pillar 日期