Migrar aplicativos do JBoss EAP para o JBoss EAP no Serviço de Aplicativo do Azure
Este guia descreve as informações das quais você deverá estar ciente quando desejar migrar um aplicativo do JBoss EAP existente para execução no JBoss EAP em uma instância do Serviço de Aplicativo do 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.
Inventariar a capacidade do servidor
Documente o hardware (memória, CPU, disco) dos servidores de produção atuais, assim como as contagens de solicitações média e de pico e a utilização de recursos. Você precisará dessas informações independentemente do caminho de migração que escolher. Elas são úteis, por exemplo, para ajudar a orientar a seleção do tamanho das VMs no pool de nós, da quantidade de memória a ser usada pelo contêiner e de quantos compartilhamentos de CPU o contêiner precisa.
É possível redimensionar pools de nós no AKS. Para saber como, consulte Redimensionar pools de nós no AKS (Serviço de Kubernetes do Azure).
Inventariar todos os segredos
Verifique todas as propriedades e os arquivos de configuração nos servidores de produção em busca de segredos e senhas. Não se esqueça de verificar o jboss-web.xml em seus WARs. Arquivos de configuração que contenham senhas ou credenciais também podem ser encontrados dentro de seu aplicativo.
Considere armazenar esses segredos no Azure Key Vault. Para saber mais, consulte Conceitos básicos do Azure Key Vault.
Você pode usar segredos do Key Vault na sua instância do Serviço de Aplicativo com as referências do Key Vault. As referências do Key Vault permitem que você use os segredos no seu aplicativo, mantendo-os protegidos e criptografados em repouso. Para obter mais informações, confira Usar as referências do Key Vault para o Serviço de Aplicativo e o Azure Functions.
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>
Validar se a versão Java com suporte funciona corretamente
O JBoss EAP nas VMs do Azure exige uma versão compatível do Java. Para obter orientações sobre qual versão do JDK usar, consulte Configurações com suporte na documentação do Red Hat.
Observação
Essa validação é especialmente importante se o servidor atual estiver sendo executado em um JDK não compatível (como Oracle JDK ou IBM OpenJ9).
Para determinar a sua versão atual do Java, entre no servidor de produção e execute o seguinte comando:
java -version
Recursos externos de inventário
Recursos externos, como fontes de dados, agentes de mensagem JMS e outros, são injetados por meio de JNDI (Interface de Nomenclatura e Diretório do Java). Alguns desses recursos podem exigir migração ou reconfiguração.
Dentro de seu aplicativo
Inspecione os arquivos WEB-INF/jboss-web.xml e/ou WEB-INF/web.xml. Procure elementos de <Resource>
dentro do elemento <Context>
.
Fontes de dados
Fontes de dados são recursos de JNDI com o atributo type
definido como javax.sql.DataSource
. Para cada fonte de dados, documente as seguintes informações:
- 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 obter mais informações, consulte Sobre fontes de dados do JBoss EAP na documentação do JBoss EAP.
Todos os outros recursos externos
Não é possível documentar todas as dependências externas possíveis neste guia. É responsabilidade da sua equipe verificar se você pode atender a todas as dependências externas de seu aplicativo após a migração.
Determinar se a replicação de sessão é usada
Se seu aplicativo depender da replicação de sessão, você precisará alterar seu aplicativo para remover essa dependência. O Serviço de Aplicativo não permite que as instâncias se comuniquem diretamente entre si.
Determinar se e como o sistema de arquivos é usado
Qualquer uso do sistema de arquivos no servidor de aplicativos exigirá reconfiguração ou, em casos raros, alterações de arquitetura. O sistema de arquivos pode ser usado por módulos do JBoss EAP ou pelo código do aplicativo. Você pode identificar alguns ou todos os cenários descritos nas seções a seguir.
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.
Conteúdo dinâmico ou interno
Para arquivos que são frequentemente escritos e lidos pelo aplicativo (como arquivos de dados temporários) ou arquivos estáticos que são visíveis somente para o aplicativo, você pode usar o armazenamento local do Azure associado ao Plano do Serviço de Aplicativo. Para obter mais informações, confira Funcionalidades 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 o aplicativo depende de trabalhos agendados
Os trabalhos agendados, como tarefas do Agendador do Quartz 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 que contenha tarefas agendadas internamente. No entanto, se o aplicativo for escalado horizontalmente, um mesmo trabalho agendado poderá ser executado mais de uma vez por período agendado. Essa situação pode levar a consequências indesejadas.
Inventarie todas as tarefas agendadas em execução nos servidores de produção, dentro ou fora do código do aplicativo.
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ê precisará migrá-los para um servidor do JMS hospedado externamente. O Barramento de Serviço do Azure e o AMQP (Advanced Message Queuing Protocol) podem ser uma excelente estratégia de migração para pessoas que usam o JMS. 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.
Determinar se conectores JCA estão em uso
Se o aplicativo usar conectores JCA, valide se você pode usar o conector JCA no JBoss EAP. Se você puder usar o conector JCA no JBoss EAP, adicione os JARs ao classpath do servidor e coloque os arquivos de configuração necessários na localização correta nos diretórios do servidor do JBoss EAP para que o conector esteja disponível.
Determinar se o JAAS está sendo usado
Se seu aplicativo estiver usando o JAAS, você precisará capturar como o JAAS está configurado. Se estiver usando um banco de dados, você poderá convertê-lo em um domínio JAAS no JBoss EAP. Caso se trate de uma implementação personalizada, será necessário validar que ela pode ser usada no JBoss EAP.
Determinar se seu aplicativo usa um Adaptador de Recurso
Se o aplicativo precisar de um RA (Adaptador de Recurso), ele precisará 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 do JBoss EAP para que ele fique disponível.
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 o arquivo application.xml e capture a configuração.
Observação
Se você deseja conseguir escalar cada um dos seus aplicativos Web independentemente para um melhor uso dos 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 você tiver processos em execução fora do servidor de aplicativos, como daemons de monitoramento, precisará eliminá-los ou migrá-los para outro lugar.
Realizar testes in-loco
Antes de criar as imagens de contêiner, migre o aplicativo para as versões do JDK e do JBoss EAP que pretende usar no Serviço de Aplicativo. Teste o aplicativo cuidadosamente 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 conta as observações a seguir.
Console de gerenciamento do JBoss EAP: o console Web do JBoss não é exposto no Serviço de Aplicativo. Em vez disso, o portal do Azure fornece as APIs de gerenciamento para seu aplicativo, e você deve implantá-lo usando a CLI do Azure, o plug-in do Maven para Azure ou outras ferramentas para desenvolvedores do Azure. A configuração adicional dos recursos do JBoss pode ser obtida usando a CLI do JBoss durante a inicialização do aplicativo.
Transações: a API de transações é compatível e há suporte para recuperação automática de transações. Para obter mais informações, confira Como gerenciar transações no JBoss EAP na documentação do Red Hat.
Modo de domínio gerenciado: em um ambiente de produção de vários servidores, o modo de domínio gerenciado no JBoss EAP oferece funcionalidades gerenciadas centralizadas. 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 pelo gerenciamento de suas instâncias de 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 de vários servidores baseadas em máquina virtual. Para obter mais informações, confira Sobre domínios gerenciados na documentação do Red Hat.
Clustering de servidor para servidor: A partir de 28 de setembro de 2023, a implantação em cluster do JBoss EAP está disponível para o público em geral. Esse suporte significa que você não precisa mais remover os seguintes recursos de seus aplicativos antes de implantá-los no Serviço de Aplicativo:
- Beans de sessão com estado.
- Transações distribuídas.
- Recursos semelhantes que exigem comunicação de instância a instância ou alta disponibilidade.
Para obter mais informações, consulte o anúncio de lançamento e a seção Clustering de Configurar um aplicativo Java para o Serviço de Aplicativo do Azure.
Migração
Kit de Ferramentas de Migração para Aplicativos do Red Hat
O Kit de Ferramentas de Migração para Aplicativos do Red Hat é uma extensão gratuita para o Visual Studio Code. Essa extensão analisa o código e a configuração do aplicativo para fornecer recomendações para a migração para a nuvem do local. Para obter mais informações, consulte Visão geral do Kit de Ferramentas de Migração para Aplicativos.
O conteúdo deste guia ajudará 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 as instâncias EAP em vez da interface de Gerenciamento do JBoss.
Provisionar o Serviço de Aplicativo do Azure para o runtime 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 do aplicativo Web do Linux é criado usando o runtime do JBoss EAP. Você pode criar sites do JBoss EAP somente em camadas do plano do Serviço de Aplicativo PremiumV3 e IsolatedV2.
Verifique se as variáveis de ambiente especificadas têm valores apropriados.
Observação
PremiumV3 e IsolatedV2 são qualificadas para os preços de instância reservada, o que pode reduzir os custos. Para obter mais informações sobre as camadas do plano do Serviço de Aplicativo e o preço da instância reservada, confira Preços do Serviço de Aplicativo.
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 P1V2
az webapp create \
--resource-group $resourceGroup \
--name $jbossWebApp \
--plan $jbossAppServicePlan \
--runtime "JBOSSEAP|7-java8"
# Or use "JBOSSEAP|7-java11" if you're using Java 11
Compilar o aplicativo
Compile o aplicativo usando o comando do Maven a seguir.
mvn clean install -DskipTests
Implantar o aplicativo
Se o seu aplicativo for criado com base em um arquivo POM do Maven, use o plug-in do Aplicativo Web para Maven para criar o aplicativo Web e implantar seu aplicativo. Para obter mais informações, consulte Início Rápido: Criar um aplicativo Java no Serviço de Aplicativo do Azure.
Para automatizar a implantação de aplicativos do JBoss EAP, você pode usar a tarefa do Azure Pipelines para aplicativo Web ou a GitHub Action para implantar no Azure WebApp.
Configurar as fontes de dados
Há três etapas principais ao registrar uma fonte de dados com o JBoss EAP: carregar o driver JDBC, adicionar o driver JDBC como módulo e registrar o módulo. Para obter mais informações, confira Gerenciamento de fonte de dados na documentação do JBoss EAP. O Serviço de Aplicativo é um serviço de hospedagem sem estado, portanto, os comandos de configuração para adicionar e registrar o módulo da fonte de dados devem ter um script e ser aplicados à medida que o contêiner é iniciado.
Para configurar fontes de dados, siga as etapas a seguir.
Obtenha o driver JDBC do banco de dados.
Crie um arquivo de definição do módulo XML para o driver JDBC. O exemplo mostrado abaixo é uma definição do módulo para PostgreSQL. Substitua o valor
resource-root path
pelo caminho para o driver JDBC usado.<?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>
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 a seguir mostra os comandos da CLI do JBoss para PostgreSQL.
Observação
A Microsoft recomenda usar o fluxo de autenticação mais seguro disponível. O fluxo de autenticação descrito neste procedimento, como 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 computador 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
Crie um script de inicialização chamado startup_script.sh que chama os comandos da CLI do JBoss. O exemplo a seguir mostra como chamar o arquivo jboss-cli-commands.cli. Posteriormente, você vai configurar o Serviço de Aplicativo para executar esse script quando a instância for iniciada.
$JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/deployments/tools/jboss-cli-commands.cli
Usando um cliente FTP à sua escolha, carregue o driver JDBC, jboss-cli-commands.cli, startup_script.sh e a definição do módulo em /site/deployments/tools/.
Configure o site para executar startup_script.sh quando o contêiner for iniciado. No portal do Azure, navegue até Configuração > Configuraçõ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.
Reinicie o aplicativo Web, o que fará com que ele execute o script de configuração.
Atualize a configuração da fonte de dados de JTA do aplicativo. Abra o arquivo src/main/resources/META-INF/persistence.xml do aplicativo e localize o elemento
<jta-data-source>
. Substitua o conteúdo como mostrado aqui:<jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>
Compilar o aplicativo
Compile o aplicativo usando o comando do Maven a seguir.
mvn clean install -DskipTests
Implantar o aplicativo
Se o seu aplicativo for criado com base em um arquivo POM do Maven, use o plug-in do Aplicativo Web para Maven para criar o aplicativo Web e implantar seu aplicativo. Para obter mais informações, consulte Início Rápido: Criar um aplicativo Java no Serviço de Aplicativo do Azure.
Para automatizar a implantação de aplicativos do JBoss EAP, você pode usar a tarefa do Azure Pipelines para aplicativo Web ou a GitHub Action para implantar no Azure WebApp.
Após a migração
Agora que você migrou seu aplicativo para o Serviço de Aplicativo do Azure, verifique se ele funciona conforme o esperado. Depois de fazer isso, temos algumas recomendações para você que podem tornar seu aplicativo mais nativo de nuvem.
Recomendações
Se você optou por usar o diretório /home para o armazenamento de arquivos, considere substituí-lo pelo Armazenamento do Azure. Para obter mais informações, confira Acessar o Armazenamento do Microsoft Azure como um compartilhamento de rede em um contêiner no Serviço de Aplicativo.
Se você tiver uma configuração no diretório /home que contenha cadeias de conexão, chaves SSL e outras informações secretas, considere usar Azure Key Vault e/ou injeção de parâmetro com configurações de aplicativo sempre que possível. Para obter mais informações, confira Usar referências do Key Vault para o Serviço de Aplicativo e o Azure Functions e Configurar um aplicativo do Serviço de Aplicativo no portal do Azure.
Considere o uso de slots de implantação para obter implantações confiáveis sem nenhum tempo de inatividade. Para obter mais informações, consulte Configurar ambientes de preparo no Serviço de Aplicativo do Azure.
Crie e implemente uma estratégia de DevOps. Para manter a confiabilidade, aumentando simultaneamente a velocidade de desenvolvimento, considere automatizar implantações e testar com Azure Pipelines. Para obter mais informações, confira Criação e implantação em um aplicativo Web Java. Ao usar slots de implantação, você pode automatizar a implantação em um slot e depois trocá-lo por outro. Para obter mais informações, confira a seção Implantação em um slot de Implantar um Aplicativo Web do Azure (Linux).
Criar a implementar uma estratégia de continuidade dos negócios e recuperação de desastre. Para aplicativos críticos, considere a possibilidade de usar uma arquitetura de implantação em várias regiões. Para obter mais informações, confira Aplicativo Web de várias regiões altamente disponível.