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

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.

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> 

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.

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> 

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.

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>

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.

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>

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.

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>

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

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>

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.

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.

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:

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:

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:

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:

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:

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:

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:

Nächste Schritte

• Bereitstellen statischer Webdateien