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

  1. Pare o serviço RaaS nos sistemas RHEL 7 e RHEL 8/9.
  2. 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.
  3. 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
  4. Crie um banco de dados vazio e verifique o usuário:
    create database raas_43cab1f4de604ab185b51d883c5c5d09
\du – should display users for postgres and salteapi
  5. Copie os arquivos /etc/raas/pki/.raas.key e /etc/raas/pki/.instance_id do servidor RaaS antigo para o novo Servidor RaaS.
  6. 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.
  1. Faça login no mestre Salt e verifique se o diretório /etc/salt/master.d existe. Crie-o se ele não existir.
  2. Gere as definições de configuração do mestre.
    Cuidado: Se quiser preservar as configurações ao atualizar sua instalação, faça um backup do arquivo de configuração do Master Plugin existente antes de executar essa etapa. Em seguida, copie as configurações relevantes da sua configuração existente para o arquivo recém-gerado.
    Observação: Se você quiser preservar as definições de configuração, faça um backup do arquivo de configuração do Master Plugin existente antes de executar essa etapa. Em seguida, copie as configurações relevantes da sua configuração existente para o arquivo recém-gerado. 
    sudo sseapi-config --all > /etc/salt/master.d/raas.conf
    Importante: Se você tiver instalado o Salt usando o onedir, o caminho para esse executável será /opt/saltstack/salt/extras-3.10/bin/sseapi-config.
  3. Edite o arquivo raas.conf gerado e atualize os valores da seguinte maneira:
    Valor Descrição

    sseapi_ssl_validate_cert

    Valida o certificado usado pela API (RaaS). O padrão é True.

    Se estiver usando seus próprios certificados emitidos por uma CA, definir esse valor como True e defina as configurações sseapi_ssl_ca, sseapi_ssl_cert e sseapi_ssl_cert:.

    Caso contrário, defina como False para não validar o certificado.

    sseapi_ssl_validate_cert:False

    sseapi_server

    Endereço IP HTTP do seu nó RaaS, por exemplo, http://example.com, ou https://example.com, se o SSL estiver ativado.

    sseapi_command_age_limit

    Define a idade (em segundos) após a qual trabalhos antigos e potencialmente obsoletos são ignorados. Por exemplo, para ignorar trabalhos com mais de um dia, defina o valor como:

    sseapi_command_age_limit:86400

    Trabalhos ignorados continuam a existir no banco de dados e são exibidos com um status de Completed na interface de usuário do Automation Config.

    Alguns ambientes podem exigir que o mestre Salt fique offline por longos períodos e, quando ele voltar a ficar online, execute todos os trabalhos que foram enfileirados. Se isso se aplicar ao seu ambiente, defina o limite de idade como 0.
    sseapi_windows_minion_deploy_delay Define um atraso para permitir que todos os serviços do Windows necessários se tornem ativos. O valor predefinido é 180 segundos.
    sseapi_linux_minion_deploy_delay Define um atraso para permitir a ativação de todos os serviços do Linux necessários. O valor predefinido é 90 segundos. 
    sseapi_local_cache
     load: 3600
     tgt: 86400
     pillar: 3600
     exprmatch: 86400
     tgtmatch: 86400

    Define o período de tempo em que determinados dados são armazenados em cache localmente em cada mestre salt. Os valores são em segundos. Os valores de exemplo são valores recomendados.

    • Payloads load- salt save_load()

    • Grupos de destino tgt- SSE

    • Dados de pilar pillar- SSE (criptografados)

    • Dados correspondentes à expressão de destino exprmatch- SSE

    • Dados correspondentes ao grupo de destino tgtmatch- SSE

  4. OPCIONAL: Essa etapa é necessária apenas para instalações manuais. Para verificar se você pode se conectar ao SSL antes de conectar o Master Plugin, edite o arquivo raas.conf gerado para atualizar os seguintes valores. Se você não atualizar esses valores, o Master Plugin usará o certificado gerado padrão.
    Valor Descrição
    sseapi_ssl_ca O caminho para um arquivo CA.
    sseapi_ssl_cert O caminho para o certificado. O valor padrão é /etc/pki/raas/certs/localhost.crt.
    sseapi_ssl_key O caminho para a chave privada do certificado. O valor padrão é /etc/pki/raas/certs/localhost.key.
    id Assinale essa linha como comentário adicionando # no início. Ela não é necessária.
  5. OPCIONAL: Atualize as configurações relacionadas ao desempenho. Para ambientes grandes ou movimentados, você pode melhorar o desempenho das comunicações entre o mestre Salt e o Automation Config ajustando as seguintes configurações.
    • Configure os mecanismos de plug-in mestre:

      Os mecanismos de plug-in mestre eventqueue e rpcqueue descarregam certas comunicações com o Automation Config de caminhos de código essenciais ao desempenho para processos dedicados. Enquanto os mecanismos estão esperando para se comunicar com o Automation Config, as payloads são armazenadas no sistema de arquivos local do mestre Salt para que os dados possam persistir entre as reinicializações do mestre Salt. O mecanismo tgtmatch move o cálculo de correspondências do grupo de destino de subordinados do servidor RaaS para os mestres salt.

      Para ativar os mecanismos, certifique-se de que as seguintes configurações estejam presentes no arquivo de configuração do Salt Master Plugin (raas.conf): 

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

      Para configurar o mecanismo eventqueue, verifique se as seguintes configurações estão 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

      Os parâmetros da fila podem ser ajustados levando em consideração como eles funcionam juntos. Por exemplo, assumindo uma média de 400 eventos por segundo no barramento de eventos Salt, as configurações mostradas acima permitem a coleta de cerca de 24 horas de tráfego de eventos em fila no mestre Salt antes que os eventos mais antigos sejam descartados devido a limites de tamanho ou idade.

      Para configurar o mecanismo rpcqueue, verifique as seguintes configurações em 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
      Observação: Para usar a correspondência de destinos nos mestres salt, a seguinte configuração config também deve estar presente na configuração do RaaS: target_groups_from_master_only: true.
    • Limitar tamanhos de payload de grãos de subordinados:
      sseapi_max_minion_grains_payload: 2000
    • Ative a opção para ignorar trabalhos anteriores a um horário definido (em segundos). Por exemplo, use 86400 para configurá-lo de forma a ignorar trabalhos com mais de um dia. Quando definido como 0, esse recurso será desativado:
      sseapi_command_age_limit:0
      Observação:

      Durante atualizações do sistema, ativar essa configuração é útil para evitar que comandos antigos armazenados no banco de dados sejam executados inesperadamente.

    Juntos, o enfileiramento de eventos no Salt e os mecanismos de enfileiramento, a correspondência de destinos do mestre salt, o limite de tamanho da payload de grãos e o limite de idade de comandos no Salt Master Plugin aumentam o throughput e reduzem a latência das comunicações entre o mestre Salt e o Automation Config nos caminhos de código mais sensíveis ao desempenho.

  6. Reinicie o serviço do mestre.
    sudo systemctl restart salt-master
  7. OPCIONAL: Talvez você queira executar um trabalho de teste para garantir que o Master Plugin está agora permitindo a comunicação entre o mestre e o nó RaaS.
    salt -v '*' test.ping
O Mestre RHEL 8/9 agora aparece na página Chaves Mestres.
Cuidado: 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.
  1. Entre via SSH no nó rhel9-master e navegue até o diretório /etc/salt/minion.d.
  2. Edite o arquivo minion.conf e altere a configuração mestre para master:localhost.
  3. Navegue até o diretório /etc/salt/pki/minion e exclua o arquivo minion_master.pub.
  4. Reinicie o serviço salt-minion usando o
    systemctl restart salt-minion
  5. Visualize e aceite a chave de subordinado no rhel9-master executando: 
    salt-key
salt-key -A
  6. No Automation Config, navegue até Administração > Chaves Mestres e aceite a Chave Mestre.

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

  7. 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.
Observação: Essas etapas não se aplicam a sistemas de vários mestres.
  1. 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
  2. Crie um arquivo map.yaml que inclua (consulte o exemplo de código acima):
    1. <mestre salt antigo> endereço IP/FQDN
    2. <novo mestre salt> endereço IP/FQDN
    3. Lista de saltminionIDs a serem movidos.
  3. Crie um arquivo de estado (consulte o exemplo de código acima) para processar a migração . Por exemplo, move_minions_map.sls.
  4. Adicione esses arquivos a um diretório (por exemplo, /srv/salt/switch_mastersno Mestre Salt RHEL7.
  5. 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.
  6. Monitore o progresso no Automation Config. Aceite os IDs de subordinado Salt de migração conforme eles são preenchidos na UI.
  7. 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.
  1. Os arquivos são armazenados em /srv/salt e /srv/pillar para arquivos de estado e de pilar, respectivamente.
  2. 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.
  3. Atualizar data do pilar usando Salt \* saltutil.refresh_pillar