Migrar para o RHEL 8/9
Last Updated February 5, 2025

Depois de criar e preparar sua infraestrutura Salt para os novos sistemas RHEL 8/9, você pode realizar estas etapas de migração para concluir o upgrade para o RHEL 8/9.

Preparar e realizar a migração

Pare o serviço RaaS nos sistemas RHEL 7 e RHEL 8/9.

Copie o arquivo de backup gz do servidor antigo para o novo servidor . O arquivo gz deve ser armazenado no diretório

/var/lib/pgsql

com ownership=postgres:postgres.

No usuário postgres, execute estes comandos para remover o diretório do banco de dados:

su - postgres
psql -U postgres
drop database raas_43cab1f4de604ab185b51d883c5c5d09

Crie um banco de dados vazio e verifique o usuário:

create database raas_43cab1f4de604ab185b51d883c5c5d09
\du – should display users for postgres and salteapi

Copie os arquivos

/etc/raas/pki/.raas.key

/etc/raas/pki/.instance_id

do servidor RaaS antigo para o novo Servidor RaaS.

Execute os comandos de upgrade para o novo banco de dados Postgresql:

su – raas
raas -l debug upgrade

Agora você pode inicializar o serviço raas no novo servidor rhel9-raas. Você também pode acessar a interface de usuário do

Automation Config

no seu navegador. Em seguida, você deve configurar o master plugin no novo Mestre Salt RHEL 8/9.

Configurar o Master Plugin no novo Mestre Salt

Realize estas etapas no novo nó rhel9-master.

/etc/salt/master.d

directory exists, or create it.

Generate the master configuration settings.

If you want to preserve your settings when upgrading your installation, make a backup of your existing Master Plugin configuration file before running this step. Then copy relevant settings from your existing configuration to the newly generated file.

sudo sseapi-config --all > /etc/salt/master.d/raas.conf

If you installed Salt using onedir, the path to this executable is

/opt/saltstack/salt/extras-3.10/bin/sseapi-config

Edit the generated

raas.conf

file and update the values as follows:

Value	Description
sseapi_ssl_validate_cert	Validates the certificate the API (RaaS) uses. The default is True . If you are using your own CA-issued certificates, set this value to True and configure the sseapi_ssl_ca , sseapi_ssl_cert , and sseapi_ssl_cert: settings. Otherwise, set this to False to not validate the certificate. `sseapi_ssl_validate_cert:False`
sseapi_server	HTTP IP address of your RaaS node, for example, http://example.com , or https://example.com if SSL is enabled.
sseapi_command_age_limit	Sets the age (in seconds) after which old, potentially stale jobs are skipped. For example, to skip jobs older than a day, set it to: `sseapi_command_age_limit:86400` Skipped jobs continue to exist in the database and display with a status of Completed in the Automation Config user interface. Some environments might need the Salt master to be offline for long periods of time and will need the Salt master to run any jobs that were queued after it comes back online. If this applies to your environment, set the age limit to 0 .
sseapi_windows_minion_deploy_delay	Sets a delay to allow all requisite Windows services to become active. The default value is 180 seconds.
sseapi_linux_minion_deploy_delay	Sets a delay to allow all requisite Linux services to become activate. The default value is 90 seconds.
`sseapi_local_cache load: 3600 tgt: 86400 pillar: 3600 exprmatch: 86400 tgtmatch: 86400`	Sets the length of time that certain data is cached locally on each salt master. Values are in seconds. The example values are recommended values. load- salt save_load() payloads tgt- SSE target groups pillar- SSE pillar data (encrypted) exprmatch- SSE target expression matching data tgtmatch- SSE target group matching data

OPTIONAL:

This step is necessary for manual installations only. To verify you can connect to SSL before connecting the Master Plugin, edit the generated

raas.conf

file to update the following values. If you do not update these values, the Master Plugin uses the default generated certificate.

Value	Description
sseapi_ssl_ca	The path to a CA file.
sseapi_ssl_cert	The path to the certificate. The default value is /etc/pki/raas/certs/localhost.crt .
sseapi_ssl_key	The path to the certificate’s private key. The default value is /etc/pki/raas/certs/localhost.key .
id	Comment this line out by adding a # at the beginning. It is not required.

OPTIONAL:

Update performance-related settings. For large or busy environments, you can improve the performance of the communications between the Salt master and

Automation Config

by adjusting the following settings.

Configure the master plugin engines:

The master plugin

eventqueue

and

rpcqueue

engines offload some communications with

Automation Config

from performance-critical code paths to dedicated processes. While the engines are waiting to communicate with

Automation Config

, payloads are stored in the Salt master’s local filesystem so the data can persist across restarts of the Salt master. The

tgtmatch

engine moves the calculation of minion target group matches from the RaaS server to the salt-masters.

To enable the engines, ensure that the following settings are present in the Salt Master Plugin configuration file (raas.conf):

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

To configure the

eventqueue

engine, verify that the following settings are present:

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

The queue parameters can be adjusted with consideration to how they work together. For example, assuming an average of 400 events per second on the Salt event bus, the settings shown above allow for about 24 hours of queued event traffic to collect on the Salt master before the oldest events are discarded due to size or age limits.

To configure the

rpcqueue

engine, verify the following settings in 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 o mecanismo tgtmatch, certifique-se de que essas configurações estejam presentes no arquivo de configuração do Master Plugin (/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

To make use of target matching on the salt-masters, the following config setting must also be present in the RaaS configuration:

target_groups_from_master_only: true

Limit minion grains payload sizes:

sseapi_max_minion_grains_payload: 2000

Enable skipping jobs that are older than a defined time (in seconds). For example, use

86400

to set it to skip jobs older than a day. When set to

, this feature is disabled:

sseapi_command_age_limit:0

During system upgrades, enabling this setting is useful to prevent old commands stored in the database from running unexpectedly.

Together, event queuing in Salt and the queuing engines, salt-master target matching, grains payload size limit, and command age limit in the Salt Master Plugin increase the throughput and reduce the latency of communications between the Salt master and

Automation Config

in the most performance-sensitive code paths.

Restart the master service.

sudo systemctl restart salt-master

OPTIONAL:

You might want to run a test job to ensure the Master Plugin is now enabling communication between the master and the RaaS node.

salt -v '*' test.ping

O Mestre RHEL 8/9 agora aparece na página

Chaves Mestres

Não aceite a chave do mestre neste momento.

Configurar o agente subordinado

Siga estas etapas para configurar o agente subordinado no nó rhel9-master para apontar para si mesmo.

Entre via SSH no nó rhel9-master e navegue até o diretório

/etc/salt/minion.d

Edite o arquivo

minion.conf

e altere a configuração mestre para

master:localhost

Navegue até o diretório

/etc/salt/pki/minion

e exclua o arquivo

minion_master.pub

Reinicie o serviço salt-minion usando o

systemctl restart salt-minion

Visualize e aceite a chave de subordinado no rhel9-master executando:

salt-key
salt-key -A

Automation Config

, navegue até

Administração

Chaves Mestres

e aceite a Chave Mestre.

O Mestre RHEL8/9 agora deve aparecer na página

Destinos

Entre por SSH no Mestre RHEL7 e exclua a chave para o subordinado rhel9-master.

Migrar sistemas Salt-Minion

Há várias maneiras de migrar seus sistemas gerenciados . Se você já tiver um processo configurado, siga esse processo. Caso contrário, use estas instruções para migrar seus salt-minions de um Mestre Salt antigo para um novo Mestre Salt.

Essas etapas não se aplicam a sistemas de vários mestres.

Crie um arquivo de orquestração. Por exemplo:

# 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

Crie um arquivo

map.yaml

que inclua (consulte o exemplo de código acima):

<mestre salt antigo> endereço IP/FQDN

<novo mestre salt> endereço IP/FQDN

Lista de saltminionIDs a serem movidos.

Crie um arquivo de estado (consulte o exemplo de código acima) para processar a migração . Por exemplo,

move_minions_map.sls

Adicione esses arquivos a um diretório (por exemplo,

/srv/salt/switch_masters

no Mestre Salt RHEL7.

Execute o arquivo de orquestração no Mestre Salt RHEL7. Isso resulta em alguns erros quando o serviço de subordinado Salt é reiniciado e não volta a ficar online para o Mestre Salt RHEL7.

Monitore o progresso no

Automation Config

. Aceite os IDs de subordinado Salt de migração conforme eles são preenchidos na UI.

Depois que todos os sistemas tiverem migrado, execute um trabalho

test.ping

para verificar se tudo está se comunicando corretamente.

Migrar arquivos existentes

Esse processo depende completamente de como sua organização cria, armazena e gerencia seu arquivo de estado e configuração. Os casos de uso mais comuns são descritos abaixo como referência.

Caso de uso 1: servidor de arquivos do

Automation Config

Nesse caso de uso, seus arquivos

Automation Config

são armazenados no banco de dados Postgres e aparecem na UI do

Automation Config

Durante a restauração do banco de dados Postgres, esses arquivos são recuperados e migrados. Não há etapas adicionais necessárias para migrar esses arquivos para o seu ambiente RHEL8/9.

Caso de uso 2: servidor de arquivos Github/Gitlab

Nesse caso de uso, seus arquivos de estado

Automation Config

e de configuração são armazenados no Github/Gitlab/Bitbucket ou em algum outro sistema de controle de versão de código.

Como esses arquivos são armazenados em uma ferramenta de terceiros, você precisa configurar seu novo Mestre RHEL8/9 para se conectar ao seu sistema de repositório. Essa configuração espelhará a configuração do repositório RHEL7 .

Caso de uso 3: raízes de arquivo locais do Mestre Salt

Nesse caso de uso, seu

Automation Config

é armazenado em um diretório do servidor de arquivos local no Mestre Salt.

Para migrar esses arquivos para o seu Mestre RHEL8/9, copie os diretórios apropriados do seu Mestre RHEL7 para o seu Mestre RHEL8/9.

Os arquivos são armazenados em

/srv/salt

/srv/pillar

para arquivos de estado e de pilar, respectivamente.

Execute uma cópia segura desses diretórios do seu Mestre RHEL7 para o seu Mestre RHEL8/9 usando uma ferramenta de cópia segura, como winscp ou a linha de comando.

Atualizar data do pilar usando

Salt \* saltutil.refresh_pillar

Fazendo upgrade do RHEL 7

Content feedback and comments

VMware Aria Automation 8.16 - Portuguese - Brazil

Migrar para o RHEL 8/9Last Updated February 5, 2025

Preparar e realizar a migração

Configurar o Master Plugin no novo Mestre Salt

Configurar o agente subordinado

Migrar sistemas Salt-Minion

Migrar arquivos existentes

Migrar para o RHEL 8/9
Last Updated February 5, 2025