Migrar para o RHEL 8/9

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 e /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 SaltStack 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.

Faça login no mestre Salt e verifique se o diretório /etc/salt/master.d existe. Crie-o se ele não existir.
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 SaltStack 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.

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

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.

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 SaltStack Config ajustando as seguintes configurações.
- Ative o enfileiramento de eventos (disponível no salt 2019.2.2 e posterior). Eventos podem ser enfileirados no mestre Salt e enviados ao retornador de eventos em lotes usando uma única transação para vários eventos. Por padrão, esse mecanismo de enfileiramento está desativado. Para ativar o enfileiramento de eventos, defina o seguinte no arquivo de configuração do Salt Master Plugin:
```
event_return_queue:2500
event_return_queue_max_seconds:5
```
  O tamanho máximo sugerido da fila de eventos é 2500, conforme indicado. Quando estiver cheia, a fila será descarregada, encaminhando eventos ao retornador de eventos. Um valor mais baixo pode ser uma opção melhor para ambientes menores ou menos movimentados.
  Em alguns casos, o barramento de eventos Salt pode não se ocupar o suficiente para fazer com que a fila atinja regularmente seu tamanho máximo. A configuração event_return_queue_max_seconds fará com que a fila seja descarregada quando seu evento mais antigo for mais antigo do que o valor configurado, independentemente de quantos eventos estejam na fila.
- Ativar e configurar os mecanismos eventqueue e rpcqueue:
  Esses mecanismos descarregam certas comunicações com o SaltStack Config em caminhos de código essenciais ao desempenho para processos dedicados. Enquanto os mecanismos estão esperando para se comunicar com o SaltStack 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 SaltStack Config nos caminhos de código mais sensíveis ao desempenho.
Reinicie o serviço do mestre.
```
sudo systemctl restart salt-master
```
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.

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
```
No SaltStack 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.

Observação: 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):
1. <mestre salt antigo> endereço IP/FQDN
2. <novo mestre salt> endereço IP/FQDN
3. 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_mastersno 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 SaltStack 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 SaltStack Config

Nesse caso de uso, seus arquivos SaltStack Config são armazenados no banco de dados Postgres e aparecem na UI do SaltStack 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 SaltStack 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 SaltStack 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 e /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