Migrar aplicativos JBoss EAP para o Azure Red Hat OpenShift

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

Pré-migração

Para garantir uma migração bem-sucedida, antes de começar, conclua as etapas de avaliação e inventário descritas nas seções a seguir.

Certifique-se de que o destino é o destino apropriado para o seu 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 apropriado. O JBoss EAP funciona bem em máquinas virtuais (VMs) do Azure ou no Azure Red Hat OpenShift.

O destino da VM é a escolha mais fácil, porque se assemelha mais a uma implantação local. A experiência administrativa e de implantação para máquinas virtuais é análoga à 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 o atrito do desenvolvimento, modernização, implantação, execução e gerenciamento de aplicativos. O Azure Red Hat OpenShift foi criado no Kubernetes. O Azure Red Hat OpenShift oferece uma experiência consistente em nuvem pública, local, nuvem híbrida ou arquitetura de borda.

Se minimizar as alterações for o fator mais importante para seu 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 execução no Red Hat OpenShift para reduzir o custo de tempo de execução, considere uma migração baseada no Azure Red Hat OpenShift. Nesse caso, continue com Migrar aplicativos JBoss EAP para JBoss EAP no Azure Red Hat OpenShift. Para entender as diferenças entre JBoss EAP e JBoss EAP para OpenShift, consulte Comparação: JBoss EAP e JBoss EAP para OpenShift.

Determinar se a oferta pré-criada do Azure Marketplace é um bom ponto de partida

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

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

Se você não usar a oferta pré-criada 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 para o Operador EAP está disponível em Red Hat.

O restante desta seção fornece algumas considerações para decidir usar a oferta pré-criada do Azure Marketplace ou usar o operador diretamente.

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

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

Fazer o inventário da capacidade do servidor

Documente o hardware (memória, CPU, disco) do(s) servidor(es) de produção atual e as contagens médias e de pico de solicitações e a utilização de recursos. Você precisa dessas informações independentemente do caminho de migração escolhido. Os seguintes aspetos, e muito mais, se beneficiam de ter um inventário detalhado da capacidade do servidor.

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

É possível redimensionar pools de nós no Azure Red Hat OpenShift. 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, tínhamos um conjunto díspar de definições de configuração que, efetivamente, funcionavam como aquilo a que hoje chamamos "segredos". Com servidores de aplicativos como o JBoss EAP, esses segredos estão em muitos arquivos de configuração e armazenamentos de configuração diferentes. Procure segredos e palavras-passe nas propriedades e nos ficheiros de configuração do servidor ou servidores de produção. Certifique-se de verificar arquivos de configuração como custom-config.xml ou jboss-web.xml em seus aplicativos. Também poderá encontrar ficheiros de configuração com palavras-passe ou credenciais dentro da aplicação. Para obter mais informações, veja Conceitos básicos do Azure Key Vault.

Depois de ter um inventário sólido de segredos, consulte a documentação do Operador EAP sobre segredos. Para obter mais informações, consulte Criando um segredo na documentação da Red Hat.

Inventariar todos os certificados

Documente todos os certificados utilizados para os pontos finais SSL públicos. Pode ver todos os certificados no servidor ou servidores de produção com o comando seguinte:

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

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

Verificar se a versão de Java suportada funciona corretamente

Todos os caminhos de migração do JBoss EAP para o Azure Red Hat OpenShift exigem uma versão específica do Java, que varia para cada caminho. Você precisa validar se seu aplicativo é capaz de executar corretamente usando essa versão suportada.

Nota

Esta validação é particularmente importante se o seu servidor atual estiver a ser executado num JDK não suportado (como Oracle JDK ou IBM OpenJ9).

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

java -version

Inventariar recursos do JNDI

Inventariar todos os recursos do JNDI. Por exemplo, as origens de dados como as bases de dados podem ter associado um nome do JNDI que permite que o JPA vincule corretamente instâncias de EntityManager a uma base de dados específica. 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 mensagens na documentação da Red Hat.

Determinar se é utilizada a replicação de sessões

Se seu aplicativo depende da replicação de sessão, com ou sem Infinispan, você tem 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, esteja ciente da configuração JGroups. Determine se o sistema está operando como um domínio gerenciado ou servidor autônomo.
    • Se estiver em um domínio gerenciado, os perfis ha ou full-ha lidam com JGroups.
    • Se estiver em um servidor autônomo, os arquivos de configuração standalone-ha.xml ou standalone-full-ha.xml lidam com JGroups.
    • O Microsoft Azure não suporta protocolos de descoberta 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.
  • Refatorize a sua aplicação para utilizar uma base de dados para a gestão de sessões.
  • Refatorize a sua aplicação para externalizar a sessão para o Serviço de Redis do Azure. Para obter mais informações, veja Azure Cache for Redis (Cache do Azure para Redis).

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

Documentar origens de dados

Se a sua aplicação utilizar bases de dados, terá de recolher as seguintes informações:

  • Qual é o nome da origem de dados?
  • Qual é a configuração do conjunto de ligações?
  • Onde posso obter o ficheiro JAR do controlador 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 seguintes personalizações foram feitas e capture as que o foram.

  • Os scripts de arranque foram alterados? Esses scripts incluem host, eap_env, autônomo e domínio.
  • São transmitidos parâmetros específicos para a JVM?
  • Foram adicionados JARs ao classpath do servidor?

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

Determinar se é necessária uma ligação ao local

Se a sua aplicação precisar de aceder a um dos seus serviços no local, tem de aprovisionar um dos serviços de conectividade do Azure. Para obter mais informações, veja como Escolher uma solução para ligar uma rede no local ao Azure. Em alternativa, tem de refatorizar a aplicação para utilizar as APIs publicamente disponíveis que os seus recursos no local expõem.

Determinar se os Tópicos ou Filas do Java Message Service (JMS) estão a ser utilizados

Se seu aplicativo estiver usando Filas ou Tópicos JMS, convém migrá-los para um servidor JMS hospedado externamente. O Azure Service Bus e o protocolo AMQP (Advance Message Queueing Protocol) podem ser uma excelente estratégia de migração para quem utiliza o JMS. Para obter mais informações, veja Utilizar o JMS com o Azure Service Bus e o AMQP 1.0.

Se tiverem sido configurados arquivos persistentes do JMS, tem de capturar a respetiva configuração e aplicá-la após a migração.

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

Determinar se está a utilizar bibliotecas Shared Java EE criadas e personalizadas por si.

Se utilizar a funcionalidade de biblioteca Shared Java EE, tem duas opções:

  • Refatorizar o código da aplicação para remover todas as dependências nas bibliotecas e, ao invés, incorporar a funcionalidade diretamente na aplicação.
  • Adicionar 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 a aplicação contem código de SO específico

Se a sua aplicação contiver código com dependências no SO anfitrião, terá de a refatorizar para remover essas dependências. Por exemplo, poderá ter de substituir qualquer utilização de / ou \ em caminhos do sistema de ficheiros por File.Separator ou Paths.get.

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

Determinar se a sua aplicação é composta por vários WARs

Se a sua aplicação for composta por vários WARs, deve tratar cada um desses WARs como aplicações separadas e seguir este guia para cada qual individualmente.

Determinar se a sua aplicação está empacotada como EAR

Se o seu aplicativo for empacotado como um arquivo EAR, certifique-se de capturar suas configurações.

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

Se tiver processos em execução fora do servidor de aplicações, como daemons de monitorização, terá de eliminar ou migrá-los para outro local.

Conta para requisitos de balanceamento de carga

A melhor maneira de contabilizar o balanceamento de carga é usar a integração do App Gateway. Para obter mais informações, consulte O que é o Azure Application Gateway?

Migração

As etapas nesta seção pressupõem que sua análise o levou a decidir usar a oferta pré-criada do Azure Marketplace.

Aprovisionar a oferta

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

Migrando seus aplicativos

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

Pós-migração

Após alcançar os objetivos de migração que definiu no passo de pré-migração, realize alguns testes de aceitação ponto a ponto para verificar se tudo está a funcionar conforme o esperado. Para obter informações sobre alguns possíveis aprimoramentos pós-migração, consulte os seguintes artigos: