Compartilhar via

Migrar aplicativos WebLogic Server para o JBoss EAP no Serviço de Aplicativo do Azure

  • Artigo

Este guia descreve as informações das quais você deve estar ciente quando deseja migrar um aplicativo WebLogic Server existente para ser executado no Serviço de Aplicativo do Azure usando o JBoss EAP.

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.

Se você não atender a nenhum desses requisitos de pré-migração, consulte o guia de migração complementar para migrar seus aplicativos para Máquinas Virtuais: Migrar aplicativos do WebLogic Server para Máquinas Virtuais do Azure

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ê precisará dessas informações independentemente do caminho de migração que escolher. É útil, por exemplo, para orientar a seleção do Plano do Serviço de Aplicativo.

A lista de camadas disponíveis do Plano do Serviço de Aplicativo mostra as informações sobre memória, núcleos de CPU, armazenamento e preços. Observe que o JBoss EAP no Serviço de Aplicativo está disponível somente nas camadas do Plano do Serviço de Aplicativo Premium V3 e Isolated V2.

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 WebLogic Server, 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. Não se esqueça de verificar o weblogic.xml em seus WARs. 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.

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>

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 os recursos e bancos de dados de JNDI, consulte Fontes de dados do WebLogic Server na documentação da Oracle. Outros recursos relacionados a JNDI, como agentes de mensagens JMS, podem exigir migração ou reconfiguração. Para obter mais informações sobre a configuração do JMS, confira Oracle WebLogic Server 12.2.1.4.0.

Inspecionar a configuração de domínio

A unidade de configuração principal no WebLogic Server é o domínio. Portanto, o arquivo config.xml contém uma infinidade de configurações que você precisa considerar cuidadosamente para a migração. O arquivo inclui referências a arquivos XML adicionais que são armazenados em subdiretórios. A Oracle recomenda que você use normalmente o Console de Administração para configurar os objetos e os serviços gerenciáveis do WebLogic Server e permitir que o WebLogic Server mantenha o arquivo config.xml. Para saber mais, consulte Arquivos de configuração de domínio.

Dentro de seu aplicativo

Inspecione o arquivo WEB-INF/weblogic.xml e/ou o arquivo WEB-INF/web.xml.

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

Se seu aplicativo depender da replicação de sessão, com ou sem o Oracle Coherence*Web, você terá duas opções:

  • 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 WebLogic faz a replicação de estado de sessão HTTP. Para obter mais informações, consulte Replicação de estado de sessão HTTP na documentação da Oracle.

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 saber mais sobre drivers JDBC no WebLogic, consulte Usando drivers JDBC com o WebLogic Server.

Determinar se o WebLogic 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 setDomainEnv, commEnv, startWebLogic e stopWebLogic.
  • Parâmetros específicos foram passados para a JVM?
  • JARs foram adicionados ao classpath do servidor?

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ê precisará migrá-los para um servidor do JMS hospedado externamente. O Barramento de Serviço do Azure e o AMQP (Advanced Message Queuing Protocol) podem ser uma excelente estratégia de migração para pessoas que usam o 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.

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.

Determinar se pacotes OSGi são usados

Se você usou pacotes OSGi adicionados ao WebLogic Server, precisará adicionar os arquivos JAR equivalentes diretamente ao seu aplicativo Web.

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.

Determinar se o Barramento de Serviço da Oracle está em uso

Se seu aplicativo estiver usando o OSB (Barramento de Serviço do Oracle), você precisará capturar como o OSB está configurado. Para saber mais, consulte Sobre a instalação do Barramento de Serviço da Oracle.

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 seu aplicativo estiver empacotado como um arquivo EAR, examine os arquivos application.xml e weblogic-application.xml e capture as configurações deles.

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.

Validar se a versão Java com suporte funciona corretamente

O JBoss EAP no Serviço de Aplicativo do Azure dá suporte a Java 8 e 11. Portanto, você precisará validar se seu aplicativo pode ser executado corretamente usando essa versão com suporte. Essa validação será especialmente importante se o servidor atual estiver usando um JDK 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

Determinar se o aplicativo depende de trabalhos agendados

Os trabalhos agendados, como tarefas do Agendador do Quartz ou trabalhos cron do UNIX, NÃO devem ser usados com o Serviço de Aplicativo do Azure. O Serviço de Aplicativo do Azure não impedirá que você implante um aplicativo que contenha tarefas agendadas internamente. No entanto, se o aplicativo for escalado horizontalmente, um mesmo trabalho agendado poderá ser executado mais de uma vez por período agendado. Essa situação pode levar a consequências indesejadas.

Para executar trabalhos agendados no Azure, considere a possibilidade de usar o Azure Functions com um gatilho de temporizador. Para mais informações, consulte Gatilho de temporizador para o Azure Functions. Você não precisa migrar o código do trabalho propriamente dito para uma função. A função pode simplesmente invocar uma URL no aplicativo para disparar o trabalho.

Observação

Para evitar o uso mal-intencionado, você provavelmente precisará garantir que o ponto de extremidade de invocação do trabalho exija credenciais. Nesse caso, a função de gatilho precisará fornecer as credenciais.

Determinar se a WLST (WebLogic Scripting Tool) é usada

Se você usar a WLST para realizar a implantação atualmente, precisará avaliar o que ela está fazendo. Se a WLST estiver alterando parâmetros (runtime) do seu aplicativo como parte da implantação, você precisará verificar se esses parâmetros estão em conformidade com uma das seguintes opções:

  • Eles são externalizados como configurações do aplicativo.
  • Eles são inseridos em seu aplicativo.
  • Eles estão usando a CLI do JBoss durante a implantação.

Se a WLST estiver fazendo mais do que o mencionado acima, você terá que realizar um trabalho adicional durante a migração.

Determinar se seu aplicativo usa APIs específicas do WebLogic

Se o aplicativo usar APIs específicas do WebLogic, você precisará refatorar o aplicativo para NÃO usá-las. Por exemplo, se você usou uma classe mencionada na Referência de API Java para o Oracle WebLogic Server, você usou uma API específica do WebLogic em seu aplicativo. O Kit de Ferramentas de Migração para Aplicativos do Red Hat pode ajudar a remover e refatorar essas dependências.

Determinar se o aplicativo usa Beans de Entidade ou Beans CMP com estilo EJB 2.x

Se o aplicativo usar Beans de Entidade ou Beans CMP com estilo EJB 2.x, você precisará refatorá-lo para NÃO usá-los.

Determinar se o recurso Cliente do aplicativo Java EE é usado

Se tiver aplicativos cliente que se conectam ao seu aplicativo (servidor) usando o recurso Cliente do Aplicativo Java EE, você precisará refatorar os aplicativos cliente e seu aplicativo (servidor) para usar APIs HTTP.

Determinar se um plano de implantação foi usado

Se um plano de implantação tiver sido usada para fazer a implantação, você precisará avaliar o que o plano de implantação está fazendo. Se o plano de implantação for uma implantação direta, então você poderá implantar seu aplicativo Web sem nenhuma alteração. Se o plano de implantação for mais elaborado, você precisará determinar se pode usar a CLI do JBoss para configurar adequadamente seu aplicativo como parte da implantação. Se não for possível usar a CLI do JBoss, você precisará refatorar seu aplicativo de modo que um plano de implantação não seja mais necessário.

Determinar se temporizadores EJB estão sendo usados

Se seu aplicativo usar temporizadores EJB, você precisará validar que o código do temporizador EJB pode ser disparado por cada instância do JBoss EAP de maneira independente. Essa validação é necessária porque, quando o Serviço de Aplicativo é expandido horizontalmente, cada temporizador EJB é disparado em sua própria instância do JBoss EAP.

Validar se e como o sistema de arquivos é usado

Qualquer uso do sistema de arquivos no servidor de aplicativos exigirá reconfiguração ou, em casos raros, alterações de arquitetura. O sistema de arquivos pode ser usado por módulos compartilhados do WebLogic ou pelo código do aplicativo. Você pode identificar alguns ou todos os cenários a seguir.

Conteúdo estático somente leitura

Se o aplicativo atualmente fornece conteúdo estático, será necessário um local alternativo para esse conteúdo estático. Talvez você queira considerar a migração de conteúdo estático para o Armazenamento de Blobs do Azure e a adição da CDN do Azure para downloads extremamente rápidos, globalmente.

Conteúdo estático publicado dinamicamente

Se o aplicativo permitir conteúdo estático que é carregado/produzido pelo aplicativo, mas não puder ser alterado após sua criação, você poderá usar o Armazenamento de Blobs do Azure e a CDN do Azure, conforme descrito acima, com uma Função do Azure para lidar com uploads e atualização de CDN. Fornecemos uma implementação de exemplo para seu uso.

Conteúdo dinâmico ou interno

Para arquivos que são frequentemente escritos e lidos pelo aplicativo (como arquivos de dados temporários) ou arquivos estáticos que são visíveis somente para o aplicativo, o Azure Storage pode ser montado no sistema de arquivos do Serviço de Aplicativo.

Determinar se conectores JCA são usados

Se seu aplicativo usar conectores JCA, você precisará validar se o conector JCA pode ser usado no JBoss EAP. Se a implementação do JCA estiver vinculada ao WebLogic, você precisará refatorar seu aplicativo para NÃO usar o conector JCA. Se puder ser usado, você precisará adicionar os JARs ao classpath do servidor e colocar os arquivos de configuração necessários no local correto nos diretórios do servidor do JBoss EAP para que ele esteja disponível.

Determinar se seu aplicativo usa um Adaptador de Recurso

Se o aplicativo precisar de um RA (Adaptador de Recurso), ele precisará ser compatível com o JBoss EAP. Determine se o RA funciona bem em uma instância autônoma do JBoss EAP implantando-o no servidor e configurando-o corretamente. Se o RA funcionar corretamente, você precisará adicionar os JARs ao classpath do servidor da instância do Serviço de Aplicativo e colocar os arquivos de configuração necessários no local correto nos diretórios do servidor do JBoss EAP para que ele fique disponível.

Determinar se o JAAS é usado

Se o aplicativo estiver usando o JAAS, você precisará capturar como o JAAS está configurado. Se estiver usando um banco de dados, você poderá convertê-lo em um domínio JAAS no JBoss EAP. Caso se trate de uma implementação personalizada, será necessário validar que ela pode ser usada no JBoss EAP.

Determinar se o clustering do WebLogic é usado

É provável que você tenha implantado seu aplicativo em vários WebLogic Servers para conseguir alta disponibilidade. O Serviço de Aplicativo do Azure é capaz de escalar, mas se você tiver usado a API de Cluster do WebLogic, precisará refatorar seu código para eliminar o uso dessa API.

Migração

Kit de Ferramentas de Migração para Aplicativos do Red Hat

O Kit de Ferramentas de Migração para Aplicativos do Red Hat é uma extensão gratuita para o Visual Studio Code. Essa extensão analisa o código e a configuração do aplicativo para fornecer recomendações para migrar seus aplicativos Jakarta EE para o JBoss EAP de outros servidores de aplicativos, como remover dependências de APIs proprietárias. A extensão também fornecerá recomendações se você estiver migrando para a nuvem do local. Para obter mais informações, consulte Visão geral do Kit de Ferramentas de Migração para Aplicativos.

O conteúdo deste guia ajudará você a abordar os outros componentes da jornada de migração, como escolher o tipo correto de Plano do Serviço de Aplicativo, externalizar o estado da sessão e usar o Azure para gerenciar as instâncias EAP em vez da interface de Gerenciamento do JBoss.

Provisionar um plano do Serviço de Aplicativo

Na lista de planos de serviço disponíveis, selecione o plano cujas especificações correspondem às especificações do hardware de produção atual ou as superam.

Observação

Se você planeja executar implantações de preparo/canário ou usar slots de implantação, o plano do Serviço de Aplicativo precisará incluir essa capacidade adicional. É recomendável usar planos Premium ou superiores para aplicativos Java.

Crie o plano do Serviço de Aplicativo.

Criar e implantar aplicativos Web

Você precisará criar um aplicativo Web no Plano do Serviço de Aplicativo para cada arquivo WAR implantado em seu servidor JBoss EAP.

Observação

Embora seja possível implantar vários arquivos WAR em um único aplicativo Web, isso é altamente indesejável. Implantar vários arquivos WAR em um único aplicativo Web impede que cada aplicativo seja dimensionado de acordo com suas próprias demandas de uso. Ele também adiciona complexidade a pipelines de implantação subsequentes. Se vários aplicativos precisarem estar disponíveis em uma única URL, considere a possibilidade de usar uma solução de roteamento, como o Gateway de Aplicativo do Azure.

Aplicativos Maven

Se o seu aplicativo for criado com base em um arquivo POM do Maven, use o plug-in do Aplicativo Web para Maven para criar o aplicativo Web e implantar seu aplicativo. Para saber mais, confira a seção Configurar o plug-in do Maven do Início Rápido: Criar um aplicativo Java no Serviço de Aplicativo do Azure.

Aplicativos não Maven

Se não for possível usar o plug-in do Maven, você precisará provisionar o aplicativo Web por meio de outros mecanismos, como:

Depois de criar o aplicativo Web, use um dos mecanismos de implantação disponíveis para implantar o aplicativo. Para obter mais informações, consulte Implantar arquivos no Serviço de Aplicativo.

Migrar opções de runtime da JVM

Se o aplicativo exigir opções específicas de runtime, use o mecanismo mais apropriado para especificá-las. Para saber mais, consulte a seção Definir opções de runtime do Java de Configurar um aplicativo Java para o Serviço de Aplicativo do Azure.

Migrar parâmetros externalizados

Se você precisa usar parâmetros externos, é necessário defini-los como configurações do aplicativo. Para saber mais, confira Definir configurações de aplicativo.

Migrar scripts de inicialização

Se o aplicativo original usou um script de inicialização personalizado, você precisa migrá-lo para um script Bash. Confira mais informações em Personalizar a configuração do servidor de aplicativos.

Popular segredos

Use as Configurações do Aplicativo para armazenar os segredos específicos no aplicativo. Se você pretende usar o mesmo segredo ou segredos entre vários aplicativos ou se você requer funcionalidades de auditoria e políticas de acesso refinadas, use as referências do Azure Key Vault. Para obter mais informações, consulte a seção Usar referências de Key Vault de Configurar um aplicativo Java para o Serviço de Aplicativo do Azure.

Configurar Custom Domain e SSL

Se o aplicativo ficar visível em um domínio personalizado, você precisará mapear seu aplicativo Web para ele. Para obter mais informações, confira Tutorial: Mapear um nome DNS personalizado existente para o Serviço de Aplicativo do Azure.

Em seguida, você precisará associar o certificado TLS/SSL para esse domínio ao seu aplicativo Web do Serviço de Aplicativo. Para obter mais informações, confira Proteger um nome DNS personalizado com uma associação TLS/SSL no Serviço de Aplicativo do Azure.

Migrar fontes de dados, bibliotecas e recursos de JNDI

Para migrar fontes de dados, siga as etapas na seção Configurar fonte de dados em Configurar um aplicativo Java para o Serviço de Aplicativo do Azure.

Migre as dependências de classpath de nível do servidor adicionais seguindo as instruções na seção JBoss EAP de Configurar um aplicativo Java para o Serviço de Aplicativo do Azure.

Migre quaisquer recursos JDNI de nível de servidor compartilhados adicionais. Para obter mais informações, confira a seção JBoss EAP de Configurar um aplicativo Java para o Serviço de Aplicativo do Azure.

Migrar conectores JCA e módulos JAAS

Migre os conectores JCA e módulos JAAS seguindo as instruções em Instalar módulos e dependências.

Observação

Se você estiver seguindo a arquitetura recomendada de um WAR por aplicativo, considere migrar bibliotecas de classpath de nível de servidor e recursos de JNDI para o aplicativo. Fazer isso simplifica significativamente a governança de componentes e o gerenciamento de alterações. Se você quiser implantar mais de um WAR por aplicativo, veja um de nossos guias complementares mencionados no início deste guia.

Migrar os trabalhos agendados

No mínimo, você deve mover seus trabalhos agendados para uma VM do Azure para que eles não façam mais parte do seu aplicativo. Como alternativa, você pode optar por modernizá-los em Java controlado por eventos usando serviços do Azure, como Azure Functions, Banco de Dados SQL e Hubs de Eventos.

Reinicialização e smoke test

Por fim, você precisará reiniciar seu aplicativo Web para aplicar todas as alterações de configuração. Após a conclusão da reinicialização, verifique se o aplicativo está sendo executado corretamente.

Após a migração

Agora que você migrou seu aplicativo para o Serviço de Aplicativo do Azure, verifique se ele funciona conforme o esperado. Depois de fazer isso, temos algumas recomendações que podem tornar seu aplicativo mais nativo da nuvem.

Recomendações