Después de crear y preparar la infraestructura de Salt para los nuevos sistemas RHEL 8/9, puede realizar estos pasos de migración para completar la actualización a RHEL 8/9.

Preparar y realizar la migración

  1. Detenga el servicio RaaS en los sistemas RHEL 7 y RHEL 8/9.
  2. Copie el archivo de copia de seguridad gz del servidor anterior al nuevo servidor. El archivo gz debe almacenarse en el directorio /var/lib/pgsql con ownership=postgres:postgres.
  3. Desde el usuario postgres, ejecute estos comandos para eliminar el directorio de la base de datos:
    su - postgres
    psql -U postgres
    drop database raas_43cab1f4de604ab185b51d883c5c5d09
    
  4. Cree una base de datos vacía y compruebe el usuario:
    create database raas_43cab1f4de604ab185b51d883c5c5d09
    \du – should display users for postgres and salteapi
  5. Copie los archivos /etc/raas/pki/.raas.key y /etc/raas/pki/.instance_id del servidor RaaS anterior en el nuevo servidor RaaS.
  6. Ejecute los comandos de actualización para la nueva base de datos de PostgreSQL:
    su – raas
    raas -l debug upgrade
    
Ahora puede iniciar el servicio RaaS en el nuevo servidor rhel9-raas. También puede acceder a la interfaz de usuario de Automation Config en el navegador. A continuación, debe configurar el complemento principal en el nuevo maestro de Salt de RHEL 8/9.

Configurar el complemento principal en el nuevo maestro de Salt

Realice estos pasos en el nuevo nodo rhel9-master.
  1. Inicie sesión en el maestro de Salt y compruebe si existe el directorio /etc/salt/master.d. Si no existe, créelo.
  2. Genere las opciones de configuración del maestro.
    Precaución: Si desea conservar la configuración al actualizar la instalación, realice una copia de seguridad del archivo de configuración del complemento principal existente antes de realizar este paso. A continuación, copie los ajustes pertinentes de la configuración existente en el archivo recién generado.
    sudo sseapi-config --all > /etc/salt/master.d/raas.conf
    Importante: Si instaló Salt mediante onedir, la ruta de acceso a este archivo ejecutable es /opt/saltstack/salt/extras-3.10/bin/sseapi-config.
  3. Edite el archivo raas.conf generado y actualice los valores de la siguiente manera:
    Valor Descripción

    sseapi_ssl_validate_cert

    Valida el certificado que utiliza la API (RaaS). El valor predeterminado es True.

    Si utiliza sus propios certificados emitidos por una CA, establezca este valor en True y configure las opciones sseapi_ssl_ca, sseapi_ssl_cert y sseapi_ssl_cert:.

    De lo contrario, esta opción se establece como False para no validar el certificado.

    sseapi_ssl_validate_cert:False

    sseapi_server

    La dirección IP HTTP del nodo de RaaS es, por ejemplo, http://example.com, o https://example.com si SSL está habilitado.

    sseapi_command_age_limit

    Establece la antigüedad (en segundos) después de la cual se omiten los trabajos antiguos y potencialmente obsoletos. Por ejemplo, para omitir trabajos de más de un día de antigüedad, esta opción se establece en:

    sseapi_command_age_limit:86400

    Los trabajos omitidos seguirán existiendo en la base de datos y se mostrarán con el estado Completed en la interfaz de usuario de Automation Config.

    Es posible que en algunos entornos se necesite que el maestro de Salt esté sin conexión durante largos períodos y que ejecute los trabajos que se ponen en cola después de volver a estar en línea. Si esto se aplica a su entorno, establezca el límite de antigüedad en 0.

    sseapi_windows_minion_deploy_delay Establece un retraso para permitir que todos los servicios de Windows requeridos se activen. El valor predeterminado es 180 segundos.
    sseapi_linux_minion_deploy_delay Establece un retraso para permitir que se activen todos los servicios necesarios de Linux. El valor predeterminado es 90 segundos.
    sseapi_local_cache
         load: 3600
         tgt: 86400
         pillar: 3600
         exprmatch: 86400
         tgtmatch: 86400

    Establece el tiempo durante el que ciertos datos se almacenan en caché de forma local en cada maestro de Salt. Los valores son en segundos. Los valores de ejemplo son valores recomendados.

    • load: cargas útiles de salt save_load()

    • tgt: grupos de destino de SSE

    • pillar: datos del pilar SSE (cifrados)

    • exprmatch: datos que coinciden con la expresión de destino de SSE

    • tgtmatch: datos que coinciden con el grupo de destino de SSE

  4. OPCIONAL: Este paso solo es necesario para instalaciones manuales. Para comprobar que puede conectarse a SSL antes de conectar el complemento principal, edite el archivo raas.conf generado para actualizar los siguientes valores. Si no actualiza estos valores, el complemento principal utiliza el certificado generado predeterminado.
    Valor Descripción
    sseapi_ssl_ca La ruta de acceso a un archivo de CA.
    sseapi_ssl_cert La ruta de acceso al certificado. El valor predeterminado es /etc/pki/raas/certs/localhost.crt.
    sseapi_ssl_key La ruta de acceso a la clave privada del certificado. El valor predeterminado es /etc/pki/raas/certs/localhost.key.
    id Para realizar un comentario en esta línea, agregue # al principio. No es obligatorio.
  5. OPCIONAL: Actualice la configuración relacionada con el rendimiento. En los entornos grandes o cargados, es posible mejorar el rendimiento de las comunicaciones entre el maestro de Salt y Automation Config si se ajusta la siguiente configuración.
    • Configure los motores del complemento principal:

      Los motores eventqueue y rpcqueue del complemento principal descargan algunas comunicaciones con Automation Config de rutas de código fundamentales para el rendimiento a procesos dedicados. Mientras los motores esperan la comunicación con Automation Config, las cargas útiles se almacenan en el sistema de archivos local del maestro de Salt para que los datos puedan persistir después de reiniciar el maestro de Salt. El motor tgtmatch mueve el cálculo de coincidencias de grupos de destino de minions del servidor RaaS a los maestros de Salt.

      Para habilitar los motores, asegúrese de que los siguientes ajustes estén presentes en el archivo de configuración del complemento de maestro de Salt (raas.conf):

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

      Para configurar el motor eventqueue, compruebe que los siguientes ajustes estén presentes:

      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 

      Los parámetros de cola se pueden ajustar de acuerdo con la forma en que funcionan juntos. Por ejemplo, si se asume un promedio de 400 eventos por segundo en el bus de eventos de Salt, los ajustes mostrados anteriormente permiten aproximadamente 24 horas de tráfico de eventos en cola para recopilar en el maestro de Salt antes de que los eventos más antiguos se descarten debido a los límites de tamaño o antigüedad.

      Para configurar el motor rpcqueue, compruebe los siguientes ajustes en 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 
      Para configurar el motor tgtmatch, asegúrese de que estos ajustes estén presentes en el archivo de configuración del complemento principal (/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: Para utilizar la coincidencia de destinos en los maestros de Salt, el siguiente ajuste de configuración también debe estar presente en la configuración de RaaS: target_groups_from_master_only: true.
    • Limitar tamaños de carga útil de granos de minions:
      sseapi_max_minion_grains_payload: 2000
    • Habilite la omisión de trabajos que sean anteriores a un tiempo definido (en segundos). Por ejemplo, utilice 86400 para omitir trabajos más antiguos que un día. Cuando se establece 0, esta función queda deshabilitada:
      sseapi_command_age_limit:0
      Nota:

      Durante las actualizaciones del sistema, habilitar esta opción es útil para evitar que los comandos antiguos almacenados en la base de datos se ejecuten de forma inesperada.

    Juntos, la puesta en cola de eventos en Salt y los motores de cola, la coincidencia de destinos de maestro de Salt, el límite de tamaño de carga útil de granos y el límite de antigüedad de los comandos en el complemento de maestro de Salt aumentan el rendimiento y reducen la latencia de las comunicaciones entre el maestro de Salt y Automation Config en las rutas de código más sensibles al rendimiento.

  6. Reinicie el servicio principal.
    sudo systemctl restart salt-master
  7. OPCIONAL: Podría querer ejecutar un trabajo de prueba para asegurarse de que el complemento principal habilite la comunicación entre el nodo maestro y el nodo de RaaS.
    salt -v '*' test.ping
El maestro de RHEL 8/9 ahora aparece en la página Claves maestras.
Precaución: No acepte la clave maestra en este momento.

Configurar el agente de minion

Siga estos pasos para configurar el agente de minion en el nodo rhel9-master para que apunte a sí mismo.
  1. Acceda mediante SSH al nodo rhel9-master y desplácese hasta el directorio /etc/salt/minion.d.
  2. Edite el archivo minion.conf y cambie la configuración principal a master:localhost.
  3. Desplácese hasta el directorio /etc/salt/pki/minion y elimine el archivo minion_master.pub.
  4. Reinicie el servicio salt-minion mediante
    systemctl restart salt-minion
  5. Para ver y aceptar la clave de minion en rhel9-master, ejecute:
    salt-key
    salt-key -A
  6. En Automation Config, desplácese hasta Administración > Claves maestras y acepte la clave maestra.

    El maestro de RHEL 8/9 ahora debería aparecer en la página Destinos.

  7. Acceda mediante SSH al maestro de RHEL7 y elimine la clave del minion rhel9-master.

Migrar sistemas Salt-Minion

Existen varias formas de migrar los sistemas administrados. Si ya tiene un proceso configurado, siga ese proceso. Si no es así, utilice estas instrucciones para migrar los minions de Salt de un maestro de Salt anterior a un nuevo maestro de Salt.
Nota: Estos pasos no se aplican a los sistemas con varios maestros.
  1. Cree un archivo de orquestación. Por ejemplo:
    # 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. Cree un archivo map.yaml que incluya (consulte el ejemplo de código anterior):
    1. Dirección IP/FQDN <maestro de salt anterior>
    2. Dirección IP/FQDN <maestro de salt nuevo>
    3. Lista de saltminionID que deben moverse.
  3. Cree un archivo de estado (consulte el ejemplo de código anterior) para procesar la migración. Por ejemplo, move_minions_map.sls.
  4. Agregue estos archivos a un directorio (por ejemplo, /srv/salt/switch_masters en el maestro de Salt de RHEL 7.
  5. Ejecute el archivo de orquestación en el maestro de Salt de RHEL 7. Esto da como resultado algunos errores, ya que el servicio de minion de Salt se reinicia y no vuelve a conectarse para el maestro de Salt de RHEL 7.
  6. Supervise el progreso en Automation Config. Acepte los identificadores de minion de Salt de migración a medida que se rellenen en la interfaz de usuario.
  7. Después de que se hayan migrado todos los sistemas, ejecute un trabajo test.ping en ellos para comprobar que todos se comunican correctamente.

Migrar archivos existentes

Este proceso depende completamente de cómo su organización cree, almacene y administre el archivo de estado y configuración. Los casos de uso más comunes se detallan a continuación como referencia.

Caso práctico 1: servidor de archivos de Automation Config

En este caso práctico, los archivos de Automation Config se almacenan en la base de datos de Postgres y aparecen en la interfaz de usuario de Automation Config.

Durante la restauración de la base de datos de Postgres, estos archivos se recuperan y se migran. No es necesario realizar ningún paso adicional para migrar estos archivos al entorno de RHEL 8/9.

Caso práctico 2: servidor de archivos de Github/Gitlab

En este caso práctico, los archivos de estado y configuración de Automation Config se almacenan en Github/Gitlab/Bitbucket o en algún otro sistema de control de versiones de código.

Dado que estos archivos se almacenan en una herramienta de terceros, debe configurar su nuevo maestro de RHEL 8/9 para que se conecte a su nuevo sistema de repositorio. Esta configuración reflejará la configuración del repositorio de RHEL7.

Caso práctico 3: raíces de archivos locales del maestro de Salt

En este caso práctico, los archivos de Automation Config se almacenan en un directorio de servidor de archivos local en el maestro de Salt.

Para migrar estos archivos a su maestro de RHEL 8/9, copie los directorios apropiados del maestro de RHEL 7 a su maestro de RHEL 8/9.
  1. Los archivos de estado se almacenan en /srv/salt y los archivos de pilar, en /srv/pillar, respectivamente.
  2. Realice una copia segura de estos directorios del maestro de RHEL 7 al maestro de RHEL 8/9 mediante una herramienta de copia segura como wincp o la línea de comandos.
  3. Actualizar la fecha del pilar mediante Salt \* saltutil.refresh_pillar