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

  • Artigo

Este guia descreve as informações das quais você deve estar ciente quando deseja migrar um aplicativo WebLogic existente para ser executado em Máquinas Virtuais do Azure. Para obter uma visão geral das soluções WebLogic Server disponíveis no Azure Marketplace, consulte O que são soluções para executar o Oracle WebLogic Server em Máquinas Virtuais do 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.

Defina o que você quer dizer por "migração concluída"

Este guia e as ofertas do Azure Marketplace correspondentes são um ponto de partida para acelerar a migração de suas cargas de trabalho do WebLogic Server para o Azure. É importante definir o escopo do seu esforço de migração. Por exemplo, você está fazendo um "lift and shift" rigoroso de sua infraestrutura existente para Máquinas Virtuais do Azure? Nesse caso, pode estar tentado a fazer um "lift and improve" ao migrar.

É melhor se ater ao "lift and shift" puro na medida do possível, fazendo as alterações necessárias detalhadas neste guia. Defina o que você quer dizer por "migração concluída" para saber quando chegou a essa etapa. Quando você tiver atingido a "migração concluída", poderá tirar um instantâneo de suas Máquinas Virtuais, conforme descrito em Criar um instantâneo. Depois de verificar se é 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 seja o destino apropriado para 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 é bem executado em máquinas virtuais (VMs) do Azure ou no Serviço de 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 ao que você tem localmente. O trade-off 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 a alteração 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 ser executado 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.

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

A Oracle e a Microsoft fizeram 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 Middleware do Oracle Fusion para ver a lista de ofertas e escolher a que mais se aproxima da sua implantação existente. É possível 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, confira O que é IaaS?

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

Sua versão existente do WebLogic deve ser compatível com a versão nas ofertas de IaaS. Para ver as ofertas do WebLogic versão 12.2.1.3, consulte o Azure Marketplace para Oracle WebLogic 12.2.1.3. Se sua versão existente do WebLogic não for compatível com essa versão, você precisará reproduzir a implantação manualmente usando os recursos de IaaS do Azure. Para obter mais informações, consulte a documentação 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. Essas informações devem orientar a escolha do tamanho da VM. Para saber mais, veja Tamanhos dos Serviços de Nuvem.

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>

Validar se a versão Java com suporte funciona corretamente

Todos os caminhos de migração do WebLogic para o Azure exigem uma versão específica do Java, que varia para cada caminho. Você precisará 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

Observação

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

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

  • O Coherence*Web pode ser executado junto com um WebLogic Server nas máquinas virtuais do Azure, mas você deve configurar manualmente essa opção depois de provisionar a oferta. Se você estiver usando o Coherence de forma independente, também poderá executá-lo em uma máquina virtual do Azure, mas deverá configurar manualmente essa opção depois de provisionar a oferta.
  • 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 o gerenciamento em REST é usado

Se o ciclo de vida do seu aplicativo incluir o uso do gerenciamento em REST, você precisará capturar quais portas são usadas para acessar a API REST e determinar como elas são autenticadas e expostas. Após a migração, você precisará garantir que essas mesmas portas e mecanismos de autenticação sejam expostos para que o ciclo de vida do aplicativo possa funcionar de maneira semelhante a antes da migração. Para saber mais, consulte Administrando o Oracle WebLogic Server com serviços de gerenciamento RESTful.

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, confira Escolher uma solução para 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 JMS, você precisará migrá-los para um servidor 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, consulte Usar o JMS com o 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.

Se você estiver usando o Oracle Message Broker, poderá migrar esse software para as máquinas virtuais do Azure e usá-lo no estado em que se encontra.

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.

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.

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 (de tempo de execução) do seu aplicativo como parte da implantação, você precisará garantir que esse comportamento continue a funcionar enquanto testa seu aplicativo após a migração.

Determinar se e como o sistema de arquivos é usado

Os sistemas de arquivos de VMs funcionam da mesma forma que os sistemas de arquivos locais em relação à persistência, inicialização e ao desligamento. Mesmo assim, é importante estar ciente das necessidades do seu sistema de arquivos e garantir que as VMs tenham o tamanho e o desempenho de armazenamento adequados.

Conteúdo estático somente leitura

Se seu aplicativo estiver servindo conteúdo estático no momento, você precisará de um local alternativo para ele. Talvez você queira considerar a movimentaçã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. Para obter mais informações, confira Hospedagem de site estático no Armazenamento do Microsoft Azure e Início rápido: Integrar uma conta de armazenamento do Azure à CDN do Azure. Você também pode implantar diretamente o conteúdo estático em um aplicativo no plano Azure Spring Apps Enterprise. Para obter mais informações, consulte Implantar arquivos estáticos da Web.

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 em Carregar conteúdo estático e fazer o pré-carregamento desse conteúdo pela CDN com o Azure Functions. Você também pode implantar diretamente o conteúdo estático em um aplicativo no plano Azure Spring Apps Enterprise. Para obter mais informações, consulte Implantar arquivos estáticos da Web.

Determinar a topologia de rede

O conjunto atual de ofertas do Azure Marketplace é um ponto de partida para sua migração. Se a oferta não abranger aspectos de sua arquitetura que você precisa migrar, será necessário capturar a topologia de rede de sua implantação existente e reproduzi-la no Azure, mesmo depois de terminar a oferta básica com um dos modelos de solução.

Este é um tópico muito amplo, mas as referências a seguir podem dar uma direção aos seus esforços de migração:

Considerar o uso de adaptadores JCA e adaptadores de recursos

Se seu aplicativo existente estiver usando adaptadores JCA e/ou adaptadores de recursos para se conectar a outros sistemas empresariais, verifique se a configuração desses artefatos é aplicada ao WebLogic Server em execução em Máquinas Virtuais do Azure. Para saber mais, consulte Criando e configurando adaptadores de recursos

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

Se seu aplicativo estiver usando JAAS, você precisará garantir que a configuração dos provedores de segurança seja migrada corretamente. Para saber mais, consulte Sobre a configuração de provedores de segurança WebLogic na documentação da Oracle.

Determinar se o clustering do WebLogic é usado

É provável que você tenha implantado seu aplicativo em vários WebLogic Servers para conseguir alta disponibilidade. Você pode migrar esses clusters diretamente da instalação local para o WebLogic em execução em Máquinas Virtuais do Azure. Para obter mais informações, consulte Arquivos de configuração de domínio 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 o 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 Gateway de Aplicativo do Azure como um balanceador de carga.

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

Determinar se o recurso Cliente do aplicativo Java EE é usado

Se seu aplicativo usar o recurso Cliente do aplicativo Java EE, ele deverá continuar a funcionar sem alterações após a migração para as Máquinas Virtuais do Azure. Para saber mais, consulte Usando módulos do aplicativo cliente Java EE.

Migração

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

As ofertas a seguir estão disponíveis para o WebLogic em Máquinas Virtuais do 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. É importante considerar todos os aspectos do dimensionamento (memória, processador, disco) ao escolher o tamanho da VM. Para obter mais informações, confira a Documentação do Azure para o dimensionamento de máquinas virtuais

WebLogic Server de um único nó sem servidor de administração

Esta oferta cria uma única VM e instala o WebLogic nela, mas não configura domínios, o que é útil para cenários em que você tem uma configuração de domínio altamente personalizada.

WebLogic Server de um único nó com servidor de administração

Esta oferta provisiona uma única VM e instala o WebLogic Server nela. Ele cria um domínio e inicializa o servidor de administração.

Cluster de N nós do WebLogic Server

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

Cluster dinâmico de N nós do WebLogic Server

Esta oferta cria um cluster dinâmico altamente disponível e escalonável de VMs do WebLogic Server

Provisionar a oferta

Depois de selecionar a oferta inicial, siga as instruções na documentação das ofertas para provisionar essa oferta. Lembre-se de escolher o nome de domínio que corresponda ao nome de domínio existente. Você pode até mesmo corresponder a senha de domínio com sua senha de domínio existente.

Migrar os domínios

Depois de provisionar a oferta, você pode examinar a configuração de domínio e seguir este guia para obter detalhes sobre como migrar os domínios.

Conectar os bancos de dados

Após migrar os domínios, você poderá conectar os bancos de dados seguindo as instruções na documentação da oferta. Estas instruções ajudam você a contabilizar quaisquer segredos de banco de dados e cadeias de caracteres de acesso envolvidos.

Considerar os repositórios de chaves

Você deve considerar a migração de todos os repositórios de chaves SSL usados pelo seu aplicativo. Para obter mais informações, consulte Configurando repositórios de chaves.

Conectar as fontes 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 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 registro em log

Use a integração com o Elastic no Azure fornecida pelos modelos de solução de marketplace do Oracle WebLogic Server. Essa abordagem é a maneira mais fácil de contabilizar o registro em log. 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? Tutoriais completos para configurar o Elastic são fornecidos em:

Se a integração com o Elastic não for apropriada, você deverá transportar a configuração de log existente ao migrar o domínio. Para saber mais, consulte Configurar os níveis do agente java.util.logging e Configurando arquivos de log e filtrando mensagens de log para o Oracle WebLogic Server na documentação da Oracle.

Migrando seus aplicativos

As técnicas usadas para implantar aplicativos da equipe de desenvolvimento em servidores de teste, de preparo e de produção variam muito conforme o caso. Em alguns casos, há uma plataforma de CI/CD altamente evoluída que faz com que os aplicativos sejam implantados no WebLogic Server. Em outros 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 funcionando.

Você precisa configurar o Grupo de Segurança de Rede que a oferta provisiona para permitir o acesso do pipeline de CI/CD ou do sistema de implantação manual. Para saber mais, confira Grupos de segurança de rede.

Testando

Todos os testes no contêiner em relação a aplicativos devem ser configurados para acessar os novos servidores em execução no Azure. Assim como acontece com as preocupações com o 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 saber mais, confira Grupos de segurança de rede.

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