Häufig gestellte Fragen zu Azure Container Apps (FAQ)

Nein, es gibt keinen Zugriff auf die Kubernetes-API.

Ja.

Einzelheiten finden Sie auf der Seite Abrechnung.

Ja. Führen Sie mithilfe der Azure-Befehlszeilenschnittstelle az containerapp github-action -h aus, um die Optionen anzuzeigen. Navigieren Sie über das Azure-Portal zum Fenster „Kontinuierliche Bereitstellung“ unter Ihrer Container-App.

Azure Container Apps decodiert die URL, um Ihre App vor URL-Verwirrungsangriffen zu schützen. Eine Anforderungs-URL mit codierten Teilen, z. B. http://mysite.com/archive/http%3A%2F%2Fmysite.com%2Farchive%2F123, wird als http://mysite.com/archive/http%3A/mysite.com/archive/123 an Ihre App gesendet.

In Umgebungen, die nur für den Verbrauch bestimmt sind, werden Express-Routen nicht unterstützt. Grenzwerte für UDR, die wie folgt konfiguriert sind, werden unterstützt. In der UDR-Konfiguration muss eine Route für das Diensttag Azure.<REGION_NAME> mit Next Hop = "Internet" konfiguriert sein. Außerdem müssen die Regeln in der NSG-Dokumentation so konfiguriert sein, dass die Umgebung „Nur Verbrauch“ betriebsbereit ist. Diese Grenzwerte gelten nicht für Workload-Profile. Verwenden Sie Workload-Profil-Umgebungen, um die volle Unterstützung für UDR und Express Route zu erhalten.

Azure Container Apps verschiebt oder speichert keine Kundendaten außerhalb der Region, in der es bereitgestellt ist.

Fordern Sie eine Kontingenterhöhung im Azure-Portal an, wobei Azure Container-Apps als Anbieter ausgewählt sind.

Beachten Sie Folgendes im Hinblick auf Anforderungen zur Erhöhung des Kontingents:

• Skalieren von Apps im Vergleich zu Umgebungen: Es gibt viele verschiedene Kontingente, die Sie erhöhen können. Verwenden Sie die folgenden Beschreibungen, um Ihre Anforderungen zu identifizieren:

  • Erhöhen von Apps und Kernen pro Umgebung: Ermöglicht das Ausführen von mehr Apps in einer Umgebung und/oder von intensiveren Apps. Empfohlen, wenn Ihre Workloads innerhalb derselben Netzwerk- und Sicherheitsgrenzen bereitgestellt werden können.
  • Erhöhen von Umgebungen: Empfohlen, wenn Ihre Workloads Netzwerk- oder Sicherheitsgrenzen benötigen. Hinweis: Ein detaillierter Geschäftskontext kann erforderlich sein, wenn Ihre Anforderung die Erhöhung von Kontingenten auf Umgebungsebene beinhaltet. Wenn Sie eine Änderung an Ihrem regionalen Umgebungskontingent anfordern, sollten Sie eine entsprechende Änderung Ihres globalen Umgebungskontingents anfordern.

• Regionen: Genehmigungen für Erhöhungsanforderungen variieren je nach Computekapazität, die in Azure-Regionen verfügbar ist.

• Spezifische Compute-Anforderungen: Die Plattform unterstützt 4 GB pro Container-App. Außerkraftsetzungen von Arbeitsspeichergrenzwerten werden fallweise bewertet.

• Geschäftliche Begründungen für die Skalierung: Sie können eine Anforderung zur Erhöhung des Kontingents stellen, wenn die Grenzwerte der Plattform Ihre Workload-Anforderungen blockieren. Außerkraftsetzungen von Skalierungslimits werden fallweise bewertet.

Jede Dapr-Funktion wird einer gründlichen Bewertung unterzogen, um sicherzustellen, dass sie sich positiv auf Kund*innen auswirkt, die Microservices in der Azure Container Apps-Umgebung ausführen, und gleichzeitig die bestmögliche Erfahrung bietet.

Die Verfügbarkeit der Alpha-APIs von Dapr wird nicht garantiert oder von Microsoft unterstützt.

Während Komponenten der Ebene 1 vollständig unterstützt werden, werden Komponenten der Ebene 2 nach größter Mühe unterstützt. Weitere Informationen

Der typische Zeitplan für die Veröffentlichung von Dapr beträgt bis zu sechs Wochen nach der Veröffentlichung der Dapr OSS. Die neueste Dapr-Version wird erst nach strengen Tests in Azure Container Apps zur Verfügung gestellt. Die Ausweitung auf alle Regionen kann bis zu zwei Wochen oder länger dauern.

Sie können über das Azure Container Apps GitHub Repository eine Anforderung für eine Funktion einreichen. Stellen Sie sicher, dass der Titel der Funktionsanforderung „Dapr“ enthält.

Mit einer Bereitstellung ohne Docker können Sie Ihre Anwendung bereitstellen, ohne eine Dockerfile in Ihrem Code zu definieren. Stattdessen verwendet die Cloud Build-Funktionalität von Container Apps Buildpacks, um den Quellcode auf Ihrem lokalen Computer in ein Container-Image zu verwandeln. Diese Option verwendet die Standardregistrierung von Azure Container Apps.

Sie haben ein bekanntes Problem mit Bereitstellungen ohne Docker. Ein erneuter Versuch könnte das Problem beheben. Wenn dieses Problem auftritt, erstellen Sie ein GitHub-Ticket, damit unser Team es untersuchen kann.

Sie müssen den Schutz von Daten für alle .NET-Apps in Azure Container Apps aktivieren. Weitere Informationen finden Sie unter Bereitstellen und Skalieren einer ASP.NET Core-App in Azure Container Apps.

Container Apps unterstützt vier LTS JDK-Versionen: JDK 8, JDK 11, JDK 17 und JDK 21. Für die Erstellung von Quellcode ist die Standardversion JDK 17. Bei einem JAR-Datei-Build wird die JDK-Version aus dem Dateispeicherort META-INF\MANIFEST.MF im JAR gelesen, aber die Standard-JDK-Version 17 verwendet, wenn die angegebene Version nicht verfügbar ist.

Sie können die JDK-Version so konfigurieren, dass sie die Standardversion über Build-Umgebungsvariablen überschreibt.

Maven

Sie können einen Java-Imagebuild über Build-Umgebungsvariablen anpassen.

Wenn Sie die Anwendung containerapp up in Kombination mit einer Codebasis ohne Docker verwenden, benutzen Sie den Parameter --location, damit die Anwendung an einem anderen Ort als USA, Osten aufgeführt werden kann.