Compartilhar via

Migrar aplicativos spring boot para o Serviço de Aplicativo do Azure

Este guia descreve o que você deve estar ciente quando deseja migrar um aplicativo Spring Boot existente para o 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.

Alternar para uma plataforma com suporte

O Serviço de Aplicativo oferece versões específicas do Java SE. Para garantir a compatibilidade, migre seu aplicativo para uma das versões com suporte do ambiente atual antes de continuar com qualquer uma das etapas restantes. Certifique-se de testar totalmente a configuração resultante. Use a versão estável mais recente da distribuição do Linux nesses testes.

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

No Serviço de Aplicativo do Azure, os binários para Java 8 são fornecidos do Eclipse Temurin. Para Java 11, 17 e todas as versões LTS futuras do Java, o Serviço de Aplicativo fornece o Build do OpenJDK da Microsoft. Esses binários estão disponíveis para download gratuito nos seguintes sites:

Recursos externos de inventário

Identifique recursos externos, como fontes de dados, agentes de mensagens JMS e URLs de outros serviços. Em aplicativos Spring Boot, normalmente você pode encontrar a configuração para esses recursos na pasta src/main/directory , em um arquivo normalmente chamado application.properties ou application.yml. Além disso, verifique as variáveis de ambiente da implantação de produção em busca de configurações pertinentes.

Bancos de dados

Para um aplicativo Spring Boot, as cadeias de conexão normalmente aparecem em arquivos de configuração quando dependem de um banco de dados externo. Aqui está um exemplo de um arquivo application.properties :

spring.datasource.url=jdbc:mysql://localhost:3306/mysql_db
spring.datasource.username=dbuser
spring.datasource.driver-class-name=com.mysql.jdbc.Driver

Aqui está um exemplo de um arquivo application.yaml :

spring:
  data:
    mongodb:
      uri: mongodb://mongouser:deepsecret@mongoserver.contoso.com:27017

Consulte a documentação do Spring Data para obter mais cenários de configuração possíveis:

Brokers de mensagens JMS

Identifique o intermediário ou os intermediários em uso, analisando o arquivo de build (tipicamente, um arquivo pom.xml ou build.gradle) para as dependências relevantes.

Por exemplo, um aplicativo Spring Boot usando o ActiveMQ normalmente conteria essa dependência em seu arquivo depom.xml :

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-activemq</artifactId>
</dependency>

Os aplicativos Spring Boot que usam agentes comerciais normalmente contêm dependências diretamente nas bibliotecas de driver JMS dos agentes. Aqui está um exemplo de um arquivo build.gradle :

    dependencies {
      ...
      compile("com.ibm.mq:com.ibm.mq.allclient:9.4.0.5")
      ...
    }

Depois de identificar o agente ou os agentes em uso, localize as configurações correspondentes. Em aplicativos Spring Boot, normalmente você pode encontrá-los nos arquivos application.properties e application.yml no diretório do aplicativo.

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.

Aqui está um exemplo do ActiveMQ de um arquivo application.properties :

spring.activemq.brokerurl=broker:(tcp://localhost:61616,network:static:tcp://remotehost:61616)?persistent=false&useJmx=true
spring.activemq.user=admin
spring.activemq.password=<password>

Para obter mais informações sobre a configuração do ActiveMQ, consulte a documentação de mensagens do Spring Boot.

Aqui está um exemplo do IBM MQ de um arquivo application.yaml :

ibm:
  mq:
    queueManager: qm1
    channel: dev.ORDERS
    connName: localhost(14)
    user: admin
    password: <password>

Para obter mais informações sobre a configuração do IBM MQ, consulte a documentação de componentes do IBM MQ Spring.

Identificar caches externos

Identifique os caches externos em uso. Frequentemente, o Redis é usado por meio do Spring Data Redis. Para obter informações de configuração, consulte a documentação do Spring Data Redis .

Determine se os dados de sessão estão sendo armazenados em cache via Spring Session pesquisando a respectiva configuração (em Java ou XML).

Provedores de identidade

Identifique todos os provedores de identidade usados pelo aplicativo. Para obter informações sobre como os provedores de identidade podem ser configurados, consulte o seguinte:

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 todas as dependências externas do aplicativo podem ser atendidas após uma migração do Serviço de Aplicativo.

Segredos de inventário

Senhas e cadeias de caracteres seguras

Verifique todas as propriedades e arquivos de configuração e todas as variáveis de ambiente nas implantações de produção para quaisquer cadeias de caracteres e senhas secretas. Em um aplicativo Spring Boot, essas cadeias de caracteres provavelmente serão encontradas em application.properties ou application.yml.

Certificados de inventário

Documente todos os certificados usados para endpoints SSL públicos ou comunicação com bancos de dados de back-end e outros sistemas. Você pode exibir todos os certificados nos servidores de produção executando o seguinte comando:

keytool -list -v -keystore <path to keystore>

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. Você pode identificar alguns ou todos os cenários a seguir.

Conteúdo estático somente leitura

Se seu aplicativo atualmente serve conteúdo estático, você precisará 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 Microsoft Azure e Integrar uma conta de armazenamento do Azure com o Azure Front Door.

Casos especiais

Determinados cenários de produção podem exigir alterações adicionais ou impor limitações adicionais. Embora esses cenários possam ser pouco frequentes, é importante garantir que eles sejam inaplicáveis ao seu aplicativo ou resolvidos corretamente.

Determinar se o aplicativo depende de trabalhos agendados

Trabalhos agendados, como tarefas do Quartz Scheduler ou cron jobs, não podem ser usados com o App Service. O Serviço de Aplicativo 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.

Faça um inventário de todos os trabalhos agendados, dentro ou fora do processo de aplicativos.

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.

Identificar todos os processos/daemons externos em execução nos servidores de produção

Os processos em execução fora do Servidor de Aplicativos, como os daemons de monitoramento, precisarão ser migrados para outro lugar ou eliminados.

Identificar o tratamento de solicitações não HTTP ou várias portas

O Serviço de Aplicativo dá suporte apenas a um único ponto de extremidade HTTP em uma única porta. Se o aplicativo escutar em várias portas ou aceitar solicitações usando protocolos diferentes de HTTP, não use o Serviço de Aplicativo do Azure.

Migração

Parametrizar a configuração

Verifique se todas as coordenadas de recursos externos (como cadeias de conexão de banco de dados) e outras configurações personalizáveis podem ser lidas de variáveis de ambiente. Se você estiver migrando um Aplicativo Spring Boot, todas as configurações já deverão ser externalizáveis. Para obter mais informações, consulte Configuração Externalizada na documentação do Spring Boot.

Aqui está um exemplo que faz referência a uma SERVICEBUS_CONNECTION_STRING variável de ambiente de um arquivo application.properties :

spring.jms.servicebus.connection-string=${SERVICEBUS_CONNECTION_STRING}
spring.jms.servicebus.topic-client-id=contoso1
spring.jms.servicebus.idle-timeout=10000

Provisionar um plano do Serviço de Aplicativo

Na lista de planos de serviço disponíveis, selecione o plano cujas especificações atendem ou excedem as do hardware de produção atual.

Observação

Se você planeja executar implantações de preparo/canário ou usar slots de implantação, o plano do Serviço de Aplicativo precisará incluir essa capacidade adicional. É recomendável usar planos Premium ou superiores para aplicativos Java.

Crie o plano do Serviço de Aplicativo.

Criar e implantar aplicativos Web

Você precisará criar um aplicativo Web em seu Plano do Serviço de Aplicativo (escolhendo "Java SE" como a pilha de runtime) para cada arquivo JAR executável que você pretende executar.

Aplicativos Maven

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.

Aplicativos não Maven

Se não for possível usar o plug-in do Maven, você precisará provisionar o aplicativo Web por meio de outros mecanismos, como:

Depois que o aplicativo Web tiver sido criado, use um dos mecanismos de implantação disponíveis para implantar seu aplicativo. Se possível, seu aplicativo deve ser carregado em /home/site/wwwroot/app.jar. Se você não quiser renomear seu JAR para app.jar, poderá carregar um script de shell com o comando para executar seu JAR. Em seguida, cole o caminho completo para esse script na caixa de texto Arquivo de Inicialização na seção Configuração do portal. O script de inicialização não é executado por meio do diretório no qual ele é colocado. Portanto, sempre use caminhos absolutos para fazer referência a arquivos em seu script de inicialização (por exemplo: java -jar /home/myapp/myapp.jar).

Migrar opções de runtime da JVM

Se o aplicativo exigir opções de runtime específicas, use o mecanismo mais apropriado para especificá-las.

Configurar o domínio personalizado e o SSL

Se o aplicativo ficar visível em um domínio personalizado, você precisará mapear seu aplicativo Web para ele. Para obter mais informações, confira Tutorial: Mapear um nome DNS personalizado existente para o Serviço de Aplicativo do Azure.

Em seguida, você precisará associar o certificado SSL para esse domínio ao aplicativo Web do Serviço de Aplicativo. Para obter mais informações, consulte Proteger um nome DNS personalizado com uma associação SSL no Serviço de Aplicativo do Azure.

Importar certificados de servidor

Todos os certificados para comunicação com sistemas de back-end, como bancos de dados, precisam ser disponibilizados para o Serviço de Aplicativo. Para obter mais informações, consulte Adicionar um certificado SSL no Serviço de Aplicativo.

Migrar coordenadas de recursos externos e outras configurações

Siga estas etapas para migrar cadeias de conexão e outras configurações.

Observação

Para qualquer configuração de aplicativo Spring Boot parametrizada com variáveis na seção Parametrizar a configuração , essas variáveis de ambiente devem ser definidas na configuração do aplicativo. Todas as configurações do aplicativo Spring Boot não explicitamente parametrizadas com variáveis de ambiente ainda podem ser substituídas por elas por meio da Configuração do Aplicativo. Por exemplo:

spring.jms.servicebus.connection-string=${CUSTOMCONNSTR_SERVICE_BUS}
spring.jms.servicebus.topic-client-id=contoso1
spring.jms.servicebus.idle-timeout=1800000

Configuração do aplicativo do App Service

Migrar os trabalhos agendados

Para executar trabalhos agendados no Azure, considere usar um gatilho timer para o Azure Functions. Você não precisa migrar o código do trabalho propriamente dito para uma função. A função pode simplesmente invocar uma URL no aplicativo para disparar o trabalho. Se essas execuções de trabalho precisarem ser invocadas dinamicamente e/ou controladas centralmente, considere o uso do Spring Batch.

Como alternativa, você pode criar um aplicativo lógico com um gatilho de recorrência para invocar a URL sem escrever nenhum código fora do aplicativo. Para obter mais informações, consulte Visão geral – O que são os Aplicativos Lógicos do Azure? E Criar, agendar e executar tarefas e fluxos de trabalho recorrentes com o gatilho de recorrência nos Aplicativos Lógicos do Azure.

Observação

Para evitar o uso mal-intencionado, você provavelmente precisará garantir que o ponto de extremidade de invocação do trabalho exija credenciais. Nesse caso, a função de gatilho precisará fornecer as credenciais.

Migrar e habilitar o provedor de identidade

Se o aplicativo exigir autenticação ou autorização, verifique se ele está configurado para acessar o provedor de identidade usando as seguintes diretrizes:

  • Se o provedor de identidade for a ID do Microsoft Entra, nenhuma alteração deverá ser necessária.
  • Se o provedor de identidade for uma floresta local do Active Directory, considere implementar uma solução de identidade híbrida com o Microsoft Entra ID. Para obter mais informações, consulte a documentação de identidade híbrida.
  • Se o provedor de identidade for outra solução local, como PingFederate, consulte a instalação personalizada do tópico do Microsoft Entra Connect para configurar a federação com a ID do Microsoft Entra. Como alternativa, considere usar o Spring Security para usar seu provedor de identidade por meio do OAuth2/OpenID Connect ou SAML.

Reinicialização e smoke test

Por fim, você precisará reiniciar seu aplicativo Web para aplicar todas as alterações de configuração. Após a conclusão da reinicialização, verifique se o aplicativo está sendo executado corretamente.

Pós-migração

Agora que seu aplicativo foi migrado para o Serviço de Aplicativo do Azure, você deve verificar 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