Olá a todos,

Li recentemente um excelente artigo pelo Raul Mahiques no site da SuSE que decidi traduzir para Português, e adicionar a minha experiencia pessoal sobre o tema.
Quem me conhece sabe que SuSE foi um dos meus primeiros amores, e é uma das melhores distribuições disponíveis no mercado e francamente é uma pena que não tenha a projeção que outras distribuições ditas como empresariais possuem.
Embora desprovido de muito conteúdo técnico, este post alavanca de uma forma muito high level um procedimento ou roadmap para que quem deseje possa migrar os seus workloads de Centos/RHEL para Opensuse.

O texto abaixo é da autoria do mesmo e foi publicado com autorização, se mantivesse referencia aos autores originais.

Migrar para um novo sistema operacional geralmente levanta várias questões:

Quais etapas devo seguir para migrar os meus workloads?

1) Identificar as aplicações a serem migradas e suas versões.

Aqui, não me refiro a todos as aplicações instaladas instaladas, mas àqueles que prestam um serviço ou são necessários para nossas ferramentas de operação e automação.

Caso as mesmas versões não estejam disponíveis em ambas as plataformas, podemos testar se a versão existente na nova plataforma é suficiente e na maioria dos casos, será.
Distribuições como RHEL ou SLES esforçam-se para garantir que as atualizações sejam perfeitas e não afetem as aplicações existentes, exigindo muito esforço em correções de erros de backporting para que a segurança não seja uma preocupação, mesmo que seja semelhante a uma versão antiga.

2) Identificar os pacotes no OpenSUSE Leap que fornecem os aplicativos de que precisamos.

Forneceremos todos os detalhes técnicos necessários em próximos posts, embora que em muitos casos, os nomes dos pacotes sejam os mesmos em ambas as plataformas, isso pode nem ser necessário.

Podemos e deveremos utilizar uma tabela semelhante à abaixo para preparar nossa migração:

• A primeira coluna contém o nome do aplicativo, conforme a função e os requisitos do sistema, por exemplo, se tivermos um aplicativo da Web que consiste em um servidor Web front-end e banco de dados back-end, dividiremos em duas linhas, uma para o front-end e outra para o Processo interno.
• A coluna a seguir contém os principais pacotes que precisamos no novo sistema, incluindo suas versões, se necessário especificar.
• Em seguida, o número de servidores que precisamos configurar.
• E por último todos os outros requisitos e notas que precisamos para fazer a migração.

3) Preparar a própria migração

Podemos executar a migração sem tempo de inatividade? A resposta depende da aplicação, mas sempre há métodos para minimizar o tempo de inatividade usando uma configuração temporária (ou permanente se você quiser ter mais resiliência e uma configuração sem preocupações), Ativa-Ativa ou Ativa-Passiva.

Dependendo da importância do serviço, nós podemos decidir se vale a pena investir nesses mecanismos. Examinaremos alguns exemplos disso nos próximos artigos (nota do tradutor – ou em artigos já publicados neste blog)

Lembre-se de que as migrações *são* tediosas e propensas a erros humanos. Esta é a oportunidade perfeita para automatizar.

Automatize a implantação da aplicação no nosso novo sistema operativo (suse),e talvez, o próprio processo de migração para minimizar o tempo de inatividade, especialmente se o esforço for razoável e pudermos reutilizá-lo para outros casos de uso.

Por último, mas não menos importante, não nos podemos esquecçer de incluir uma tarefa para garantir backup (e testar um restore).

4) Prepare o plano de reversão

Podemos usar a configuração anterior se nossa migração não for bem-sucedida na primeira tentativa? É sempre recomendável ter um plano de rollback caso a migração não saia conforme o planeado, mas para isso é importante identificar o que fazer a garantir os nossos serviços em execução caso algo não saia conforme o esperado.
Como podemos manter os dados sincronizados para que possam ser usados ​​em nosso sistema anterior? etc… também é muito importante tentar não misturar atualizações de aplicações em migração, para evitar complicar e introduzir mais variáveis.

Em alguns casos, um quick fix pode ser o caminho, se pensarmos que vai demorar mais para reverter, e nada irreversível precisa ser feito.

De qualquer forma, não queremos problemas e a melhor forma de evitá-los é testando a migração, e o plano de rollback, em um ambiente de desenvolvimento o mais próximo possível do produtivo.

5) Bônus – Teste Automatizado

Para garantir que a nossa aplicação funciona conforme o esperado, esse processo de migração oferece uma ótima oportunidade para começar a criar os nossos novos testes automatizados. Embora não possamos migrar para um novo sistema operativo num futuro próximo, esses testes podem ser benéficos ao atualizar ou implantar novas instâncias das aplicações. Eles são uma boa prática a ser adotada, especialmente se planejamos mover esses serviços para um ambiente Kubernetes ou de escalamento fácil na horizontal num futuro proximo.

Conclusão

Este artigo de blog descreve brevemente algumas das etapas necessárias para migrar de CentOS para o OpenSUSE Leap numa perspectiva mais prática.

A migração do CentOS para  openSUSE traz vários benefícios, incluindo estabilidade, suporte e compromisso do SUSE à comunidade , poderosas ferramentas de gestão de sistema, recursos avançados de distribuição e acesso a um dos mais ricos repositório de pacotes homebrew.
A comunidade openSUSE ativa e as ferramentas de fácil migração aprimoram ainda mais o processo de transição. Se estão á procura uma distribuição Linux robusta e confiável para os seus workloads, considere o openSUSE.

Chegamos ao fim um post diferente, muito necessário hoje em dia, altura em que procuramos alternativas para o problema que a RedHat causou aos sistemas operativos empresariais opensource.

Agradeço novamente ao escritor original do post, peço que perdoe as minhas anotações, e caso exista algo que não concordem, ou tenha feito má referencia, sabem onde me encontrar.

Até para a semana!
Nuno