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 SaltStack 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

    Si al ejecutar este comando se produce un error, es posible que esté relacionado con el método que utilizó al instalar Salt inicialmente. Si instaló Salt a través del instalador de SaltStack Config, es probable que la instalación incluya un paquete sin conexión, llamado Salt Crystal, que tiene instrucciones de actualización especiales. Para obtener más información, consulte la página Solución de problemas.

  3. Edite el archivo raas.conf generado y actualice los valores de la siguiente manera para validar el certificado que usa la API (RaaS) y establecer su dirección IP.
    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 SaltStack 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 Establece el tiempo durante el que ciertos datos se almacenan en caché de forma local en cada maestro de Salt. El valor predeterminado es 300 segundos (5 min).
  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 SaltStack Config si se ajusta la siguiente configuración.
    • Habilite la puesta en cola de eventos (disponible en Salt 2019.2.2 y versiones posteriores). Los eventos se pueden poner en cola en el maestro de Salt y se pueden enviar al regresador de eventos por lotes mediante una sola transacción para varios eventos. De forma predeterminada, este mecanismo de puesta en cola está deshabilitado. Para habilitar la puesta en cola de eventos, establezca lo siguiente en el archivo de configuración del complemento de maestro de Salt:
      event_return_queue:2500
event_return_queue_max_seconds:5

      El tamaño máximo recomendado para la cola de eventos es 2500 como se muestra. La cola se vaciará y los eventos se reenviarán al regresador de eventos cuando la cola esté llena. Un valor inferior se adapta mejor a los entornos pequeños o menos cargados.

      En algunos casos, es posible que el bus de eventos de Salt no se cargue lo suficiente para hacer que la cola alcance regularmente su tamaño máximo. Si se establece event_return_queue_max_seconds, la cola se vaciará cuando el evento más antiguo de la cola sea anterior al valor configurado, independientemente de la cantidad de eventos en la cola.

    • Habilite y configure los motores eventqueue y rpcqueue:

      Estos motores descargan algunas comunicaciones con SaltStack Config de rutas de código fundamentales para el rendimiento a procesos dedicados. Mientras los motores esperan la comunicación con SaltStack 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.

      Para habilitar los motores, quite las marcas de comentario de los siguientes ajustes en el archivo de configuración del complemento de maestro de Salt (raas.conf):

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

      Para configurar el motor eventqueue, quite las marcas de comentario de los siguientes ajustes y actualícelos:

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

      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, quite las marcas de comentario de los siguientes ajustes y actualícelos:

      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
    • Habilitar almacenamiento en caché de cargas:
      sseapi_local_cache:
    load:3600
      Nota: Si se habilita el motor rpcqueue, también se debe habilitar el almacenamiento en caché de cargas para que el maestro de Salt controle los trabajos correctamente.
    • 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:

      Esto es útil durante la actualización 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, el almacenamiento en caché de cargas, 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 SaltStack 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 SaltStack 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 SaltStack 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 SaltStack Config

En este caso práctico, los archivos de SaltStack Config se almacenan en la base de datos de Postgres y aparecen en la interfaz de usuario de SaltStack 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 SaltStack 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 SaltStack 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