Compartilhar via

Migrar aplicativos WebSphere para o Red Hat OpenShift no Azure

  • Artigo

Este guia descreve o que você deve saber quando quiser migrar uma carga de trabalho existente do WebSphere Application Server (WAS) para o IBM WebSphere Liberty ou Open Liberty que é executado no Red Hat OpenShift no 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.

Verifique se o destino é o adequado para o esforço de migração

A primeira etapa em uma migração bem-sucedida de um aplicativo WAS para o Azure é selecionar o destino de migração mais adequado.

O WAS tradicional funciona bem em Máquinas Virtuais do Azure. O destino da máquina virtual (VM) é a escolha mais fácil, pois se assemelha mais a uma implantação local. A experiência administrativa e de implantação para máquinas virtuais é parecida com a que você tem no local.

Outra opção é migrar para contêineres convertendo a carga de trabalho tradicional do WAS em contêineres de aplicativos. Você pode executar o destino do contêiner no Serviço de Kubernetes do Azure (AKS) e no Red Hat OpenShift no Azure. A compensação para essa facilidade é o custo econômico.

De modo geral, o custo por minuto para uma solução baseada em VM é maior em comparação com contêineres. Embora uma solução baseada em contêiner custe menos para ser executada, você deve restringir seu aplicativo para se adequar aos requisitos da plataforma de orquestração de contêineres.

Se minimizar as mudanças é o fator mais importante para o esforço de migração, considere uma migração baseada em VM. Nesse caso, confira Migrar aplicativos do WebSphere para Máquinas Virtuais do Azure.

Se você puder tolerar a conversão de seu aplicativo para ser executado em contêineres para reduzir o custo de runtime, considere uma migração baseada no AKS ou no Red Hat OpenShift no Azure.

Para a migração baseada no AKS, você pode começar usando a camada Gratuito. Obtenha gerenciamento de cluster gratuito e pague apenas pelas máquinas virtuais, pelo armazenamento associado e pelos recursos de rede consumidos. Nesse caso, confira Migrar aplicativos do WebSphere para Serviço de Kubernetes do Azure.

Para a migração baseada no Red Hat OpenShift no Azure, além dos custos de cálculo e infraestrutura, os nós de aplicativo têm outro custo para o componente de licença do OpenShift. Esse custo é faturado com base no número de nós de aplicativo e no tipo de instância. Use preços sob demanda ou instâncias reservadas, o que melhor atender à necessidade de sua carga de trabalho e empresa. Nesse caso, consulte Migrar aplicativos WebSphere para o Red Hat OpenShift no Azure.

Os guias de instruções na documentação do Red Hat OpenShift no Azure abordam alguns aspectos relevantes para a migração. Para obter a lista completa de guias de instruções, consulte a documentação do Red Hat OpenShift no Azure.

Determinar se a oferta predefinida do Azure Marketplace é um bom ponto de partida

Depois de decidir que o Red Hat OpenShift no Azure é o destino de implantação apropriado, você deve aceitar que o operador do IBM WebSphere Liberty ou o Operador do Open Liberty (o operador) é a única maneira de executar o Liberty no Kubernetes. Depois de aceitar esse fato, você deve decidir se a oferta do Azure Marketplace predefinida é ou não um bom ponto de partida. Aqui estão alguns itens a considerar sobre a oferta predefinida do Azure Marketplace:

  • A IBM e a Microsoft criaram essa oferta para permitir que você provisione rapidamente o Liberty no Red Hat OpenShift no Azure. Esse conceito será explicado mais detalhadamente no conteúdo a seguir.
  • Em um alto nível, a oferta automatiza as etapas a seguir para você.
    • Tire uma imagem de aplicativo existente, se desejar.
    • Provisione um cluster do Red Hat OpenShift no Azure, se desejar.
    • Instale e configure o operador do IBM WebSphere Liberty ou o operador do Open Liberty no Red Hat OpenShift no Azure.
    • Use o operador para executar todo o processo. O operador implanta e gerencia aplicativos Liberty em contêineres no Red Hat OpenShift no Azure. É possível localizar a documentação de referência em Operador do IBM WebSphere Liberty e Operador do Open Liberty.

Se você não usar a oferta predefinida 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 está disponível em Operador do IBM WebSphere Liberty e Operador do Open Liberty.

Agora que já conheceu as várias maneiras de lidar com o Liberty no Red Hat OpenShift no Azure, você pode escolher melhor se deseja usar a oferta predefinida do Azure Marketplace ou fazer isso por conta própria usando o operador diretamente.

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

Você precisa do Operador do Open Liberty ou do operador do WebSphere Liberty para implantar e gerenciar aplicativos em clusters baseados em Kubernetes. Certifique-se de que sua versão existente do Liberty seja uma das versões suportadas pelo operador. As versões do Open Liberty são mantidas no GitHub OpenLiberty/open-liberty. A IBM mantém versões do IBM WebSphere Application Server Liberty. Para obter mais informações, consulte WebSphere Application Server Liberty.

A oferta predefinida do Azure Marketplace permite que você selecione as imagens do aplicativo no registro público e, portanto, dá suporte implicitamente a todas as versões.

Determinar se uma licença é necessária

Para o IBM WebSphere Liberty, você deve aceitar os termos do contrato de licença correspondente à versão do Programa IBM no contêiner do aplicativo. Para obter o contrato de licença aplicável a este Programa IBM, consulte Visualizando informações de licença para o operador do WebSphere Liberty. Para obter mais informações, consulte Executando o WebSphere Liberty no Microsoft Azure.

Se a edição do seu produto for algo diferente do IBM WebSphere Application Server (base) padrão, o .spec.license.edition value deverá especificar sua edição do produto. Outros valores disponíveis são IBM WebSphere Application Server Liberty Core e IBM WebSphere Application Server Network Deployment. A oferta predefinida do Azure Marketplace permite que você selecione a edição do produto com suporte.

Diferenças de inventário usando ferramentas de migração IBM

Para mover seus aplicativos para o WebSphere Application Server Liberty ou Open Liberty, é necessário planejar a migração, analisar os aplicativos e atualizar o código de origem. A IBM fornece ferramentas de migração para ajudar a identificar quaisquer diferenças entre seu ambiente atual e as tecnologias em seu novo ambiente Liberty, como Java EE 7 ou Java EE 8 e Java SE 8 ou Java SE 11. Para obter mais informações, consulte Migrando aplicativos para o Liberty.

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ê precisa dessas informações independentemente do caminho de migração que escolher. Essas informações são úteis, por exemplo, para ajudar a orientar a seleção do tamanho das VMs no nó, da quantidade de memória a ser usada pelo contêiner e de quantos compartilhamentos de CPU o contêiner precisaria.

Para aproveitar a capacidade não utilizada com uma economia de custo significativa, é possível usar as Máquinas Virtuais de Spot do Azure no Red Hat OpenShift no Azure. Para saber como, consulte Usar Máquinas Virtuais de Spot do Azure em um cluster do Red Hat OpenShift no Azure.

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 WAS, 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. Arquivos de configuração que contenham senhas ou credenciais também podem ser encontrados dentro de seu aplicativo. O WAS armazena dados de configuração em vários documentos em uma hierarquia em cascata de diretórios. A maioria dos documentos de configuração tem conteúdo XML. Para obter mais informações, consulte Documentos de configuração e Conceitos básicos do Azure Key Vault.

Depois que você tiver um inventário sólido de segredos, veja a documentação do operador sobre segredos. Para obter mais informações, consulte os seguintes artigos:

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, configure-os usando os seguintes artigos:

Validar se a versão Java com suporte funciona corretamente

Usar o Liberty requer uma versão específica do Java. Portanto, você precisa confirmar se o aplicativo é executado corretamente usando essa versão com suporte.

O runtime do WebSphere Application Server Liberty tem requisitos específicos para o nível mínimo do Java Runtime Environment (JRE). Para obter mais informações, consulte Dependências de versão Java para recursos.

O Open Liberty requer um runtime Java SE. Ele pode ser executado usando uma distribuição Java Runtime Environment (JRE) ou Java SE Development Kit (JDK). Para obter mais informações, consulte Versões do Java SE compatíveis.

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 WebSphere na documentação da IBM. 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 Usando recursos do JMS.

Se você estiver usando a oferta predefinida do Azure Marketplace, o conjunto de recursos JNDI que você pode personalizar no momento da implantação será limitado ao suporte da oferta. Para o WebSphere Liberty no AKS (Serviço de Kubernetes do Azure), é possível disponibilizar um objeto no namespace JNDI (Java Naming and Directory Interface) padrão. Para obter mais informações, consulte Desenvolvendo com o namespace padrão JNDI em um recurso do Liberty. Para o Open Liberty, consulte Java Naming and Directory Interface.

Inspecionar a configuração de perfil

A principal unidade de configuração no WAS é o perfil. Portanto, o arquivo resources.xml contém uma infinidade de configurações que você precisa considerar cuidadosamente para a migração. O arquivo inclui referências a outros arquivos XML que são armazenados em subdiretórios. Para obter mais informações, consulte Gerenciando perfis em sistemas operacionais distribuídos e IBM i.

Dentro de seu aplicativo

Inspecione o arquivo deployment.xml e/ou o arquivo WEB-INF/web.xml.

Você precisa capturar essas personalizações na imagem de contêiner que o Red Hat OpenShift no Azure executa. Quando você usa a oferta predefinida do Azure Marketplace, essas personalizações são melhor tratadas criando uma imagem de contêiner personalizada e disponibilizando-a em um registro público e, em seguida, apontando para esse registro no momento da implantação.

Se você estiver usando uma célula do WebSphere Application Server Network Deployment, cada membro do cluster será executado em uma instalação do WAS tradicional. O Liberty é um perfil leve do WebSphere Application Server. É um perfil flexível e dinâmico do WAS, que permite que o servidor WAS implante apenas os recursos personalizados necessários, em vez de implantar um grande conjunto de componentes JEE disponíveis.

Determinar se a replicação de sessão é usada

Se o aplicativo depender da replicação de sessão, você terá as seguintes opções:

  • Para sessões HTTP, de acordo com o nível de gerenciamento de sessões, você pode usar o cache ou um banco de dados para coletar dados da sessão.
  • Para sessões distribuídas, você pode salvar sessões em um banco de dados usando a persistência de sessão de banco de dados.
  • Para Cache dinâmico, você pode gerenciar dados de sessão no cache ou em um banco de dados.
  • Você pode refatorar seu aplicativo para usar um banco de dados para gerenciamento de sessão.
  • Você pode refatorar 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 Liberty faz a replicação de estado de sessão HTTP. Os documentos a seguir ajudam a entender como gerenciar sessões HTTP no Liberty:

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 WAS, consulte Usando drivers JDBC com o WebSphere Application Server.

A configuração JDBC é uma configuração do servidor núcleo no Liberty. Para obter mais informações, consulte Driver JDBC.

A oferta predefinida do Azure Marketplace tem suporte limitado para bancos de dados. Você pode manipular a configuração nas imagens do aplicativo e usar a imagem ao implantar a oferta.

Determinar se o WAS 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 wsadmin, AdminControl, AdminConfig, AdminApp e AdminTask.
  • Parâmetros específicos foram passados para a JVM?
  • JARs foram adicionados ao classpath do servidor?
  • Os recursos de nível de sistema operacional, como systemd, foram usados para fazer com que os componentes do WAS sejam iniciados automaticamente após a reinicialização do servidor?

Você precisa levar em conta as considerações de migração, dependendo das respostas a essas perguntas.

Você precisa capturar essas personalizações na imagem de contêiner que o Red Hat OpenShift no Azure executa. Quando você usa a oferta predefinida do Azure Marketplace, essas personalizações são melhor tratadas criando uma imagem de contêiner personalizada e disponibilizando-a em um registro público e, em seguida, apontando para esse registro no momento da implantação.

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, consulte 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 do JMS, você precisa migrá-los para um servidor do JMS hospedado externamente. Uma estratégia para pessoas que usam JMS é usar o Barramento de Serviço do Azure e o Advanced Message Queuing Protocol. Para obter mais informações, confira Usar o Java Message Service 1.1 com o padrão de 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 IBM MQ, poderá migrar esse software para as Máquinas Virtuais do Azure e usá-lo no estado em que se encontra.

A Microsoft tem uma solução para integrar o IBM MQ com os Aplicativos Lógicos. Para obter mais informações, consulte Conectar a um servidor IBM MQ de um fluxo de trabalho nos Aplicativos Lógicos do Azure.

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.

É possível manipular essas bibliotecas usando as mesmas técnicas descritas em Acessando APIs de terceiros em um aplicativo Java EE.

Determinar se pacotes OSGi são usados

Se você usou pacotes OSGi adicionados ao WAS, precisa adicionar os arquivos JAR equivalentes diretamente ao seu aplicativo Web.

Você pode incluir os pacotes na imagem fornecida para a oferta predefinida do Azure Marketplace. Para obter mais informações, consulte Configurando bibliotecas para aplicativos OSGi.

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 se o aplicativo estiver em execução no Windows.

O Liberty no Red Hat OpenShift no Azure é executado no Linux x86_64. Qualquer código específico do sistema operacional deve ser compatível com o Linux. Para saber como descobrir informações específicas do sistema operacional, siga as etapas na seção Determinar se a versão do Liberty é compatível.

Determinar se o IBM Integration Bus está em uso

Se seu aplicativo estiver usando o IBM Integration Bus, você precisará capturar como o IBM Integration Bus está configurado. Para obter mais informações, consulte a documentação do IBM Integration Bus.

O IBM Integration Bus não tem suporte direto na oferta predefinida do Azure Marketplace. Para ativar o recurso, siga as instruções em Ativando o aplicativo JMS no Liberty para se conectar ao barramento de integração de serviços na documentação da IBM.

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, ibm-application-bnd.xmi e ibm-application-ext.xmi e capture as configurações deles. Para obter mais informações, consulte Construindo o pacote de arquivo corporativo (EAR) no WebSphere.

A oferta predefinida do Azure Marketplace permite que você use uma imagem de contêiner existente. Você pode preparar o aplicativo de acordo com seus requisitos de negócios.

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 e como o sistema de arquivos é usado

O Kubernetes lida com sistemas de arquivos com PV (volumes persistentes). Não há suporte para a montagem de volumes persistentes na oferta predefinida do Azure Marketplace. Para criar uma StorageClass dos Arquivos do Azure, siga as instruções em Criar uma StorageClass dos Arquivos do Azure no Red Hat OpenShift 4 no Azure.

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 migraçã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.

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.

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, capture a topologia de rede de sua implantação existente. Em seguida, você precisa reproduzir essa topologia no Azure, mesmo depois de manter a oferta básica com um dos modelos de solução.

Topologia de rede é 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 o aplicativo existente usar adaptadores JCA ou adaptadores de recursos para se conectar a outros sistemas corporativos, certifique-se de aplicar a configuração desses artefatos ao servidor Liberty em execução no AKS (Serviço de Kubernetes do Azure). Para obter mais informações, consulte Visão geral dos elementos de configuração do JCA e Arquitetura do conector Java.

Determinar se o clustering é ou não usado

O operador lida com clustering para todas as maneiras possíveis de executar uma carga de trabalho do WAS no Red Hat OpenShift no Azure.

Inspecionar o clustering EJB

Se o seu aplicativo estiver usando Enterprise Java Beans (EJB) locais, talvez seja necessário migrá-los para um EJB em cluster. Para obter mais informações, consulte Desenvolvendo aplicativos EJB no Liberty.

Conta para requisitos de balanceamento de carga

A oferta predefinida do Azure Marketplace usa uma rota interna do OpenShift para hospedar o aplicativo em um URL público e uma conta para balanceamento de carga. Para obter mais informações, consulte Configuração do OpenShift Route.

Migração

As etapas nesta seção pressupõem que sua análise levou você a optar pela oferta predefinida do Azure Marketplace.

Provisionar a oferta

Para abrir a oferta no portal do Azure, consulte IBM WebSphere Liberty e Open Liberty no Red Hat OpenShift no Azure. Selecione Criar e use as informações coletadas nas etapas anteriores para ajudar no preenchimento dos campos da oferta.

Considerar os repositórios de chaves

Você deve considerar a migração de todos os repositórios de chaves SSL/TLS 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, é possível configurar o JMS seguindo as instruções em Visão geral dos elementos de configuração do JCA na documentação da IBM.

Considerar o registro em log

Você não pode usar a nuvem sem dominar o registro em log. O operador fornece diferentes abordagens para monitoramento. Para obter mais informações, consulte Monitorando o ambiente de runtime do servidor Liberty. É útil dominar o sistema de registro e monitoramento no Red Hat OpenShift. Para obter mais informações, consulte Noções básicas sobre o subsistema de registro do Red Hat OpenShift e Sobre o monitoramento do OpenShift Container Platform. Você pode configurar insights de contêineres do Azure Monitor para o Red Hat OpenShift no Azure. Para obter mais informações, consulte Configurar insights de contêineres do Azure Monitor para o Red Hat OpenShift no Azure. Se você preferir usar o Elastic Stack, o Azure oferece um ótimo suporte para o Elastic. Para obter detalhes completos, consulte O que é a integração do Elastic com o Azure? Você pode combinar o conhecimento desses recursos para obter uma solução de registro otimizada para o Azure para o Liberty no Red Hat OpenShift no Azure.

Migre os aplicativos

Independentemente de você optar ou não por fornecer uma imagem de aplicativo no momento da implantação, será necessário atualizar o aplicativo por meio de CI/CD. A documentação do OpenShift tem exemplos que mostram como fazer essa atualização. Para obter mais informações, consulte Visão geral de CI/CD do OpenShift Container Platform.

Configurar testes

Configure os testes no contêiner em relação a aplicativos 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. Os artigos a seguir fornecem informações sobre aprimoramentos pós-migração: