Migrar aplicativos do WebLogic Server para o Serviço Kubernetes do Azure

  • Artigo

Este guia descreve o que você deve estar ciente quando deseja migrar um aplicativo WebLogic Server (WLS) existente para ser executado no Serviço de Kubernetes do Azure (AKS).

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.

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.

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

Depois de decidir que o AKS é o destino de implantação apropriado, você deve aceitar que o operador Oracle WLS Kubernetes (o operador) é a única maneira de executar o WLS no Kubernetes. Depois de aceitar esse fato, você deve decidir se a oferta pré-criada do Azure Marketplace é ou não um bom ponto de partida. Aqui estão algumas coisas a serem consideradas sobre a oferta pré-criada do Azure Marketplace.

  • A Oracle e a Microsoft criaram esta oferta para permitir que você provisione rapidamente o WLS no AKS usando o tipo de origem inicial do domínio Modelo em Imagem . Esse conceito é explicado com mais detalhes mais adiante neste artigo.
  • Em um alto nível, a oferta automatiza as etapas a seguir para você.
    • Pegue uma implantação WAR ou EAR existente, se desejado.
    • Envolva-o em um contêiner usando a WebLogic Image Tool (WIT). Para obter mais informações, consulte WebLogic Image Tool na documentação do Oracle.
    • Instale e configure o operador WebLogic Kubernetes no AKS.
    • Use o operador para executar a coisa toda. O operador invoca o WebLogic Deploy Tooling (WDT) para sustentar ambientes WebLogic e executar operações de ciclo de vida de domínio de forma repetível com base em um modelo de metadados. Para obter mais informações, consulte WebLogic Deploy Tooling na documentação do Oracle.
  • Embora a oferta pré-criada forneça várias integrações de serviço do Azure, como Gateway de Aplicativo, log elástico, integração de banco de dados e muito mais, ela faz muitas suposições simplificadoras. Essas premissas fazem com que a oferta não seja tão flexível quanto dominar e usar o próprio operador.

Se você não usar a oferta pré-criada do Azure Marketplace, deverá aprender a usar o operador diretamente. Dominar o operador está além do escopo deste artigo. A documentação completa do WLS Kubernetes Operator está disponível na Oracle.

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

Primeiro, você tem que entender o conceito do "domínio" do WLS. Um domínio é um grupo logicamente relacionado de recursos do WLS. Para obter a definição canônica do domínio WLS, consulte a documentação do Oracle. Executar o WLS no AKS requer decidir como o AKS lida com domínios. As várias opções são chamadas de "tipo de fonte inicial do domínio". O operador WLS Kubernetes oferece suporte a três opções de tipo de origem inicial de domínio. A oferta pré-criada do Azure Marketplace usa a primeira desta tabela.

Tipo de origem base do domínio Descrição Aspectos positivos Aspectos negativos
Modelo em Imagem O WLS e os aplicativos estão na imagem do contêiner e todo o resto é mantido fora dessa imagem. Suportado por oferta pré-construída. Documentado como uma amostra oficial; consulte Oracle. A maioria usa WDT. A opção mais "nativa da nuvem". Integração CI/CD mais simples. Maior curva de aprendizado.
Domínio em PV O domínio reside em um volume persistente do Kubernetes. Conceitualmente semelhante à execução em VMs. Você pode usar o console do WLS para fazer alterações e essas alterações persistem nas reinicializações do pod do AKS. Documentado como uma amostra oficial; consulte Oracle. Alguns desafios relacionados à NFS devem ser mitigados. Para obter mais informações, consulte Oracle. Essa abordagem é a técnica menos "nativa da nuvem"; o estado reside inteiramente fora do cluster AKS.
Domínio em Imagem O domínio reside em uma imagem de contêiner. Os aplicativos estão contidos em uma imagem de contêiner que é sobreposta à imagem de domínio. Mais "nativo da nuvem" do que domínio em PV. Mais fácil para CI/CD. Não é possível usar o console WLS. Deve manter mais imagens de contêiner.

Importante

Se você escolher o tipo de origem Domínio em PV , recomendamos fortemente NFS em vez de SMB. O NFS evoluiu a partir do sistema operacional UNIX e de outras variantes, como GNU/Linux. Por esse motivo, ao usar o NFS com tecnologias de contêiner, como o Docker, é menos provável que haja problemas para leituras simultâneas e bloqueio de arquivos.

Certifique-se de ativar o NFS v4.1. Versões inferiores à v4.1 terão problemas.

A documentação do operador também inclui uma tabela útil comparando as várias opções. Para obter mais informações, consulte Escolher um tipo de fonte base de domínio.

Para ter uma ideia da oferta pré-criada do Azure Marketplace, consulte Guia de início rápido: implantar o WebLogic Server no Serviço Kubernetes do Azure usando o portal do Azure. Para obter a documentação de referência sobre a oferta pré-criada do Azure Marketplace, consulte Oracle.

Para ter uma ideia do uso direto do operador, experimente as amostras na documentação do operador.

Agora que você foi apresentado às várias maneiras de lidar com domínios WLS no AKS, é mais possível escolher se deseja usar a oferta pré-criada do Azure Marketplace ou fazer isso sozinho usando o operador diretamente.

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

Sua versão existente do WLS deve ser uma das versões suportadas pelo operador. A Oracle mantém essas versões no Oracle Container Registry (OCR). Use as etapas a seguir para ver a lista de versões com suporte.

  1. Visite o site do Oracle Container Registry e faça login. Para obter mais informações, consulte https://container-registry.oracle.com/.
  2. Se você tiver um direito de suporte, selecione Middleware e procure weblogic_cpu. Selecione weblogic_cpu.
  3. Se você não tiver um direito de suporte da Oracle, selecione Middleware e procure weblogic. Selecione weblogic.

Observação

Obtenha um direito de suporte da Oracle antes de ir para a produção. Não fazer isso resulta na execução de imagens inseguras que não são corrigidas por falhas críticas de segurança. Para obter mais informações sobre as atualizações de patches críticos da Oracle, consulte Atualizações de patches críticos, alertas de segurança e boletins.

A oferta pré-criada do Azure Marketplace permite que você selecione as imagens do WLS do OCR e do Registro de Contêiner do Azure (ACR) e, portanto, oferece suporte implícito a todas as versões disponíveis do OCR. Se você direcionar a oferta para extrair uma imagem do ACR, verifique se ela é derivada de uma das versões com suporte listadas no OCR.

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, ajudar a orientar a seleção do tamanho das VMs no pool de nós, a quantidade de memória a ser usada pelo contêiner e quantos compartilhamentos de CPU o contêiner precisa.

É possível redimensionar pools de nós no AKS. Para saber como, consulte Redimensionar pools de nós no Serviço de Kubernetes do Azure (AKS).

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.

Depois de ter um inventário sólido de segredos, consulte a documentação do operador sobre segredos. Para saber mais, consulte Segredos.

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>

Depois de ter um inventário sólido de certificados, você poderá instalá-los diretamente com a oferta pré-criada do Azure Marketplace. Para obter mais informações, consulte Configuração de TLS/SSL. Se você estiver usando o operador diretamente, consulte Atualizando certificados externos do operador.

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.

Se você estiver usando a oferta pré-criada do Azure Marketplace, o conjunto de recursos JNDI que você pode personalizar no momento da implantação será limitado ao que a oferta suporta. Procure JNDI na documentação da oferta. Se você estiver usando o operador diretamente, os recursos JDNI podem ser definidos dependendo do tipo de origem inicial do domínio escolhido. Para Domínio em PV, você pode defini-los da maneira usual, com o WLST ou com o console de administração. Para Domínio em Imagem ou Modelo em Imagem, consulte Substituições típicas.

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.

A oferta pré-criada do Azure Marketplace cria automaticamente um recurso de domínio. Se você estiver usando o operador diretamente, poderá personalizar completamente como seu domínio é representado. Para obter informações completas, consulte Recurso de domínio.

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.

A oferta pré-criada do Azure Marketplace dá suporte à afinidade de sessão por meio do controlador de entrada do Gateway de Aplicativo. Ao implantar a oferta, selecione Ativar afinidade baseada em cookies. Procure afinidade baseada em cookies na documentação da oferta.

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.

A oferta pré-criada do Azure Marketplace tem suporte para os bancos de dados mais populares. Para obter mais informações, consulte Banco de dados. Para Domínio em PV, você pode defini-los da maneira usual, com o WLST ou com o console de administração. Para Domínio em Imagem ou Modelo em Imagem, consulte Substituições típicas.

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?

Você precisa capturar essas personalizações na imagem de contêiner executada pelo AKS. Para a oferta pré-criada do Azure Marketplace, essas personalizações são melhor tratadas criando uma imagem de contêiner personalizada e disponibilizando-a no Registro de Contêiner do Azure e, em seguida, apontando para esse Registro no momento da implantação. Para obter mais informações, consulte Seleção de imagem. Se você estiver usando o operador diretamente, consulte Memória JVM e variáveis de ambiente de opção Java.

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.

O único tipo de origem base de domínio em que faz sentido continuar a usar o gerenciamento sobre REST é Domínio em PV. É possível usá-lo com os outros tipos de origem inicial do domínio, mas as alterações feitas são efêmeras e não persistem nas reinicializações do pod.

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.

Essas bibliotecas podem ser manipuladas usando as mesmas técnicas descritas em Determinar se o WebLogic foi personalizado.

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.

Você pode incluí-los no WAR ou EAR fornecido para a oferta pré-criada do Azure Marketplace ou usando o operador diretamente.

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.

O WLS no AKS é executado no Oracle Linux. Qualquer código específico do sistema operacional deve ser compatível com o Oracle Linux. Para saber como descobrir informações específicas do sistema operacional, siga as etapas em Determinar se a versão do WebLogic é compatível.

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.

O OSB não tem suporte direto na oferta pré-criada do Azure Marketplace. Se você deve usar OSB, você deve usar o operador diretamente.

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.

A oferta pré-criada do Azure Marketplace oferece suporte a WARs e EARs. Usar o operador diretamente também suporta WARs e EARs.

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.

O único tipo de origem inicial de domínio compatível com o uso do WLST é Domínio em PV. Para obter mais informações, consulte Página inicial do domínio em um PV.

Determinar se e como o sistema de arquivos é usado

O Kubernetes lida com sistemas de arquivos com volumes persistentes (PV). A montagem de volumes persistentes tem suporte na oferta pré-criada do Azure Marketplace e ao usar o operador diretamente. Se você estiver usando Domínio no PV, o sistema de arquivos é um aspecto central da configuração.

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 sua implantação depender de adaptadores de recursos, a opção mais suportada será Domínio inicial em um PV.

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.

Se sua implantação depender de provedores de segurança, a opção mais suportada será Domínio inicial em um PV.

Determinar se o clustering do WebLogic é usado

O operador lida com clustering para todas as maneiras possíveis de executar o WLS no AKS.

Inspecione seu cluster EJB

Se seu aplicativo estiver usando EJB local, você precisará migrá-los para EJB clusterizado. Para obter mais informações, consulte EJB clusterizado versus local.

Conta para requisitos de balanceamento de carga

A melhor maneira de contabilizar o balanceamento de carga é usar a integração do Gateway de Aplicativo fornecida pela oferta interna do Azure Marketplace. Para obter mais informações, consulte Tutorial: Migrar um cluster do WebLogic Server para o Azure com o Gateway de Aplicativo do Azure como um balanceador de carga.

Determinar se o recurso Cliente do aplicativo Java EE é usado

Se sua implementação depender de clientes de aplicativos Java EE, é melhor usar o operador diretamente. Para obter mais informações, consulte Clientes externos.

Determinar se várias imagens de contêiner são necessárias

Um domínio do WebLogic Server pode conter vários clusters. Por exemplo, um aplicativo de várias camadas pode ser representado em um único domínio, mas tem dois clusters, digamos "frontend" e "back-end". É útil poder atualizar o frontend, sem atualizar o back-end, e vice-versa. No entanto, com o tipo de origem base do domínio Modelo em Imagem, todo o domínio é representado em uma imagem de contêiner. Para acomodar esse caso de uso, você deve separar os clusters em seus próprios domínios, cada um com sua própria imagem de contêiner. O operador pode gerenciar vários domínios em vários namespaces. Para obter mais informações, consulte Escolher uma estratégia de seleção de namespace de domínio

A adoção de vários domínios pode apresentar problemas de acesso T3 entre domínios. Para resolver esses problemas, habilite um canal personalizado conforme descrito em Determinar se é necessário habilitar o acesso de host desconhecido.

Determinar se é necessário habilitar o acesso a host desconhecido

Talvez seja necessário habilitar o acesso a host desconhecido aplicando um patch ao WebLogic para os seguintes cenários:

  • Permitir acesso T3 de clientes externos fora do AKS a clusters WLS no AKS através de um canal personalizado.
  • Permitir acesso T3 entre diferentes domínios WLS no AKS através de um canal personalizado.

Para obter os detalhes do patch, siga as orientações em Como usar a pesquisa de patch no My Oracle Support (MOS) e procure o patch 30656708.

Depois que o patch for aplicado, consulte Habilitando o acesso de host desconhecido.

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.

Provisionar a oferta

Para abrir a oferta no portal do Azure, consulte https://aka.ms/wlsaks. Selecione Criar e siga as instruções na documentação da oferta. Use as informações coletadas nas etapas anteriores para ajudar no preenchimento dos campos da oferta.

Migrar os domínios

Depois de provisionar a oferta, produza o domínio seguindo estas etapas.

Se você saiu da página A implantação está em andamento, as etapas a seguir mostram como voltar para ela. Se você ainda estiver na página que mostra A implantação foi concluída, vá para a etapa 5.

  1. No canto superior esquerdo de qualquer página do portal, selecione o menu hambúrguer e selecione Grupos de recursos.

  2. Na caixa com o texto Filtrar para qualquer campo, insira os primeiros caracteres do grupo de recursos criado anteriormente. Se você seguiu a convenção recomendada, insira suas iniciais e selecione o grupo de recursos apropriado.

  3. No painel de navegação esquerdo, na seção Configurações , selecione Implantações para ver uma lista ordenada das implantações neste grupo de recursos, com a mais recente primeiro.

  4. Role até a entrada mais antiga nesta lista. Essa entrada corresponde à implantação iniciada na seção anterior. Selecione a implantação mais antiga, conforme mostrado na captura de tela a seguir.

    Screenshot of Azure portal showing the resource group deployments list.

  5. No painel esquerdo, selecione Saídas. Essa lista mostra os valores de saída da implantação. Informações úteis são incluídas nas saídas. Estamos interessados nas saídas que nos permitem inspecionar o domínio e interagir com o operador. Os outros valores nas saídas são explicados em detalhes no guia do usuário do WebLogic no AKS.

  6. Localize a saída chamada shellCmdtoConnectAks. Cole o valor da saída em um shell Bash e execute o comando. Esse comando permite que você use kubectl conforme descrito em Conectar ao cluster.

  7. Localize a saída chamada shellCmdtoOutputWlsDomainYaml. Cole o valor da saída em um shell Bash e execute o comando. Esse comando gera a saída do recurso de domínio como um arquivo YAML.

  8. Agora que você tem o domínio YAML da implantação atual, você pode aplicar o conhecimento em Implantando arquivos YAML de recurso de domínio e revisar esta orientação para obter mais pistas sobre como migrar os domínios. Essa orientação requer adaptação para se aplicar ao modo Kubernetes de fazer as coisas, mas ainda é útil saber.

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 seguindo as instruções em Middleware do Fusion Administrando recursos JMS para o Oracle WebLogic Server na documentação do WebLogic.

Considerar o registro em log

Você não pode fazer nuvem sem dominar o registro em log. O operador fornece amostras para usar o Elasticsearch e o Kibana. Para obter mais informações, consulte a documentação do operador. O Azure fornece um ótimo suporte para o Elastic. Para obter detalhes completos, consulte O que é a integração elástica com o Azure?. Você pode combinar o conhecimento nesses dois recursos para obter uma solução de log otimizada para o Azure para WLS no AKS.

Migrando seus aplicativos

Se você optou ou não por fornecer um arquivo WAR ou EAR no momento da implantação, você precisa atualizar o aplicativo via CI/CD. A documentação do operador tem um exemplo que mostra como fazer essa atualização. Para obter mais informações, consulte Atualização 3. Os outros exemplos de atualização são relevantes para a migração e valem a pena explorar.

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: