Compartilhar via

Como implantar aplicativos poliglotas no plano Enterprise dos Aplicativos Spring do Azure

  • 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 mostra como implantar aplicativos poliglotas no plano Enterprise dos Aplicativos Spring do Azure e como esses aplicativos poliglotas podem usar os recursos do serviço de build oferecidos por buildpacks.

Pré-requisitos

Implantar aplicativos poliglotas em uma instância de serviço

Esta seção é dedicada à criação e implantação de aplicativos poliglotas quando o serviço de build está habilitado. Se desabilitar o serviço de build, você só poderá implantar aplicativos com uma imagem de contêiner personalizada. Você pode criar sua própria imagem ou usar uma criada por uma instância dos Aplicativos Spring do Azure Enterprise. Para mais informações, confira o tópico Implantar um aplicativo com uma imagem de contêiner personalizada.

Gerenciar construtores

Ao criar uma instância dos Aplicativos Spring do Azure Enterprise, você deve escolher um construtor padrão dentre os seguintes buildpacks de família de linguagem com suporte:

Para mais informações, confira os Buildpacks de família de linguagem para o VMware Tanzu.

Esses buildpacks dão suporte ao desenvolvimento com código-fonte ou artefatos para aplicativos Java, .NET Core, Go, arquivos estáticos web, Node.js e Python. Você também pode ver versões do buildpack durante a criação ou exibição de um construtor. E você pode criar um construtor personalizado especificando buildpacks e uma pilha.

Todos os construtores configurados em uma instância de serviço dos Aplicativos Spring do Azure são listados na página Serviço de Build, conforme mostrado na captura de tela a seguir:

Captura de tela do portal do Azure que mostra a página Serviço de Build com a lista Construtores em destaque.

Selecione Adicionar para criar um construtor. A imagem a seguir mostra os recursos que você deve usar para criar o construtor personalizado. A pilha do sistema operacional inclui Bionic Base, Bionic Full, Jammy Tiny, Jammy Base e Jammy Full. Bionic é baseado em Ubuntu 18.04 (Bionic Beaver) e Jammy é baseado em Ubuntu 22.04 (Jammy Jellyfish). Para mais informações, confira a seção Recomendações de pilha de sistema operacional.

Recomendamos usar a Jammy OS Stack para criar seu construtor porque o VMware está descontinuando a Bionic OS Stack.

Captura de tela do portal do Azure que mostra a página Adicionar Construtor com a Pilha do Sistema Operacional e o nome do buildpack selecionado em destaque.

Você também pode editar um construtor personalizado quando o construtor não for usado em uma implantação. É possível atualizar os buildpacks ou a pilha do sistema operacional, mas o nome do construtor é somente leitura.

Captura de tela do portal do Azure exibindo a página Serviço de Build com o botão de reticências e a opção de menu Editar construtor em destaque.

O construtor é um recurso que contribui continuamente para suas implantações. Ele fornece as imagens de runtime mais recentes e os buildpacks mais recentes.

Você não pode excluir um construtor quando as implantações ativas existentes estão sendo compiladas pelo construtor. Para excluir um construtor nesse estado, siga as próximas etapas:

  1. Salve a configuração como um novo construtor.
  2. Implante aplicativos com o novo construtor. As implantações estão vinculadas ao novo construtor.
  3. Migre as implantações no construtor anterior para o novo construtor.
  4. Exclua o construtor original.

Recomendações de pilha de sistema operacional

Nos Aplicativos Spring do Azure, recomendamos usar a Jammy OS Stack para criar seu construtor porque a Bioinic OS Stack previsto para ser descontinuado pela VMware. A lista a seguir descreve as opções disponíveis:

  • Jammy Tiny: ideal para compilar uma imagem mínima, visando o menor tamanho possível e menor volume de memória. Assim como ao compilar uma Java Native Image, isso pode reduzir o tamanho final da imagem de contêiner. As bibliotecas integradas são limitadas. Por exemplo, você não pode conectar-se a uma instância de aplicativo para solucionar problemas, pois não há a biblioteca shell.

    • A maioria dos aplicativos em Go.
    • Aplicativos em Java. Algumas opções de configuração do Apache Tomcat, como a configuração bin/setenv.sh, não estão disponíveis porque o Tiny não possui shell.

  • Jammy Base: adequado para a maioria dos aplicativos sem extensões nativas.

    • Aplicativos em Java e .NET Core.
    • Aplicativos em Go que necessitam de algumas bibliotecas em C.
    • Aplicativos em Node.js, Python ou Web Servers sem extensões nativas.

  • Jammy Full: contém a maioria das bibliotecas e é adequado para aplicativos com extensões nativas. Por exemplo, inclui uma biblioteca mais completa de fontes. Se o aplicativo depende de extensão nativa, use a pilha Full.

    • Aplicativos em Node.js ou Python com extensões nativas.

Para obter mais informações, consulte as Pilhas do Ubuntu na documentação da VMware.

Gerenciar o registro de contêiner

Esta seção ensina como gerenciar o registro de contêiner usado pelo serviço de build se você habilitar o serviço de build com seu próprio registro de contêiner. Se você habilitar o serviço de build com um registro de contêiner gerenciado dos Aplicativos Spring do Azure, pule esta seção.

Após habilitar um registro de contêiner de usuário com o serviço de build, você pode mostrar e configurar o registro usando o portal do Azure ou a CLI do Azure.

Siga as próximas etapas para mostrar, adicionar, editar e excluir o registro de contêiner:

  1. Abra o Portal do Azure.

  2. Selecione o Registro de contêiner no painel de navegação.

  3. Selecione Adicionar para criar um registro de contêiner.

    Captura de tela do portal do Azure que mostra a página

  4. Para um registro de contêiner, selecione o botão de reticências (...) e depois Editar para exibir a configuração do registro.

    Captura de tela do portal do Azure que amostra a página de

  5. Confira os valores na página Editar registro de contêiner.

    Captura de tela do portal do Azure que mostra a página

  6. Para excluir um registro de contêiner, selecione o botão de reticências (...) e depois Excluir. Se o registro de contêiner estiver sendo usado pelo serviço de build, ele não poderá ser excluído.

    Captura de tela do portal do Azure que mostra a página

O serviço de build pode usar um registro de contêiner e também pode alterar o registro de contêiner associado. Esse processo é demorado. Quando a mudança acontece, todos os construtores e recursos de build e sob o serviço de build são recompiladas e, em seguida, as imagens finais de contêiner são enviadas por push para o novo registro de contêiner.

Siga as próximas etapas para mudar o registro de contêiner associado ao serviço de build:

  1. Abra o Portal do Azure.

  2. Selecione Serviço de Build no painel de navegação.

  3. Selecione Registro de contêiner referenciado para atualizar o registro de contêiner para o serviço de build.

    Captura de tela do portal do Azure que mostra a página Serviço de Build com o registro de contêiner referenciado em destaque.

Criar e implantar aplicativos poliglotas

Você pode criar e implantar aplicativos poliglotas das seguintes formas, usando o registro de contêiner:

  • Para o serviço de build que usa o registro de contêiner gerenciado dos Aplicativos Spring do Azure, você pode criar um aplicativo para uma imagem e, em seguida, implantá-lo na instância atual do serviço Aplicativos Spring do Azure. A compilação e a implantação são executadas juntas usando o comando az spring app deploy.

  • Para o serviço de build usando um registro de contêiner gerenciado pelo usuário, você pode criar um aplicativo em uma imagem de contêiner e, em seguida, implantar a imagem tanto na instância atual dos Aplicativos Spring do Azure Enterprise quanto em outras instâncias. Os comandos de compilação e implantação são separados. Você pode usar o comando de build para criar ou atualizar um build e, em seguida, usar o comando de implantação para implantar a imagem de contêiner na instância de serviço.

Para mais informações, confira a seção Serviço de build sob demanda do artigo Usar o Tanzu Build Service.

Os exemplos a seguir mostram alguns comandos de build úteis a serem usados.

az configure --defaults group=<resource-group-name> spring=<service-name>

az spring build-service build list
az spring build-service build show --name <build-name>
az spring build-service build create --name <build-name> --artifact-path <artifact-path>
az spring build-service build update --name <build-name> --artifact-path <artifact-path>
az spring build-service build delete --name <build-name>

Os exemplos a seguir da CLI do Azure mostram a criação e a implantação de um arquivo de artefato para dois cenários de registro de contêiner:

  • Registro de contêiner gerenciado dos Aplicativos Spring do Azure.
  • Registro de contêiner gerenciado pelo usuário.

Este exemplo cria e implanta com um único comando. O comando a seguir especifica um construtor para criar um aplicativo em uma imagem de contêiner e, em seguida, implanta o aplicativo diretamente na instância de serviço dos Aplicativos Spring do Azure Enterprise.

Se você não especificar o construtor, será usado um construtor default.

az spring app deploy \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <app-name> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

Se você for implantar o aplicativo com um arquivo de artefato, use --artifact-path para especificar o caminho do arquivo. Arquivos JAR e WAR são aceitos.

Se a CLI do Azure detectar o pacote WAR como um JAR fino, use --disable-validation para desabilitar a validação.

O exemplo a seguir implanta a pasta de código-fonte em uma implantação ativa usando o parâmetro --source-path para especificar a pasta.

az spring app deploy \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <app-name> \
    --builder <builder-name> \
    --source-path <path-to-source-code>

Você também pode configurar o ambiente de build para criar o aplicativo. Por exemplo, em um aplicativo Java, você pode especificar a versão do JDK usando o ambiente de build BP_JVM_VERSION.

Para especificar ambientes de build, use --build-env, como mostrado no exemplo a seguir. As variáveis de ambiente de build disponíveis serão descritas mais adiante neste artigo.

O comando a seguir implanta um aplicativo:

az spring app deploy \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <app-name> \
    --build-env <key1=value1> <key2=value2> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

Para cada compilação, você também pode definir os recursos de build, conforme mostrado no exemplo a seguir.

O comando a seguir implanta um aplicativo:

az spring app deploy \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <app-name> \
    --build-env <key1=value1> <key2=value2> \
    --build-cpu <build-cpu-size> \
    --build-memory <build-memory-size> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

Os recursos de CPU e memória para um build padrão é 1 vCPU, 2 Gi. Se o aplicativo precisar de uma quantidade menor ou maior de memória, use --build-memory para especificar os recursos de memória (por exemplo, 500Mi, 1Gi, 2Gi e assim por diante). Se o aplicativo precisar de uma quantidade menor ou maior de recursos de CPU, use --build-cpu para especificar os recursos de CPU (por exemplo, 500m, 1, 2 e assim por diante). O limite máximo de recursos de CPU e memória para um build é de 8 vCPU, 16Gi.

Os recursos de CPU e memória são limitados pelo tamanho do pool de agentes do serviço de build. Para mais informações, veja a seção Pool de agentes de build do artigo Usar o Tanzu Build Service. A soma da cota de recursos de build em processamento não pode ultrapassar o tamanho do pool de agentes.

O número de tarefas de build paralelas depende do tamanho do pool de agentes e de cada recurso de build. Por exemplo, se o recurso de build for o padrão 1 vCPU, 2 Gi e o tamanho do pool de agentes for 6 vCPU, 12 Gi, o número de builds paralelos será 6.

Outras tarefas de build podem ser bloqueadas temporariamente devido às limitações de cota de recursos.

Seu aplicativo deve escutar na porta 8080. Os aplicativos Spring Boot substituem a SERVER_PORT para usar a porta 8080 automaticamente.

Linguagens com suporte para implantações

A tabela a seguir indica os recursos com suporte para cada linguagem.

Recurso Java Python Nó .NET Core Go Arquivos estáticos Java Native Image PHP
Gerenciamento do ciclo de vida do Aplicativo ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Atribuir ponto de extremidade ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Azure Monitor ✅ ✅ ✅ ✅ ✅ ✅ ✅
Integração do APM pronta para uso ✅
Implantação azul/verde ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Domínio personalizado ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Escala – dimensionamento automático ✅ ✅ ✅ ✅ ✅ ✅ ✅
Escala – dimensionamento manual (aumentar/diminuir a escala horizontal, aumentar/diminuir a escala vertical) ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Identidade gerenciada ✅ ✅ ✅ ✅ ✅ ✅ ️ ✅
Portal de API para VMware Tanzu ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Spring Cloud Gateway para VMware Tanzu ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Serviço de configuração de aplicativos para o VMware Tanzu ✅ ✅
Registro de serviço do VMware Tanzu ✅ ✅
App Live View para VMware Tanzu ✅ ✅
Rede virtual ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Endereço IP de saída ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
TLS E2E ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Solução avançada de problemas – despejo de thread/heap/JFR ✅
Traga seu próprio armazenamento ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Integrar a associação de serviço ao Conector de Recursos ✅ ✅
Zona de disponibilidade ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Eventos de ciclo de vida de aplicativo ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Tamanho reduzido do aplicativo – 0,5 vCPU e 512 MB ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Automatizar implantações de aplicativos com o Terraform e a Tarefa do Azure Pipeline ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Exclusão reversível ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Experiência interativa de diagnóstico (baseada em AppLens) ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Contrato de Nível de Serviço ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Personalizar as investigações de integridade ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Conexão via web shell para solucionar problemas ✅ ✅ ✅ ✅ ✅ ✅ ️ ✅ ✅
Depuração remota ✅ ️ ️ ️

Para mais informações sobre as configurações compatíveis com diferentes aplicativos em várias linguagens, confira a seção correspondente mais adiante neste artigo.

Limitações da Java Native Image

O Native Image é uma tecnologia que compila código Java antecipadamente para um executável nativo. As imagens nativas oferecem diversas vantagens, como inicialização instantânea e menor consumo de memória. Você pode empacotar imagens nativas em uma imagem de contêiner leve para que faça implantações mais rápidas e eficientes. Por causa da Closed World Optimization (otimização em mundo fechado, em tradução livre), as seguintes limitações se aplicam:

  • As seguintes funcionalidades do Java precisam ser configurados no momento da compilação do executável:
    • Carregamento dinâmico de classes
    • Reflexão
    • Proxy dinâmico
    • JNI (Java Native Interface)
    • Serialização
  • O bytecode não está mais disponível no runtime, portanto, não é possível realizar a depuração e o monitoramento com ferramentas direcionadas à JVMTI.

Não há suporte para as funcionalidades a seguir nos Aplicativos Spring do Azure devido à limitação da Java Native Image. Os Aplicativos Spring do Azure oferecerão suporte a elas quando a Java Native Image e a comunidade superarem a limitação.

Recurso Por que não há suporte
Azure Monitor Imagens nativas compiladas pela GraalVM não dão suporte a métricas da JVM.
Escala – dimensionamento automático Imagens nativas compiladas pela GraalVM não dão suporte a métricas da JVM.
Integração de APM pronta para uso O APM Vendor &Buildpack não dá suporte à imagem nativa.
Identidade gerenciada Os SDKs do Azure não dão suporte à imagem nativa.
Solução de problemas avançada – despejo de thread/heap/JFR Imagens nativas criadas pela GraalVM não dão suporte ao despejo de thread/heap/JFR.
Depuração remota A GraalVM Native Image não dá suporte à Depuração Remota.
Conexão sem senha usando o Conector de Serviço O SDK do Azure Java não dá suporte à imagem nativa.

Observação

Nas seções a seguir sobre configuração de build e implantação em diferentes linguagens de programação, --build-env indica que o ambiente é usado na fase de build. --env significa que o ambiente é usado na fase de runtime.

Recomendamos que você especifique a versão da linguagem, caso a versão padrão mude. Por exemplo, use --build-env BP_JVM_VERSION=11.* para especificar o Java 11 como a versão do JDK. Para outras linguagens, você pode encontrar o nome da variável de ambiente nas descrições a seguir para cada linguagem.

Implantar aplicativos Java

O buildpack para implantar aplicativos Java é tanzu-buildpacks/java-azure.

A tabela a seguir lista as funcionalidades com suporte nos Aplicativos Spring do Azure:

Descrição do recurso Comentário Variável de ambiente Uso
Oferece o Microsoft OpenJDK. Configura a versão da JVM. A versão padrão do JDK é 17. Versões com suporte no momento: JDK 8, 11, 17 e 21. BP_JVM_VERSION --build-env BP_JVM_VERSION=11.*
Amb. de runtime Configura se o Controle de Memória Nativa (NMT) do Java está habilitado. O valor padrão é true. Sem suporte no JDK 8. BPL_JAVA_NMT_ENABLED --env BPL_JAVA_NMT_ENABLED=true
Configura o nível de detalhes para a saída do Controle de Memória Nativa (NMT) do Java. O valor padrão é resumo. Defina como detalhe para uma saída NMT detalhada. BPL_JAVA_NMT_LEVEL --env BPL_JAVA_NMT_ENABLED=summary
Adiciona certificados AC ao repositório de confiança do sistema na fase de compilação e runtime. Confira a seção Configurar certificados de AC para compilações e implantações de aplicativos do artigo Como configurar a integração APM e certificados de AC. N/D N/D
Integra com os agentes APM do Application Insights, Dynatrace, Elastic, New Relic ou App Dynamic. Confira Como configurar a integração APM e certificados de AC. N/D N/D
Implanta o pacote WAR com Apache Tomcat ou TomEE. Defina o servidor de aplicativos a ser usado. Defina como tomcat para usar o Tomcat e como tomee para usar o TomEE. O valor padrão é tomcat. BP_JAVA_APP_SERVER --build-env BP_JAVA_APP_SERVER=tomee
Oferece suporte a aplicativos do Spring Boot. Indica se deve adicionar suporte ao Spring Cloud Bindings para a imagem na fase de compilação. O valor padrão é falso. BP_SPRING_CLOUD_BINDINGS_DISABLED --build-env BP_SPRING_CLOUD_BINDINGS_DISABLED=false
Indica se deve configurar automaticamente as propriedades do ambiente Spring Boot a partir de associações na fase de runtime. Este recurso requer que o Spring Cloud Bindings já esteja instalado na fase de compilação, caso contrário, não terá efeito. O valor padrão é falso. BPL_SPRING_CLOUD_BINDINGS_DISABLED --env BPL_SPRING_CLOUD_BINDINGS_DISABLED=false
Oferece suporte à criação de aplicativos baseados em Maven a partir da fonte. Usado para um projeto com vários módulos. Indica o módulo onde é possível localizar o artefato do aplicativo. O padrão é o módulo raiz (vazio). BP_MAVEN_BUILT_MODULE --build-env BP_MAVEN_BUILT_MODULE=./gateway
Suporte à criação de aplicativos baseados em Gradle a partir da fonte. Usado para um projeto com vários módulos. Indica o módulo onde é possível localizar o artefato do aplicativo. O padrão é o módulo raiz (vazio). BP_GRADLE_BUILT_MODULE --build-env BP_GRADLE_BUILT_MODULE=./gateway
Habilitar a configuração de rótulos na imagem criada. Configura rótulos especificados pela OCI com nomes de variáveis de ambiente curtos e rótulos arbitrários usando uma sintaxe delimitada por espaços em uma única variável de ambiente. BP_IMAGE_LABELS
BP_OCI_AUTHORS
Veja mais variáveis de ambiente aqui.		 --build-env BP_OCI_AUTHORS=<value>
Integra o agente JProfiler. Indica se o suporte ao JProfiler será integrado. O valor padrão é falso. BP_JPROFILER_ENABLED fase de compilação:
--build-env BP_JPROFILER_ENABLED=true
fase de runtime:
--env BPL_JPROFILER_ENABLED=true
BPL_JPROFILER_PORT=<port> (opcional, padrão para 8849)
BPL_JPROFILER_NOWAIT=true (opcional. Indica se a JVM é executada antes do JProfiler ser anexado. O valor padrão é true.)
Indica se o suporte ao JProfiler deve ser habilitado na fase de runtime. O valor padrão é falso. BPL_JPROFILER_ENABLED --env BPL_JPROFILER_ENABLED=false
Especifica em qual porta o agente JProfiler escuta. O valor padrão é 8849. BPL_JPROFILER_PORT --env BPL_JPROFILER_PORT=8849
Indica se a JVM é executada antes do JProfiler ser anexado. O valor padrão é true. BPL_JPROFILER_NOWAIT --env BPL_JPROFILER_NOWAIT=true
Integra o agente JRebel. O aplicativo deve conter um arquivo rebel-remote.xml. N/D N/D
Criptografa um aplicativo com AES na fase de compilação e a descriptografa no momento do lançamento. A chave AES a ser usada no momento da compilação. BP_EAR_KEY --build-env BP_EAR_KEY=<value>
A chave AES a ser usada no momento do runtime. BPL_EAR_KEY --env BPL_EAR_KEY=<value>
Integra o agenteAspectJ Weaver. <APPLICATION_ROOT>/aop.xml está presente e aspectj-weaver.*.jar também. N/D N/D

Implantar aplicativos .NET

O buildpack para implantar aplicativos .NET é tanzu-buildpacks/dotnet-core.

A tabela a seguir lista as funcionalidades com suporte nos Aplicativos Spring do Azure:

Descrição do recurso Comentário Variável de ambiente Uso
Configura a versão do runtime do .NET Core. Dá suporte ao Net6.0 e ao Net8.0.
Você pode configurar por meio de um arquivo runtimeconfig.json ou um arquivo de Projeto MSBuild.
O runtime padrão é 6.0..		 N/D N/D
Adiciona certificados AC ao repositório de confiança do sistema na fase de compilação e runtime. Confira a seção Configurar certificados de AC para compilações e implantações de aplicativos do artigo Como configurar a integração APM e certificados de AC. N/D N/D
Integra aos agentes APM Dynatrace e New Relic. Confira Como configurar a integração APM e certificados de AC. N/D N/D
Habilitar a configuração de rótulos na imagem criada. Configura rótulos especificados pela OCI com nomes de variáveis de ambiente curtos e rótulos arbitrários usando uma sintaxe delimitada por espaços em uma única variável de ambiente. BP_IMAGE_LABELS
BP_OCI_AUTHORS
Veja mais variáveis de ambiente aqui.		 --build-env BP_OCI_AUTHORS=<value>

Implantar aplicativos Python

O buildpack para implantar aplicativos Python é tanzu-buildpacks/python.

A tabela a seguir lista as funcionalidades com suporte nos Aplicativos Spring do Azure:

Descrição do recurso Comentário Variável de ambiente Uso
Especifica uma versão do Python. Oferece suporte às versões 3.8., 3.9., 3.10., 3.11., 3.12.. O valor padrão é 3.10.*
Você pode especificar a versão do Python através da variável de ambiente BP_CPYTHON_VERSION durante a compilação.		 BP_CPYTHON_VERSION --build-env BP_CPYTHON_VERSION=3.8.*
Adiciona certificados AC ao repositório de confiança do sistema na fase de compilação e runtime. Confira a seção Configurar certificados de AC para compilações e implantações de aplicativos do artigo Como configurar a integração APM e certificados de AC. N/D N/D
Habilitar a configuração de rótulos na imagem criada. Configura rótulos especificados pela OCI com nomes de variáveis de ambiente curtos e rótulos arbitrários usando uma sintaxe delimitada por espaços em uma única variável de ambiente. BP_IMAGE_LABELS
BP_OCI_AUTHORS
Veja mais variáveis de ambiente aqui.		 --build-env BP_OCI_AUTHORS=<value>

Implantar aplicativos Go

O buildpack para implantar aplicativos Go é tanzu-buildpacks/go.

A tabela a seguir lista as funcionalidades com suporte nos Aplicativos Spring do Azure:

Descrição do recurso Comentário Variável de ambiente Uso
Especifica uma versão do Go. Oferece suporte a 1.21.*, 1.22.*. O valor padrão é 1.21.*.
A versão Go é detectada automaticamente no arquivo go.mod do aplicativo. Você pode substituir essa versão definindo a variável de ambiente BP_GO_VERSION no momento da compilação.		 BP_GO_VERSION --build-env BP_GO_VERSION=1.22.*
Configuração de múltiplos destinos. Especifica vários destinos para um build do Go. BP_GO_TARGETS --build-env BP_GO_TARGETS=./some-target:./other-target
Adiciona certificados AC ao repositório de confiança do sistema na fase de compilação e runtime. Confira a seção Configurar certificados de AC para compilações e implantações de aplicativos do artigo Como configurar a integração APM e certificados de AC. N/D N/D
Integra ao agente APM do Dynatrace. Confira Como configurar a integração APM e certificados de AC. N/D N/D
Habilitar a configuração de rótulos na imagem criada. Configura rótulos especificados pela OCI com nomes de variáveis de ambiente curtos e rótulos arbitrários usando uma sintaxe delimitada por espaços em uma única variável de ambiente. BP_IMAGE_LABELS
BP_OCI_AUTHORS
Veja mais variáveis de ambiente aqui.		 --build-env BP_OCI_AUTHORS=<value>

Implantar aplicativos Node.js

O buildpack para implantar aplicativos Node.js é tanzu-buildpacks/nodejs.

A tabela a seguir lista as funcionalidades com suporte nos Aplicativos Spring do Azure:

Descrição do recurso Comentário Variável de ambiente Uso
Especifica uma versão do Node. Oferece suporte às versões 16., 18., 19., 20.. O valor padrão é 20.*.
Você pode especificar a versão do Node por meio de um arquivo .nvmrc ou .node-version na raiz do diretório do aplicativo. BP_NODE_VERSION substitui as configurações.		 BP_NODE_VERSION --build-env BP_NODE_VERSION=20.*
Adiciona certificados AC ao repositório de confiança do sistema na fase de compilação e runtime. Confira a seção Configurar certificados de AC para compilações e implantações de aplicativos do artigo Como configurar a integração APM e certificados de AC. N/D N/D
Integra com os agentes APM do Dynatrace, Elastic, New Relic ou App Dynamic. Confira Como configurar a integração APM e certificados de AC. N/D N/D
Habilitar a configuração de rótulos na imagem criada. Configura rótulos especificados pela OCI com nomes de variáveis de ambiente curtos e rótulos arbitrários usando uma sintaxe delimitada por espaços em uma única variável de ambiente. BP_IMAGE_LABELS
BP_OCI_AUTHORS
Veja mais variáveis de ambiente aqui.		 --build-env BP_OCI_AUTHORS=<value>
Implanta um aplicativo Angular com o Angular Live Development Server. Especifica o host antes de executar ng serve no package.json: ng serve --host 0.0.0.0 --port 8080 --public-host <your application domain name>. O nome de domínio do aplicativo está disponível na página Visão Geral do aplicativo, na seção URL. Remova o protocolo https:// antes de continuar. BP_NODE_RUN_SCRIPTS
NODE_ENV		 --build-env BP_NODE_RUN_SCRIPTS=build NODE_ENV=development

Implantar aplicativos WebServer

O buildpack para implantar aplicativos WebServer é tanzu-buildpacks/web-servers.

Para mais informações, veja Implantar arquivos estáticos da web.

Implantar aplicativos Java Native Image (pré-visualização)

O buildpack para implantar aplicativos Java Native Image é tanzu-buildpacks/java-native-image.

Você pode implantar aplicativos de imagem nativa Spring Boot usando o buildpack tanzu-buildpacks/java-native-image. O Spring Native oferece suporte para compilar aplicativos Spring Boot em executáveis nativos. O buildpack usa o Liberica Native Image Kit (NIK)para criar imagens nativas de aplicativos Spring Boot e esses aplicativos têm suporte total.

Ao criar uma Java Native Image, você deve definir o ambiente de build BP_NATIVE_IMAGE para true e o recurso de memória de build não deve ser inferior a 8 Gi. O tamanho do pool de agentes do serviço de build não deve ser menor que 4 vCPU, 8 Gi. Para mais informações, veja a seção Pool de agentes de build do artigo Usar o Tanzu Build Service.

Se você quiser criar a imagem nativa em uma imagem de contêiner de tamanho menor, recomendamos usar um construtor com a pilha de sistema operacional Jammy Tiny. Para mais informações, confira a seção Recomendações de pilha de sistema operacional.

A tabela a seguir lista as funcionalidades com suporte nos Aplicativos Spring do Azure:

Descrição do recurso Comentário Variável de ambiente Uso
Integra ao Bellsoft OpenJDK. Configura a versão do JDK. Versões com suporte no momento: JDK 8, 11, 17 e 21. BP_JVM_VERSION --build-env BP_JVM_VERSION=17
Configure argumentos para o comando native-image. Argumentos a serem passados diretamente para o comando native-image. Esses argumentos devem ser válidos e formados corretamente ou o comando de imagem nativa falhará. BP_NATIVE_IMAGE_BUILD_ARGUMENTS --build-env BP_NATIVE_IMAGE_BUILD_ARGUMENTS="--no-fallback"
Adiciona certificados AC ao repositório de confiança do sistema na fase de compilação e runtime. Confira Como configurar a integração APM e certificados de AC. Não aplicável. Não aplicável.
Habilitar a configuração de rótulos na imagem criada Configura rótulos especificados pela OCI com nomes de variáveis de ambiente curtos e rótulos arbitrários usando uma sintaxe delimitada por espaços em uma única variável de ambiente. BP_IMAGE_LABELS
BP_OCI_AUTHORS
Veja mais variáveis de ambiente aqui.		 --build-env BP_OCI_AUTHORS=<value>
Oferece suporte à criação de aplicativos baseados em Maven a partir da fonte. Usado para um projeto com vários módulos. Indica o módulo onde é possível localizar o artefato do aplicativo. O padrão é o módulo raiz (vazio). BP_MAVEN_BUILT_MODULE --build-env BP_MAVEN_BUILT_MODULE=./gateway

Existem algumas limitações para a Java Native Image. Para obter mais informações, confira a seção Limitações da Java Native Image.

Implantar aplicativos PHP

O buildpack para implantar aplicativos PHP é tanzu-buildpacks/php.

O buildpack do Tanzu PHP só é compatível com a pilha completa do sistema operacional. É recomendável usar um construtor com a pilha de sistema operacional Jammy Full. Para mais informações, confira a seção Recomendações de pilha de sistema operacional.

A tabela a seguir lista as funcionalidades com suporte nos Aplicativos Spring do Azure:

Descrição do recurso Comentário Variável de ambiente Uso
Especifique a versão do PHP. Configura a versão do PHP. Atualmente com suporte: PHP 8.1.*, 8.2.*e 8.3.*. O valor padrão é 8.1.* BP_PHP_VERSION --build-env BP_PHP_VERSION=8.1.*
Adiciona certificados AC ao repositório de confiança do sistema na fase de compilação e runtime. Confira a seção Configurar certificados de AC para compilações e implantações de aplicativos do artigo Como configurar a integração APM e certificados de AC. N/D N/D
Integra com os agentes APM do Dynatrace, New Relic ou App Dynamic. Confira Como configurar a integração APM e certificados de AC. N/D N/D
Seleciona um Servidor Web. As opções de configuração são php-server, httpd e nginx. O valor padrão é php-server. BP_PHP_SERVER --build-env BP_PHP_SERVER=httpd
Configura o Diretório Web. Quando o servidor web é HTTPD ou NGINX, o diretório web padrão é htdocs. Quando o servidor web é o servidor interno do PHP, o diretório web padrão é /workspace. BP_PHP_WEB_DIR --build-env BP_PHP_WEB_DIR=htdocs

Próximas etapas