Dopo aver creato e preparato l'infrastruttura Salt per i nuovi sistemi RHEL 8/9, è possibile eseguire i seguenti passaggi di migrazione per completare l'aggiornamento a RHEL 8/9.

Preparazione ed esecuzione della migrazione

  1. Arrestare il servizio RaaS nei sistemi RHEL 7 e RHEL 8/9.
  2. Copiare il file di backup gz dal server precedente al nuovo server. Il file gz deve essere archiviato nella directory /var/lib/pgsql con ownership=postgres:postgres.
  3. Dall'utente postgres, eseguire i seguenti comandi per rimuovere la directory del database:
    su - postgres
psql -U postgres
drop database raas_43cab1f4de604ab185b51d883c5c5d09
  4. Creare un database vuoto e verificare l'utente:
    create database raas_43cab1f4de604ab185b51d883c5c5d09
\du – should display users for postgres and salteapi
  5. Copiare i file /etc/raas/pki/.raas.key e /etc/raas/pki/.instance_id dal server RaaS precedente al nuovo server RaaS.
  6. Eseguire i comandi di aggiornamento per il nuovo database Postgresql:
    su – raas
raas -l debug upgrade
A questo punto, è possibile avviare il servizio raas nel nuovo server rhel9-raas. È inoltre possibile accedere all'interfaccia utente di SaltStack Config nel browser. Successivamente, è necessario configurare il plug-in Master nel nuovo Salt Master RHEL 8/9.

Configurazione del plug-in Master nel nuovo Salt Master

Eseguire i seguenti passaggi nel nuovo nodo rhel9-master.
  1. Accedere al Salt Master e verificare che la directory /etc/salt/master.d esista. In caso contrario, crearla.
  2. Generare le impostazioni di configurazione del Master.
    Attenzione: Se si desidera conservare le impostazioni quando si aggiorna l'installazione, creare un backup del file di configurazione del plug-in Master esistente prima di eseguire questo passaggio. Copiare quindi le impostazioni pertinenti dalla configurazione esistente nel file appena generato. 
    sudo sseapi-config --all > /etc/salt/master.d/raas.conf

    Se l'esecuzione di questo comando causa un errore, è possibile che sia dovuto al metodo usato durante l'installazione iniziale di Salt. Se Salt è stato installato tramite il programma di installazione di SaltStack Config, è probabile che l'installazione includa un pacchetto offline, denominato Salt Crystal, che richiede istruzioni di aggiornamento speciali. Per ulteriori informazioni, vedere la pagina Risoluzione dei problemi.

  3. Modificare il file raas.conf generato e aggiornare i valori come segue per convalidare il certificato utilizzato dall'API (RaaS) e impostare il relativo indirizzo IP.
    Valore Descrizione

    sseapi_ssl_validate_cert

    Convalida il certificato utilizzato dall'API (RaaS). Il valore predefinito è True.

    Se si utilizzano certificati emessi dall'autorità di certificazione, impostare questo valore su True e configurare le impostazioni sseapi_ssl_ca, sseapi_ssl_cert e sseapi_ssl_cert:.

    In caso contrario, impostarlo su False per non convalidare il certificato.

    sseapi_ssl_validate_cert:False

    sseapi_server

    Indirizzo IP HTTP del nodo RaaS, ad esempio http://example.com o https://example.com se SSL è abilitato.

    sseapi_command_age_limit

    Imposta il periodo di tempo (in secondi) dopo il quale i processi precedenti e potenzialmente obsoleti vengono ignorati. Ad esempio, per ignorare i processi che risalgono a un giorno prima, impostarla su:

    sseapi_command_age_limit:86400

    I processi ignorati continuano ad esistere nel database e vengono visualizzati con lo stato Completed nell'interfaccia utente di SaltStack Config.

    In alcuni ambienti che richiedono che il Salt Master rimanga offline per lunghi periodi di tempo è necessario che il Salt Master esegua tutti i processi accodati quando torna online. Se questa condizione si applica al proprio ambiente, impostare il limite di età su 0.
    sseapi_windows_minion_deploy_delay Imposta un ritardo per consentire l'attivazione di tutti i servizi Windows necessari. Il valore predefinito è 180 secondi.
    sseapi_linux_minion_deploy_delay Imposta un ritardo per consentire l'attivazione di tutti i servizi Linux necessari. Il valore predefinito è 90 secondi.
    sseapi_local_cache Imposta l'intervallo di tempo per cui determinati dati vengono memorizzati nella cache in locale in ogni Salt Master. Il valore predefinito è 300 secondi (5 minuti).
  4. FACOLTATIVO: questo passaggio è necessario solo per le installazioni manuali. Per verificare che sia possibile connettersi a SSL prima di connettere il plug-in Master, modificare il file raas.conf generato per aggiornare i valori seguenti. Se questi valori non vengono aggiornati, il plug-in Master utilizza il certificato generato per impostazione predefinita.
    Valore Descrizione
    sseapi_ssl_ca Percorso di un file CA.
    sseapi_ssl_cert Percorso del certificato. Il valore predefinito è /etc/pki/raas/certs/localhost.crt.
    sseapi_ssl_key Percorso della chiave privata del certificato. Il valore predefinito è /etc/pki/raas/certs/localhost.key.
    id Per commentare questa riga, aggiungere un # all'inizio. Non è obbligatorio.
  5. FACOLTATIVO: aggiornare le impostazioni relative alle prestazioni. Per gli ambienti di grandi dimensioni oppure occupati, è possibile migliorare le prestazioni delle comunicazioni tra il Salt Master e SaltStack Config modificando le seguenti impostazioni.
    • Abilitare l'accodamento degli eventi (disponibile in Salt 2019.2.2 e versioni successive). Gli eventi possono essere accodati nel Salt Master e inviati al returner di eventi in batch utilizzando una singola transazione per più eventi. Per impostazione predefinita, questo meccanismo di accodamento è disabilitato. Per abilitare l'accodamento degli eventi, impostare quanto segue nel file di configurazione del plug-in Salt Master:
      event_return_queue:2500
event_return_queue_max_seconds:5

      Il numero massimo suggerito di eventi in coda è 2500, come illustrato. Quando è piena, la coda viene svuotata e gli eventi vengono inoltrati al returner di eventi. Un valore inferiore potrebbe essere più adatto per gli ambienti più piccoli o meno occupati.

      In alcuni casi, il bus degli eventi di Salt potrebbe non essere sufficientemente occupato da causare il regolare raggiungimento delle dimensioni massime della coda. Se si imposta event_return_queue_max_seconds, la coda verrà svuotata quando l'evento meno recente nella coda è precedente al valore configurato, indipendentemente dal numero di eventi presenti nella coda.

    • Abilitare e configurare i motori eventqueue e rpcqueue:

      Questi motori effettuano l'offload di alcune comunicazioni con SaltStack Config dai percorsi di codice critici per le prestazioni ai processi dedicati. Mentre i motori sono in attesa di comunicare con SaltStack Config, i payload vengono archiviati nel file system locale del Salt Master in modo che i dati possano persistere a ogni riavvio del Salt Master.

      Per abilitare i motori, rimuovere il commento dalle seguenti impostazioni nel file di configurazione del plug-in Salt Master (raas.conf):

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

      Per configurare il motore eventqueue, rimuovere il commento e aggiornare le impostazioni seguenti:

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

      I parametri della coda possono essere modificati in base al modo in cui collaborano. Ad esempio, supponendo una media di 400 eventi al secondo nel bus degli eventi di Salt, le impostazioni visualizzate in precedenza consentono di raccogliere circa 24 ore di traffico degli eventi in coda nel Salt Master prima che gli eventi meno recenti vengono eliminati a causa dei limiti di dimensione o di età.

      Per configurare il motore rpcqueue, rimuovere il commento e aggiornare le impostazioni seguenti:

      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
    • Abilitare la memorizzazione nella cache del carico:
      sseapi_local_cache:
    load:3600
      Nota: Se il motore rpcqueue è abilitato, deve essere abilitata anche la memorizzazione nella cache del carico per consentire al Salt Master di gestire correttamente i processi.
    • Limitare le dimensioni del payload dei grani dei minion:
      sseapi_max_minion_grains_payload:2000
    • Abilitare la funzionalità che consente di ignorare i processi che risalgono a prima di un periodo definito (in secondi). Ad esempio, utilizzare 86400 per impostarla in modo che ignori i processi che hanno più di un giorno. Quando è impostata su 0, questa funzionalità è disabilitata:
      sseapi_command_age_limit:0
      Nota:

      Questa funzionalità è utile durante l'aggiornamento per evitare l'esecuzione imprevista dei comandi precedenti archiviati nel database.

    Insieme, l'accodamento degli eventi in Salt e i motori di accodamento, la memorizzazione nella cache del carico, il limite delle dimensioni del payload dei grani e il limite di età dei comandi nel plug-in Salt Master aumentano la velocità effettiva e riducono la latenza delle comunicazioni tra il Salt Master e SaltStack Config nei percorsi di codice più sensibili alle prestazioni.

  6. Riavviare il servizio Master.
    sudo systemctl restart salt-master
  7. FACOLTATIVO: potrebbe essere necessario eseguire un processo di test per assicurarsi che a questo punto il plug-in Master consenta la comunicazione tra il Master e il nodo RaaS.
    salt -v '*' test.ping
Il Master RHEL 8/9 viene ora visualizzato nella pagina Chiavi master.
Attenzione: Al momento non accettare la chiave master.

Configurazione dell'agente minion

Eseguire i seguenti passaggi per configurare l'agente minion nel nodo rhel9-master in modo che punti a se stesso.
  1. Accedere tramite SSH al nodo rhel9-master e passare alla directory /etc/salt/minion.d.
  2. Modificare il file minion.conf e modificare l'impostazione master in master:localhost.
  3. Passare alla directory /etc/salt/pki/minion ed eliminare il file minion_master.pub.
  4. Riavvio del servizio dei minion Salt utilizzando
    systemctl restart salt-minion
  5. Visualizzare e accettare la chiave minion in rhel9-master eseguendo: 
    salt-key
salt-key -A
  6. In SaltStack Config, passare ad Amministrazione > Chiavi master e accettare la chiave master.

    Il Master RHEL8/9 dovrebbe ora essere visualizzato nella pagina Destinazioni.

  7. Accedere tramite SSH al Master RHEL7 ed eliminare la chiave per il minion rhel9-master.

Migrazione dei sistemi dei minion Salt

Esistono molti modi per eseguire la migrazione dei sistemi gestiti. Si è già stato configurato un processo, eseguire tale processo. In caso contrario, attenersi alle seguenti istruzioni per eseguire la migrazione dei minion Salt da un Salt Master precedente a uno nuovo.
Nota: Questi passaggi non si applicano ai sistemi con più master.
  1. Creare un file di orchestrazione. Ad esempio, 
    # 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. Creare un file map.yaml che includa (vedere l'esempio di codice precedente):
    1. <Salt Master precedente> Indirizzo IP/nome di dominio completo
    2. <nuovo Salt Master> Indirizzo IP/nome di dominio completo
    3. Elenco di saltminionID da spostare.
  3. Creare un file di stato (vedere l'esempio di codice precedente) per elaborare la migrazione. Ad esempio, move_minions_map.sls.
  4. Aggiungere questi file in una directory (ad esempio, /srv/salt/switch_masters nel Salt Master RHEL7.
  5. Eseguire il file di orchestrazione nel Salt Master RHEL7. Ciò comporta alcuni errori quando il servizio dei minion Salt viene riavviato e non torna online per il Salt Master RHEL7.
  6. Monitorare l'avanzamento in SaltStack Config. Accettare la migrazione degli ID minion Salt quando vengono compilati nell'interfaccia utente.
  7. Una volta eseguita la migrazione di tutti i sistemi, eseguire un processo test.ping per verificare che tutto comunichi correttamente.

Migrazione dei file esistenti

Questo processo dipende completamente dal modo in cui l'organizzazione crea, archivia e gestisce il file di stato e configurazione. I casi d'uso più comuni sono descritti di seguito come riferimento.

Caso d'uso 1: SaltStack Config file server

In questo caso d'uso, i file di SaltStack Config vengono archiviati nel database Postgres e visualizzati nell'interfaccia utente di SaltStack Config.

Durante il ripristino del database Postgres, questi file vengono ripristinati e migrati. Non è necessario eseguire ulteriori passaggi per eseguire la migrazione di questi file nell'ambiente RHEL8/9.

Caso d'uso 2: file server Github/Gitlab

In questo caso d'uso, i file di stato e configurazione del SaltStack Config vengono archiviati in Github/Gitlab/Bitbucket o in un altro sistema di controllo della versione del codice.

Poiché questi file vengono archiviati in uno strumento di terzi, è necessario configurare il nuovo Master RHEL8/9 per la connessione al sistema di repository. Questa configurazione eseguirà il mirroring della configurazione del repository di RHEL7.

Caso d'uso 3: file root locali di Salt Master

In questo caso d'uso, tali file di SaltStack Config vengono archiviati in una directory del file server locale nel Salt Master.

Per eseguire la migrazione di questi file nel Master RHEL8/9, copiare le directory appropriate dal Master RHEL7 al Master RHEL8/9.
  1. I file vengono archiviati rispettivamente in /srv/salt e /srv/pillar per i file di stato e i file dei pillar.
  2. Eseguire una copia sicura di queste directory dal Master RHEL7 al Master RHEL8/9 utilizzando uno strumento di copia sicura come winscp o la riga di comando.
  3. Aggiornamento dei dati dei pillar utilizzando Salt \* saltutil.refresh_pillar