新しい RHEL 8/9 システム用に Salt インフラストラクチャを作成して準備した後、次の移行手順を実行して RHEL 8/9 へのアップグレードを完了できます。

準備と移行の実行

  1. RHEL 7 システムと RHEL 8/9 システムの両方で RaaS サービスを停止します。
  2. gz バックアップ ファイルを古いサーバから新しいサーバにコピーします。gz ファイルは、ownership=postgres:postgres の付いた /var/lib/pgsql ディレクトリに格納する必要があります。
  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 サーバから新しい RaaS サーバにコピーします。
  6. 新しい PostgreSQL データベースのアップグレード コマンドを実行します。
    su – raas
raas -l debug upgrade
新しい rhel9-raas サーバで raas サービスを起動できるようになります。ブラウザで Automation Config ユーザー インターフェイスにアクセスすることもできます。次に、新しい RHEL 8/9 Salt マスターでマスター プラグインを構成する必要があります。

新しい Salt マスターでのマスター プラグインの構成

新しい rhel9 マスター ノードで、次の手順を実行します。
  1. Salt マスターにログインし、/etc/salt/master.d ディレクトリがあることを確認するか、作成します。
  2. マスター構成設定を生成します。
    注意： インストールのアップグレード時に設定を保持するには、この手順を実行する前に、既存のマスター プラグイン構成ファイルのバックアップを作成します。その後、必要な設定を既存の構成から新しく生成されたファイルにコピーします。 
    sudo sseapi-config --all > /etc/salt/master.d/raas.conf

    このコマンドの実行によってエラーが発生する場合は、Salt を最初にインストールするときに使用した方法が関係している可能性があります。Automation Config インストーラを使用して Salt をインストールした場合、インストールには通常、Salt Crystal というオフライン パッケージが含まれます。これは、特別なアップグレード手順を必要とします。詳細については、トラブルシューティングのページを参照してください。

  3. 生成された raas.conf ファイルを編集します。API (RaaS) が使用する証明書を検証し、その IP アドレスを設定するために、値を次のように更新します。
    値 説明

    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、または SSL が有効な場合は https://example.com。

    sseapi_command_age_limit

    古く無効な可能性があるジョブをスキップするための経過時間（秒）を設定します。たとえば、1 日以上経過した古いジョブをスキップするには、次のように設定します。

    sseapi_command_age_limit:86400

    スキップされたジョブはデータベースに引き続き存在し、Automation Config のユーザー インターフェイスで Completed ステータスとして表示されます。

    一部の環境では、Salt マスターを長時間オフラインにする必要があり、キューに入れられたジョブはオンラインに戻った後に実行する必要があります。これが該当する環境では、経過時間の上限を 0 にします。
    sseapi_windows_minion_deploy_delay すべての Windows サービスがアクティブ状態になる際に必要な遅延を設定します。デフォルト値は 180 秒です。
    sseapi_linux_minion_deploy_delay すべての Linux サービスがアクティブ状態になる際に必要な遅延を設定します。デフォルト値は 90 秒です。
    sseapi_local_cache 各 Salt マスターで特定のデータがローカルにキャッシュされる時間の長さを設定します。デフォルト値は 300 秒（5 分）です。
  4. [オプション：]この手順は、手動インストールの場合にのみ必要です。マスター プラグインに接続する前に 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 この行は、先頭に # を追加してコメント アウトします。この値は不要です。
  5. [オプション：]パフォーマンス関連の設定を更新します。大規模な環境または処理量の多い環境では、次の設定を調整することによって Salt マスターと Automation Config の間の通信のパフォーマンスを向上させることができます。
    • eventqueue および rpcqueue エンジンを構成します。

      これらのエンジンは、Automation Config との通信の一部を、パフォーマンスが重要なコード パスから専用のプロセスにオフロードします。エンジンが Automation Config との通信を待機している間にペイロードが Salt マスターのローカル ファイルシステムに保存されるため、Salt マスターの再起動後もデータが保持されます。

      エンジンを有効にするには、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 イベント バス上の平均イベント数を 1 秒あたり 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 マスターがジョブを正しく処理するには、ロード キャッシュも有効になっている必要があります。
    • ミニオン グレインのペイロード サイズを制限します。
      sseapi_max_minion_grains_payload:2000
    • 定義された時間（秒）よりも古いジョブのスキップを有効にします。たとえば、1 日よりも古いジョブをスキップするように設定するには、86400 を使用します。0 に設定すると、この機能は無効になります。
      sseapi_command_age_limit:0
      注：

      これは、アップグレード時に、データベースに保存されている古いコマンドが予期せず実行されることを防ぐために役立ちます。

    Salt でのイベント キュー、キュー エンジン、ロード キャッシュ、グレインのペイロード サイズ制限、および Salt マスター プラグインでのコマンドの経過時間制限を組み合わせることで、スループットが向上し、パフォーマンスが重視されるコード パスにおける Salt マスターと Automation Config の間の通信の遅延が減少します。

  6. マスター サービスを再起動します。
    sudo systemctl restart salt-master
  7. [オプション：]マスター プラグインによってマスターと RaaS ノードの間の通信が有効になっていることを確認するために、テスト ジョブを実行できます。
    salt -v '*' test.ping
RHEL 8/9 マスターが [マスター キー] 画面に表示されるようになります。
注意： この時点ではマスター キーを受け入れないでください。

ミニオン エージェントの構成

次の手順に従って、rhel9-master ノードでミニオン エージェントが自身を参照するように構成します。
  1. rhel9-master ノードに SSH 接続し、/etc/salt/minion.d ディレクトリを参照します。
  2. minion.conf ファイルを編集し、マスター設定を master:localhost に変更します。
  3. /etc/salt/pki/minion ディレクトリを参照し、minion_master.pub ファイルを削除します。
  4. 次のコマンドを使用して salt-minion サービスを再起動します。
    systemctl restart salt-minion
  5. 次の手順を実行して、rhel9-master のミニオン キーを表示して受け入れます。 
    salt-key
salt-key -A
  6. Automation Config,で、[管理] > [マスター キー] の順に移動し、マスター キーを受け入れます。

    RHEL8/9 マスターが [ターゲット] 画面に表示されます。

  7. RHEL7 マスターに SSH 接続し、rhel9-master ミニオンのキーを削除します。

Salt-Minion システムの移行

管理対象システムを移行する方法は多数あります。プロセスをすでに設定している場合は、そのプロセスに従います。そうでない場合は、次の手順を使用して Salt ミニオンを古い 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. 移動する saltminionID のリスト。
  3. 移行を処理する状態ファイル（上記のサンプル コードを参照）を作成します。例：move_minions_map.sls。
  4. これらのファイルを RHEL7 Salt マスターのディレクトリ（例：/srv/salt/switch_masters）に追加します。
  5. RHEL7 Salt マスターでオーケストレーション ファイルを実行します。これにより、Salt ミニオン サービスが再開し、RHEL7 Salt マスターでサービスがオンラインに復帰しないというエラーが表示されます。
  6. Automation Config で進行状況を監視します。移行 Salt ミニオン ID がユーザー インターフェイスにポピュレートされたら受け入れます。
  7. すべてのシステムが移行された後、システムに対して test.ping ジョブを実行し、すべてが適切に通信していることを確認します。

既存のファイルの移行

このプロセスは、組織が状態ファイルと構成ファイルを作成、保存、および管理する方法によって完全に異なります。以下、参照として最も一般的な使用事例について説明します。

使用事例 1：Automation Config ファイル サーバ

この使用事例では、Automation Config ファイルは Postgres データベースに保存され、Automation Config ユーザー インターフェイスに表示されます。

Postgres データベースのリストア中に、これらのファイルがリカバリおよび移行されます。これらのファイルを RHEL8/9 環境に移行するために必要な追加の手順はありません。

使用事例 2：Github/Gitlab サーバ

この使用事例では、Automation Config 状態と構成ファイルは Github/Gitlab/Bitbucket などのコード バージョン管理システムに保存されます。

これらのファイルはサードパーティ製ツールに保存されるため、リポジトリ システムに接続するように新しい RHEL8/9 マスターを構成する必要があります。この構成は、RHEL7 リポジトリ構成をミラーリングします。

使用事例 3：Salt マスターのローカル ファイル ルート

この使用事例では、Automation Config は Salt マスターのローカル ファイル サーバ ディレクトリに保存されます。

これらのファイルを RHEL8/9 マスターに移行するには、RHEL7 マスターから RHEL8/9 マスターに適切なディレクトリをコピーします。
  1. ファイルは、状態ファイルとピラー ファイルについて /srv/salt および /srv/pillar にそれぞれ保存されます。
  2. winscp などのセキュア コピー ツールやコマンド ラインを使用して、RHEL7 マスターから RHEL8/9 マスターへのこれらのディレクトリのセキュア コピーを実行します。
  3. Salt \* saltutil.refresh_pillar を使用してピラーの日付を更新します。