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

Este artigo se aplica a(o):❌ 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

• Uma instância do plano Enterprise dos Aplicativos Spring do Azure já provisionada. Para obter mais informações, confira Início Rápido: criar e implantar aplicativos nos Aplicativos Spring do Azure usando o plano Enterprise.
• CLI do Azure versão 2.45.0 ou superior. Use o seguinte comando para instalar a extensão do Aplicativos Spring do Azure: az extension add --name spring

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:

• Buildpack do Azure Java para VMware Tanzu
• Buildpack do .NET Core para VMware Tanzu
• Buildpack do Go para VMware Tanzu
• Buildpack do Web Servers para VMware Tanzu
• Buildpack do Node.js para VMware Tanzu
• Buildpack do Python para VMware Tanzu
• Buildpack da Java Native Image para VMware Tanzu
• Buildpack do PHP para VMware Tanzu

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:

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.

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.

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.

az spring container-registry list \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> 

az spring container-registry show \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <your-container-registry-name>

az spring container-registry update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <your-container-registry-name> \
    --server <your-container-registry-login-server> \
    --username <your-container-registry-username> \
    --password <your-container-registry-password>

az spring container-registry delete \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <your-container-registry-name> 

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.

az spring build-service show \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name>

az spring build-service update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --registry-name <your-container-registry-name> 

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.

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>

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

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

az spring app deploy \
   --resource-group <resource-group-name> \
   --service <Azure-Spring-Apps-instance-name> \
   --name <app-name> \
   --container-image <your-container-image> \
   --container-registry <your-container-registry> \
   --registry-password <your-password> \
   --registry-username <your-username>

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>

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

az spring build-service build update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <build-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.

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>

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

az spring build-service build update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <build-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.

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>

az spring build-service build create \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <build-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>

az spring build-service build update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <build-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.

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.

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:

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:

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:

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:

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:

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:

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:

Próximas etapas

• Implantar arquivos estáticos da Web