Migrar aplicativos do WebLogic Server para Máquinas Virtuais do Azure

  • Artigo

Este guia descreve as noções de que deve estar ciente quando quer migrar uma aplicação WebLogic já existente para a executar em Máquinas Virtuais do Microsoft Azure. Para obter uma visão geral das soluções disponíveis do WebLogic Server no Azure Marketplace, consulte Quais são as soluções para executar o Oracle WebLogic Server em Máquinas Virtuais do Azure?

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.

Definir o que quer dizer com "migração concluída"

Este guia e as Ofertas do Azure Marketplace correspondentes são um ponto de partida para acelerar a migração das suas cargas de trabalho do WebLogic Server para o Azure. É importante definir o âmbito do seu esforço de migração. Por exemplo, está a fazer uma migração estritamente "lift-and-shift" da sua infraestrutura existente para Máquinas Virtuais do Microsoft Azure? Em caso afirmativo, poderá sentir-se tentado a fazer alguma migração "lift-and-improve" à medida que migra.

Contudo, é melhor manter-se o mais próximo possível de uma migração "lift-and-shift" pura, tendo em conta as mudanças necessárias conforme detalhado neste guia. Defina o que quer dizer com "migração concluída" para ficar ciente do momento em que atingiu este marco. Quando atingir o marco "migração concluída", pode criar um instantâneo das suas Máquinas Virtuais conforme descrito em Criar um instantâneo. Depois de verificar que é possível restaurar com êxito a partir do snapshot, você pode fazer as melhorias sem medo de perder o progresso da migração alcançado até agora.

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 WLS para o Azure é selecionar o destino de migração mais apropriado. O WLS funciona bem em máquinas virtuais (VMs) do Azure ou no Serviço Kubernetes do Azure (AKS). 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 é muito análoga à que você tem no local. A contrapartida para essa facilidade é o custo econômico. De um modo geral, o custo por minuto para uma solução baseada em VM é maior em comparação com o AKS. Embora uma solução baseada em AKS custe menos para ser executada, você deve restringir seu aplicativo para se adequar aos requisitos do AKS. 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 WebLogic para máquinas virtuais do Azure. Se você puder tolerar a conversão de seu aplicativo para execução no Kubernetes para reduzir o custo de tempo de execução, considere uma migração baseada em AKS. Nesse caso, continue com Migrar aplicativos do WebLogic Server para o Serviço Kubernetes do Azure.

Determine se as ofertas pré-criadas do Azure Marketplace são um bom ponto de partida

A Oracle e a Microsoft estabeleceram uma parceria para trazer um conjunto de modelos de solução do Azure para o Azure Marketplace para fornecer um ponto de partida sólido para a migração para o Azure. Consulte a documentação do Oracle Fusion Middleware para ver a lista de ofertas e escolher a que mais bem corresponde à sua implementação existente. Você pode ver a lista de ofertas no artigo de visão geral O que é o Oracle WebLogic Server no Azure?

Se nenhuma das ofertas existentes for um bom ponto de partida, você precisará reproduzir a implantação manualmente usando os recursos da Máquina Virtual do Azure. Você pode encontrar a orientação passo a passo em Instalar o Oracle WebLogic Server em Máquinas Virtuais do Azure manualmente. Para obter mais informações, consulte O que é IaaS?

Determinar se a versão do WebLogic é compatível

A sua versão do WebLogic tem de ser compatível com a versão nas ofertas IaaS. Para ver as ofertas do WebLogic versão 12.2.1.4, consulte o Azure Marketplace for Oracle WebLogic 12.2.1.4. Se sua versão existente do WebLogic não for compatível com essa versão, você precisará reproduzir a implantação manualmente usando recursos de IaaS do Azure. Para obter mais informações, consulte a documentação do Azure.

Fazer o inventário da capacidade do servidor

Documente o hardware (memória, CPU, disco) dos servidores de produção atuais, bem como as contagens médias e máximas de pedidos e utilização de recursos. Estas informações têm de influenciar a escolha do tamanho das VMs. Para obter mais informações, veja Tamanhos para Serviços Cloud.

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>

Verificar se a versão de Java suportada funciona corretamente

Todos os caminhos de migração do WebLogic para o Azure requerem uma versão de Java específica, que varia para cada caminho. Será necessário que verifique se é possível executar a sua aplicação corretamente com 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

Nota

Ao migrar para WLS em máquinas virtuais do Azure, os requisitos para as versões específicas do Java são determinados pelo Java pré-instalado nas máquinas virtuais. Ao migrar para WLS no AKS, a versão específica do Java é determinada pela imagem de contêiner escolhida. Há uma grande variedade de opções, mas todas elas usam o Oracle JDK.

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 três opções:

  • O Coherence*Web pode ser executado em conjunto com um WebLogic Server nas máquinas virtuais do Azure, mas tem de configurar manualmente esta opção depois de aprovisionar a oferta. Se estiver a utilizar o Coherence de forma autónoma, também pode executá-lo numa máquina virtual do Azure, mas tem de configurar manualmente esta opção depois de aprovisionar a oferta.
  • 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 a Gestão através de REST é utilizada

Se o ciclo de vida da sua aplicação incluir a utilização da Gestão através de REST, tem de capturar as portas utilizadas para aceder à API REST e determinar como são autenticadas e expostas. Depois da migração, tem de garantir que estas mesmas portas e estes mesmos mecanismos de autenticação são expostos, para que o ciclo de vida da aplicação possa funcionar de forma semelhante à anterior à migração. Para obter mais informações, veja Administering Oracle WebLogic Server with RESTful Management Services (Administrar o Oracle WebLogic Server com Serviços de Gestão RESTful).

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

Se estiver a utilizar o Oracle Message Broker, pode migrar este software para as máquinas virtuais do Azure e utilizá-lo tal como está.

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.

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

Se utilizar atualmente o WLST para fazer a sua implementação, tem de avaliar o que a ferramenta está a fazer. Se o WLST estiver a alterar algum parâmetro (de runtime) da sua aplicação como parte da implementação, tem de garantir que esse comportamento continua a funcionar enquanto testa a aplicação após a migração.

Determinar se e como é que o sistema de ficheiros é utilizado

Os sistemas de ficheiros de VMs funcionam da mesma forma que os sistemas de ficheiros no local no que diz respeito a persistência, arranque e encerramento. Contudo, é importante ter noção das necessidades do seu sistema de ficheiros e garantir que o tamanho de armazenamento e o desempenho das VMs é adequado.

Conteúdo estático só de leitura

Se a sua aplicação servir conteúdo estático atualmente, precisa de uma localização alternativa para o mesmo. Pode considerar mover o conteúdo estático para o Armazenamento de Blobs do Azure e adicionar a CDN do Azure para obter transferências super-rápidas a nível global. Para obter mais informações, consulte Hospedagem de site estático no Armazenamento do Azure e Guia de início rápido: integrar uma conta de armazenamento do Azure com a CDN do Azure.

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. Disponibilizamos uma implementação de exemplo que pode utilizar, em Uploading and CDN-preloading static content with Azure Functions (Carregamento e pré-carregamento da CDN de conteúdo estático com as Funções do Azure).

Determinar a topologia de rede

O conjunto atual de ofertas do Azure Marketplace é um ponto de partida para a sua migração. Se a oferta não cobrir algum aspeto da arquitetura que precise de migrar, tem de capturar a topologia de rede da sua implementação existente e reproduzi-la no Azure, mesmo depois de complementar a oferta básica com um dos modelos de solução.

Este tópico é bastante amplo, mas as referências seguintes podem ajudar a orientar os seus esforços de migração:

  • Esta referência enumera os tópicos de alto nível relevantes para a migração da topologia de rede para o Azure: Guia de Implantação Fast Track.
  • Esta referência descreve preocupações importantes em relação ao clustering, que tem um impacto na topologia de rede: WebLogic Server Clustering.
  • Uma vez que as origens de dados são servidores separados num sistema WebLogic, tem de as encarar como fazendo parte da análise da topologia de rede. WebLogic Server Data Sources (Origens de dados do WebLogic Server).
  • As origens das mensagens também são servidores separados. WebLogic Server Messaging (Mensagens do WebLogic Server).
  • O balanceamento de carga é um requisito fundamental. Esta referência abrange o lado do WebLogic Server do balanceamento de carga: Balanceamento de carga em um cluster.

Considerar a utilização de Adaptadores JCA e de Adaptadores de Recursos

Se a sua aplicação existente estiver a utilizar Adaptadores JCA e/ou Adaptadores de Recursos para se ligar a outros sistemas empresariais, certifique-se de que a configuração destes artefactos é aplicada ao WebLogic Server em execução em Máquinas Virtuais do Microsoft Azure. Para obter mais informações, veja Creating and Configuring Resource Adapters (Criar e Configurar Adaptadores de Recursos).

Conta para o uso de provedores de segurança personalizados e JAAS

Se a sua aplicação estiver a utilizar o JAAS, tem de se certificar de que a configuração dos fornecedores de segurança é corretamente migrada. Para obter mais informações, veja About Configuring WebLogic Security Providers (Sobre a configuração de fornecedores de segurança WebLogic) na documentação da Oracle.

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. Pode migrar esses clusters diretamente a partir da instalação no local para o WebLogic em execução nas Máquinas Virtuais do Azure. Para obter mais informações, veja Domain Configuration Files (Ficheiros de Configuração de Domínios) na documentação da Oracle.

Conta para requisitos de balanceamento de carga

O balanceamento de carga é uma parte essencial da migração do cluster do Oracle WebLogic Server para o Azure. A solução mais fácil é usar o suporte interno para o Gateway de Aplicativo do Azure fornecido na oferta do Azure Marketplace para cluster do Oracle WebLogic Server. Para obter um tutorial sobre este tópico, consulte Tutorial: Migrar um cluster do WebLogic Server para o Azure com o Azure Application Gateway como um balanceador de carga.

Para obter um resumo dos recursos do Gateway de Aplicativo do Azure em comparação com outras soluções de balanceamento de carga do Azure, consulte Visão geral das opções de balanceamento de carga no Azure.

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

Se a sua aplicação estiver a utilizar a funcionalidade da aplicação cliente Java EE, deverá continuar a funcionar de forma inalterada após a migração para Máquinas Virtuais do Azure. Para obter mais informações, veja Using Java EE Client Application Modules (Utilizar os módulos da aplicação cliente Java EE).

Migração

Selecionar uma oferta WebLogic em Máquinas Virtuais do Microsoft Azure

Estão disponíveis as seguintes ofertas para o WebLogic em Máquinas Virtuais do Microsoft Azure.

Durante a implantação de uma oferta, você será solicitado a escolher o tamanho da máquina virtual para os nós do servidor WebLogic. Quando escolher o tamanho das VMs, é importante considerar todos os aspetos do tamanho (memória, processador, disco, etc.). Para obter mais informações, consulte a Documentação do Azure para dimensionamento de máquinas virtuais

WebLogic Server Single Node with no Admin Server (nó único do WebLogic Server sem servidor de administrador)

Esta oferta cria uma única VM e instala o WebLogic na mesma, mas não configura nenhum domínio, o que é útil em cenários onde tem uma configuração de domínio altamente personalizada.

WebLogic Server Single Node with Admin Server (nó único do WebLogic Server com servidor de administrador)

Esta oferta provisiona uma única VM e instala o WebLogic Server nela. Cria um domínio e inicia o servidor de administrador.

WebLogic Server N-Node Cluster (cluster de "n" nós do WebLogic Server)

Esta oferta cria um cluster altamente disponível de VMs do WebLogic Server.

WebLogic Server N-Node Dynamic Cluster (cluster dinâmico de "n" nós do WebLogic Server)

Esta oferta cria um cluster altamente disponível de VMs do WebLogic Server.

Aprovisionar a oferta

Depois de ter selecionado a oferta com a qual vai começar, siga as instruções na documentação das ofertas para aprovisionar essa oferta. Certifique-se de que escolhe o nome de domínio que corresponde ao seu nome de domínio já existente. Pode até fazer corresponder a palavra-passe de domínio com a sua palavra-passe de domínio já existente.

Migrar os domínios

Depois de ter aprovisionado a oferta, pode examinar a configuração do domínio e seguir estas orientações para obter informações detalhadas sobre como pode migrar os domínios.

Ligar as bases de dados

Depois de ter migrado os domínios, pode ligar as bases de dados ao seguir as instruções que se encontram na documentação da oferta. Estas instruções ajudam você a contabilizar quaisquer segredos de banco de dados e cadeias de caracteres de acesso envolvidas.

Considerar os KeyStores

Tem de ter em conta a migração de todos os KeyStores SSL utilizados pela sua aplicação. Para obter mais informações, veja Configuring Keystores (Configurar Keystores).

Ligar as origens do JMS

Depois de conectar os bancos de dados, você pode configurar o JMS. Para obter mais informações, consulte Fusion Middleware Administering JMS Resources for Oracle WebLogic Server na documentação do WebLogic.

Conta para autenticação e autorização

A maioria dos aplicativos tem algum tipo de autenticação e autorização. Se você usar LDAP para autenticação, poderá configurar os Serviços de Domínio do Microsoft Entra com LDAP seguro e configurar conexões LDAP no WebLogic Server. Para obter mais informações, consulte Criar e configurar um domínio gerenciado dos Serviços de Domínio Microsoft Entra e Configurar LDAP seguro para um domínio gerenciado dos Serviços de Domínio Microsoft Entra.

Considerar o registo

Use a integração com o Elastic on Azure fornecida pelos modelos de solução de mercado do Oracle WebLogic Server. Essa abordagem é a maneira mais fácil de contabilizar o registro. Você pode ver a lista de ofertas no artigo de visão geral O que são soluções para executar o Oracle WebLogic Server em Máquinas Virtuais do Azure? Os tutoriais completos para configurar o Elastic são fornecidos em:

Se a integração elástica não for apropriada, você deverá transferir a configuração de log existente ao migrar o domínio. Para obter mais informações, consulte Configure java.util.logging logger levels e Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server na documentação do Oracle.

Migrando seus aplicativos

As técnicas utilizadas para implementar aplicações da equipa de desenvolvimento em servidores de teste e de produção variam muito de caso para caso. Em alguns casos, há uma plataforma de CI/CD altamente evoluída que resulta na implantação dos aplicativos no WebLogic Server. Noutros casos, o processo pode ser mais manual. Um benefício de usar as Máquinas Virtuais do Azure para migrar aplicativos WebLogic para a nuvem é que seus processos existentes continuam a funcionar.

Você precisa configurar o Grupo de Segurança de Rede que a oferta provisiona para permitir o acesso a partir do seu pipeline de CI/CD ou sistema de implantação manual. Para obter mais informações, consulte Grupos de segurança de rede.

Testar

Todos os testes em contentor em aplicações têm de ser configurados para aceder aos novos servidores que estão em execução dentro do Azure. Assim como acontece com as preocupações de CI/CD, você deve garantir que as regras de segurança de rede necessárias permitam que seus testes acessem os aplicativos implantados no Azure. Para obter mais informações, consulte Grupos de segurança de rede.

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 orientações sobre alguns possíveis aprimoramentos pós-migração, consulte as seguintes recomendações: