Bereitstellen von mehrsprachigen Apps im Azure Spring Apps-Enterprise-Plan

Hinweis

Azure Spring Apps ist der neue Name für den Azure Spring Cloud-Dienst. Obwohl der Dienst umbenannt wurde, wird der alte Name noch an einigen Stellen verwendet, solange wir Ressourcen wie Screenshots, Videos und Diagramme aktualisieren.

Dieser Artikel gilt für:❌ Basic/Standard ✔️ Enterprise

Dieser Artikel zeigt Ihnen, wie Sie Polyglot-Apps im Azure Spring Apps Enterprise-Plan bereitstellen und wie diese Polyglot-Apps die Build-Dienst-Funktionen von Buildpacks nutzen können.

Voraussetzungen

• Eine bereits bereitgestellte Azure Spring Apps Enterprise-Planinstanz. Weitere Informationen finden Sie unter Schnellstart: Erstellen und Bereitstellen von Anwendungen in Azure Spring Apps mit dem Enterprise Plan.
• Azure CLI (ab Version 2.45.0) Verwenden Sie den folgenden Befehl, um die Azure Spring Apps-Erweiterung zu installieren: az extension add --name spring

Bereitstellen von Polyglot-Anwendungen in einer Dienstinstanz

Dieser Abschnitt bezieht sich auf die Erstellung und Bereitstellung von Polyglot-Anwendungen, wenn der Build-Dienst aktiviert ist. Wenn Sie den Build-Dienst deaktivieren, können Sie Anwendungen nur mit einem benutzerdefinierten Containerimage bereitstellen. Sie können Ihr eigenes Image erstellen oder eines verwenden, das von einer Azure Spring Apps Enterprise-Instanz erstellt wurde. Weitere Informationen finden Sie unter Bereitstellen einer Anwendung mit einem benutzerdefinierten Containerimage.

Verwalten von Generatoren

Wenn Sie eine Instanz von Azure Spring Apps Enterprise erstellen, müssen Sie einen Standard-Generator aus einem der folgenden unterstützten Sprachfamilien-Buildpacks auswählen:

• Java Azure Buildpack für VMware Tanzu
• .NET Core Buildpack für VMware Tanzu
• Go Buildpack für VMware Tanzu
• Web Servers Buildpack für VMware Tanzu
• Node.js Buildpack für VMware Tanzu
• Python Buildpack für VMware Tanzu
• Java Native Image Buildpack für VMware Tanzu
• PHP Buildpack für VMware Tanzu

Weitere Informationen finden Sie unter Sprachfamilien-Buildpacks für VMware Tanzu.

Diese Buildpacks unterstützen die Erstellung mit Quellcode oder Artefakten für Java-, .NET Core-, Go-, statische Webdatei-, Node.js- und Python-Anwendungen. Sie können Buildpack-Versionen auch während des Erstellens oder Anzeigens eines Generators anzeigen. Und Sie können einen benutzerdefinierten Generator erstellen, indem Sie Buildpacks und einen Stapel angeben.

Alle in einer Azure Spring Apps-Dienstinstanz konfigurierten Generatoren werden auf der Seite Build-Dienst aufgeführt, wie im folgenden Screenshot gezeigt:

Klicken Sie auf Hinzufügen, um einen neuen Generator zu erstellen. Der folgende Screenshot veranschaulicht die Ressourcen, die Sie zum Erstellen des benutzerdefinierten Builders verwenden sollten. Der Betriebssystemstapel umfasst Bionic Base, Bionic Full, Jammy Tiny, Jammy Base, und Jammy Full. Bionic basiert auf Ubuntu 18.04 (Bionic Beaver) und Jammy basiert auf Ubuntu 22.04 (Jammy Jellyfish). Weitere Informationen finden Sie im Abschnitt Empfehlungen für den Betriebssystemstapel.

Es wird empfohlen Jammy OS Stack zu verwenden, um ihren Generator zu erstellen, da VMware Bionic OS Stack veraltet.

Sie können auch einen benutzerdefinierten Generator bearbeiten, wenn der Generator in keiner Bereitstellung verwendet wird. Sie können die Buildpacks oder den Betriebssystemstapel aktualisieren, der Name des Generators ist jedoch schreibgeschützt.

Der Generator ist eine Ressource, die kontinuierlich zu Ihren Bereitstellungen beiträgt. Der Generator stellt die neuesten Runtime-Images und die neuesten Buildpacks bereit.

Sie können einen Generator nicht löschen, wenn vorhandene aktive Bereitstellungen vom Generator erstellt wurden. Führen Sie die folgenden Schritte aus, um einen Generator in diesem Zustand zu löschen:

1. Speichern Sie die Konfiguration als neuen Generator.
2. Stellen Sie Apps mit dem neuen Generator bereit. Die Bereitstellungen sind mit dem neuen Generator verknüpft.
3. Migrieren Sie die Bereitstellungen unter dem vorherigen Generator zum neuen Generator.
4. Löschen Sie den ursprünglichen Generator.

Empfehlungen für Betriebssystemstapel

In Azure Spring Apps empfehlen wir die Verwendung von Jammy OS Stack zum Erstellen Ihres Generators, da Bioinic OS Stack von VMware nicht mehr unterstützt wird. In der folgenden Liste werden die verfügbaren Optionen beschrieben:

• Jammy Tiny: Geeignet für die Erstellung eines minimalen Images für die kleinstmögliche Größe und Sicherheit. Wie bei der Erstellung eines Java Native Image kann das endgültige Containerimage dadurch kleiner werden. Die integrierten Bibliotheken sind begrenzt. So können Sie beispielsweise keine Verbindung zu einer App-Instanz für die Fehlerbehebung herstellen, weil es keine shell-Bibliothek gibt.

  • Die meisten Go-Apps.
  • Java-Apps. Einige Konfigurationsoptionen für Apache Tomcat, wie z. B. das Festlegen von bin/setenv.sh, sind nicht verfügbar, da Tiny keine Shell hat.

• Jammy Base: Geeignet für die meisten Apps ohne native Erweiterungen.

  • Java-Apps und .NET Core-Apps.
  • Go-Apps, für einige C-Bibliotheken erfordern.
  • Node.js-, Python- oder Webserver-Apps ohne systemeigene Erweiterungen.

• Jammy Full: Enthält die meisten Bibliotheken und eignet sich für Apps mit nativen Erweiterungen. Es enthält beispielsweise eine umfassendere Bibliothek mit Schriftarten. Wenn Ihre App auf der nativen Erweiterung basiert, verwenden Sie den Full Stapel.

  • Node.js oder Python-Apps mit nativen Erweiterungen.

Weitere Informationen finden Sie unter Ubuntu-Stapel in der VMware-Dokumentation.

Verwalten der Containerregistrierung

In diesem Abschnitt erfahren Sie, wie Sie die vom Build-Dienst verwendete Containerregistrierung verwalten, wenn Sie den Build-Dienst mit Ihrer eigenen Containerregistrierung aktivieren. Wenn Sie den Build-Dienst mit einer verwalteten Azure Spring Apps-Containerregistrierung aktivieren, können Sie diesen Abschnitt überspringen.

Nachdem Sie eine Benutzercontainerregistrierung mit dem Build-Dienst aktiviert haben, können Sie die Registrierung mithilfe des Azure-Portals oder der Azure CLI anzeigen und konfigurieren.

Azure portal

Führen Sie die folgenden Schritte aus, um die Containerregistrierung anzuzeigen, hinzuzufügen, zu bearbeiten und zu löschen:

1. Öffnen Sie das Azure-Portal.

2. Wählen Sie im Navigationsbereich Containerregistrierung aus.

3. Wählen Sie Hinzufügen aus, um eine Containerregistrierung zu erstellen.

   

4. Wählen Sie für eine Containerregistrierung die Schaltfläche mit den Auslassungspunkten (…) und dann Bearbeiten aus, um die Registrierungskonfiguration anzuzeigen.

   

5. Überprüfen Sie die Werte auf der Seite Containerregistrierung bearbeiten.

   

6. Um eine Containerregistrierung zu löschen, wählen Sie die Schaltfläche mit den Auslassungspunkten (…) und dann Löschen aus, um die Registrierung zu löschen. Wenn die Containerregistrierung vom Build-Dienst verwendet wird, kann sie nicht gelöscht werden.

   

Azure-Befehlszeilenschnittstelle

Verwenden Sie den folgenden Befehl, um alle Containerregistrierungen für die Dienstinstanz auflisten:

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

Verwenden Sie den folgenden Befehl, um die Containerregistrierung anzuzeigen:

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

Verwenden Sie den folgenden Befehl, um die Containerregistrierung zu aktualisieren:

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>

Verwenden Sie den folgenden Befehl, um die Containerregistrierung zu löschen:

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

Wenn der Build-Dienst die Containerregistrierung verwendet, können Sie ihn nicht löschen.

Der Build-Dienst kann eine Containerregistrierung verwenden und auch die zugeordnete Containerregistrierung ändern. Dieser Vorgang ist zeitaufwändig. Wenn die Änderung erfolgt, werden alle Generator- und Buildressourcen unter dem Build-Dienst neu erstellt, und dann werden die endgültigen Containerimages an die neue Containerregistrierung übertragen.

Azure portal

Führen Sie die folgenden Schritte aus, um die Containerregistrierung zu wechseln, die dem Build-Dienst zugeordnet ist:

1. Öffnen Sie das Azure-Portal.

2. Wählen Sie im Navigationsbereich Build-Dienst aus.

3. Wählen Sie Referenzierte Containerregistrierung aus, um die Containerregistrierung für den Build-Dienst zu aktualisieren.

   

Azure-Befehlszeilenschnittstelle

Verwenden Sie den folgenden Befehl, um den Build-Dienst anzuzeigen:

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

Verwenden Sie den folgenden Befehl, um den Build-Dienst mit einer bestimmten Containerregistrierung zu aktualisieren:

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

Erstellen und Bereitstellen von Polyglot-Anwendungen

Sie können Polyglot-Anwendungen auf folgende Weise mithilfe der Containerregistrierung erstellen und bereitstellen:

• Für den Build-Dienst, der die verwaltete Azure Spring Apps-Containerregistrierung verwendet, können Sie eine Anwendung für ein Image erstellen und dann innerhalb der aktuellen Azure Spring Apps-Dienstinstanz bereitstellen. Der Build und die Bereitstellung werden mithilfe des Befehls az spring app deploy zusammen ausgeführt.

• Für den Build-Dienst, der eine benutzerverwaltete Containerregistrierung verwendet, können Sie eine Anwendung in einem Containerimage erstellen und das Image dann auf der aktuellen Azure Spring Apps Enterprise-Instanz und anderen Instanzen bereitstellen. Die Befehle build und deploy sind unabhängig voneinander. Sie können den Befehl build verwenden, um ein Build zu erstellen oder zu aktualisieren, und dann den Befehl deploy verwenden, um das Containerimage in der Dienstinstanz bereitzustellen.

Weitere Informationen finden Sie im Abschnitt Build-Dienst auf Abruf unter Verwenden des Tanzu Build-Diensts.

Die folgenden Beispiele zeigen einige hilfreiche Build-Befehle, die Sie verwenden können.

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>

Die folgenden Azure CLI-Beispiele zeigen die Erstellung und Bereitstellung einer Artefaktdatei für zwei Containerregistrierungsszenarien:

• Verwaltete Azure Spring Apps-Containerregistrierung.
• Benutzerverwaltete Containerregistrierung.

Verwaltete Azure Spring Apps-Containerregistrierung

In diesem Beispiel werden Build und Bereitstellung mit einem einzigen Befehl ausgeführt. Der folgende Befehl gibt einen Generator an, der eine Anwendung in einem Containerimage erstellt, und stellt die Anwendung dann direkt in der Azure Springs Apps Enterprise Dienstinstanz bereit.

Wenn Sie den Generator nicht angeben, wird ein default-Generator verwendet.

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>

Benutzerverwaltete Containerregistrierung

Dieses Beispiel erstellt oder aktualisiert eine Anwendung und stellt sie mit zwei Befehlen bereit. Mit einer benutzerverwalteten Containerregistrierung können Sie eine Anwendung nur über ein benutzerdefiniertes Containerimage bereitstellen. Weitere Informationen finden Sie unter Bereitstellen einer Anwendung mit einem benutzerdefinierten Containerimage.

Mit dem folgenden Befehl wird eine Anwendung erstellt:

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>

Der folgende Befehl aktualisiert ein bestehendes Build:

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>

Mit dem folgenden Befehl wird eine Anwendung bereitgestellt.

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>

Wenn Sie die App mit einer Artefaktdatei bereitstellen, verwenden Sie --artifact-path, um den Dateipfad anzugeben. Sowohl JAR- als auch WAR-Dateien sind zulässig.

Wenn die Azure CLI das WAR-Paket als dünnes JAR erkennt, verwenden Sie --disable-validation, um die Validierung zu deaktivieren.

Im folgenden Beispiel wird der Quellcode-Ordner in einer aktiven Bereitstellung bereitgestellt, indem Sie den Parameter --source-path zur Angabe des Ordners verwenden.

Verwaltete Azure Spring Apps-Containerregistrierung

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>

Benutzerverwaltete Containerregistrierung

Mit dem folgenden Befehl wird eine Anwendung erstellt:

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>

Der folgende Befehl aktualisiert ein bestehendes Build:

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>

Informationen zum Bereitstellen der Anwendung finden Sie unter Bereitstellen einer Anwendung mit einem benutzerdefinierten Containerimage.

Sie können die Build-Umgebung auch so konfigurieren, dass sie die App erstellt. Beispielsweise können Sie in einer Java-Anwendung die JDK-Version mithilfe der Buildumgebung BP_JVM_VERSION angeben.

Verwenden Sie zum Angeben von Buildumgebungen --build-env, wie im folgenden Beispiel gezeigt. Die verfügbaren Buildumgebungsvariablen werden weiter unten in diesem Artikel beschrieben.

Verwaltete Azure Spring Apps-Containerregistrierung

Der folgende Befehl stellt eine Anwendung bereit:

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>

Benutzerverwaltete Containerregistrierung

Mit dem folgenden Befehl wird eine Anwendung erstellt:

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>

Der folgende Befehl aktualisiert ein bestehendes Build:

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>

Informationen zum Bereitstellen der Anwendung finden Sie unter Bereitstellen einer Anwendung mit einem benutzerdefinierten Containerimage.

Für jeden Build können Sie auch die Buildressourcen angeben, wie im folgenden Beispiel gezeigt.

Verwaltete Azure Spring Apps-Containerregistrierung

Der folgende Befehl stellt eine Anwendung bereit:

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>

Benutzerverwaltete Containerregistrierung

Mit dem folgenden Befehl wird eine Anwendung erstellt:

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>

Der folgende Befehl aktualisiert ein bestehendes Build:

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>

Informationen zum Bereitstellen der Anwendung finden Sie unter Bereitstellen einer Anwendung mit einem benutzerdefinierten Containerimage.

Die standardmäßige Build-CPU-/Speicherressource ist 1 vCPU, 2 Gi. Wenn Ihre Anwendung eine kleinere oder größere Arbeitsspeichermenge benötigt, geben Sie mit --build-memory die Speicherressourcen an, z. B. 500Mi, 1Gi, 2Gi, usw. Wenn Ihre Anwendung eine kleinere oder größere Menge an CPU-Ressourcen benötigt, verwenden Sie --build-cpu, um die CPU-Ressourcen anzugeben, z. B. 500m, 1, 2, usw. Der maximale Grenzwert für CPU-/Arbeitsspeicherressourcen für einen Build ist 8 vCPU, 16Gi.

Die CPU- und Arbeitsspeicherressourcen sind durch die Größe des Build-Agentpools begrenzt. Weitere Informationen finden Sie im Abschnitt Build-Agentpool unter Verwenden des Tanzu Build-Diensts. Die Summe der Kontingente für die Verarbeitung von Buildressourcen darf die Größe des Agentenpools nicht überschreiten.

Die parallele Anzahl von Buildaufgaben hängt von der Größe des Agentenpools und der jeweiligen Buildressource ab. Wenn die Buildressource beispielsweise die Standardressource 1 vCPU, 2 Gi ist und die Größe des Agentpools 6 vCPU, 12 Gilautet, lautet die parallele Buildnummer 6.

Andere Buildaufgaben werden aufgrund von Grenzwerten für die Ressourcen eine Zeit lang blockiert.

Ihre Anwendung muss an Port 8080 lauschen. Spring Boot-Anwendungen setzen SERVER_PORT außer Kraft und verwenden automatisch 8080.

Unterstützte Sprachen für Bereitstellungen

In der folgenden Tabelle werden die für die einzelnen Sprachen unterstützten Features aufgeführt.

Funktion	Java	Python	Node	.NET Core	Go	Statische Dateien	Java Native Image	PHP
App-Lebenszyklusverwaltung	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Zuweisen eines Endpunkts	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Azure Monitor	✔️	✔️	✔️	✔️	✔️	✔️		✔️
Sofortige APM-Integration	✔️
Blau/Grün-Bereitstellung	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Benutzerdefinierte Domäne	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Skalierung: automatische Skalierung	✔️	✔️	✔️	✔️	✔️	✔️		✔️
Skalierung: manuelle Skalierung (horizontal herunter/horizontal, auf/ab)	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Verwaltete Identität	✔️	✔️	✔️	✔️	✔️	✔️	️	✔️
API-Portal für VMware Tanzu	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Spring Cloud-Gateway für VMware Tanzu	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Anwendungskonfigurationsdienst für VMware Tanzu	✔️						✔️
VMware Tanzu-Dienstregistrierung	✔️						✔️
App Live View für VMware Tanzu	✔️						✔️
Virtuelles Netzwerk	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Ausgehende IP-Adresse	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
E2E TLS	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Erweiterte Problembehandlung: Thread/Heap/JFR-Speicherabbild	✔️
Bring Your Own Storage (BYOS)	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Integrieren der Dienstbindung in den Ressourcenconnector	✔️						✔️
Verfügbarkeitszone	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
App-Lebenszyklusereignisse	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Reduzierte App-Größe: 0,5 vCPU und 512 MB	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Automatisieren von App-Bereitstellungen mit Terraform und Azure Pipeline Task	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Vorläufiges Löschen	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Interaktive Diagnosebenutzeroberfläche (AppLens-basiert)	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
SLA	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Anpassen von Integritätstests	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Web-Shell-Verbindung zur Problembehandlung	✔️	✔️	✔️	✔️	✔️	✔️	️ ✔️	✔️
Remotedebuggen	✔️				️	️	️

Weitere Informationen zu den unterstützten Konfigurationen für Apps in verschiedenen Sprachen finden Sie im entsprechenden Abschnitt weiter unten in diesem Artikel.

Einschränkungen für Java Native Image

Native Image ist eine Technologie, um Java-Code vorab in eine systemeigene ausführbare Datei zu kompilieren. Native Images bieten verschiedene Vorteile, z. B. einen sofortigen Start und einen reduzierten Arbeitsspeicherverbrauch. Sie können Native Images in ein einfaches Containerimage verpacken, um eine schnellere und effizientere Bereitstellung zu ermöglichen. Aufgrund der Optimierung der geschlossenen Welt gelten die folgenden Einschränkungen:

• Für die folgenden Java-Features ist die Konfiguration zur ausführbaren Buildzeit erforderlich:
  • Dynamisches Laden von Klassen
  • Reflexion
  • Dynamischer Proxy
  • JNI (Java Native Interface)
  • Serialisierung
• Bytecode ist zur Laufzeit nicht mehr verfügbar. Daher ist das Debuggen und Überwachen mit Tools für JVMTI nicht möglich.

Die folgenden Features werden in Azure Spring Apps aufgrund der Einschränkung von Java Native Image nicht unterstützt. Azure Spring Apps unterstützen sie, wenn das Java Native Image und die Community die Einschränkung überwindet.

Funktion	Warum dies nicht unterstützt wird
Azure Monitor	Die von GraalVM erstellten nativen Images unterstützen keine JVM-Metriken.
Skalierung – automatische Skalierung	Die von GraalVM erstellten nativen Images unterstützen keine JVM-Metriken.
Out-Of-The-Box-APM-Integration	APM Vendor & Buildpack unterstützt kein systemeigenes Image.
Verwaltete Identität	Azure SDKs unterstützen kein systemeigenes Image.
Erweiterte Problembehandlung – Thread/Heap/JFR-Speicherabbild	Die von GraalVM erstellten nativen Images unterstützen kein Thread-/Heap-/JFR-Speicherabbild.
Remotedebuggen	GraalVM Native Image unterstützt kein Remotedebugging.
Kennwortlose Verbindung mit dem Dienstconnector	Das Azure Java SDK unterstützt kein systemeigenes Image.

Hinweis

In den folgenden Abschnitten von Builds und Bereitstellungskonfigurationen in verschiedenen Sprachen bedeutet --build-env, dass die Umgebung in der Buildphase verwendet wird. --env bedeutet, dass die Umgebung in der Runtime-Phase verwendet wird.

Es wird empfohlen, die Sprachversion anzugeben, falls sich die Standardversion ändert. Verwenden Sie beispielsweise --build-env BP_JVM_VERSION=11.*, um Java 11 als JDK-Version anzugeben. Für andere Sprachen können Sie den Namen der Umgebungsvariablen in den folgenden Beschreibungen für jede Sprache abrufen.

Bereitstellen von Java-Anwendungen

Das Buildpack für die Bereitstellung von Java-Anwendungen ist tanzu-buildpacks/java-azure.

In der folgenden Tabelle sind die in Azure Spring Apps unterstützten Funktionen aufgeführt:

Featurebeschreibung	Kommentar	Umgebungsvariable	Verbrauch
Stellt das Microsoft OpenJDK bereit.	Konfiguriert die JVM-Version. Die JDK-Standardversion ist 17. Derzeit unterstützt: JDK 8, 11, 17 und 21.	BP_JVM_VERSION	--build-env BP_JVM_VERSION=11.*
	Runtime-Umgebung Konfiguriert, ob Java Native Memory Tracking (NMT) aktiviert ist. Der Standardwert lautet true. In JDK 8 nicht unterstützt.	BPL_JAVA_NMT_ENABLED	--env BPL_JAVA_NMT_ENABLED=true
	Konfiguriert die Detailebene für die NMT-Ausgabe (Java Native Memory Tracking). Der Standardwert ist Zusammenfassung. Legt die Details für die detaillierte NMT-Ausgabe fest.	BPL_JAVA_NMT_LEVEL	--env BPL_JAVA_NMT_ENABLED=summary
Fügen Sie ZS-Zertifikate zum Systemvertrauensspeicher zur Build- und Runtime hinzu.	Weitere Informationen finden Sie im Abschnitt Konfigurieren von ZS-Zertifikaten für App-Builds und -Bereitstellungen unter Konfigurieren der APM-Integration und von ZS-Zertifikaten.	–	–
Integration in Application Insights, Dynatrace, Elastic, New Relic, App Dynamic APM Agent.	Weitere Informationen finden Sie unter Konfigurieren der APM-Integration und von ZS-Zertifikaten.	–	–
Bereitstellen des WAR-Pakets mit Apache Tomcat oder TomEE.	Legen Sie den zu verwendenden Anwendungsserver fest. Wählen Sie tomcat, um Tomcat zu verwenden und tomee, um TomEE zu verwenden. Der Standardwert ist tomcat.	BP_JAVA_APP_SERVER	--build-env BP_JAVA_APP_SERVER=tomee
Unterstützung von Spring Boot-Anwendungen.	Gibt an, ob die Unterstützung von Spring Cloud Bindungen für das Image zur Erstellungszeit hinzugefügt werden soll. Der Standardwert ist false.	BP_SPRING_CLOUD_BINDINGS_DISABLED	--build-env BP_SPRING_CLOUD_BINDINGS_DISABLED=false
	Gibt an, ob Spring Boot-Umgebungseigenschaften von Bindungen zur Laufzeit automatisch konfiguriert werden sollen. Diese Funktion setzt voraus, dass Spring Cloud Bindungen zum Zeitpunkt der Erstellung bereits installiert sind, sonst funktioniert sie nicht. Der Standardwert ist false.	BPL_SPRING_CLOUD_BINDINGS_DISABLED	--env BPL_SPRING_CLOUD_BINDINGS_DISABLED=false
Unterstützt die Erstellung von Maven-basierten Anwendungen aus dem Quellcode.	Wird für ein Projekt mit mehreren Modulen verwendet. Gibt das Modul an, in dem das Anwendungsartefakt zu finden ist. Standardmäßig wird das Stammmodul (leer) verwendet.	BP_MAVEN_BUILT_MODULE	--build-env BP_MAVEN_BUILT_MODULE=./gateway
Unterstützung der Erstellung von Gradle-basierten Anwendungen aus dem Quellcode.	Wird für ein Projekt mit mehreren Modulen verwendet. Gibt das Modul an, in dem das Anwendungsartefakt zu finden ist. Standardmäßig wird das Stammmodul (leer) verwendet.	BP_GRADLE_BUILT_MODULE	--build-env BP_GRADLE_BUILT_MODULE=./gateway
Aktivieren Sie die Konfiguration von Bezeichnungen für das erstellte Image.	Konfiguriert sowohl OCI-spezifische Bezeichnungen mit kurzen Umgebungsvariablennamen als auch beliebige Bezeichnungen mit einer durch Leerzeichen getrennten Syntax in einer einzigen Umgebungsvariablen.	BP_IMAGE_LABELS BP_OCI_AUTHORS Weitere Umgebungsvariablen finden Sie hier.	--build-env BP_OCI_AUTHORS=<value>
Integrieren des JProfiler-Agent.	Gibt an, ob die JProfiler-Unterstützung integriert werden soll. Der Standardwert ist false.	BP_JPROFILER_ENABLED	Buildphase: --build-env BP_JPROFILER_ENABLED=true Laufzeitphase: --env BPL_JPROFILER_ENABLED=true BPL_JPROFILER_PORT=<port> (Optional, der Standardwert ist 8849) BPL_JPROFILER_NOWAIT=true (optional. Gibt an, ob das JVM ausgeführt wird, bevor JProfiler angefügt wird. Der Standardwert ist true.)
	Gibt an, ob die JProfiler-Unterstützung zur Laufzeit aktiviert werden soll. Der Standardwert ist false.	BPL_JPROFILER_ENABLED	--env BPL_JPROFILER_ENABLED=false
	Gibt an, auf welchen Port der JProfiler-Agent lauscht. Der Standardwert ist 8849.	BPL_JPROFILER_PORT	--env BPL_JPROFILER_PORT=8849
	Gibt an, ob das JVM ausgeführt wird, bevor JProfiler angefügt wird. Der Standardwert lautet true.	BPL_JPROFILER_NOWAIT	--env BPL_JPROFILER_NOWAIT=true
Integrieren des JRebel-Agent.	Die Anwendung sollte eine Datei mit dem Namen rebel-remote.xml enthalten.	–	–
AES verschlüsselt eine Anwendung zur Erstellungszeit und entschlüsselt sie dann zur Ausführungszeit.	Der AES-Schlüssel, der zur Erstellungszeit verwendet werden soll.	BP_EAR_KEY	--build-env BP_EAR_KEY=<value>
	Der AES-Schlüssel, der zur Laufzeit verwendet werden soll.	BPL_EAR_KEY	--env BPL_EAR_KEY=<value>
Integrieren des AspectJ Weaver Agent.	<APPLICATION_ROOT>/aop.xml existiert und aspectj-weaver.*.jar existiert.	–	–

Bereitstellen von .NET-Anwendungen

Das Buildpack für die Bereitstellung von .NET-Anwendungen ist tanzu-buildpacks/dotnet-core.

In der folgenden Tabelle sind die in Azure Spring Apps unterstützten Funktionen aufgeführt:

Featurebeschreibung	Kommentar	Umgebungsvariable	Verbrauch
Konfigurieren der .NET Core-Laufzeitversion.	Unterstützt .Net 6.0, .Net 7.0, und .Net 8.0. Sie können die Konfiguration über eine runtimeconfig.json- oder MSBuild-Projektdatei durchführen. Die Standardlaufzeit ist 6.0.*.	–	–
Fügen Sie ZS-Zertifikate zum Systemvertrauensspeicher zur Build- und Runtime hinzu.	Weitere Informationen finden Sie im Abschnitt Konfigurieren von ZS-Zertifikaten für App-Builds und -Bereitstellungen unter Konfigurieren der APM-Integration und von ZS-Zertifikaten.	–	–
Integration in die Dynatrace- und New Relic APM-Agenten.	Weitere Informationen finden Sie unter Konfigurieren der APM-Integration und von ZS-Zertifikaten.	–	–
Aktivieren Sie die Konfiguration von Bezeichnungen für das erstellte Image.	Konfiguriert sowohl OCI-spezifische Bezeichnungen mit kurzen Umgebungsvariablennamen als auch beliebige Bezeichnungen mit einer durch Leerzeichen getrennten Syntax in einer einzigen Umgebungsvariablen.	BP_IMAGE_LABELS BP_OCI_AUTHORS Weitere Umgebungsvariablen finden Sie hier.	--build-env BP_OCI_AUTHORS=<value>

Bereitstellen von Python-Anwendungen

Das Buildpack für die Bereitstellung von Python-Anwendungen ist tanzu-buildpacks/python.

In der folgenden Tabelle sind die in Azure Spring Apps unterstützten Funktionen aufgeführt:

Featurebeschreibung	Kommentar	Umgebungsvariable	Verbrauch
Geben Sie eine Python-Version an.	Unterstützt 3.8.*, 3.9.*, 3.10.*, 3.11.*, 3.12.*. Der Standardwert ist 3.10.*. Sie können die Version während des Builds über die Umgebungsvariable BP_CPYTHON_VERSION angeben.	BP_CPYTHON_VERSION	--build-env BP_CPYTHON_VERSION=3.8.*
Fügen Sie ZS-Zertifikate zum Systemvertrauensspeicher zur Build- und Runtime hinzu.	Weitere Informationen finden Sie im Abschnitt Konfigurieren von ZS-Zertifikaten für App-Builds und -Bereitstellungen unter Konfigurieren der APM-Integration und von ZS-Zertifikaten.	–	–
Aktivieren Sie die Konfiguration von Bezeichnungen für das erstellte Image.	Konfiguriert sowohl OCI-spezifische Bezeichnungen mit kurzen Umgebungsvariablennamen als auch beliebige Bezeichnungen mit einer durch Leerzeichen getrennten Syntax in einer einzigen Umgebungsvariablen.	BP_IMAGE_LABELS BP_OCI_AUTHORS Weitere Umgebungsvariablen finden Sie hier.	--build-env BP_OCI_AUTHORS=<value>

Bereitstellen von Go-Anwendungen

Das Buildpack für die Bereitstellung von Go-Anwendungen ist tanzu-buildpacks/go.

In der folgenden Tabelle sind die in Azure Spring Apps unterstützten Funktionen aufgeführt:

Featurebeschreibung	Kommentar	Umgebungsvariable	Verbrauch
Geben Sie eine Go-Version an.	Unterstützt 1.20.*, 1.21.*. Der Standardwert ist 1.20.*. Die Go-Version wird automatisch aus der go.mod-Datei der App erkannt. Sie können diese Version außer Kraft setzen, indem Sie zur Erstellungszeit die Umgebungsvariable BP_GO_VERSION festlegen.	BP_GO_VERSION	--build-env BP_GO_VERSION=1.20.*
Konfigurieren mehrerer Ziele.	Gibt mehrere Ziele für einen Go-Build an.	BP_GO_TARGETS	--build-env BP_GO_TARGETS=./some-target:./other-target
Fügen Sie ZS-Zertifikate zum Systemvertrauensspeicher zur Build- und Runtime hinzu.	Weitere Informationen finden Sie im Abschnitt Konfigurieren von ZS-Zertifikaten für App-Builds und -Bereitstellungen unter Konfigurieren der APM-Integration und von ZS-Zertifikaten.	–	–
Integration mit Dynatrace APM-Agent.	Weitere Informationen finden Sie unter Konfigurieren der APM-Integration und von ZS-Zertifikaten.	–	–
Aktivieren Sie die Konfiguration von Bezeichnungen für das erstellte Image.	Konfiguriert sowohl OCI-spezifische Bezeichnungen mit kurzen Umgebungsvariablennamen als auch beliebige Bezeichnungen mit einer durch Leerzeichen getrennten Syntax in einer einzigen Umgebungsvariablen.	BP_IMAGE_LABELS BP_OCI_AUTHORS Weitere Umgebungsvariablen finden Sie hier.	--build-env BP_OCI_AUTHORS=<value>

Entwickeln von Node.js-Anwendungen

Das Buildpack für die Bereitstellung von Node.js Anwendungen ist tanzu-buildpacks/nodejs.

In der folgenden Tabelle sind die in Azure Spring Apps unterstützten Funktionen aufgeführt:

Featurebeschreibung	Kommentar	Umgebungsvariable	Verbrauch
Geben Sie eine Node-Version an.	Unterstützt 16.*, 18.*, 19.*, 20.*. Der Standardwert ist 20.*. Sie können die Node-Version über eine .nvmrc - oder .node-version-Datei im Anwendungsverzeichnisstamm angeben. BP_NODE_VERSION überschreibt die Einstellungen.	BP_NODE_VERSION	--build-env BP_NODE_VERSION=19.*
Fügen Sie ZS-Zertifikate zum Systemvertrauensspeicher zur Build- und Runtime hinzu.	Weitere Informationen finden Sie im Abschnitt Konfigurieren von ZS-Zertifikaten für App-Builds und -Bereitstellungen unter Konfigurieren der APM-Integration und von ZS-Zertifikaten.	–	–
Integration in Dynatrace, Elastic, New Relic, App Dynamic APM Agent.	Weitere Informationen finden Sie unter Konfigurieren der APM-Integration und von ZS-Zertifikaten.	–	–
Aktivieren Sie die Konfiguration von Bezeichnungen für das erstellte Image.	Konfiguriert sowohl OCI-spezifische Bezeichnungen mit kurzen Umgebungsvariablennamen als auch beliebige Bezeichnungen mit einer durch Leerzeichen getrennten Syntax in einer einzigen Umgebungsvariablen.	BP_IMAGE_LABELS BP_OCI_AUTHORS Weitere Umgebungsvariablen finden Sie hier.	--build-env BP_OCI_AUTHORS=<value>
Stellen Sie eine Angular-Anwendung mit Angular Live Development Server bereit.	Geben Sie den Host an, bevor Sie ng serve in der Datei package.json ausführen: ng serve --host 0.0.0.0 --port 8080 --public-host <your application domain name>. Den Domänennamen der Anwendung finden Sie auf der Seite Übersicht der Anwendung im Abschnitt URL. Entfernen Sie das Protokoll https://, bevor Sie fortfahren.	BP_NODE_RUN_SCRIPTS NODE_ENV	--build-env BP_NODE_RUN_SCRIPTS=build NODE_ENV=development

Bereitstellen von WebServer-Anwendungen

Das Buildpack für die Bereitstellung von WebServer-Anwendungen ist tanzu-buildpacks/web-servers.

Weitere Informationen finden Sie unter Bereitstellen statischer Webdateien.

Bereitstellen von Java Native Image-Anwendungen (Preview)

Das Buildpack für die Bereitstellung von Java Native Image-Anwendungen ist tanzu-buildpacks/java-native-image.

Sie können systemeigene Spring Boot Image-Anwendungen mithilfe des Buildpacks tanzu-buildpacks/java-native-image bereitstellen. Spring Native bietet Unterstützung für das Kompilieren von Spring Boot-Anwendungen in systemeigenen ausführbaren Dateien. Das Buildpack verwendet das Liberica Native Image Kit (NIK), um native Images von Spring Boot-Anwendungen zu erstellen, und diese Anwendungen werden vollständig unterstützt.

Wenn Sie ein Java Native Image erstellen, müssen Sie die Buildumgebung BP_NATIVE_IMAGE auf true festlegen, und die Buildspeicherressource sollte nicht kleiner als 8 Gi sein. Die Größe des Build-Dienst-Agentpools sollte nicht kleiner als 4 vCPU, 8 Gi sein. Weitere Informationen finden Sie im Abschnitt Build-Agentpool unter Verwenden des Tanzu Build-Diensts.

Wenn Sie das systemeigene Image in einem kleinerer Containerimage erstellen möchten, empfehlen wir die Verwendung eines Generators mit dem Betriebssystemstapel Jammy Tiny. Weitere Informationen finden Sie im Abschnitt Empfehlungen für den Betriebssystemstapel.

In der folgenden Tabelle sind die in Azure Spring Apps unterstützten Funktionen aufgeführt:

Featurebeschreibung	Kommentar	Umgebungsvariable	Verbrauch
Integration in Bellsoft OpenJDK.	Konfiguriert die JDK-Version. Derzeit unterstützt: JDK 8, 11, 17, und 20.	BP_JVM_VERSION	--build-env BP_JVM_VERSION=17
Konfigurieren Sie Argumente für den Befehl native-image.	Argumente, die direkt an den Native Image-Befehl übergeben werden. Diese Argumente müssen gültig und richtig formatiert sein, sonst kann der Befehl für Native Images nicht ausgeführt werden.	BP_NATIVE_IMAGE_BUILD_ARGUMENTS	--build-env BP_NATIVE_IMAGE_BUILD_ARGUMENTS="--no-fallback"
Fügen Sie ZS-Zertifikate zum Systemvertrauensspeicher zur Build- und Runtime hinzu.	Weitere Informationen finden Sie unter Konfigurieren der APM-Integration und von ZS-Zertifikaten.	Nicht zutreffend.	Nicht zutreffend.
Aktivieren der Konfiguration von Bezeichnungen im erstellten Image	Konfiguriert sowohl OCI-spezifische Bezeichnungen mit kurzen Umgebungsvariablennamen als auch beliebige Bezeichnungen mit einer durch Leerzeichen getrennten Syntax in einer einzigen Umgebungsvariablen.	BP_IMAGE_LABELS BP_OCI_AUTHORS Weitere Umgebungsvariablen finden Sie hier.	--build-env BP_OCI_AUTHORS=<value>
Unterstützt die Erstellung von Maven-basierten Anwendungen aus dem Quellcode.	Wird für ein Projekt mit mehreren Modulen verwendet. Gibt das Modul an, in dem das Anwendungsartefakt zu finden ist. Standardmäßig wird das Stammmodul (leer) verwendet.	BP_MAVEN_BUILT_MODULE	--build-env BP_MAVEN_BUILT_MODULE=./gateway

Es gibt einige Einschränkungen für Java Native Image. Weitere Informationen finden Sie im Abschnitt Einschränkungen von Java Native Image.

Bereitstellen von PHP-Anwendungen

Das Buildpack für die Bereitstellung von PHP-Anwendungen ist tanzu-buildpacks/php.

Das Tanzu PHP Buildpack ist nur mit dem Betriebssystemstapel „Full“ kompatibel. Wir empfehlen die Verwendung eines Generators mit dem Betriebssystemstapel Jammy Full. Weitere Informationen finden Sie im Abschnitt Empfehlungen für den Betriebssystemstapel.

In der folgenden Tabelle sind die in Azure Spring Apps unterstützten Funktionen aufgeführt:

Featurebeschreibung	Kommentar	Umgebungsvariable	Verbrauch
Angeben der PHP-Version.	Konfiguriert die PHP-Version. Derzeit unterstützt: PHP 8.1.* und 8.2.*. Der Standardwert ist 8.1.*.	BP_PHP_VERSION	--build-env BP_PHP_VERSION=8.0.*
Fügen Sie ZS-Zertifikate zum Systemvertrauensspeicher zur Build- und Runtime hinzu.	Weitere Informationen finden Sie im Abschnitt Konfigurieren von ZS-Zertifikaten für App-Builds und -Bereitstellungen unter Konfigurieren der APM-Integration und von ZS-Zertifikaten.	–	–
Integration in Dynatrace, New Relic, App Dynamic APM Agent.	Weitere Informationen finden Sie unter Konfigurieren der APM-Integration und von ZS-Zertifikaten.	–	–
Wählen Sie einen Webserver aus.	Die Einstellungsoptionen sind php-server, httpdund nginx. Der Standardwert ist php-server.	BP_PHP_SERVER	--build-env BP_PHP_SERVER=httpd
Konfigurieren des Webverzeichnisses.	Wenn der Webserver HTTPD oder NGINX ist, wird das Webverzeichnis standardmäßig auf htdocs festgelegt. Wenn der Webserver der integrierte PHP-Server ist, wird das Webverzeichnis standardmäßig auf /workspace festgelegt.	BP_PHP_WEB_DIR	--build-env BP_PHP_WEB_DIR=htdocs

Nächste Schritte

• Bereitstellen statischer Webdateien