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 Kubernetes do Azure (AKS).

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.

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.

Determinar 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 considerar 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 fonte inicial do domínio Model in Image . Este conceito é explicado em mais detalhes mais adiante neste artigo.
  • Em um alto nível, a oferta automatiza as seguintes etapas para você.
    • Pegue uma implantação WAR ou EAR existente, se desejar.
    • 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 criar ambientes WebLogic e executar operações de ciclo de vida do 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 App Gateway, log elástico, integração de banco de dados e muito mais, ela faz muitas suposições simplificadas. Essas suposições 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 para o operador WLS Kubernetes está disponível em 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.

Decida se deseja usar a oferta pré-criada do Azure Marketplace

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

Tipo de origem inicial do domínio Description Aspetos positivos Aspetos negativos
Modelo em Imagem WLS e aplicativos estão na imagem do contêiner, e todo o resto é mantido fora dessa imagem. Suportado por oferta pré-construída. Documentado como amostra oficial; consulte Oracle. A maioria usa WDT. A opção mais "nativa da nuvem". Integração CI/CD mais simples. Maior curva de aprendizagem.
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 WLS para fazer alterações e essas alterações persistem nas reinicializações do pod AKS. Documentado como amostra oficial; consulte Oracle. Alguns desafios relacionados com o NFS devem ser mitigados. Para obter mais informações, consulte Oracle. Esta 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 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 fonte Domínio em PV , recomendamos NFS em vez de SMB. NFS evoluiu a partir do sistema operacional UNIX, e 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 inicial 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 de como usar o operador diretamente, 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, você pode escolher melhor se deseja usar a oferta pré-criada do Azure Marketplace ou fazê-lo você mesmo usando o operador diretamente.

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

Sua versão WLS existente 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 suportadas.

  1. Visite o site do Oracle Container Registry e faça login. Para obter mais informações, veja https://container-registry.oracle.com/.
  2. Se tiver um direito de suporte, selecione Middleware e, em seguida, 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.

Nota

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

A oferta pré-criada do Azure Marketplace permite selecionar as imagens WLS do OCR e do Azure Container Registry (ACR) e, portanto, suporta implicitamente 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 suportadas listadas no OCR.

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 tamanho das VMs em seu pool de nós, a quantidade de memória a ser usada pelo contêiner e quantas CPUs compartilham as necessidades do contêiner.

É possível redimensionar pools de nós no AKS. Para saber como, consulte Redimensionar pools de nós no Serviço 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, 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.

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

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>

Depois de ter um inventário sólido de certificados, você pode 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.

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.

Se estiver a utilizar a oferta pré-criada do Azure Marketplace, o conjunto de recursos JNDI que pode personalizar no momento da implementação está 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 fonte inicial do domínio escolhido. Para Domínio em PV, você pode defini-los da maneira habitual, com WLST ou com o console de administração. Para Domínio na imagem ou Modelo na imagem, consulte Substituições típicas.

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.

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

A oferta pré-criada do Azure Marketplace suporta afinidade de sessão através do controlador de entrada do Gateway de Aplicação. Ao implantar a oferta, selecione Ativar afinidade baseada em cookies. Procure afinidade baseada em cookies na documentação da oferta.

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

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 habitual, com WLST ou com o console de administração. Para Domínio na imagem ou Modelo na imagem, consulte Substituições típicas.

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?

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 imagens. Se você estiver usando o operador diretamente, consulte Memória JVM e variáveis de ambiente de opção Java.

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

O único tipo de fonte inicial 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 é 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 como Escolher uma solução para 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, veja Utilizar o JMS com o Azure Service Bus e o 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.

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

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.

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

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

Se a sua aplicação contiver código com dependências no SO anfitrião, terá de a refatorizar para remover essas dependências. Por exemplo, poderá ter de substituir qualquer utilização de / ou \ em caminhos do sistema de ficheiros por File.Separator ou Paths.get.

WLS no AKS é executado em Oracle Linux. Qualquer código específico do SO 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 WebLogic é compatível.

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

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

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.

A oferta pré-criada do Azure Marketplace suporta 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 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.

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

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

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

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

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). Você também pode implantar diretamente o conteúdo estático em um aplicativo no plano do 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 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 sua implantação depender de adaptadores de recursos, a opção mais suportada é Domain home on a PV.

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.

Se sua implantação depender de provedores de segurança, a opção mais suportada é Domain home on a PV.

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

O operador lida com clustering para todas as maneiras possíveis de executar 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 App Gateway 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 Azure Application Gateway como um balanceador de carga.

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

Se sua implementação depende 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 "backend". É útil poder atualizar o frontend, sem atualizar o backend, e vice-versa. No entanto, com o tipo de fonte inicial Model in Image domain, 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 introduzir 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 de host desconhecido

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

  • Permita o acesso T3 de clientes externos fora do AKS a clusters WLS no AKS através de um canal personalizado.
  • Permite o 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 How to Use the Patch Search in My Oracle Support (MOS) e procure por 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.

Aprovisionar 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ê navegou para fora da página Implantação está em andamento , as etapas a seguir mostram como voltar a essa página. Se você ainda estiver na página que mostra Sua implantação foi concluída, pule 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 Filtro 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 para esse grupo de recursos, com a mais recente primeiro.

  4. Desloque-se para a entrada mais antiga desta lista. Esta entrada corresponde à implantação iniciada na seção anterior. Selecione a implantação mais antiga, conforme mostrado na captura de tela a seguir.

    Captura de ecrã do portal do Azure a mostrar a lista de implementações do grupo de recursos.

  5. No painel esquerdo, selecione Saídas. Esta lista mostra os valores de saída da implantação. Informações úteis estão incluídas nos resultados. 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 WebLogic on AKS.

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

  7. Localize a saída chamada shellCmdtoOutputWlsDomainYaml. Cole o valor da saída em um shell Bash e execute o comando. Este comando produz o 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. Esta orientação requer adaptação para se aplicar à maneira Kubernetes de fazer as coisas, mas ainda é útil saber.

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 ter ligado as bases de dados, pode configurar o JMS ao seguir as instruções que se encontram em Fusion Middleware Administering JMS Resources for Oracle WebLogic Server (Fusion Middleware – Administração de Recursos do JMS para o Oracle WebLogic Server) na documentação do WebLogic.

Considerar o registo

Você não pode fazer nuvem sem dominar o registro. 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 excelente 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 do 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 merecem ser explorados.

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: