Migrar aplicativos WebSphere para o Serviço Kubernetes do Azure

  • Artigo

Este guia descreve o que você deve estar ciente quando deseja migrar uma carga de trabalho existente do WebSphere Application Server (WAS) para o IBM WebSphere Liberty ou Open Liberty no Azure Kubernetes Service (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 WAS para o Azure é selecionar o destino de migração mais apropriado.

O WAS tradicional funciona bem nas Máquinas Virtuais do Azure. O destino da máquina virtual (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 é análoga à 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 Kubernetes do Azure (AKS) e no Azure Red Hat OpenShift. 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 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 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 WebSphere para Máquinas Virtuais do Azure.

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

Para migração baseada em AKS, você pode começar a usar o nível Gratuito. Obtenha gerenciamento de cluster gratuito e pague apenas pelas máquinas virtuais, armazenamento associado e recursos de rede consumidos. Nesse caso, consulte Migrar aplicativos WebSphere para o Serviço Kubernetes do Azure.

Para a migração baseada no Azure Red Hat OpenShift, além dos custos de computação e infraestrutura, os nós de aplicativo têm outro custo para o componente de licença do OpenShift. Esse custo é cobrado 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 às necessidades de sua carga de trabalho e negócios. Nesse caso, consulte Migrar aplicativos WebSphere para o Azure Red Hat OpenShift.

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

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

Depois de decidir que o AKS é o destino de implementação apropriado, você deve aceitar que o operador IBM WebSphere Liberty ou Open Liberty Operator (o operador) é a única maneira de executar o Liberty 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. Eis alguns aspetos a considerar sobre a oferta pré-criada do Azure Marketplace:

  • A IBM e a Microsoft criaram esta oferta para permitir que você provisione rapidamente o Liberty no AKS. Este conceito é explicado mais detalhadamente no conteúdo a seguir.
  • Em um alto nível, a oferta automatiza as seguintes etapas para você.
    • Tire uma imagem de aplicativo existente, se desejar.
    • Provisione um cluster AKS e uma instância do Azure Container Registry (ACR), se desejar.
    • Instale e configure o operador IBM WebSphere Liberty ou o operador Open Liberty no AKS.
    • Use o operador para executar a coisa toda. O operador implanta e gerencia aplicativos Liberty em contêineres no AKS. É possível encontrar a documentação de referência em IBM WebSphere Liberty operator e Open Liberty operator.

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 está disponível em IBM WebSphere Liberty operator e Open Liberty operator.

Agora que você foi apresentado às várias maneiras de lidar com o Liberty 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 Liberty é compatível

Você precisa do operador Open Liberty ou do operador WebSphere Liberty para implementar e gerenciar aplicativos em clusters baseados em Kubernetes. Certifique-se de que a sua versão existente do Liberty é 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 pré-criada do Azure Marketplace permite-lhe selecionar as imagens da sua aplicação a partir do registo público e, assim, suporta implicitamente 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 WebSphere Liberty. Para obter mais informações, consulte Executando o WebSphere Liberty no Microsoft Azure.

Se a edição do produto for algo diferente do IBM WebSphere Application Server padrão (base), o .spec.license.edition value deverá especificar a 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 pré-criada do Azure Marketplace permite-lhe selecionar a edição do produto suportada.

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

Para mover seus aplicativos para o WebSphere Application Server Liberty ou Open Liberty, você precisa planejar sua migração, analisar seus aplicativos e atualizar seu código-fonte. 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.

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 servidores de aplicativos como o WAS, esses segredos estão em muitos arquivos de configuração e armazenamentos de configuração diferentes. Procure segredos e palavras-passe nas propriedades e nos ficheiros de configuração do servidor ou servidores de produção. Também poderá encontrar ficheiros de configuração com palavras-passe ou credenciais dentro da aplicação. 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 de ter um inventário sólido de segredos, consulte a documentação do operador sobre segredos. Para obter mais informações, consulte os seguintes artigos que podem estar em inglês:

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

Verificar se a versão de Java suportada funciona corretamente

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

O tempo de execução 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 da versão Java para recursos.

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

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 recursos e bancos de dados JNDI, consulte WebSphere Data Sources na documentação da IBM. 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 do JMS, consulte Usando recursos do JMS.

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. Para o WebSphere Liberty no AKS, é possível disponibilizar um objeto no namespace Java Naming and Directory Interface (JNDI) padrão. Para obter mais informações, consulte Desenvolvendo com o namespace padrão JNDI em um recurso Liberty. Para Open Liberty, consulte Java Naming and Directory Interface.

Inspecione a configuração do seu perfil

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

Na aplicação

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 AKS executa. Quando você usa a oferta pré-criada 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 estiver usando uma célula do WebSphere Application Server Network Deployment, cada membro do cluster será executado em uma instalação do WAS tradicional. Liberty é um perfil leve do WebSphere Application Server. É um perfil flexível e dinâmico do WAS, que permite que o servidor WAS implemente apenas os recursos personalizados necessários, em vez de implementar um grande conjunto de componentes Java EE disponíveis.

Determinar se é utilizada a replicação de sessões

Se seu aplicativo depende da replicação de sessão, você tem as seguintes opções:

  • Para sessões HTTP, de acordo com o nível de gerenciamento de sessão, você pode usar cache ou um banco de dados para coletar dados de sessão.
  • Para sessões distribuídas, você pode salvar sessões em um banco de dados usando a persistência da sessão do banco de dados.
  • Para cache dinâmico, você pode gerenciar dados de sessão em 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, veja Azure Cache for Redis (Cache do Azure para Redis).

Para todas essas opções, é uma boa ideia dominar como o Liberty faz a Replicação de Estado de Sessão HTTP. Os seguintes documentos ajudam você a entender como gerenciar sessões HTTP no Liberty:

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.

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

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

A oferta pré-criada 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 seguintes personalizações foram feitas e capture as que o foram.

  • Os scripts de arranque foram alterados? Esses scripts incluem wsadmin, AdminControl, AdminConfig, AdminApp e AdminTask.
  • São transmitidos parâmetros específicos para a JVM?
  • Foram adicionados JARs ao classpath do servidor?
  • Os recursos no nível do sistema operacional foram systemd 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 AKS executa. Quando você usa a oferta pré-criada 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 é 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 seu aplicativo estiver usando Filas ou Tópicos JMS, você precisará migrá-los para um servidor JMS hospedado externamente. Uma estratégia para aqueles que usam JMS é usar o Barramento de Serviço do Azure e o Protocolo Avançado de Enfileiramento de Mensagens. Para obter mais informações, veja Utilizar o JMS com o Azure Service Bus e o AMQP 1.0.

Se você configurou armazenamentos persistentes JMS, deverá capturar sua configuração e aplicá-la após a migração.

Se estiver usando o IBM MQ, você poderá migrar esse software para Máquinas Virtuais do Azure e usá-lo como está.

A Microsoft tem uma solução para integrar o IBM MQ com Aplicativos Lógicos. Para obter mais informações, consulte Conectar-se a um servidor IBM MQ a partir de um fluxo de trabalho no Azure Logic Apps.

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.

Você pode manipular essas bibliotecas usando as mesmas técnicas descritas em Acessando APIs de terceiros a partir de um aplicativo Java EE.

Determinar se os conjuntos OSGi são utilizados

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

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

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.

Liberty no AKS roda em Linux x86_64. Qualquer código específico do SO deve ser compatível com 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 é suportado diretamente na oferta pré-criada 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ço na documentação da IBM.

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 seu aplicativo for empacotado como um arquivo EAR, certifique-se de examinar os arquivos application.xml, ibm-application-bnd.xmi e ibm-application-ext.xmi e capturar suas configurações. Para obter mais informações, consulte Building the enterprise archive (EAR) package on WebSphere.

A oferta pré-criada 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 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 e como é que o sistema de ficheiros é utilizado

O Kubernetes lida com sistemas de arquivos com volumes persistentes (PV). A montagem de volumes persistentes não é suportada na oferta pré-criada do Azure Marketplace. Para habilitar diferentes opções de armazenamento, siga as instruções em Opções de armazenamento para aplicativos no Serviço Kubernetes do Azure.

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 abranger aspetos da sua arquitetura que você precisa migrar, você precisará capturar a topologia de rede de sua implantação existente. Em seguida, você precisa reproduzir essa topologia no Azure, mesmo depois de apresentar a oferta básica com um dos modelos de solução.

A topologia de rede é um tópico amplo, mas as referências a seguir podem dar alguma direção aos seus esforços de migração:

  • Para obter uma enumeração dos tópicos de alto nível relevantes para a migração da topologia de rede para o Azure, consulte Topologias do WebSphere Application Server Network Deployment.
  • Como as fontes de dados são servidores separados em um sistema Liberty, você deve considerá-las como parte da análise de topologia de rede. Para obter mais informações, consulte WebSphere Application Server Liberty Data Sources.
  • As origens das mensagens também são servidores separados. Para obter mais informações, consulte WebSphere Application Server Liberty: WebSphere MQ messaging.
  • O balanceamento de carga é um requisito fundamental. Para obter informações sobre o lado Liberty do balanceamento de carga, consulte Arquitetura coletiva Liberty do WebSphere Application Server.

Conta para o uso de adaptadores JCA e adaptadores de recursos

Se seu aplicativo existente usa 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. Para obter mais informações, consulte Visão geral dos elementos de configuração JCA e Arquitetura Java Connector.

Determinar se o clustering é usado

O operador lida com clustering para todas as maneiras possíveis de executar a carga de trabalho do WAS no AKS.

Inspecione seu cluster EJB

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

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.

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 IBM WebSphere Liberty e Open Liberty no Serviço Kubernetes do Azure. Selecione Criar e use as informações coletadas nas etapas anteriores para ajudar no preenchimento dos campos da oferta.

Considerar os KeyStores

Você deve levar em conta a migração de quaisquer KeyStores SSL/TLS usados pelo seu aplicativo. Para obter mais informações, veja Configuring Keystores (Configurar Keystores).

Ligar as origens do 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 JCA na documentação da IBM.

Considerar o registo

Você não pode fazer nuvem sem dominar o registro. O operador fornece diferentes abordagens para monitoramento. Para obter mais informações, consulte Monitorando o ambiente de tempo de execução do servidor Liberty. 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 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 o Liberty no AKS.

Migre as suas aplicações

Se você optou ou não por fornecer uma imagem do aplicativo no momento da implantação, você precisa atualizar o aplicativo via CI/CD. A documentação da IBM tem uma amostra que mostra como fazer essa atualização. Para obter mais informações, consulte Implantando aplicativos no Liberty.

Configurar testes

Você deve configurar quaisquer testes no contêiner em aplicativos para acessar os novos servidores em execução no 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. Os seguintes artigos fornecem informações sobre aprimoramentos pós-migração: