Migrar aplicativos JBoss EAP para o Red Hat OpenShift no Azure

  • Artigo

Este guia descreve o que você deve saber quando deseja migrar um aplicativo JBoss EAP existente a ser executado em Red Hat OpenShift no Azure.

Pré-migração

Antes de tudo, para garantir uma migração bem-sucedida, conclua as etapas de avaliação e de inventário descritas nas seções a seguir.

Verifique se o destino é o adequado para o esforço de migração

A primeira etapa em uma migração bem-sucedida de um aplicativo JBoss EAP para o Azure é selecionar o destino de migração mais adequado. O JBoss EAP é executado bem em máquinas virtuais (VMs) do Azure ou no Red Hat OpenShift no Azure.

O destino da VM é a escolha mais fácil, pois se assemelha mais a uma implantação local. A experiência administrativa e de implantação para máquinas virtuais é parecida com a que você tem no local. A seleção de VMs permite adiar a modernização.

O Red Hat OpenShift reúne serviços testados e confiáveis para reduzir os conflitos relacionados a desenvolvimento, modernização, implantação, execução e gerenciamento de aplicativos. O Red Hat OpenShift no Azure é baseado no Kubernetes. O Red Hat OpenShift no Azure oferece uma experiência sólida em arquiteturas de nuvem pública, locais, de nuvem híbrida ou de borda.

Se minimizar as mudanças é o fator mais importante para o esforço de migração, considere uma migração baseada em VM. Nesse caso, consulte Migrar aplicativos JBoss EAP para JBoss EAP em VMs do Azure. Se você puder tolerar a conversão de seu aplicativo para ser executado no Red Hat OpenShift para reduzir o custo do runtime, considere uma migração baseada no Red Hat OpenShift no Azure. Nesse caso, continue com Migrar aplicativos JBoss EAP para JBoss EAP no Red Hat OpenShift no Azure. Para entender as diferenças entre o JBoss EAP e o JBoss EAP para OpenShift, consulte Comparação: JBoss EAP e JBoss EAP para OpenShift.

Determinar se a oferta predefinida do Azure Marketplace é um bom ponto de partida

Primeiro, decida se o Red Hat OpenShift no Azure é o destino de implantação apropriado. Em seguida, decida se a oferta do Azure Marketplace predefinida é ou não um bom ponto de partida. Considere os seguintes pontos sobre a oferta predefinida do Azure Marketplace:

  • A Red Hat e a Microsoft criaram essa oferta para habilitar o provisionamento rápido do JBoss EAP no Red Hat OpenShift no Azure.
  • Em um alto nível, a oferta automatiza as etapas a seguir para você.
    • Instale o operador EAP no Red Hat OpenShift no Azure.
    • Crie uma imagem de aplicativo usando o modelo eap-s2i-build. Para obter mais informações sobre Source-to-image (S2I), consulte Usando o Source-to-Image do OpenJDK 11 para OpenShift.
    • Implante o aplicativo Java usando o operador EAP. Para obter mais informações, consulte a documentação de referência do Operador EAP na Red Hat.

Se você não usar a oferta predefinida do Azure Marketplace, deverá aprender a usar o Operador EAP diretamente. Dominar o operador está além do escopo deste artigo. A documentação completa do Operador EAP está disponível na Red Hat.

O restante desta seção fornece algumas considerações para você decidir usar a oferta predefinida do Azure Marketplace ou o operador diretamente.

Determinar se a versão do JBoss EAP é compatível

Sua versão do JBoss EAP existente deve ser uma das versões compatíveis com o operador. Para obter mais informações, consulte Compatibilidade e suporte de versão na documentação da Red Hat.

Inventariar a capacidade do servidor

Documente o hardware (memória, CPU, disco) dos servidores de produção atuais, assim como as contagens de solicitações média e de pico e a utilização de recursos. Você precisa dessas informações independentemente do caminho de migração que escolher. Os seguintes aspectos, e outros, se beneficiam de ter um inventário detalhado da capacidade do servidor.

  • Para ajudar a orientar a seleção do tamanho das VMs em seu pool de nós.
  • Para entender a quantidade de memória a ser usada pelo contêiner.
  • Para saber de quantos compartilhamentos de CPU o contêiner precisa.

É possível redimensionar pools de nós no Red Hat OpenShift no Azure. Para obter mais informações, consulte Redimensionando um cluster – Microsoft Azure na documentação da Red Hat.

Inventariar todos os segredos

Antes do advento das tecnologias de "configuração como serviço", como o Azure Key Vault, não havia um conceito bem definido de "segredos". Em vez disso, você tinha um conjunto distinto de definições de configuração que funcionavam efetivamente como aquilo que agora chamamos de "segredos". Com servidores de aplicativos como o JBoss EAP, esses segredos estão em muitos arquivos de configuração e repositórios de configuração diferentes. Verifique todas as propriedades e os arquivos de configuração nos servidores de produção em busca de segredos e senhas. Verifique arquivos de configuração como custom-config.xml ou jboss-web.xml em seus aplicativos. Arquivos de configuração que contenham senhas ou credenciais também podem ser encontrados dentro de seu aplicativo. Para saber mais, consulte Conceitos básicos do Azure Key Vault.

Quando você tiver um inventário sólido de segredos, veja a documentação do Operador EAP sobre segredos. Para obter mais informações, confira Como criar um segredo na documentação da Red Hat.

Inventariar todos os certificados

Documente todos os certificados usados para pontos de extremidade SSL públicos. Você pode exibir todos os certificados nos servidores de produção executando o seguinte comando:

keytool -list -v -keystore <path to keystore>

Depois de ter um inventário sólido de certificados, você poderá configurá-los no Red Hat OpenShift no Azure. Para obter mais informações, consulte Configuração de TLS no OpenShift Container Platform(replace) na documentação da Red Hat.

Validar se a versão Java com suporte funciona corretamente

Todos os caminhos de migração do JBoss EAP para o Red Hat OpenShift no Azure exigem uma versão específica do Java, que varia para cada caminho. Você precisa validar que seu aplicativo pode ser executado corretamente usando essa versão com suporte.

Observação

Essa validação é especialmente importante se o servidor atual estiver sendo executado em um JDK não compatível (como Oracle JDK ou IBM OpenJ9).

Para determinar a sua versão atual do Java, entre no servidor de produção e execute o seguinte comando:

java -version

Inventariar recursos de JNDI

Faça um inventário de todos os recursos de JNDI. Por exemplo, fontes de dados como bancos de dados podem ter um nome JNDI associado que permite que o JPA associe corretamente instâncias de EntityManager a um banco de dados específico. Para obter mais informações sobre recursos e bancos de dados JNDI, consulte Gerenciamento de fonte de dados na documentação da Red Hat. Outros recursos relacionados a JNDI, como agentes de mensagens ActiveMQ Artemis, podem exigir migração ou reconfiguração. Para obter mais informações sobre a configuração do ActiveMQ Artemis, consulte Configurando o sistema de mensagens na documentação da Red Hat.

Determinar se a replicação de sessão é usada

Se seu aplicativo depender da replicação de sessão, com ou sem o Infinispan, você terá três opções:

  • O Infinispan funciona bem em máquinas virtuais do Azure, mas se você estiver usando um perfil que fornece recursos de alta disponibilidade, lembre-se da configuração do JGroups. Determine se o sistema está operando como um domínio gerenciado ou um servidor autônomo.
    • Se estiver em um domínio gerenciado, os perfis ha ou full-ha lidam com JGroups.
    • Se estiver em um servidor independente, os arquivos de configuração standalone-ha.xml ou standalone-full-ha.xml lidam com JGroups.
    • O Microsoft Azure não oferece suporte para protocolos de descoberta de JGroups baseados em multicast UDP. Para obter mais informações, consulte Usando a alta disponibilidade do JBoss EAP no Microsoft Azure na documentação da Red Hat.
  • Refatore seu aplicativo para usar um banco de dados para gerenciamento de sessão.
  • Refatore seu aplicativo para externalizar a sessão para o serviço Redis do Azure. Para obter mais informações, consulte Azure Cache for Redis.

Para todas essas opções, é uma boa ideia saber como o JBoss EAP faz a replicação de estado de sessão HTTP. Para obter mais informações, consulte Sobre a replicação de sessão HTTP na documentação da Red Hat.

Documentar fontes de dados

Se seu aplicativo usar algum banco de dados, você precisará capturar as informações a seguir:

  • Qual é o nome da fonte de dados?
  • Qual é a configuração do pool de conexões?
  • Onde posso encontrar o arquivo JAR do driver JDBC?

Para obter mais informações sobre drivers JDBC no JBoss EAP, consulte Gerenciamento de fonte de dados na documentação da Red Hat.

Determinar se o JBoss EAP foi personalizado

Determine quais das personalizações a seguir foram feitas e capture o que foi feito.

  • Os scripts de inicialização foram alterados? Esses scripts incluem host, eap_env, autônomo e domínio.
  • Parâmetros específicos foram passados para a JVM?
  • JARs foram adicionados ao classpath do servidor?

Essas personalizações precisam ser capturadas na imagem de contêiner em execução no Red Hat OpenShift no Azure. Para obter mais informações, consulte Configurando o JBoss EAP para a imagem do OpenShift para seu aplicativo Java na documentação da Red Hat.

Determinar se uma conexão com o local é necessária

Se seu aplicativo precisar acessar qualquer um dos seus serviços locais, você precisará provisionar um dos serviços de conectividade do Azure. Para obter mais informações, consulte Conectar uma rede local ao Azure. Como alternativa, você precisará refatorar seu aplicativo para usar APIs disponíveis publicamente que seus recursos locais expõem.

Determinar se as Filas ou os Tópicos do JMS (Java Message Service) estão em uso

Se seu aplicativo estiver usando Filas ou Tópicos do JMS, você talvez queira migrá-los para um servidor do JMS hospedado externamente. O Barramento de Serviço do Azure e o Advanced Message Queuing Protocol podem ser uma excelente estratégia de migração para pessoas que usam JMS. Para obter mais informações, confira Usar o Java Message Service 1.1 com o padrão de Barramento de Serviço do Azure e o AMQP 1.0.

Se os armazenamentos persistentes JMS tiverem sido configurados, você deverá capturar a configuração deles e aplicá-la após a migração.

Para obter mais informações, consulte Configurando mensagens na documentação da Red Hat.

Determinar se você está usando suas próprias bibliotecas Java EE compartilhadas personalizadas criadas

Se você estiver usando o recurso de biblioteca Java EE compartilhada, terá duas opções:

  • Refatore o código do aplicativo para remover todas as dependências em suas bibliotecas e incorporar a funcionalidade diretamente ao seu aplicativo.
  • Adicione as bibliotecas ao classpath do servidor.

Você pode manipular essas bibliotecas usando as mesmas técnicas descritas na seção Determinar se o JBoss EAP foi personalizado.

Determinar se o aplicativo contém código específico do sistema operacional

Se seu aplicativo contiver qualquer código com dependências do sistema operacional do host, você precisará refatorá-lo para remover essas dependências. Por exemplo, talvez seja necessário substituir qualquer uso de / ou \ em caminhos do sistema de arquivos com File.Separator ou Paths.get se o aplicativo estiver em execução no Windows.

O Red Hat OpenShift no Azure é executado no OpenShift 4 usando RHCOS (Red Hat Enterprise Linux CoreOS) como o sistema operacional para todos os nós de trabalho e do painel de controle. Qualquer código específico do sistema operacional deve ser compatível com RHCOS.

Determinar se seu aplicativo é composto por vários WARs

Se seu aplicativo for composto por vários WARs, você deverá tratar cada um desses WARs como aplicativos separados e consultar este guia para cada um deles.

Determinar se seu aplicativo está empacotado como um EAR

Se o aplicativo estiver empacotado como um arquivo EAR, capture as configurações.

Identificar todos os processos e daemons externos em execução nos servidores de produção

Se você tiver processos em execução fora do servidor de aplicativos, como daemons de monitoramento, precisará eliminá-los ou migrá-los para outro lugar.

Conta para requisitos de balanceamento de carga

A melhor maneira de considerar o balanceamento de carga é usar a integração do Gateway de Aplicativo. Para saber mais, confira O que é o Gateway de Aplicativo do Azure?

Migração

As etapas nesta seção pressupõem que sua análise levou você a optar pela oferta predefinida do Azure Marketplace.

Provisionar a oferta

Para abrir a oferta no portal do Azure, consulte JBoss EAP no Red Hat OpenShift no Azure. Selecione Criar e siga as instruções na oferta.

Migrando seus aplicativos

A oferta suporta o processo Source-to-Image (S2I) para criar e executar um aplicativo Java na imagem JBoss EAP para OpenShift. A Red Hat tem um exemplo que mostra como fazer isso manualmente se você quiser implantar mais tarde por conta própria. Para obter mais informações, consulte o Capítulo 2. Criar e executar um aplicativo Java no JBoss EAP para imagem do OpenShift na documentação da Red Hat.

Pós-migração

Depois de atingir as metas de migração que você definiu na etapa de pré-migração, execute um teste de aceitação de ponta a ponta para verificar se tudo funciona conforme o esperado. Para obter informações sobre alguns possíveis aprimoramentos pós-migração, consulte os seguintes artigos: