Partilhar via

Migrar aplicações JBoss EAP para o JBoss EAP no Serviço de Aplicações do Azure

  • Artigo

Este guia descreve o que você deve estar ciente quando deseja migrar um aplicativo Red Hat JBoss Enterprise Application Platform (EAP) existente para ser executado no JBoss EAP em uma instância do Serviço de Aplicativo do Azure.

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

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 fazê-lo, consulte Redimensionar pools de nós no Serviço Kubernetes do Azure (AKS).

Inventariar todos os segredos

Verifique todas as propriedades e arquivos de configuração nos servidores de produção para quaisquer segredos e senhas. Certifique-se de verificar jboss-web.xml em seus arquivos do Web Application Archive (WAR). Os arquivos de configuração que contêm senhas ou credenciais também podem ser encontrados dentro do seu aplicativo.

Considere armazenar esses segredos no Azure Key Vault. Para obter mais informações, veja Conceitos básicos do Azure Key Vault.

Pode utilizar segredos do Azure Key Vault na sua instância do Serviço de Aplicações com referências do Azure Key Vault. As referências do Key Vault permitem que se utilizem os segredos na sua aplicação, mantendo-os protegidos e encriptados quando não estão em uso. Para obter mais informações, consulte Referências do Azure Key Vault para App Service e Azure Functions.

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>

Verificar se a versão de Java suportada funciona corretamente

O JBoss EAP on App Service requer uma versão suportada do Java. Para obter orientação sobre qual versão do Java Development Kit (JDK) usar, consulte Configurações suportadas na documentação da Red Hat.

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

Inventariar os recursos externos

Recursos externos, como fontes de dados, agentes de mensagens Java Message Service (JMS) e outros são injetados via Java Naming and Directory Interface (JNDI). Alguns desses recursos podem exigir migração ou reconfiguração.

Na aplicação

Inspecione os arquivos WEB-INF/jboss-web.xml e/ou WEB-INF/web.xml . Procure elementos <Resource> dentro do elemento <Context>.

Origens de Dados

Origens de dados são recursos JNDI com o atributo type definido para javax.sql.DataSource. Documente a seguinte informação de cada origem de dados:

  • Qual é o nome da origem de dados?
  • Qual é a configuração do pool de conexões?
  • Onde posso encontrar o arquivo JAR do driver Java Database Connectivity (JDBC)?

Para obter mais informações, consulte Sobre fontes de dados do JBoss Enterprise Application Platform (EAP) na documentação do JBoss EAP.

Todos os outros recursos externos

Não é exequível documentar todas as dependências externas possíveis neste guia. Cabe à sua equipa verificar que pode satisfazer todas as dependências externas da sua aplicação após a migração.

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

Qualquer uso do sistema de arquivos no servidor de aplicativos requer reconfiguração ou, em casos raros, alterações na arquitetura. Os módulos EAP do JBoss ou o código do seu aplicativo podem usar o sistema de arquivos. Você pode identificar alguns ou todos os cenários descritos nas seções a seguir.

Conteúdo estático com acesso só de leitura

Se o seu aplicativo atualmente serve conteúdo estático, você precisa de um local alternativo para ele. Você deve considerar mover conteúdo estático para o Armazenamento de Blobs do Azure e adicionar o Azure Front Door para downloads rápidos globalmente. Para obter mais informações, consulte hospedagem de site estático no Armazenamento do Azure e integrar uma conta de armazenamento do Azure com o Azure Front Door.

Conteúdo dinâmico ou interno

Para arquivos que são frequentemente gravados e lidos pelo seu aplicativo (como arquivos de dados temporários) ou arquivos estáticos que são visíveis apenas para seu aplicativo, você pode usar o armazenamento de arquivos local associado ao seu plano de serviço de aplicativo. Para obter mais informações, consulte Funcionalidade do sistema operacional no Serviço de Aplicativo do Azure e Noções básicas sobre o sistema de arquivos do Serviço de Aplicativo do Azure.

Determinar se a aplicação depende de trabalhos agendados

Trabalhos agendados, como tarefas do Agendador de Quartzo ou trabalhos cron do Unix, NÃO devem ser usados com o Serviço de Aplicativo do Azure. O Serviço de Aplicativo do Azure não impedirá que você implante um aplicativo contendo tarefas agendadas internamente. Contudo, se a sua aplicação estiver ampliada, a mesma tarefa agendada pode ser executada mais de uma vez por período agendado. Esta situação pode provocar consequências não intencionais.

Inventarie todas as tarefas agendadas em execução no(s) servidor(es) de produção, dentro ou fora do código do aplicativo.

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 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 as Filas ou Tópicos 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 Advanced Message Queuing Protocol (AMQP) podem ser uma excelente estratégia de migração para quem utiliza o JMS. Para obter mais informações, consulte Usar o Java Message Service 1.1 com o Azure Service Bus Standard e 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.

Determinar se há conectores JCA em utilização

Se seu aplicativo usa conectores JCA (Java Connector Architecture), valide se você pode usar o conector JCA no JBoss EAP. Se você puder usar o conector JCA no JBoss EAP, para que ele esteja disponível, você deve adicionar os arquivos Java Archive (JAR) ao classpath do servidor e colocar os arquivos de configuração necessários no local correto nos diretórios do servidor JBoss EAP.

Determinar se o JAAS está a ser utilizado

Se a sua aplicação utilizar o JAAS, tem de capturar a forma como este é configurado. Se estiver usando um banco de dados, você poderá convertê-lo em um domínio JAAS no JBoss EAP. Se for uma implementação personalizada, você precisará validar que ela pode ser usada no JBoss EAP.

Determinar se a aplicação utiliza um Adaptador de Recursos

Se seu aplicativo precisa de um adaptador de recursos (RA), ele precisa ser compatível com o JBoss EAP. Determine se o RA funciona bem em uma instância autônoma do JBoss EAP implantando-o no servidor e configurando-o corretamente. Se o RA funcionar corretamente, você precisará adicionar os JARs ao classpath do servidor do Serviço de Aplicativo e colocar os arquivos de configuração necessários no local correto nos diretórios do servidor JBoss EAP para que ele esteja disponível.

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 ficheiro EAR, certifique-se de que examina o ficheiro application.xml e captura a configuração.

Nota

Se quiser ser capaz de dimensionar cada um dos seus aplicativos Web de forma independente para melhor usar os recursos do Serviço de Aplicativo, divida o EAR em aplicativos Web separados.

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.

Realizar testes no local de origem

Antes de criar seus aplicativos Web, migre seu aplicativo para as versões JDK e JBoss EAP que você pretende usar no Serviço de Aplicativo. Teste a aplicação de forma minuciosa para garantir a compatibilidade e o desempenho.

Notas de recursos do JBoss EAP no Serviço de Aplicativo

Ao usar o JBoss EAP no Serviço de Aplicativo, leve em consideração as seguintes notas.

  • Console de gerenciamento do JBoss EAP: o console da web do JBoss não está exposto no App Service. Em vez disso, o portal do Azure fornece as APIs de gerenciamento para seu aplicativo e você deve implantar usando a CLI do Azure, o Plug-in do Azure Maven ou outras ferramentas de desenvolvedor do Azure. A configuração adicional dos recursos do JBoss pode ser obtida usando a CLI do JBoss durante a inicialização do aplicativo.

  • Transactions: A API de transações é suportada e há suporte para recuperação automática de transações. Para obter mais informações, consulte Gerenciando transações no JBoss EAP na documentação da Red Hat.

  • Modo de domínio gerenciado: em um ambiente de produção multisservidor, o modo de domínio gerenciado no JBoss EAP oferece recursos gerenciados centralizados. No entanto, com o JBoss EAP no Serviço de Aplicativo, a plataforma do Serviço de Aplicativo assume a responsabilidade pela configuração e gerenciamento das instâncias do servidor. O Serviço de Aplicativo elimina a necessidade do modo de domínio gerenciado do JBoss EAP. O modo de domínio é uma boa opção para implantações multisservidor baseadas em máquina virtual. Para obter mais informações, consulte Sobre domínios gerenciados na documentação da Red Hat.

  • Clusterização servidor-para-servidor: o App Service suporta totalmente as implantações clusterizadas do JBoss EAP. Isso significa que você pode usar com confiança:

    • Beans de sessão com monitoração de estado.
    • Transações distribuídas.
    • Funcionalidades semelhantes que exigem comunicação instância a instância ou alta disponibilidade.

    Para obter mais informações, consulte a seção Clustering de Configurar um aplicativo Java para o Serviço de Aplicativo do Azure.

Migração

Ferramenta de Migração Red Hat para Aplicações

O Red Hat Migration Toolkit for Applications é uma extensão gratuita para o Visual Studio Code. Esta extensão analisa o código e a configuração do aplicativo para fornecer recomendações de migração local para a nuvem. Para obter mais informações, consulte Visão geral do Migration Toolkit for Applications.

O conteúdo deste guia ajuda você a abordar os outros componentes da jornada de migração, como escolher o tipo correto de Plano do Serviço de Aplicativo, externalizar o estado da sessão e usar o Azure para gerenciar suas instâncias EAP em vez da interface de Gerenciamento JBoss.

Provisionar o Serviço de Aplicações do Azure para o tempo de execução do JBoss EAP

Use os comandos a seguir para criar um grupo de recursos e um Plano do Serviço de Aplicativo do Azure. Depois que o Plano do Serviço de Aplicativo é criado, um plano de aplicativo Web Linux é criado usando o tempo de execução do JBoss Enterprise Application Platform (EAP).

Certifique-se de que as variáveis de ambiente especificadas tenham valores apropriados.

az group create --resource-group $resourceGroup --location eastus
az acr create --resource-group $resourceGroup --name $acrName --sku Standard
az appservice plan create \
    --resource-group $resourceGroup \
    --name $jbossAppService \
    --is-linux \
    --sku P0v3
az webapp create \
    --resource-group $resourceGroup \
    --name $jbossWebApp \
    --plan $jbossAppServicePlan \
    --runtime "JBOSSEAP|8-java17"
    #  Or use "JBOSSEAP|8-java11" if you're using Java 11

Criar a aplicação

Crie o aplicativo usando o seguinte comando Maven.

mvn clean install -DskipTests

Implementar a aplicação

Se a sua aplicação tiver sido criada a partir de um ficheiro POM do Maven, utilize o plug-in de aplicações Web para o Maven para criar a aplicação Web e implementar a sua aplicação. Para obter mais informações, veja Início Rápido: Criar uma aplicação Java no App Service do Azure.

Para automatizar a implantação de aplicativos EAP JBoss, você pode usar a tarefa Azure Pipelines for Web App ou GitHub Action para implantar no Azure WebApp.

Configurar origens de dados

Há três etapas principais ao registrar uma fonte de dados com o JBoss Enterprise Application Platform (EAP): carregar o driver JDBC (Java Database Connectivity), adicionar o driver JDBC como um módulo e registrar o módulo. Para obter mais informações, consulte Gerenciamento de fonte de dados na documentação do JBoss EAP. O App Service é um serviço de hospedagem sem estado, portanto, os comandos de configuração para adicionar e registrar o módulo de fonte de dados devem ser scriptados e aplicados quando o contêiner é iniciado.

Para configurar fontes de dados, use as etapas a seguir.

  1. Obtenha o driver JDBC do seu banco de dados.

  2. Crie um arquivo de definição de módulo XML para o driver JDBC. O exemplo mostrado é uma definição de módulo para PostgreSQL. Certifique-se de substituir o valor resource-root path pelo caminho para o driver JDBC que utiliza.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.postgres">
    <resources>
    <!-- ***** IMPORTANT: REPLACE THIS PLACEHOLDER *******-->
    <resource-root path="/home/site/deployments/tools/postgresql-42.2.12.jar" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

  3. Coloque os comandos da CLI do JBoss em um arquivo chamado jboss-cli-commands.cli. Os comandos do JBoss devem adicionar o módulo e registrá-lo como fonte de dados. O exemplo mostra os comandos da CLI do JBoss para PostgreSQL.

    Nota

    A Microsoft recomenda o uso do fluxo de autenticação mais seguro disponível. O fluxo de autenticação descrito neste procedimento, como para bancos de dados, caches, mensagens ou serviços de IA, requer um grau muito alto de confiança no aplicativo e traz riscos não presentes em outros fluxos. Use esse fluxo somente quando opções mais seguras, como identidades gerenciadas para conexões sem senha ou sem chave, não forem viáveis. Para operações de máquina local, prefira identidades de usuário para conexões sem senha ou sem chave.

    module add --name=org.postgres --resources=/home/site/deployments/tools/postgresql-42.2.12.jar --module-xml=/home/site/deployments/tools/postgres-module.xml

/subsystem=datasources/jdbc-driver=postgres:add(driver-name="postgres",driver-module-name="org.postgres",driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)

data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=${POSTGRES_CONNECTION_URL,env.POSTGRES_CONNECTION_URL:jdbc:postgresql://db:5432/postgres} --user-name=${POSTGRES_SERVER_ADMIN_FULL_NAME,env.POSTGRES_SERVER_ADMIN_FULL_NAME:postgres} --password=${POSTGRES_SERVER_ADMIN_PASSWORD,env.POSTGRES_SERVER_ADMIN_PASSWORD:example} --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker

  4. Crie um script de inicialização chamado startup_script.sh que chame os comandos da CLI do JBoss. O exemplo mostra como executar o seu arquivo jboss-cli-commands.cli. Mais tarde, você configura o Serviço de Aplicativo para executar esse script quando a instância é iniciada.

    $JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/deployments/tools/jboss-cli-commands.cli

  5. Usando um cliente FTP de sua escolha, carregue seu driver JDBC, jboss-cli-commands.cli, startup_script.sh e a definição do módulo para /site/deployments/tools/.

  6. Configure seu site para executar startup_script.sh quando o contentor for iniciado. No portal do Azure, navegue até Configurações > Definições Gerais > Comando de Inicialização. Defina o campo de comando de inicialização como /home/site/deployments/tools/startup_script.sh e selecione Salvar.

  7. Reinicie o aplicativo Web, o que faz com que ele execute o script de configuração.

  8. Atualize a configuração da fonte de dados Java Transaction API (JTA) para seu aplicativo. Abra o arquivo src/main/resources/META-INF/persistence.xml do seu aplicativo e localize o <jta-data-source> elemento . Substitua os respetivos conteúdos, conforme mostrado aqui:

    <jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>

Criar a aplicação

Crie o aplicativo usando o seguinte comando Maven.

mvn clean install -DskipTests

Implementar a aplicação

Se a sua aplicação tiver sido criada a partir de um ficheiro POM do Maven, utilize o plug-in de aplicações Web para o Maven para criar a aplicação Web e implementar a sua aplicação. Para obter mais informações, consulte Guia de Início Rápido: Criar uma aplicação Java no App Service do Azure.

Para automatizar a implantação de aplicativos EAP JBoss, você pode usar a tarefa Azure Pipelines for Web App ou GitHub Action para implantar no Azure WebApp.

Pós-migração

Agora que migrou seu aplicativo para o Serviço de Aplicativo do Azure, verifique se ele funciona como esperado. Depois de fazer isso, temos algumas recomendações para você que podem tornar seu aplicativo mais nativo da nuvem.

Recomendações