新しい 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
    重要： onedir を使用して Salt をインストールした場合、この実行可能ファイルへのパスは次のようになります： /opt/saltstack/salt/extras-3.10/bin/sseapi-config。
  3. 生成された 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、または 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
     load: 3600
     tgt: 86400
     pillar: 3600
     exprmatch: 86400
     tgtmatch: 86400

    各 Salt マスターで特定のデータがローカルにキャッシュされる時間の長さを設定します。値は秒単位です。値の例は推奨値です。

    • load- salt save_load() ペイロード

    • tgt- SSE ターゲット グループ

    • ピラー- SSE ピラー データ(暗号化済み)

    • exprmatch- SSE ターゲット式一致データ

    • tgtmatch- SSE ターゲット グループの一致データ

  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 マスターの再起動後もデータが保持されます。tgtmatch エンジンは、RaaS サーバから salt-master に対して一致するミニオン ターゲット グループの計算を移動します。

      エンジンを有効にするには、Salt マスター プラグイン構成ファイル (raas.conf) に次の設定があることを確認します。 

      engines: 
     - sseapi: {} 
     - eventqueue: {} 
     - rpcqueue: {} 
     - jobcompletion: {}      
     - 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 イベント バス上の平均イベント数を 1 秒あたり 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: {}    
    - 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-master でターゲット一致を利用するには、RaaS 構成に次の構成設定も含まれている必要があります： target_groups_from_master_only: true。
    • ミニオン グレインのペイロード サイズを制限します。
      sseapi_max_minion_grains_payload: 2000
    • 定義された時間（秒）よりも古いジョブのスキップを有効にします。たとえば、1 日よりも古いジョブをスキップするように設定するには、86400 を使用します。0 に設定すると、この機能は無効になります。
      sseapi_command_age_limit:0
      注：

      システムのアップグレード中にこの設定を有効にすると、データベースに保存されている古いコマンドが予期せずに実行されるのを防ぐのに役立ちます。

    Salt でのイベント キュー、キュー エンジン、salt-master ターゲット一致、グレインのペイロード サイズ制限、および 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 を使用してピラーの日付を更新します。