Visão geral da migração de aplicativos

Artigo
02/04/2025

Nota

Os planos Basic, Standard e Enterprise serão preteridos a partir de meados de março de 2025, com um período de aposentadoria de 3 anos. Recomendamos a transição para os Aplicativos de Contêiner do Azure. Para obter mais informações, consulte o anúncio de aposentadoria do Azure Spring Apps.

O plano de consumo padrão e dedicado será preterido a partir de 30 de setembro de 2024, com um desligamento completo após seis meses. Recomendamos a transição para os Aplicativos de Contêiner do Azure. Para obter mais informações, consulte Migrar consumo padrão e plano dedicado do Azure Spring Apps para Aplicativos de Contêiner do Azure.

Este artigo aplica-se a:✅ Basic/Standard ✅ Enterprise

Este artigo fornece uma visão geral de uma abordagem de migração de aplicativos do Azure Spring Apps para o Azure Container Apps.

Pré-requisitos

Uma instância existente do Azure Spring Apps.
Um aplicativo de contêiner do Azure existente. Para obter mais informações, veja o Início Rápido: implementar a primeira aplicação de contentor com o portal do Azure.

Implementar uma aplicação

Os Aplicativos de Contêiner do Azure permitem que você implante a partir de registros de contêiner, como o Registro de Contêiner do Azure (ACR) ou o Hub do Docker. Você pode usar ferramentas como o portal do Azure, a CLI do Azure ou outras para a implantação. O exemplo a seguir mostra como implantar um aplicativo no ambiente my-container-appsgerenciado de destino. Para obter mais informações, consulte Implantar seu primeiro aplicativo de contêiner com containerapp up ou Implantar seu primeiro aplicativo de contêiner usando o portal do Azure.

az containerapp up \
    --resource-group my-container-apps \
    --name my-container-app \
    --location centralus \
    --environment 'my-container-apps' \
    --image mcr.microsoft.com/k8se/quickstart:latest \
    --target-port 80 \
    --ingress external

Os Aplicativos de Contêiner do Azure agora oferecem um recurso de visualização para aplicativos Java. Esse recurso permite que os usuários implantem aplicativos diretamente de um arquivo JAR ou código-fonte de um repositório local ou de código. É altamente recomendável que você implante aplicativos de contêiner usando uma imagem de contêiner.

Variáveis de ambiente

Os Aplicativos de Contêiner do Azure permitem configurar variáveis de ambiente. Você pode configurá-los ao criar um novo aplicativo ou posteriormente, criando uma nova revisão.

Para alterar variáveis de ambiente por meio do portal do Azure, você precisa criar uma nova revisão explicitamente. Ao usar a CLI do Azure, você pode atualizar o aplicativo com o comando az containerapp update, conforme mostrado no exemplo a seguir, que cria uma nova revisão automaticamente. É importante não duplicar variáveis de ambiente. Se várias variáveis tiverem o mesmo nome, apenas a última da lista entrará em vigor.

az containerapp update \
    --resource-group <RESOURCE_GROUP_NAME> \
    --name <APP NAME> \
    --set-env-vars <VAR_NAME>=<VAR_VALUE>

Os Aplicativos de Contêiner do Azure também fornecem variáveis de ambiente internas. Essas variáveis oferecem metadados de plataforma úteis durante o tempo de execução. Para obter mais informações, consulte a seção Variáveis de ambiente internas de Gerenciar variáveis de ambiente em Aplicativos de Contêiner do Azure.

Segredos

Os Aplicativos de Contêiner do Azure ajudam a armazenar valores de configuração confidenciais, conhecidos como segredos, com segurança. Esses segredos são definidos no nível do aplicativo como pares nome/valor e são acessíveis a todas as revisões de aplicativos de contêiner.

Recomendamos que você armazene segredos no Cofre da Chave do Azure em vez de inseri-los diretamente. Você pode fazer referência ao valor de cada segredo do Cofre da Chave do Azure usando um dos seguintes formatos:

https://myvault.vault.azure.net/secrets/mysecret refere-se à versão mais recente de um segredo.
https://myvault.vault.azure.net/secrets/mysecret/<version-ID> refere-se a uma versão específica de um segredo.

Para essa abordagem, você deve habilitar a identidade gerenciada para seu aplicativo de contêiner e conceder-lhe acesso ao Cofre da Chave. A política de acesso no Cofre da Chave deve permitir que o aplicativo seja usado GET para obter segredos. Como alternativa, se o Cofre da Chave usar o controle de acesso baseado em função do Azure, você precisará atribuir Key Vault Secrets User a função. Depois de configurar a identidade gerenciada, você pode adicionar uma referência do Cofre da Chave como um segredo em seu aplicativo especificando o URI do segredo. Em seguida, o aplicativo pode recuperar segredo em tempo de execução usando a identidade gerenciada.

Tenha em mente as seguintes regras:

Remover ou alterar um segredo não afeta automaticamente as revisões existentes. Ao atualizar ou excluir segredos, você precisa implantar uma nova revisão ou reiniciar uma existente para refletir as alterações.
Você também pode usar segredos dentro de regras de escala.

Você pode usar segredos em aplicativos de contêiner fazendo referência a eles em variáveis de ambiente ou montando-os em volumes. Em variáveis de ambiente, o valor do segredo é preenchido automaticamente. Como alternativa, você pode montar segredos em volumes. Nesse caso, cada segredo é armazenado como um arquivo com o nome do segredo como o nome do arquivo e o valor secreto como o conteúdo do arquivo. Essa flexibilidade permite que você manipule segredos com segurança e acesse-os dentro do ambiente do aplicativo. Para obter mais informações, consulte Gerenciar segredos em aplicativos de contêiner do Azure.

Se sua carga de trabalho proteger a configuração confidencial e recuperar propriedades do Cofre da chave com spring-cloud-azure-starter-keyvault-secrets biblioteca, você poderá usar o SDK do Azure ou o Spring KeyVault PropertySource nos Aplicativos de Contêiner do Azure. Não é necessário alterar o código durante a migração.

Opções da JVM

Para imprimir as opções da JVM nos Aplicativos de Contêiner do Azure, siga as etapas em Criar Imagem de Contêiner de um JAR ou WAR para conteinerizar seu aplicativo. Você pode adicionar -XX:+PrintFlagsFinal o ENTRYPOINT do seu Dockerfile, conforme mostrado no exemplo a seguir:

# filename: JAR.dockerfile

FROM mcr.microsoft.com/openjdk/jdk:17-mariner

ARG JAR_FILENAME

COPY $JAR_FILENAME /opt/app/app.jar
ENTRYPOINT ["java", "-XX:+PrintFlagsFinal", "-jar", "/opt/app/app.jar"]

Para consultar opções da JVM em Aplicativos de Contêiner do Azure, use a seguinte consulta:

ContainerAppConsoleLogs_CL
| where ContainerAppName_s == "<APP_NAME>"
| where Log_s has_any ('{default}', '{command line}', '{ergonomic}')

O log a seguir é um exemplo que mostra as opções da JVM depois de executar uma consulta:

size_t MinHeapSize = 8388608 {product} {ergonomic}
size_t MaxHeapSize = 268435456 {product} {ergonomic}

Para ajustar as opções da JVM nos Aplicativos de Contêiner do Azure, você pode adicionar opções da JVM no ENTRYPOINT Dockerfile, conforme mostrado no exemplo a seguir:

# filename: JAR.dockerfile

FROM mcr.microsoft.com/openjdk/jdk:17-mariner

ARG JAR_FILENAME

COPY $JAR_FILENAME /opt/app/app.jar
ENTRYPOINT ["java", "-XX:+PrintFlagsFinal", "-Xmx400m", "-Xss200m", "-jar", "/opt/app/app.jar"]

Para obter mais informações sobre as opções da JVM, consulte Opções de VM do Java HotSpot e Configurando opções da JVM.

Armazenamento

Os Aplicativos Azure Spring e os Aplicativos de Contêiner do Azure dão suporte ao armazenamento com escopo de contêiner, o que significa que os dados armazenados no contêiner estão disponíveis apenas enquanto o contêiner está em execução. Para o Azure Spring Apps, o armazenamento total de um aplicativo é de 5 GiB. Os Aplicativos de Contêiner do Azure oferecem armazenamento que varia de 1 GiB a 8 GiB, dependendo do número total de vCPUs alocadas. Esse armazenamento inclui todo o armazenamento efêmero atribuído a cada réplica. Para obter mais informações, consulte a seção Armazenamento efêmero de Usar montagens de armazenamento em Aplicativos de Contêiner do Azure.

Os Aplicativos de primavera do Azure e os Aplicativos de Contêiner do Azure dão suporte ao armazenamento permanente por meio dos Arquivos do Azure. Os Aplicativos de Contêiner do Azure dão suporte à montagem de compartilhamentos de arquivos usando protocolos SMB e NFS. Você precisa criar uma definição de armazenamento no ambiente gerenciado e, em seguida, definir um volume de AzureFile (SMB) ou NfsAzureFile (NFS) em uma revisão. Você pode concluir toda a configuração do AzureFile (SMB) no portal do Azure. Para obter mais informações, consulte Criar uma montagem de volume do Azure Files em Aplicativos de Contêiner do Azure. O suporte para a montagem de compartilhamentos NFS está atualmente em visualização. Você pode configurá-lo usando a CLI do Azure ou um modelo ARM. Para obter mais informações, consulte Compartilhamentos de arquivos do Azure NFS e a seção Criar um compartilhamento de arquivos do Azure NFS do Tutorial: Criar um compartilhamento de arquivos do Azure NFS e montá-lo em uma VM Linux usando o portal do Azure.

Identidade gerida

Cada aplicativo de contêiner tem uma identidade gerenciada atribuída pelo sistema ou identidades gerenciadas atribuídas pelo usuário para acessar recursos protegidos do Azure. Para saber como gerenciar identidades e conceder permissões, consulte Identidades gerenciadas em Aplicativos de Contêiner do Azure.

Cada aplicativo de contêiner tem um ponto de extremidade REST interno, acessível por meio da IDENTITY_ENDPOINT variável de ambiente, que difere do ponto de extremidade usado no Azure Spring Apps. Se seu aplicativo usa uma solicitação HTTP GET direta, você precisa ajustar o código para obter o ponto de extremidade correto. Se seu aplicativo usa uma identidade gerenciada por meio da biblioteca de cliente do Azure Identity, você não precisa de nenhuma alteração de código porque o Azure Identity gerencia esses detalhes automaticamente.

Quando uma carga de trabalho acessa recursos protegidos do Azure, ela precisa buscar um token de acesso usando a ID do aplicativo ou a ID do cliente de uma identidade gerenciada. Em um ambiente do Azure Spring Apps, você pode definir a ID do cliente de uma identidade gerenciada atribuída pelo sistema ou pelo usuário. Como alternativa, você pode deixá-lo vazio e permitir que o serviço selecione o ID do aplicativo de uma das identidades gerenciadas. Nos Aplicativos de Contêiner do Azure, você não pode especificar explicitamente a ID do aplicativo ao usar uma identidade gerenciada atribuída pelo sistema. No entanto, a ID do aplicativo é necessária ao usar uma identidade gerenciada atribuída pelo usuário.

Sondas do estado de funcionamento

Os Aplicativos de Contêiner do Azure e os Aplicativos de primavera do Azure dão suporte a todos os três tipos de testes de integridade, incluindo teste de inicialização, teste de vivacidade e teste de preparação. Para os Aplicativos de Contêiner do Azure, as sondas podem usar o protocolo HTTP ou TCP. exec ainda não é suportado.

No Azure Spring Apps, as configurações de teste são definidas no recurso de implantação. Por outro lado, para os Aplicativos de Contêiner do Azure, as configurações de teste são definidas no recurso do aplicativo de contêiner. Estão disponíveis as seguintes definições:

Property	Description	Azure Spring Apps	Azure Container Apps
`probeAction`	A ação da sonda.	Suporta `HTTPGetAction`, `TCPSocketAction`e `ExecAction`.	Não há propriedades para o tipo de ação. O usuário deve usar um ou `httpGettcpSocket` diretamente.
`disableProbe`	Indica se a sonda está desativada.	Boolean	Boolean
`initialDelaySeconds`	O número de segundos após o início da instância do aplicativo antes que as sondas sejam iniciadas.		O valor varia de 1 a 60.
`periodSeconds`	Quantas vezes, em segundos, para executar a sonda.	O valor mínimo é 1.	O valor varia de 1 a 240, com um valor padrão de 10.
`timeoutSeconds`	O número de segundos após os quais a sonda atinge o tempo limite.	O valor mínimo é 1.	O valor varia de 1 a 240, com um valor padrão de 1.
`failureThreshold`	As falhas consecutivas mínimas para que a sonda seja considerada falha após ter sido bem-sucedida.	O valor mínimo é 1.	O valor varia de 1 a 10, com um valor padrão de 3.
`successThreshold`	Os sucessos consecutivos mínimos para que a sonda seja considerada bem-sucedida depois de ter falhado.	O valor mínimo é 1.	O valor varia de 1 a 10, com um valor padrão de 1.
`terminationGracePeriodSeconds`	A duração opcional em segundos, o pod precisa terminar normalmente em caso de falha da sonda.	O valor padrão é 90 segundos.	O valor máximo é de 3600 segundos.

Atualmente, não é possível configurar os testes para Aplicativos de Contêiner do Azure diretamente no portal do Azure. Em vez disso, você precisa configurá-los usando um modelo ARM ou um arquivo YAML de aplicativo de contêiner por meio da CLI do Azure. Para obter mais informações, consulte Sondas de integridade em aplicativos de contêiner do Azure.

Escala

Os Aplicativos de Contêiner do Azure dão suporte ao dimensionamento horizontal por meio de um conjunto de regras de dimensionamento. Quando uma regra é adicionada ou alterada, uma nova revisão do aplicativo de contêiner é criada.

O dimensionamento tem três categorias de gatilhos, HTTP, TCP e personalizado. HTTP e TCP são baseados no número de solicitações ou conexões de rede. Para obter mais informações, veja Definir regras de dimensionamento no Azure Container Apps.

Acionar a escala com base na CPU ou na memória

As regras de dimensionamento de aplicativos de contêiner personalizadas são baseadas no escalador KEDA baseado em ScaledObject. Você pode obter dimensionamento com aplicativos de contêiner com base no uso de CPU ou memória por meio do KEDA CPU scaler e Memory scaler.

O exemplo a seguir demonstra uma configuração em que o dimensionamento ocorre quando o uso médio de memória excede 25%. O uso de memória inclui a memória usada pelo aplicativo de contêiner atual e também os pods relevantes, como contêineres de sidecar internos. O KEDA inclui configuração interna para evitar que o aplicativo de contêiner bata. Para obter mais informações sobre configurações internas, consulte Definir regras de dimensionamento em Aplicativos de Contêiner do Azure. Você deve verificar o comportamento durante o tempo de execução para garantir que ele atenda às suas necessidades.

az containerapp create \
    --resource-group MyResourceGroup \
    --name my-containerapp \
    --image my-queue-processor --environment MyContainerappEnv \
    --min-replicas 1 --max-replicas 10 \
    --scale-rule-name memory-scaler \
    --scale-rule-type memory \
    --scale-rule-metadata "type=Utilization" \
                          "value=25"

Escala de gatilho com base em métricas Java

O KEDA oferece um dimensionador do Azure Monitor, que permite o dimensionamento com base nas métricas disponíveis no Azure Monitor. Você pode usar esse recurso para dimensionar seus aplicativos dinamicamente com base em métricas específicas do Java publicadas no Azure Monitor.

Pré-requisitos

Registar uma aplicação no Microsoft Entra ID Para obter mais informações, consulte Guia de início rápido: registrar um aplicativo com a plataforma de identidade da Microsoft.
Conceda permissões. Atribua ao aplicativo registrado a Monitoring Reader função para seu recurso de Aplicativos de Contêiner do Azure.

Passos

Adicione segredos. Use o seguinte comando para armazenar a ID do cliente e o segredo do aplicativo Microsoft Entra nos Aplicativos de Contêiner do Azure como segredos:

az containerapp secret set \
    --resource-group MyResourceGroup \
    --name my-containerapp \
    --secrets activeDirectoryClientId=<Microsoft-Entra-Application-Client-ID> \
              activeDirectoryClientPassword=<Microsoft-Entra-Application-Client-Password>

Defina uma regra de dimensionamento. Use o comando a seguir para criar uma regra de dimensionamento personalizada que usa o dimensionador do Azure Monitor. Esta regra aciona ações de dimensionamento com base em uma métrica Java específica, como JvmThreadCount, monitorada por meio do Azure Monitor.

az containerapp create \
    --resource-group MyResourceGroup \
    --name my-containerapp \
    --image my-queue-processor --environment MyContainerappEnv \
    --min-replicas 1 --max-replicas 10 \
    --scale-rule-name thread-count \
    --scale-rule-type azure-monitor \
    --scale-rule-auth "activeDirectoryClientId=activeDirectoryClientId" \
                      "activeDirectoryClientPassword=activeDirectoryClientPassword" \
    --scale-rule-metadata "activationTargetValue=1" \
                          "metricAggregationInterval=0:1:0" \
                          "metricAggregationType=Maximum" \
                          "metricName=JvmThreadCount" \
                          "resourceGroupName=MyResourceGroup" \
                          "resourceURI=MyContainerAppShortURI" \
                          "subscriptionId=MyResourceID" \
                          "targetValue=30" \
                          "tenantId=MyTenantID"

Detalhes principais

Gestão de segredos: As credenciais da aplicação - ID do cliente e palavra-passe - são armazenadas de forma segura como segredos.
Critérios de escala: O metricName parâmetro identifica a métrica Java - JvmThreadCount neste caso - que é usada para avaliar quando o dimensionamento deve ocorrer.
Valor de destino: o targetValue parâmetro define o limite para dimensionamento - por exemplo, dimensionamento quando a contagem de threads excede 30.

Ao configurar essa regra, seu aplicativo de contêiner pode ajustar dinamicamente o número de instâncias com base em métricas de desempenho específicas do Java, melhorando a capacidade de resposta e a utilização de recursos.

Partilhar via

Visão geral da migração de aplicativos

Pré-requisitos

Implementar uma aplicação

Variáveis de ambiente

Segredos

Opções da JVM

Armazenamento

Identidade gerida

Sondas do estado de funcionamento

Escala

Acionar a escala com base na CPU ou na memória

Escala de gatilho com base em métricas Java

Pré-requisitos

Passos

Detalhes principais

Comentários

Recursos adicionais