Partilhar via

Migrar aplicativos do 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

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.

Mudar para uma plataforma suportada

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 suportadas de seu ambiente atual antes de continuar com qualquer uma das etapas restantes. Certifique-se de que testa a configuração resultante na íntegra. Utilize a versão estável mais recente da sua distribuição Linux nestes testes.

Observação

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

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

Inventariar os recursos externos

Identifique os recursos externos, tais como origens de dados, mediadores de mensagens JMS e URLs de outros serviços. Em aplicativos Spring Boot, você normalmente 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 para quaisquer definições de configuração pertinentes.

Bases 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. Eis um exemplo de um ficheiro application.properties:

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

Eis um exemplo de um ficheiro 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:

Agentes de mensagens JMS

Identifique o broker ou brokers em uso procurando no manifesto de compilação (normalmente, um arquivo pom.xml ou build.gradle ) as dependências relevantes.

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

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

Os aplicativos Spring Boot que usam corretores comerciais normalmente contêm dependências diretamente nas bibliotecas de drivers JMS dos corretores. Eis um exemplo de um ficheiro build.gradle:

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

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

Observação

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.

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 dos componentes do IBM MQ Spring.

Identificar caches externos

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

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

Provedores de identidade

Identifique o(s) provedor(es) de identidade usado(s) pelo seu aplicativo. Para obter informações sobre como os provedores de identidade podem ser configurados, consulte o seguinte:

  • Para a configuração do OAuth2, consulte a referência do Spring Security.
  • Para a configuração do Auth0 Spring Security, consulte a documentação do Auth0 Spring Security.
  • Para a configuração do PingFederate Spring Security, consulte as instruções do Auth0 PingFederate.

Todos os outros recursos externos

Não é exequível documentar todas as dependências externas possíveis neste guia. É responsabilidade da sua equipe verificar se cada dependência externa do seu aplicativo pode ser satisfeita após uma migração do Serviço de Aplicativo.

Inventariar segredos

Palavras-passe e cadeias protegidas

Procure cadeias de segredos e palavras-passe nas propriedades e nos ficheiros de configuração e nas variáveis ambientais nas implementações de produção. Em um aplicativo Spring Boot, essas cadeias de caracteres provavelmente serão encontradas em application.properties ou application.yml.

Inventariar certificados

Documente todos os certificados utilizados em pontos finais SSL públicos ou em comunicações com bases de dados de back-end e outros sistemas. Pode ver todos os certificados no servidor ou servidores de produção com o comando seguinte:

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

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

Qualquer utilização do sistema de ficheiros no servidor de aplicações irá exigir uma reconfiguração ou, em casos raros, alterações da arquitetura. Poderá identificar alguns ou todos os cenários seguintes.

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.

Casos Especiais

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

Determinar se a aplicação depende de tarefas agendadas

As tarefas agendadas, tais como tarefas do Quartz Scheduler ou do Cron, não podem ser utilizadas com o Serviço de Aplicações. O Serviço de Aplicativo não impedirá que você implante um aplicativo que contenha 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 todos os trabalhos agendados, dentro ou fora do processo de candidatura.

Determinar se a aplicação contem código de SO específico

Se seu aplicativo contiver qualquer código com dependências no sistema operacional 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 por File.Separator ou Paths.get se seu aplicativo estiver sendo executado no Windows.

Identificar todos os processos/daemons externos em execução no(s) servidor(es) de produção

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

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

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

Migração

Parametrizar a configuração

Certifique-se de que todas as coordenadas de recursos externos (como cadeias de conexão de banco de dados) e outras configurações personalizáveis possam ser lidas a partir de variáveis de ambiente. Se você estiver migrando um aplicativo Spring Boot, todas as definições de configuração já devem 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 de Serviço de Aplicações

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 planeia executar implementações de teste/proteção ou utilizar blocos de implementação, o plano do Serviço de Aplicações tem de incluir essa capacidade adicional. Recomendamos a utilização de planos Premium ou superiores para aplicações Java.

Crie o plano do Serviço de Aplicações.

Criar e Implementar Aplicações Web

Você precisará criar uma aplicação Web no seu plano de serviço de aplicações (escolhendo "Java SE" como a pilha de tempo de execução) para cada ficheiro JAR executável que pretenda executar.

Aplicações do Maven

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.

Aplicações não pertencentes ao Maven

Se não puder utilizar o plug-in do Maven, terá de aprovisionar a aplicação Web através de outros mecanismos, tais como:

Uma vez criada a aplicação Web, utilize um dos mecanismos de implementação disponíveis para implementar a sua aplicação. Se possível, a sua aplicação deve ser carregada para /home/site/wwwroot/app.jar. Se você não quiser renomear seu JAR para app.jar, você pode carregar um shell script 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 a partir do diretório no qual foi colocado. Por isso, utilize sempre caminhos absolutos para referenciar ficheiros no script de arranque (por exemplo: java -jar /home/myapp/myapp.jar).

Migrar opções de runtime JVM

Se a sua aplicação necessitar de opções específicas de runtime, utilize o mecanismo mais adequado para as especificar.

Configurar o domínio personalizado e o SSL

Se a sua aplicação estiver visível num domínio personalizado, tem de mapear a aplicação Web para o mesmo. Para obter mais informações, consulte Tutorial: Mapear um nome DNS personalizado existente para o Serviço de Aplicativo do Azure.

Em seguida, tem de vincular o certificado SSL desse domínio à Aplicação Web do Serviço de Aplicações. Para obter mais informações, veja Proteger um nome DNS personalizado com um enlace SSL no Serviço de Aplicações do Azure.

Importar certificados de back-end

Todos os certificados para comunicação com sistemas de back-end, como bases de dados têm de ser disponibilizados para o Serviço de Aplicações. Para obter mais informações, veja Adicionar um certificado SSL no Serviço de Aplicações.

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. Qualquer configuração de aplicativo Spring Boot não explicitamente parametrizada com variáveis de ambiente ainda pode ser substituída 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 Serviço de Aplicações

Migrar trabalhos agendados

Para executar trabalhos agendados no Azure, considere utilizar um acionador Temporizador para as Funções do Azure. Não é preciso migrar o código do trabalho para uma função. Esta pode simplesmente invocar um URL na aplicação para acionar o trabalho. Se essas execuções de trabalhos tiverem de ser invocadas dinamicamente e/ou monitorizadas centralmente, considere utilizar o Spring Batch.

Em alternativa, pode criar uma aplicação lógica com um acionador Recorrência para invocar o URL sem escrever código fora da aplicação. Para obter mais informações, veja Descrição Geral – O que é o Azure Logic Apps? e Criar, agendar e executar tarefas e fluxos de trabalho recorrentes com o acionador Recorrência no Azure Logic Apps.

Observação

Para evitar utilizações maliciosas, é provável que tenha de confirmar que o ponto final de invocação dos trabalhos exige credenciais. Nesse caso, a função de acionador terá de fornecer essas credenciais.

Migrar e habilitar o provedor de identidade

Se seu aplicativo exigir autenticação ou autorização, verifique se eles estão configurados para acessar o provedor de identidade usando as seguintes orientações:

  • Se o provedor de identidade for o Microsoft Entra ID, nenhuma alteração deverá ser necessária.
  • Se o provedor de identidade for uma floresta do Ative Directory local, 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 o PingFederate, consulte o tópico Instalação personalizada do Microsoft Entra Connect para configurar a federação com o Microsoft Entra ID. Como alternativa, considere usar o Spring Security para usar seu provedor de identidade por meio do OAuth2/OpenID Connect ou SAML.

Reiniciar e efetuar teste de fumo

Por fim, terá de reiniciar a sua aplicação Web para aplicar todas as alterações de configuração. Após a conclusão do reinício, verifique se a sua aplicação está a funcionar corretamente.

Pós-migração

Agora que já migrou a sua aplicação para o Serviço de Aplicações do Azure, deve verificar se esta funciona como esperado. Depois de fazer isso, temos algumas recomendações para você que podem tornar seu aplicativo mais nativo da nuvem.

Recomendações

  • Last updated on