Après avoir créé et préparé votre infrastructure Salt pour les nouveaux systèmes RHEL 8/9, vous pouvez effectuer les étapes de migration suivantes pour terminer la mise à niveau vers RHEL 8/9.

Préparer et effectuer la migration

  1. Arrêtez le service RaaS sur les systèmes RHEL 7 et RHEL 8/9.
  2. Copiez le fichier de sauvegarde .gz de l'ancien serveur vers le nouveau serveur. Le fichier .gz doit être stocké dans le répertoire /var/lib/pgsql avec ownership=postgres:postgres.
  3. À partir de l'utilisateur postgres, exécutez les commandes suivantes pour supprimer le répertoire de base de données :
    su - postgres
psql -U postgres
drop database raas_43cab1f4de604ab185b51d883c5c5d09
  4. Créez une base de données vide et vérifiez l'utilisateur :
    create database raas_43cab1f4de604ab185b51d883c5c5d09
\du – should display users for postgres and salteapi
  5. Copiez les fichiers /etc/raas/pki/.raas.key et /etc/raas/pki/.instance_id de l'ancien serveur RaaS vers le nouveau serveur RaaS.
  6. Exécutez les commandes de mise à niveau pour la nouvelle base de données Postgresql :
    su – raas
raas -l debug upgrade
Vous pouvez maintenant démarrer le service raas sur le nouveau serveur rhel9-raas. Vous pouvez également accéder à l'interface utilisateur de Automation Config dans votre navigateur. Ensuite, vous devez configurer le plug-in master sur le nouveau master Salt RHEL 8/9.

Configurer le plug-in master sur le nouveau master Salt

Effectuez ces étapes sur le nouveau nœud rhel9-master.
  1. Connectez-vous à votre master Salt et vérifiez que le répertoire /etc/salt/master.d existe ou créez-le.
  2. Générez les paramètres de configuration du master.
    Attention : Si vous souhaitez conserver vos paramètres lors de la mise à niveau de votre installation, sauvegardez votre fichier de configuration de plug-in master existant avant d'effectuer cette étape. Copiez ensuite les paramètres pertinents de votre configuration existante dans le fichier qui vient d'être généré.
    Note : Si vous souhaitez conserver vos paramètres de configuration, sauvegardez votre fichier de configuration de plug-in master existant avant d'effectuer cette étape. Copiez ensuite les paramètres pertinents de votre configuration existante dans le fichier qui vient d'être généré. 
    sudo sseapi-config --all > /etc/salt/master.d/raas.conf
    Important : Si vous avez installé Salt à l'aide d'onedir, le chemin d'accès à cet exécutable est /opt/salt/salt/extras-3.10/bin/sseapi-config.
  3. Modifiez le fichier raas.conf généré et mettez à jour les valeurs comme suit :
    Valeur Description

    sseapi_ssl_validate_cert

    Valide le certificat que l'API (RaaS) utilise. La valeur par défaut est True.

    Si vous utilisez vos propres certificats émis par une autorité de certification, définissez cette valeur sur True et configurez les paramètres sseapi_ssl_ca, sseapi_ssl_cert et sseapi_ssl_cert:.

    Sinon, définissez cette valeur sur False pour ne pas valider le certificat.

    sseapi_ssl_validate_cert:False

    sseapi_server

    Adresse IP HTTP de votre nœud RaaS, par exemple, http://example.com, ou https://example.com si SSL est activé.

    sseapi_command_age_limit

    Définit l'âge (en secondes) après lequel les tâches anciennes et potentiellement périmées sont ignorées. Par exemple, pour ignorer les tâches datant de plusieurs jours, définissez-le sur :

    sseapi_command_age_limit:86400

    Les tâches ignorées continuent à exister dans la base de données et s'affichent avec l'état Completed dans l'interface utilisateur de Automation Config.

    Certains environnements peuvent avoir besoin que le master Salt soit hors ligne pendant de longues périodes et auront besoin du master Salt pour exécuter les tâches qui ont été mises en file d'attente après son retour en ligne. Si cela s'applique à votre environnement, définissez la limite d'âge sur 0.
    sseapi_windows_minion_deploy_delay Définit un délai pour permettre à tous les services Windows requis de devenir actifs. La valeur par défaut est de 180 secondes.
    sseapi_linux_minion_deploy_delay Définit un délai pour permettre à tous les services Linux requis de devenir actifs. La valeur par défaut est de 90 secondes. 
    sseapi_local_cache
     load: 3600
     tgt: 86400
     pillar: 3600
     exprmatch: 86400
     tgtmatch: 86400

    Définit la durée pendant laquelle certaines données sont mises en cache localement sur chaque master Salt. Les valeurs sont en secondes. Les exemples de valeurs sont des valeurs recommandées.

    • load : charges utiles salt save_load()

    • tgt : groupes cibles SSE

    • pillar : données de Pillar SSE (chiffrées)

    • exprmatch : données de correspondance d'expression cible SSE

    • tgtmatch : données de correspondance du groupe cible SSE

  4. FACULTATIF : cette étape est uniquement nécessaire pour les installations manuelles. Pour vérifier que vous pouvez vous connecter à SSL avant de connecter le plug-in master, modifiez le fichier raas.conf généré pour mettre à jour les valeurs suivantes. Si vous ne mettez pas à jour ces valeurs, le plug-in maître utilise le certificat généré par défaut.
    Valeur Description
    sseapi_ssl_ca Chemin d'accès à un fichier d'autorité de certification.
    sseapi_ssl_cert Chemin d'accès au certificat. La valeur par défaut est /etc/pki/raas/certs/localhost.crt.
    sseapi_ssl_key Chemin d'accès à la clé privée du certificat. La valeur par défaut est /etc/pki/raas/certs/localhost.key.
    id Mettez cette ligne en commentaire en ajoutant un # au début. Cela n'est pas obligatoire.
  5. FACULTATIF : mettez à jour les paramètres liés aux performances. Pour les environnements de grande taille ou fortement sollicités, vous pouvez améliorer les performances des communications entre le master Salt et Automation Config en ajustant les paramètres suivants.
    • Configurez les moteurs de plug-in master :

      Le plug-in master eventqueue et les moteurs rpcqueue déchargent certaines communications avec Automation Config des chemins de code critiques pour les performances vers des processus dédiés. Pendant que les moteurs attendent de communiquer avec Automation Config, les charges utiles sont stockées dans le système de fichiers local du master Salt afin que les données persistent lors des redémarrages de celui-ci. Le moteur tgtmatch déplace le calcul des correspondances du groupe cible de minions du serveur RaaS vers les services salt-master.

      Pour activer les moteurs, assurez-vous de la présence des paramètres suivants dans le fichier de configuration du plug-in master Salt (raas.conf) : 

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

      Pour configurer le moteur eventqueue, vérifiez la présence des paramètres suivants :

      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

      Les paramètres de file d'attente peuvent être ajustés en fonction de leur interfonctionnement. Par exemple, en supposant une moyenne de 400 événements par seconde sur le bus d'événements Salt, les paramètres indiqués ci-dessus permettent de collecter environ 24 heures de trafic d'événements mis en file d'attente sur le master Salt avant que les événements les plus anciens soient supprimés pour cause de limites de taille ou d'ancienneté.

      Pour configurer le moteur rpcqueue, vérifiez les paramètres suivants dans 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
      Pour configurer le moteur tgtmatch, assurez-vous de la présence de ces paramètres dans le fichier de configuration du 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
      Note : Pour utiliser la correspondance cible sur les services salt-master, le paramètre de configuration suivant doit également être présent dans la configuration RaaS : target_groups_from_master_only: true.
    • Limitez les tailles de charge utile des grains de minions :
      sseapi_max_minion_grains_payload: 2000
    • Activez l'annulation des tâches d'une ancienneté supérieure à une période définie (en secondes). Par exemple, utilisez la valeur 86400 pour que les tâches remontant à plus d'une journée soient ignorées. Lorsque la valeur 0 est choisie, cette fonctionnalité est désactivée :
      sseapi_command_age_limit:0
      Note :

      Lors des mises à niveau du système, l'activation de ce paramètre est utile pour empêcher l'exécution inattendue d'anciennes commandes stockées dans la base de données.

    Ensemble, la mise en file d'attente des événements dans Salt et les moteurs de mise en file d'attente, la mise en correspondance des cibles salt-master, la limite de taille de la charge utile des grains et la limite d'ancienneté des commandes dans le plug-in master Salt augmentent le débit et réduisent la latence des communications entre le master Salt et Automation Config dans les chemins de code les plus sensibles aux performances.

  6. Redémarrez le service de master.
    sudo systemctl restart salt-master
  7. FACULTATIF : vous pouvez exécuter une tâche de test pour vous assurer que le plug-in master permet désormais la communication entre les nœuds master et RaaS.
    salt -v '*' test.ping
Le master RHEL 8/9 s'affiche désormais sur la page Clés de master.
Attention : N'acceptez pas la clé principale à ce stade .

Configurer l'agent de minion

Pour configurer l'agent de minion sur le nœud rhel9-master pour qu'il pointe vers lui-même, procédez comme suit.
  1. Connectez-vous via SSH au nœud rhel9-master et accédez au répertoire /etc/salt/minion.d.
  2. Modifiez le fichier minion.conf et définissez le paramètre master sur master:localhost.
  3. Accédez au répertoire /etc/salt/pki/minion et supprimez le fichier minion_master.pub.
  4. Redémarrer le service salt-minion à l'aide de
    systemctl restart salt-minion
  5. Affichez et acceptez la clé de minion sur rhel9-master en exécutant : 
    salt-key
salt-key -A
  6. Dans Automation Config, accédez à Administration > Clés de master et acceptez la clé principale.

    Le master RHEL 8/9 doit désormais s'afficher sur la page Cibles.

  7. Connectez-vous via SSH au master RHEL 7 et supprimez la clé du minion rhel9-master.

Migrer les systèmes Salt-Minion

Il existe plusieurs façons de migrer vos systèmes gérés. Si vous avez déjà configuré un processus, suivez ce processus. Si ce n'est pas le cas, utilisez les instructions suivantes pour migrer les minions Salt d'un ancien master Salt vers un nouveau master Salt.
Note : Ces étapes ne s'appliquent pas aux systèmes à plusieurs masters.
  1. Créez un fichier d'orchestration . Par exemple, 
    # 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. Créez un fichier map.yaml qui inclut (voir l'exemple de code ci-dessus) :
    1. Adresse IP/Nom de domaine complet de <ancien master salt>
    2. Adresse IP/Nom de domaine complet de <nouveau master salt>
    3. Liste des saltminionIDs à déplacer.
  3. Créez un fichier d'état (voir l'exemple de code ci-dessus) pour traiter la migration. Par exemple, move_minions_map.sls.
  4. Ajoutez ces fichiers à un répertoire (par exemple, /srv/salt/switch_masters sur le master Salt RHEL 7.
  5. Exécutez le fichier d'orchestration sur le master Salt RHEL 7. Cela entraîne des erreurs, car le service de minion Salt redémarre et ne revient pas en ligne pour le master Salt RHEL 7.
  6. Contrôlez l'avancement dans Automation Config. Acceptez les ID de minion Salt de migration tels qu'ils sont remplis dans l'interface utilisateur.
  7. Une fois tous les systèmes migrés, exécutez une tâche test.ping sur ceux-ci pour vérifier que tous communiquent correctement.

Migrer les fichiers existants

Ce processus dépend entièrement de la manière dont votre organisation crée, stocke et gère le fichier d'état et de configuration. Les cas d'utilisation les plus courants sont décrits ci-dessous à titre de référence.

Cas d'utilisation 1 : serveur de fichiers Automation Config

Dans ce cas d'utilisation, les fichiers Automation Config sont stockés dans la base de données Postgres et s'affichent dans l'interface utilisateur de Automation Config.

Lors de la restauration de la base de données Postgres, ces fichiers sont récupérés et migrés. Vous n'avez pas besoin d'effectuer d'autres étapes pour migrer ces fichiers vers l'environnement RHEL 8/9.

Cas d'utilisation 2 : serveur de fichiers Github/Gitlab

Dans ce cas d'utilisation, les fichiers d'état et de configuration de Automation Config sont stockés dans Github/Gitlab/Bitbucket ou dans un autre système de contrôle de version de code.

Étant donné que ces fichiers sont stockés dans un outil tiers, vous devez configurer le nouveau master Salt RHEL 8/9 pour se connecter à votre système de référentiel. Cette configuration mettra en miroir la configuration de votre référentiel RHEL7.

Cas d'utilisation 3 : racines de fichier local du master Salt

Dans ce cas d'utilisation, l'instance de Automation Config est stockée dans un répertoire de serveur de fichiers local sur le master Salt.

Pour migrer ces fichiers vers le master RHEL 8/9, copiez les répertoires appropriés du master RHEL 7 vers le master RHEL 8/9.
  1. Les fichiers sont stockés dans /srv/salt et /srv/pillar respectivement pour les fichiers d'état et les fichiers Pillar.
  2. Effectuez une copie sécurisée de ces répertoires du master RHEL 7 vers le master RHEL 8/9 à l'aide d'un outil de copie sécurisée tel que woncp ou de la ligne de commande.
  3. Actualisez la date du Pillar à l'aide de Salt \* saltutil.refresh_pillar.