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
- Detenga el servicio RaaS en los sistemas RHEL 7 y RHEL 8/9.
- 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.
- 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
- Cree una base de datos vacía y compruebe el usuario:
create database raas_43cab1f4de604ab185b51d883c5c5d09 \du – should display users for postgres and salteapi
- Copie los archivos /etc/raas/pki/.raas.key y /etc/raas/pki/.instance_id del servidor RaaS anterior en el nuevo servidor RaaS.
- Ejecute los comandos de actualización para la nueva base de datos de PostgreSQL:
su – raas raas -l debug upgrade
Configurar el complemento principal en el nuevo maestro de Salt
- Inicie sesión en el maestro de Salt y compruebe si existe el directorio
/etc/salt/master.d
. Si no existe, créelo. - 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. - 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 opcionessseapi_ssl_ca
,sseapi_ssl_cert
ysseapi_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
, ohttps://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
-
- 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. - 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
yrpcqueue
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 motortgtmatch
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: {} - keyauth: {} - 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: {} - keyauth: {} - 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 establece0
, 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.
- Configure los motores del complemento principal:
- Reinicie el servicio principal.
sudo systemctl restart salt-master
- 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
Configurar el agente de minion
- Acceda mediante SSH al nodo rhel9-master y desplácese hasta el directorio /etc/salt/minion.d.
- Edite el archivo minion.conf y cambie la configuración principal a
master:localhost
. - Desplácese hasta el directorio /etc/salt/pki/minion y elimine el archivo minion_master.pub.
- Reinicie el servicio salt-minion mediante
systemctl restart salt-minion
- Para ver y aceptar la clave de minion en rhel9-master, ejecute:
salt-key salt-key -A
- En Automation Config, desplácese hasta y acepte la clave maestra.
El maestro de RHEL 8/9 ahora debería aparecer en la página Destinos.
- Acceda mediante SSH al maestro de RHEL7 y elimine la clave del minion rhel9-master.
Migrar sistemas Salt-Minion
- 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
- Cree un archivo map.yaml que incluya (consulte el ejemplo de código anterior):
- Dirección IP/FQDN <maestro de salt anterior>
- Dirección IP/FQDN <maestro de salt nuevo>
- Lista de saltminionID que deben moverse.
- Cree un archivo de estado (consulte el ejemplo de código anterior) para procesar la migración. Por ejemplo, move_minions_map.sls.
- Agregue estos archivos a un directorio (por ejemplo, /srv/salt/switch_masters en el maestro de Salt de RHEL 7.
- 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.
- 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.
- 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.
- Los archivos de estado se almacenan en /srv/salt y los archivos de pilar, en /srv/pillar, respectivamente.
- 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.
- Actualizar la fecha del pilar mediante
Salt \* saltutil.refresh_pillar