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. 
    sudo sseapi-config --all > /etc/salt/master.d/raas.conf

    Se a execução desse comando causar um erro, talvez ele esteja relacionado ao método usado durante a instalação inicial do Salt. Se você instalou o Salt por meio do instalador do Automation Config, sua instalação provavelmente inclui um pacote offline, chamado Salt Crystal, que requer instruções de upgrade especiais. Para obter mais informações, consulte a página de Solução de problemas.

  3. Edite o arquivo raas.conf gerado e atualize os valores da seguinte maneira para validar o certificado usado pela API (RaaS) e definir seu endereço IP.
    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 Define o período de tempo em que determinados dados são armazenados em cache localmente em cada mestre salt. O valor padrão é 300 segundos (5 minutos).
  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 eventqueue e rpcqueue:

      Esses mecanismos descarregam certas comunicações com o Automation Config em 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.

      Para ativar os mecanismos, remova as marcas de comentário das seguintes configurações no arquivo de configuração do Salt Master Plugin (raas.conf):

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

      Para configurar o mecanismo eventqueue, remova as marcas de comentário e atualize as seguintes configurações:

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

      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, remova as marcas de comentário e atualize as seguintes configurações:

      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
    • Ativar cache de carregamento:
      sseapi_local_cache:
    load:3600
      Observação: Se o mecanismo rpcqueue estiver ativado, o cache de carregamento também deverá ser ativado para que o mestre Salt manipule os trabalhos corretamente.
    • 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:

      Isso é útil durante um upgrade, 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, o cache de carregamento, o limite de tamanho da payload de grãos e o limite de idade de comandos no Salt Master Plugin aumentam o rendimento 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