Compartilhar via

Visão geral da migração de aplicativos

  • Artigo

Observação

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

O plano consumo e dedicado Standard 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 mais informações, confira Migrar o plano dedicado e consumo Standard dos Aplicativos Spring do Azure para os Aplicativos de Contêiner do Azure.

Este artigo se aplica a:✅ Básico/Standard ✅ Enterprise

Este artigo fornece uma visão geral de uma abordagem de migração de aplicativos dos Aplicativos Spring do Azure para os Aplicativos de Contêiner do Azure.

Pré-requisitos

Implantar um aplicativo

Os Aplicativos de Contêiner do Azure permitem implantar de registros de contêiner, como o Registro de Contêiner do Azure (ACR) ou o Docker Hub. 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 gerenciado de destino my-container-apps. Para obter mais informações, confira Implantar seu primeiro aplicativo de contêiner com o 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 uma versão prévia do recurso 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 de código ou local. É altamente recomendável implantar aplicativos de contêiner usando uma imagem de contêiner.

Variáveis de ambiente

Os Aplicativos de Contêiner do Azure permitem que você configure as variáveis de ambiente. Você pode configurá-las ao criar um novo aplicativo ou posteriormente criando uma nova revisão.

Para alterar as 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ê poderá 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 as variáveis de ambiente. Se muitas variáveis tiverem o mesmo nome, somente a última na 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 as variáveis de ambiente internas. Essas variáveis oferecem metadados de plataforma úteis durante o runtime. Para obter mais informações, confira a seção Variáveis de ambiente internas de Gerenciar as variáveis de ambiente nos 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 os pares nome/valor e são acessíveis a todas as revisões de aplicativo de contêiner.

Recomendamos que você armazene segredos no Azure Key Vault em vez de inseri-los diretamente. Você pode referenciar o valor de cada segredo do Azure Key Vault 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 Key Vault. A política de acesso no Key Vault deve permitir que o aplicativo use GET para obter segredos. Como alternativa, se o Key Vault usar o controle de acesso baseado em função do Azure, você precisará atribuir a função Key Vault Secrets User. Depois de configurar a identidade gerenciada, você poderá adicionar uma referência do Key Vault como um segredo em seu aplicativo especificando o URI do segredo. Em seguida, o aplicativo pode recuperar o segredo no runtime 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ê precisará implantar uma nova revisão ou reiniciar uma existente para refletir as alterações.
  • Você também pode usar segredos nas regras de escala.

Você pode usar segredos em aplicativos de contêiner referenciando-os 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 os 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 lidar com os segredos com segurança e acessá-los no ambiente do aplicativo. Para obter mais informações, confira Gerenciar segredos nos Aplicativos de Contêiner do Azure.

Se sua carga de trabalho proteger a configuração confidencial e recuperar as propriedades do Key Vault com a biblioteca spring-cloud-azure-starter-keyvault-secrets, você poderá usar o SDK do Azure ou o Spring KeyVault PropertySource nos Aplicativos de Contêiner do Azure. Você não precisa alterar o código durante a migração.

Opções do JVM

Para imprimir as opções de JVM nos Aplicativos de Contêiner do Azure, siga as etapas em Criar Imagem de Contêiner de um JAR ou WAR para colocar seu aplicativo em contêiner. Você pode adicionar -XX:+PrintFlagsFinal no ENTRYPOINT do 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 as opções de JVM nos 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 de JVM depois de executar uma consulta:

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

Para ajustar as opções de JVM nos Aplicativos de Contêiner do Azure, você pode adicionar opções de JVM no ENTRYPOINT do 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 de JVM, confira Opções de VM do Java HotSpot e Configurar as Opções de JVM.

Armazenamento

Os Aplicativos Spring do Azure 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 só ficam disponíveis enquanto o contêiner está em execução. Para os Aplicativos Spring do Azure, 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, confira a seção Armazenamento efêmero de Usar as montagens de armazenamento nos Aplicativos de Contêiner do Azure.

Os Aplicativos Spring 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 por meio dos 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, confira Criar uma montagem de volume dos Arquivos do Azure nos Aplicativos de Contêiner do Azure. O suporte para montar compartilhamentos de NFS está atualmente em versão prévia. Você pode configurá-lo usando a CLI do Azure ou um modelo do ARM. Para obter mais informações, confira Compartilhamentos de arquivos do NFS Azure e a seção Criar um compartilhamento de arquivos do NFS Azure do Tutorial: Criar um compartilhamento de arquivos do NFS Azure e montá-lo em uma VM do Linux usando o portal do Azure.

Identidade gerenciada

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

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

Quando uma carga de trabalho acessa os 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 dos Aplicativos Spring do Azure, você pode definir a ID do cliente de uma identidade gerenciada atribuída pelo sistema ou atribuída pelo usuário. Como alternativa, você pode deixá-la vazia e permitir que o serviço selecione a 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.

Investigações de integridade

Os Aplicativos de Contêiner do Azure e os Aplicativos Spring do Azure dão suporte a todos os três tipos de investigações de integridade, incluindo investigação de inicialização, investigação de atividade e investigação de preparação. Para os Aplicativos de Contêiner do Azure, as investigações podem usar o protocolo HTTP ou TCP. Não há suporte a exec.

Nos Aplicativos Spring do Azure, as configurações de investigação são configuradas no recurso de implantação. Por outro lado, para os Aplicativos de Contêiner do Azure, as configurações de investigação são definidas no recurso de aplicativo de contêiner. As seguintes configurações estão disponíveis:

Propriedade Descrição Azure Spring Apps Aplicativos de Contêiner do Azure
probeAction A ação da investigação. Dá suporte a HTTPGetAction, TCPSocketAction e ExecAction. Não há propriedades para o tipo de ação. O usuário deve usar httpGet ou tcpSocket diretamente.
disableProbe Indica se a investigação está desabilitada. Boolean Boolean
initialDelaySeconds O número de segundos após o início da instância do aplicativo antes do início das investigações. O valor varia de 1 a 60.
periodSeconds A frequência, em segundos, para realizar a investigação. 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 o qual o tempo limite da investigação é atingido. 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 investigação 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 O mínimo de sucessos consecutivos para que a investigação seja considerada bem-sucedida após apresentar falha. 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 que o pod precisa para terminar normalmente em caso de falha da sonda. O valor padrão é 90 segundos. O valor máximo é 3600 segundos.

Atualmente, você não pode configurar as investigações para os Aplicativos de Contêiner do Azure diretamente no portal do Azure. Você precisa configurá-los usando um modelo do ARM ou um arquivo YAML do aplicativo de contêiner por meio da CLI do Azure. Para obter mais informações, confira Investigações de integridade nos 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 personalizados. HTTP e TCP são baseados no número de conexões de solicitação ou rede. Para saber mais, confira Definir regras de escala nos Aplicativos de Contêiner do Azure.

Dimensionamento do gatilho com base na CPU ou na memória

As regras de dimensionamento dos aplicativos de contêiner personalizados são baseadas no dimensionador KEDA baseado em ScaledObject. Você pode obter dimensionamento com os aplicativos de contêiner com base no uso de CPU ou memória por meio do Dimensionador de CPU e do Dimensionador de memória do KEDA.

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 integrada para evitar que o aplicativo do contêiner fique oscilando. Para obter mais informações sobre as configurações internas, confira Definir as regras de dimensionamento nos Aplicativos de Contêiner do Azure. Você deve verificar o comportamento durante o runtime 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"

Dimensionamento do gatilho com base nas métricas do 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

Etapas

  1. Adicione segredos. Use o seguinte comando para armazenar a ID e o segredo do cliente 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>

  2. Defina uma regra de dimensionamento. Use o comando a seguir para criar uma regra de dimensionamento personalizada que usa o dimensionador do Azure Monitor. Essa regra dispara ações de dimensionamento com base em uma métrica específica do Java, 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 da chave

  • Gerenciamento de segredos: as credenciais do aplicativo – ID do cliente e senha – são armazenadas com segurança como segredos.
  • Critérios de dimensionamento: o parâmetro metricName identifica a métrica Java – JvmThreadCount nesse caso – que é usada para avaliar quando o dimensionamento deve ocorrer.
  • Valor de destino: o parâmetro targetValue 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.