Partilhar via

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

  • Artigo

Este guia descreve o que 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

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.

Se você não puder 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

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. Independentemente do caminho de migração que escolher, vai precisar destas informações. É útil, por exemplo, para ajudar a 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 a memória, os núcleos da CPU, o armazenamento e as informações de preços. Observe que o JBoss EAP no Serviço de Aplicativo só está disponível nas camadas Premium V3 e Plano de Serviço de Aplicativo Isolado 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, tínhamos um conjunto díspar de definições de configuração que, efetivamente, funcionavam como aquilo a que hoje chamamos "segredos". Com os servidores de aplicações, como o WebLogic Server, esses segredos estão em muitos ficheiros de configuração e arquivos de configuração diferentes. Procure segredos e palavras-passe nas propriedades e nos ficheiros de configuração do servidor ou servidores de produção. Não se esqueça de verificar weblogic.xml nos seus WARs. 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.

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>

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 os recursos do JNDI e as bases de dados, veja WebLogic Server Data Sources (Origens de Dados do WebLogic Server) na documentação da Oracle. Outros recursos não relacionados com o JNDI, como os mediadores de mensagens do JMS, podem exigir migração ou reconfiguração. Para obter mais informações sobre a configuração JMS, consulte Oracle WebLogic Server 12.2.1.4.0.

Inspecione a configuração do seu domínio

A unidade de configuração principal no WebLogic Server é o domínio. Como tal, o ficheiro config.xml contém diversas configurações que tem de considerar cuidadosamente para a migração. O ficheiro inclui referências a ficheiros XML adicionais que são armazenados em subdiretórios. A Oracle recomenda que utilize normalmente a Consola de Administração para configurar os objetos e os serviços geríveis do WebLogic Server e permitir que o WebLogic Server mantenha o ficheiro config.xml. Para obter mais informações, veja Domain Configuration Files (Ficheiros de Configuração de Domínios).

Na aplicação

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

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

Se a sua aplicação depender da replicação de sessões, com ou sem o Oracle Coherence*Web, tem duas opções:

  • 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 estas opções, é recomendável saber como o WebLogic faz a Replicação de Estado de Sessões HTTP. Para obter mais informações, veja HTTP Session State Replication (Replicação de Estado de Sessões HTTP) na documentação da Oracle.

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 os controladores JDBC no WebLogic, veja Using JDBC Drivers with WebLogic Server (Utilizar Controladores JDBC com o WebLogic Server).

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

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 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 a sua aplicação utilizar Filas ou Tópicos do JMS, tem de os migrar para um servidor JMS alojado externamente. O Azure Service Bus e o Advanced Message Queuing Protocol (AMQP) podem ser uma excelente estratégia de migração para quem utiliza o JMS. Para obter mais informações, consulte Usar o Java Message Service 1.1 com o Azure Service Bus Standard e 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.

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.

Determinar se os conjuntos OSGi são utilizados

Se utilizar conjuntos OSGi adicionados ao servidor WebLogic, tem de adicionar os ficheiros JAR equivalentes diretamente à aplicação Web.

Determinar se a aplicação contem código de SO específico

Se seu aplicativo contiver qualquer código com dependências no sistema operacional 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 por File.Separator ou Paths.get se seu aplicativo estiver sendo executado no Windows.

Determinar se o Oracle Service Bus está a ser utilizado

Se a sua aplicação utilizar o Oracle Service Bus (OSB), tem de capturar a forma como este é configurado. Para obter mais informações, veja About the Oracle Service Bus Installation (Sobre a Instalação do Oracle Service Bus).

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 a sua aplicação estiver empacotada como um ficheiro EAR, confirme que examina os ficheiros application.xml e weblogic-application.xml e capture as respetivas 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.

Verificar se a versão de Java suportada funciona corretamente

O JBoss EAP no Serviço de Aplicativo do Azure dá suporte a Java 8 e 11. Assim, será necessário que verifique se é possível executar a sua aplicação corretamente com essa versão suportada. Esta validação é particularmente importante se o seu servidor atual estiver a utilizar um JDK 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

Determinar se a aplicação depende de trabalhos agendados

Trabalhos agendados, como tarefas do Agendador de Quartzo 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 contendo tarefas agendadas internamente. Contudo, se a sua aplicação estiver ampliada, a mesma tarefa agendada pode ser executada mais de uma vez por período agendado. Esta situação pode provocar consequências não intencionais.

Para executar trabalhos agendados no Azure, considere usar o Azure Functions com um Gatilho de Timer. Para obter mais informações, consulte Gatilho de temporizador para o Azure Functions. Não é preciso migrar o código do trabalho para uma função. Esta pode simplesmente invocar um URL na aplicação para acionar o trabalho.

Nota

Para evitar utilizações maliciosas, é provável que tenha de confirmar que o ponto final de invocação dos trabalhos exige credenciais. Nesse caso, a função de acionador terá de fornecer essas credenciais.

Determinar se o WebLogic Scripting Tool (WLST) está a ser utilizado

Se você usa atualmente o WLST para executar a implantação, precisará avaliar o que ele está fazendo. Se o WLST estiver alterando quaisquer parâmetros (de tempo de execução) do seu aplicativo como parte da implantação, você precisará garantir que esses parâmetros estejam em conformidade com uma das seguintes opções:

  • Estão externalizados como definições da aplicação.
  • Estão incorporados na aplicação.
  • Estão a utilizar o JBoss CLI durante a implementação.

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

Determinar se a aplicação utiliza APIs específicas do WebLogic

Se seu aplicativo usa APIs específicas do WebLogic, você precisará refatorar seu aplicativo para NÃO usá-las. Por exemplo, se tiver utilizado uma classe mencionada na Referência da API de Java para o Oracle WebLogic Server, utilizou uma API específica do WebLogic na sua aplicação. O Red Hat Migration Toolkit for Apps pode ajudar a remover e refatorar essas dependências.

Determinar se a aplicação utiliza Entity Beans ou EJB 2.x-style CMP Beans

Se seu aplicativo usa beans de entidade ou beans CMP no estilo EJB 2.x, você precisará refatorar seu aplicativo para NÃO usá-los.

Determinar se a funcionalidade da aplicação cliente Java EE está a ser utilizada

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

Determinar se foi utilizado um plano de implementação

Se um plano de implantação foi usado para executar a implantação, você precisará avaliar o que o plano de implantação está fazendo. Se o plano de implementação for uma implementação direta, poderá implementar a sua aplicação Web sem alterações. Se o plano de implementação for mais elaborado, terá de determinar se pode utilizar o JBoss CLI para configurar corretamente a sua aplicação como parte da implementação. Se não for possível utilizar o JBoss CLI, terá de refatorizar a aplicação de forma a que já não seja necessário um plano de implementação.

Determinar se os temporizadores EJB estão a ser utilizados

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

Validar se e como o sistema de arquivos é usado

Qualquer utilização do sistema de ficheiros no servidor de aplicações irá exigir uma reconfiguração ou, em casos raros, alterações da arquitetura. O sistema de arquivos pode ser usado por módulos compartilhados WebLogic ou pelo código do seu aplicativo. Poderá identificar alguns ou todos os cenários seguintes.

Conteúdo estático só de leitura

Se o seu aplicativo atualmente serve conteúdo estático, um local alternativo para esse conteúdo estático será necessário. Você pode considerar mover conteúdo estático para o Armazenamento de Blobs do Azure e adicionar a CDN do Azure para downloads extremamente rápidos globalmente.

Conteúdo estático publicado dinamicamente

Se a sua aplicação permitir conteúdo estático carregado/produzido pela mesma, mas que é imutável após a criação, pode utilizar o Armazenamento de Blobs do Azure e a CDN do Azure conforme descrito acima, com uma função das Funções do Azure que lide com os carregamentos e as atualizações da CDN. Nós fornecemos uma implementação de exemplo para seu uso.

Conteúdo dinâmico ou interno

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

Determinar se há conectores JCA a ser utilizados

Se o seu aplicativo usa conectores JCA, você terá que validar que o conector JCA pode ser usado no JBoss EAP. Se a implementação JCA estiver vinculada ao WebLogic, você terá que refatorar seu aplicativo para NÃO usar o conector JCA. Se ele 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 JBoss EAP para que ele esteja disponível.

Determinar se a aplicação utiliza um Adaptador de Recursos

Se seu aplicativo precisa de um adaptador de recursos (RA), ele precisa 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 JBoss EAP para que ele esteja disponível.

Determinar se o JAAS é usado

Se seu aplicativo estiver usando 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. Se for uma implementação personalizada, você precisará validar que ela pode ser usada no JBoss EAP.

Determinar se a colocação em clusters do WebLogic é utilizada

O mais provável é que tenha desenvolvido a sua aplicação em múltiplos servidores WebLogic para obter elevada disponibilidade. O Serviço de Aplicativo do Azure é capaz de dimensionar, mas se você tiver usado a API de Cluster WebLogic, precisará refatorar seu código para eliminar o uso dessa API.

Migração

Red Hat Migration Toolkit for Apps

O Red Hat Migration Toolkit for Applications é uma extensão gratuita para o Visual Studio Code. Esta extensão analisa o código e a configuração do aplicativo para fornecer recomendações para migrar seus aplicativos do 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 localmente. Para obter mais informações, consulte Visão geral do Migration Toolkit for Applications.

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 suas instâncias EAP em vez da interface de Gerenciamento JBoss.

Aprovisionar um plano do Serviço de Aplicações

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

Nota

Se planeia executar implementações de teste/proteção ou utilizar blocos de implementação, o plano do Serviço de Aplicações tem de incluir essa capacidade adicional. Recomendamos a utilização de planos Premium ou superiores para aplicações Java.

Crie o plano do Serviço de Aplicações.

Criar e Implementar Aplicações Web

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

Nota

Embora seja possível implementar múltiplos ficheiros WAR numa única aplicação Web, isto é extremamente indesejável. A implementação de múltiplos ficheiros WAR numa única aplicação Web impede que cada aplicação seja dimensionada de acordo com as suas próprias exigências de utilização. Além disso, torna os pipelines de implementação posteriores mais complexos. Se for necessário que múltiplas aplicações estejam disponíveis num único URL, considere utilizar uma solução de encaminhamento, tal como o Gateway de Aplicação do Azure.

Aplicações do Maven

Se a sua aplicação tiver sido criada a partir de um ficheiro POM do Maven, utilize o plug-in de aplicações Web para o Maven para criar a aplicação Web e implementar a sua aplicação. Para obter mais informações, consulte a seção Configurar o plug-in Maven de Guia de início rápido: criar um aplicativo Java no Serviço de Aplicativo do Azure.

Aplicações não pertencentes ao Maven

Se não puder utilizar o plug-in do Maven, terá de aprovisionar a aplicação Web através de outros mecanismos, tais como:

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

Migrar opções de runtime JVM

Se a sua aplicação necessitar de opções específicas de runtime, utilize o mecanismo mais adequado para as especificar. Para obter mais informações, consulte a seção Definir opções de tempo de execução Java de Configurar um aplicativo Java para o Serviço de Aplicativo do Azure.

Migrar parâmetros externalizados

Se você precisar usar parâmetros externos, precisará defini-los como configurações do aplicativo. Para obter mais informações, consulte Definir configurações do aplicativo.

Migrar scripts de inicialização

Se o aplicativo original usava um script de inicialização personalizado, você precisará migrá-lo para um script Bash. Para obter mais informações, consulte Personalizar a configuração do servidor de aplicativos.

Preencher segredos

Utilize as Definições da Aplicação para armazenar segredos específicos da sua aplicação. Se você pretende usar o mesmo segredo ou segredos entre vários aplicativos ou precisa de políticas de acesso refinadas e recursos de auditoria, use as referências do Cofre da Chave do Azure. Para obter mais informações, consulte a seção Usar referências do KeyVault de Configurar um aplicativo Java para o Serviço de Aplicativo do Azure.

Configurar domínio personalizado e SSL

Se a sua aplicação estiver visível num domínio personalizado, tem de mapear a aplicação Web para o mesmo. Para obter mais informações, consulte Tutorial: Mapear um nome DNS personalizado existente para o Serviço de Aplicativo do Azure.

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

Migrar origens de dados, bibliotecas e recursos JNDI

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

Migre quaisquer dependências adicionais de classpath no nível do servidor 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 compartilhados adicionais no nível do servidor. Para obter mais informações, consulte 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 todos os conectores JCA e módulos JAAS seguindo as instruções em Instalar módulos e dependências.

Nota

Se você estiver seguindo a arquitetura recomendada de um WAR por aplicativo, considere migrar bibliotecas de classpath no nível de servidor e recursos JNDI para seu aplicativo. Isso simplificará significativamente a governança de componentes e o gerenciamento de mudanças. Se você quiser implantar mais de um WAR por aplicativo, consulte um de nossos guias complementares mencionados no início deste guia.

Migrar 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.

Reiniciar e efetuar teste de fumo

Por fim, terá de reiniciar a sua aplicação Web para aplicar todas as alterações de configuração. Após a conclusão do reinício, verifique se a sua aplicação está a funcionar corretamente.

Pós-migração

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

Recomendações