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 Automation 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.
    Nota: Se si desidera conservare le impostazioni di configurazione, 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
    Importante: Se Salt è stato installato utilizzando onedir, il percorso di questo file eseguibile è /opt/salt/salt/extras-3.10/bin/sseapi-config.
  3. Modificare il file raas.conf generato e aggiornare i valori nel modo seguente:
    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 Automation 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
     load: 3600
     tgt: 86400
     pillar: 3600
     exprmatch: 86400
     tgtmatch: 86400

    Imposta l'intervallo di tempo per cui determinati dati vengono memorizzati nella cache in locale in ogni Salt Master. I valori sono in secondi. I valori di esempio sono valori consigliati.

    • load- salt save_load() payloads

    • tgt- SSE target groups

    • pillar- SSE pillar data (encrypted)

    • exprmatch- SSE target expression matching data

    • tgtmatch- SSE target group matching data

  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 Automation Config modificando le seguenti impostazioni.
    • Configurare i motori del plug-in Master:

      Il plug-in Master eventqueue e i motori rpcqueue effettuano l'offload di alcune comunicazioni con Automation Config dai percorsi di codice critici per le prestazioni ai processi dedicati. Mentre i motori sono in attesa di comunicare con Automation 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. Il motore tgtmatch sposta il calcolo delle corrispondenze del gruppo di destinazione dei minion dal server RaaS ai Salt Master.

      Per abilitare i motori, assicurarsi che le seguenti impostazioni siano presenti nel file di configurazione del plug-in Salt Master (raas.conf): 

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

      Per configurare il motore eventqueue, verificare che siano presenti le seguenti impostazioni:

      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

      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, verificare le seguenti impostazioni in 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
      Per configurare il motore tgtmatch, assicurarsi che queste impostazioni siano presenti nel file di configurazione del plug-in Master (/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
      Nota: Per utilizzare la corrispondenza della destinazione nei Salt Master, nella configurazione di RaaS deve essere presente anche la seguente impostazione di configurazione: target_groups_from_master_only: true.
    • 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:

      Durante gli aggiornamenti del sistema, l'abilitazione di questa impostazione è utile per evitare che i comandi precedenti archiviati nel database vengano eseguiti in modo imprevisto.

    Insieme, l'accodamento degli eventi in Salt e i motori di accodamento, la corrispondenza della destinazione del Salt Master, il limite delle dimensioni del payload dei grain 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 Automation 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 Automation 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 Automation 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: Automation Config file server

In questo caso d'uso, i file di Automation Config vengono archiviati nel database Postgres e visualizzati nell'interfaccia utente di Automation 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 Automation 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 Automation 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