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 SaltStack 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é. 
    sudo sseapi-config --all > /etc/salt/master.d/raas.conf

    Si l'exécution de cette commande provoque une erreur, celle-ci peut être liée à la méthode que vous avez utilisée lors de l'installation initiale de Salt. Si vous avez installé Salt via le programme d'installation de SaltStack Config, votre installation inclut probablement un module hors ligne, appelé Salt Crystal, qui nécessite des instructions de mise à niveau spéciales. Pour plus d'informations, reportez-vous à la page Dépannage.

  3. Modifiez le fichier raas.conf généré et mettez à jour les valeurs comme suit pour valider le certificat que l'API (RaaS) utilise et définir son adresse IP.
    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 SaltStack 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 Définit la durée pendant laquelle certaines données sont mises en cache localement sur chaque master Salt. La valeur par défaut est de 300 secondes (5 minutes).
  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 SaltStack Config en ajustant les paramètres suivants.
    • Activez la file d'attente des événements (disponible dans Salt 2019.2.2 et versions ultérieures). Les événements peuvent être mis en file d'attente sur le master Salt et envoyés au système de retour d'événements par lot à l'aide d'une transaction unique pour plusieurs événements. Par défaut, ce mécanisme de file d'attente est désactivé. Pour activer la mise en file d'attente des événements, définissez ce qui suit dans le fichier de configuration du plug-in master Salt :
      event_return_queue:2500
event_return_queue_max_seconds:5

      La taille de file d'attente d'événements maximale suggérée est de 2 500, comme indiqué. La file d'attente est vidée et les événements sont transmis au système de retour d'événements lorsque la file d'attente est pleine. Une valeur inférieure peut être mieux adaptée aux environnements plus petits ou aux environnements plus calmes.

      Dans certains cas, le bus d'événements Salt peut ne pas être suffisamment occupé pour que la file d'attente atteigne régulièrement sa taille maximale. La configuration de event_return_queue_max_seconds entraîne le vidage de la file d'attente lorsque l'événement le plus ancien de la file d'attente est antérieur à la valeur configurée, quel que soit le nombre d'événements qui se trouve dans la file d'attente.

    • Activez et configurez les moteurs eventqueue et rpcqueue :

      Ces moteurs déchargent certaines communications avec SaltStack Config des chemins de code critiques pour les performances vers des processus dédiés. Pendant que les moteurs attendent de communiquer avec SaltStack 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.

      Pour activer les moteurs, annulez la mise en commentaire des paramètres suivants dans le fichier de configuration du plug-in master Salt (raas.conf) :

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

      Pour configurer le moteur eventqueue, annulez la mise en commentaire des paramètres suivants et mettez-les à jour :

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

      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, annulez la mise en commentaire des paramètres suivants et mettez-les à jour :

      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
    • Activer la mise en cache de charge :
      sseapi_local_cache:
    load:3600
      Note : Si le moteur rpcqueue est activé, la mise en cache de charge doit également l'être pour que le master Salt gère correctement les tâches.
    • 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 :

      Cela est utile lors d'une mise à niveau pour empêcher l'exécution imprévue 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 cache de charge, la limite de taille de la charge utile des grains et la limite d'ancienneté des commandes dans le plug-in de master Salt augmentent le débit et réduisent la latence des communications entre le master Salt et SaltStack 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 SaltStack 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 SaltStack 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 SaltStack Config

Dans ce cas d'utilisation, les fichiers SaltStack Config sont stockés dans la base de données Postgres et s'affichent dans l'interface utilisateur de SaltStack 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 SaltStack 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 SaltStack 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.