Nachdem Sie Ihre Salt-Infrastruktur für die neuen RHEL 8/9-Systeme erstellt und vorbereitet haben, können Sie diese Migrationsschritte durchführen, um das Upgrade auf RHEL 8/9 abzuschließen.

Vorbereiten und Durchführen der Migration

  1. Beenden Sie den RaaS-Dienst sowohl auf dem RHEL 7- als auch auf dem RHEL 8/9-System.
  2. Kopieren Sie die GZ-Sicherungsdatei vom alten Server auf den neuen Server . Die GZ-Datei muss im Verzeichnis /var/lib/pgsql mit „ownership=postgres:postgres“ gespeichert werden .
  3. Führen Sie vom Postgres-Benutzer die folgenden Befehle aus, um das Datenbankverzeichnis zu entfernen:
    su - postgres
psql -U postgres
drop database raas_43cab1f4de604ab185b51d883c5c5d09
  4. Erstellen Sie eine leere Datenbank und überprüfen Sie den Benutzer:
    create database raas_43cab1f4de604ab185b51d883c5c5d09
\du – should display users for postgres and salteapi
  5. Kopieren Sie die Dateien /etc/raas/pki/.raas.key und /etc/raas/pki/.instance_id vom alten RaaS-Server auf den neuen RaaS-Server.
  6. Führen Sie die Upgrade-Befehle für die neue PostgreSQL-Datenbank aus:
    su – raas
raas -l debug upgrade
Sie können jetzt den RaaS-Dienst auf dem neuen rhel9-raas-Server starten . Sie können auch in Ihrem Browser auf die SaltStack Config-Benutzeroberfläche zugreifen . Als Nächstes müssen Sie das Master-Plug-In auf dem neuen RHEL 8/9-Salt-Master konfigurieren.

Konfigurieren des Master-Plug-Ins auf dem neuen Salt-Master

Führen Sie diese Schritte auf Ihrem neuen rhel9-master-Knoten aus.
  1. Melden Sie sich bei Ihrem Salt-Master an und überprüfen Sie, ob das Verzeichnis /etc/salt/master.d vorhanden ist. Ist dies nicht der Fall, erstellen Sie es.
  2. Generieren Sie die Master-Konfigurationseinstellungen.
    Vorsicht: Wenn Sie Ihre Einstellungen beim Upgrade Ihrer Installation beibehalten möchten, erstellen Sie vor dem Ausführen dieses Schrittes eine Sicherung Ihrer vorhandenen Master-Plug-In-Konfigurationsdatei. Kopieren Sie dann die relevanten Einstellungen aus Ihrer vorhandenen Konfiguration in die neu generierte Datei. 
    sudo sseapi-config --all > /etc/salt/master.d/raas.conf

    Wenn die Ausführung dieses Befehls einen Fehler verursacht, kann die Ursache dafür das von Ihnen verwendete Verfahren bei der anfänglichen Installation von Salt sein. Wenn Sie Salt über das SaltStack Config-Installationsprogramm installiert haben, enthält Ihre Installation wahrscheinlich ein Offline-Paket mit dem Namen „Salt Crystal“, das spezielle Upgrade-Anweisungen erfordert. Weitere Informationen finden Sie auf der Seite Fehlerbehebung.

  3. Bearbeiten Sie die generierte raas.conf-Datei und aktualisieren Sie die Werte wie folgt, um das von API (RaaS) verwendete Zertifikat zu validieren und die IP-Adresse festzulegen.
    Wert Beschreibung

    sseapi_ssl_validate_cert

    Validiert das von der API (RaaS) verwendete Zertifikat. Die Standardeinstellung ist True.

    Wenn Sie Ihre eigenen, von einer Zertifizierungsstelle ausgestellten Zertifikate verwenden, legen Sie diesen Wert auf True fest und konfigurieren Sie die sseapi_ssl_ca-, sseapi_ssl_cert- und sseapi_ssl_cert:-Einstellungen.

    Legen Sie dies andernfalls auf False fest, um das Zertifikat nicht zu validieren.

    sseapi_ssl_validate_cert:False

    sseapi_server

    HTTP-IP-Adresse Ihres RaaS-Knotens, z. B. http://example.com oder https://example.com, wenn SSL aktiviert ist.

    sseapi_command_age_limit

    Legt das Alter (in Sekunden) fest, nach dem ältere, potenziell veraltete Aufträge übersprungen werden. Um beispielsweise Aufträge zu überspringen, die älter als ein Tag sind, legen Sie diese Einstellung auf Folgendes fest:

    sseapi_command_age_limit:86400

    Übersprungene Aufträge sind weiterhin in der Datenbank vorhanden und werden mit dem Status Completed in SaltStack Config angezeigt.

    In bestimmten Umgebungen muss der Salt-Master möglicherweise längere Zeit offline ausgeführt werden und nach Rückkehr in den Online-Status alle in die Warteschlange gestellten Aufträge durchführen. Wenn dies für Ihre Umgebung gilt, legen Sie die Altersgrenze auf 0 fest.
    sseapi_windows_minion_deploy_delay Legt eine Verzögerung fest, damit alle erforderlichen Windows-Dienste aktiviert werden können. Der Standardwert beträgt 180 Sekunden.
    sseapi_linux_minion_deploy_delay Legt eine Verzögerung fest, damit alle erforderlichen Linux-Dienste aktiviert werden können. Der Standardwert beträgt 90 Sekunden.
    sseapi_local_cache Legt fest, wie lange bestimmte Daten lokal auf jedem Salt-Master zwischengespeichert werden. Der Standardwert lautet 300 Sekunden (5 Minuten).
  4. OPTIONAL: Dieser Schritt ist nur für manuelle Installationen erforderlich. Um sicherzustellen, dass Sie sich mit SSL verbinden können, bevor Sie eine Verbindung zum Master-Plug-In herstellen, bearbeiten Sie die generierte raas.conf-Datei, um die folgenden Werte zu aktualisieren. Wenn Sie diese Werte nicht aktualisieren, verwendet das Master-Plug-In das generierte Standardzertifikat.
    Wert Beschreibung
    sseapi_ssl_ca Der Pfad zu einer Zertifizierungsstellendatei.
    sseapi_ssl_cert Der Pfad zum Zertifikat. Der Standardwert lautet /etc/pki/raas/certs/localhost.crt.
    sseapi_ssl_key Der Pfad zum privaten Schlüssel des Zertifikats. Der Standardwert lautet /etc/pki/raas/certs/localhost.key.
    id Kommentieren Sie dieses Line-Out, indem Sie am Anfang ein # hinzufügen. Nicht obligatorisch.
  5. OPTIONAL: Aktualisieren leistungsbezogener Einstellungen. In großen oder ausgelasteten Umgebungen können Sie die Leistung der Kommunikation zwischen dem Salt-Master und SaltStack Config durch Anpassung der folgenden Einstellungen verbessern.
    • Ereigniswarteschlangen aktivieren (verfügbar in Salt 2019.2.2 und höher). Ereignisse können auf dem Salt-Master in die Warteschlange gestellt und mithilfe einer einzelnen Transaktion für mehrere Ereignisse stapelweise an den Ereignis-Returner gesendet werden. Dieser Warteschlangenmechanismus ist standardmäßig deaktiviert. Zum Aktivieren von Ereigniswarteschlangen legen Sie Folgendes in der Konfigurationsdatei des Salt Master-Plug-Ins fest:
      event_return_queue:2500
event_return_queue_max_seconds:5

      Die vorgeschlagene maximale Größe der Ereigniswarteschlange beträgt wie dargestellt 2500. Eine volle Warteschlange wird geleert, indem Ereignisse an den Ereignis-Returner gesendet werden. Ein niedrigerer Wert ist für kleinere oder weniger ausgelastete Umgebungen möglicherweise besser geeignet.

      In bestimmten Fällen ist der Salt-Ereignisbus unter Umständen nicht so stark ausgelastet, dass die Warteschlange regelmäßig ihre maximale Größe erreicht. Durch Festlegen von event_return_queue_max_seconds wird die Warteschlange geleert, wenn das älteste Ereignis in der Warteschlange älter als der konfigurierte Wert ist. Dabei spielt es keine Rolle, wie viele Ereignisse sich in der Warteschlange befinden.

    • Aktivieren und konfigurieren Sie die Module eventqueue und rpcqueue:

      Diese Module lagern bestimmte Kommunikationen mit SaltStack Config aus leistungskritischen Codepfaden in dedizierte Prozesse aus. Während die Module auf die Kommunikation mit SaltStack Config warten, werden Nutzlasten im lokalen Dateisystem des Salt-Masters gespeichert, damit die Daten bei Neustarts des Salt-Masters beibehalten werden können.

      Heben Sie zum Aktivieren der Module die Auskommentierung der folgenden Einstellungen in der Konfigurationsdatei des Salt-Master-Plug-Ins (raas.conf) auf:

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

      Heben Sie zum Konfigurieren des Moduls eventqueue die Auskommentierung der folgenden Einstellungen auf und aktualisieren Sie sie.

      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: []

      Die Warteschlangenparameter können im Hinblick auf deren Zusammenarbeit angepasst werden. Wenn man beispielsweise von durchschnittlich 400 Ereignissen pro Sekunde auf dem Salt-Ereignisbus ausgeht, können sich gemäß der oben angezeigten Einstellungen etwa 24 Stunden Ereignisverkehr in der Warteschlange auf dem Salt-Master sammeln, bevor die ältesten Ereignisse aufgrund von Größen- oder Altersbeschränkungen verworfen werden.

      Heben Sie zum Konfigurieren des Moduls rpcqueue die Auskommentierung der folgenden Einstellungen auf und aktualisieren Sie sie.

      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
    • Lastzwischenspeicherung aktivieren:
      sseapi_local_cache:
    load:3600
      Hinweis: Wenn das Modul rpcqueue aktiviert ist, muss auch die Lastzwischenspeicherung aktiviert sein, damit der Salt-Master Aufträge ordnungsgemäß verarbeiten kann.
    • Nutzlastgröße der Minion-Körner („Grains“) begrenzen:
      sseapi_max_minion_grains_payload:2000
    • Aktivieren Sie das Überspringen von Aufträgen, die älter als eine festgelegte Zeit (in Sekunden) sind. Beispiel: Legen Sie mithilfe von 86400 fest, dass Aufträge, die älter als ein Tag sind, übersprungen werden. Wenn Sie den Wert auf 0 festlegen, wird diese Funktion deaktiviert:
      sseapi_command_age_limit:0
      Hinweis:

      Diese Einstellung ist nützlich während Upgrades, um zu verhindern, dass alte in der Datenbank gespeicherte Befehle unerwartet ausgeführt werden.

    Zusammen erhöhen Ereigniswarteschlangen in Salt und die Warteschlangenmodule, die Lastzwischenspeicherung, die Grenzwerte für die Nutzlastgröße der Körner und die Altersgrenze für Befehle im Salt-Master-Plug-In den Durchsatz und reduzieren die Latenz der Kommunikation zwischen dem Salt-Master und SaltStack Config in leistungsabhängigen Codepfaden.

  6. Starten Sie den Masterdienst neu.
    sudo systemctl restart salt-master
  7. OPTIONAL: Sie möchten möglicherweise einen Testauftrag ausführen, um sicherzustellen, dass das Master-Plug-In nun die Kommunikation zwischen dem Master- und dem RaaS-Knoten ermöglicht.
    salt -v '*' test.ping
Der RHEL 8/9-Master wird jetzt auf der Seite Master-Schlüssel angezeigt.
Vorsicht: Akzeptieren Sie nicht den Master-Schlüssel an dieser Stelle.

Konfigurieren des Minion-Agents

Führen Sie die folgenden Schritte aus, um den Minion-Agent auf dem rhel9-master-Knoten so zu konfigurieren, dass er auf sich selbst verweist.
  1. Melden Sie sich über SSH beim rhel9-master-Knoten an und navigieren Sie zum Verzeichnis /etc/salt/minion.d.
  2. Bearbeiten Sie die Datei minion.conf und ändern Sie die Master-Einstellung in master:localhost.
  3. Navigieren Sie zum Verzeichnis /etc/salt/pki/minion und löschen Sie die Datei minion_master.pub.
  4. Starten Sie den Salt-Minion-Dienst neu mithilfe von
    systemctl restart salt-minion
  5. Zeigen Sie den Minion-Schlüssel auf dem rhel9-master an und akzeptieren Sie ihn, indem Sie folgenden Befehl ausführen: 
    salt-key
salt-key -A
  6. Navigieren Sie in SaltStack Config zu Verwaltung > Master-Schlüssel und akzeptieren Sie den Master-Schlüssel.

    Der RHEL8/9-Master sollte jetzt auf der Seite Ziele angezeigt werden.

  7. Melden Sie sich über SSH beim RHEL7-Master an und löschen Sie den Schlüssel für den rhel9-master-Minion.

Migrieren von Salt-Minion-Systemen

Es gibt viele Möglichkeiten, Ihre verwalteten Systeme zu migrieren. Wenn Sie bereits einen Prozess eingerichtet haben, gehen Sie nach diesem Prozess vor. Gehen Sie anderenfalls nach diesen Anwendungen vor, um Ihre Salt-Minions von einem alten Salt-Master zu einem neuen Salt-Master zu migrieren.
Hinweis: Diese Schritte gelten nicht für Multi-Master-Systeme.
  1. Erstellen Sie eine Orchestrierungsdatei. Beispiel: 
    # 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. Erstellen Sie eine map.yaml-Datei mit (siehe obiges Codebeispiel):
    1. <alter Salt-Master> IP-Adresse/FQDN
    2. <neuer Salt-Master> IP-Adresse/FQDN
    3. Liste der zu verschiebenden saltminionIDs.
  3. Erstellen Sie eine Statusdatei (siehe obiges Codebeispiel), um die Migration zu verarbeiten. Beispiel: move_minions_map.sls.
  4. Fügen Sie diese Dateien einem Verzeichnis (z. B. /srv/salt/switch_masters) auf dem RHEL7-Salt-Master hinzu.
  5. Führen Sie die Orchestrierungsdatei auf dem RHEL7-Salt-Master aus. Dies führt zu einigen Fehlern, da der Salt-Minion-Dienst neu gestartet wird und für den RHEL7-Salt-Master nicht wieder online geschaltet wird.
  6. Überwachen Sie den Fortschritt in SaltStack Config. Akzeptieren Sie die migrierten Salt-Minion-IDs, während sie in der Benutzeroberfläche aufgefüllt werden.
  7. Nachdem alle Systeme migriert wurden, führen Sie einen test.ping-Auftrag für sie aus, um sicherzustellen, dass die gesamte Kommunikation ordnungsgemäß verläuft.

Migrieren vorhandener Dateien

Dieser Vorgang hängt vollständig davon ab, wie Ihre Organisation Ihre Status- und Konfigurationsdatei erstellt, speichert und verwaltet. Die gängigsten Anwendungsfälle werden unten als Referenz beschrieben.

Anwendungsfall 1: SaltStack Config-Dateiserver

In diesem Anwendungsfall werden Ihre SaltStack Config-Dateien in der Postgres-Datenbank gespeichert und auf der SaltStack Config-Benutzeroberfläche angezeigt .

Während der Wiederherstellung der Postgres-Datenbank werden diese Dateien wiederhergestellt und migriert. Es gibt keine zusätzlichen Schritte, die Sie durchführen müssen, um diese Dateien in Ihre RHEL8/9-Umgebung zu migrieren.

Anwendungsfall 2: Github/Gitlab-Dateiserver

In diesem Anwendungsfall werden Ihre SaltStack Config-Status- und Konfigurationsdateien in Github/Gitlab/Bitbucket oder einem anderen Codeversionskontrollsystem gespeichert.

Da diese Dateien in einem Drittanbieter-Tool gespeichert sind, müssen Sie Ihren neuen RHEL8/9-Master für die Verbindung mit Ihrem Repository-System konfigurieren. Diese Konfiguration spiegelt Ihre RHEL7-Repository-Konfiguration wider.

Anwendungsfall 3: Lokale Datei-Roots von Salt-Master

In diesem Anwendungsfall werden Ihre SaltStack Config-Dateien in einem lokalen Dateiserververzeichnis auf dem Salt-Master gespeichert .

Um diese Dateien auf Ihren RHEL8/9-Master zu migrieren, kopieren Sie die entsprechenden Verzeichnisse von Ihrem RHEL7-Master auf Ihren RHEL8/9-Master.
  1. Dateien werden in /srv/salt (für Statusdateien) und /srv/pillar (für Pfeilerdateien) gespeichert.
  2. Führen Sie einen sicheren Kopiervorgang für diese Verzeichnisse von Ihrem RHEL7-Master auf Ihren RHEL8/9-Master durch und verwenden Sie dazu ein sicheres Kopiertool wie winscp oder die Befehlszeile.
  3. Aktualisieren Sie das Pfeilerdatum mithilfe von Salt \* saltutil.refresh_pillar.