Eingang in Azure Container Apps

  • Artikel

Mit Azure-Container Apps können Sie Ihre Container App für das öffentliche Web, Ihr virtuelles Netzwerk (VNET) und andere Container Apps in Ihrer Umgebung verfügbar machen, indem Sie den Eingang aktivieren. Eingangseinstellungen werden über eine Reihe von Regeln erzwungen, die das Routing des externen und internen Datenverkehrs an Ihre Container App steuern. Wenn Sie den Eingang aktivieren, müssen Sie keinen Azure Load Balancer, öffentliche IP-Adresse oder andere Azure-Ressourcen erstellen, um eingehende HTTP-Anforderungen oder TCP-Datenverkehr zu aktivieren.

Ingress unterstützt:

Beispiel für die Eingangskonfiguration, in der die Eingangsteilung zwischen zwei Revisionen angezeigt wird:

Diagram showing an ingress configuration splitting traffic between two revisions.

Konfigurationsdetails finden Sie unter Konfigurieren des Eingangs.

Externen und internen Eingang

Wenn Sie den Eingangstyp aktivieren, können Sie zwischen zwei Arten von Eingangsvorgängen wählen:

  • Extern: Akzeptiert Datenverkehr sowohl aus dem öffentlichen Internet als auch aus der internen Umgebung Ihrer Container-App.
  • Intern: Ermöglicht nur internen Zugriff innerhalb der Umgebung Ihrer Container-App.

Jede Container-App in einer Umgebung kann mit unterschiedlichen Eingangseinstellungen konfiguriert werden. Beispielsweise können Sie in einem Szenario mit mehreren Microservice-Apps eine einzelne Container-App haben, die öffentliche Anforderungen empfängt und die Anforderungen an einen Hintergrunddienst übergibt. In diesem Szenario würden Sie die öffentlich zugängliche Container-App mit einem externen Eingang und die interne Container-App mit internem Eingang konfigurieren.

Protokolltypen

Container-Apps unterstützen zwei Protokolle für den Eingang: HTTP und TCP.

HTTP

Wenn der HTTP-Eingang aktiviert ist, verfügt Ihre Container-App über Folgendes:

  • Unterstützung für TLS-Beendigung
  • Unterstützung für HTTP/1.1 und HTTP/2
  • Unterstützung für WebSocket und gRPC
  • HTTPS-Endpunkte, die immer TLS 1.2 oder 1.3 verwenden und am Eingangspunkt abgeschlossen werden
  • Endpunkte, welche die Ports 80 (für HTTP) und 443 (für HTTPS) freigeben
    • HTTP-Anforderungen an den Port 80 werden automatisch an HTTPS auf 443 umgeleitet.
  • Ein vollqualifizierter Domänenname (FQDN)
  • Das Timeout für Anforderungen beträgt 240 Sekunden.

HTTP-Kopfzeilen

HTTP-Eingang fügt Header hinzu, um Metadaten zur Clientanforderung an Ihre Container-App zu übergeben. Beispielsweise wird der X-Forwarded-Proto-Header verwendet, um das Protokoll zu identifizieren, das der Client für die Verbindung mit dem Container-Apps-Dienst verwendet hat. In der folgenden Tabelle sind die HTTP-Header aufgeführt, die für den Eingang in Container-Apps relevant sind:

Header Beschreibung Werte
X-Forwarded-Proto Protokoll, das vom Client für die Verbindung mit dem Container Apps-Dienst verwendet wird. http oder https
X-Forwarded-For Die IP-Adresse des Clients, der die Anforderung gesendet hat.
X-Forwarded-Host Der Hostname, den der Client für die Verbindung mit dem Container-Apps-Dienst verwendet hat.
X-Forwarded-Client-Cert Das Clientzertifikat, falls clientCertificateMode festgelegt ist. Durch Strichpunkte getrennte Liste von Hash, Zertifikat und Kette. Beispiel: Hash=....;Cert="...";Chain="...";

TCP

Container-Apps unterstützen andere TCP-basierte Protokolle als HTTP oder HTTPS. Sie können beispielsweise TCP-Eingang verwenden, um eine Container-App verfügbar zu machen, die das Redis-Protokoll verwendet.

Hinweis

Externer TCP-Eingang wird nur für Container-Apps-Umgebungen unterstützt, die ein benutzerdefiniertes VNET verwenden.

Mit aktivierter TCP-Eingangsanwendung ist Ihre Container-App:

  • Über den Namen (definiert durch die Eigenschaft in der name-Container-Apps-Ressource) und die verfügbar gemachte Portnummer kann auf andere Container-Apps in derselben Umgebung zugegriffen werden.
  • Extern über den vollqualifizierten Domänennamen (FQDN) und die verfügbar gemachte Portnummer, wenn der Eingang auf "extern" festgelegt ist, zugänglich.

Zusätzliche TCP-Ports

Zusätzlich zum wichtigsten HTTP/TCP-Port für Ihre Container-Apps können Sie zusätzliche TCP-Ports verfügbar machen, um Anwendungen zu ermöglichen, die TCP-Verbindungen auf mehreren Ports akzeptieren.

Hinweis

Dieses Feature erfordert die Verwendung der neuesten Vorschauversion der CLI-Erweiterung für Container-Apps.

Die folgenden Angaben gelten für zusätzliche TCP-Ports:

  • Zusätzliche TCP-Ports können nur extern sein, wenn die App selbst als extern festgelegt ist und die Container-App ein benutzerdefiniertes VNet verwendet.
  • Alle extern verfügbar gemachten zusätzlichen TCP-Ports müssen in der gesamten Container-Apps-Umgebung eindeutig sein. Dazu gehören alle externen zusätzlichen TCP-Ports, externe Haupt-TCP-Ports und 80/443-Ports, die von integrierten HTTP-Eingangsports verwendet werden. Wenn die zusätzlichen Ports intern sind, kann derselbe Port von mehreren Anwendungen gemeinsam genutzt werden.
  • Wenn kein verfügbarer Port bereitgestellt wird, entspricht der verfügbar gemachte Port standardmäßig dem Zielport.
  • Jeder Zielport muss eindeutig sein, und derselbe Zielport kann nicht für verschiedene verfügbar gemachte Ports verfügbar gemacht werden.
  • Pro Anwendung gibt es maximal 5 zusätzliche Ports. Wenn zusätzliche Ports erforderlich sind, öffnen Sie bitte eine Supportanforderung.
  • Nur der Haupteingangsport unterstützt integrierte HTTP-Funktionen wie CORS und Sitzungsaffinität. Wenn Sie HTTP über den zusätzlichen TCP-Ports ausführen, werden diese integrierten Funktionen nicht unterstützt.

Weitere Informationen zum Aktivieren zusätzlicher Ports für Ihre Container-Apps finden Sie im Artikel zum Thema „Eingang“.

Domänennamen

Sie können auf folgende Arten auf Ihre Anwendung zugreifen:

  • Der standardmäßige vollqualifizierte Domänenname (FQDN): Jede Anwendung in einer Container-Apps-Umgebung wird automatisch einem FQDN basierend auf dem DNS-Suffix der Umgebung zugewiesen. Informationen zum Anpassen des DNS-Suffixes einer Umgebung finden Sie unter DNS-Suffix der benutzerdefinierten Umgebung.
  • Ein benutzerdefinierter Domänenname: Sie können eine benutzerdefinierte DNS-Domäne für Ihre Container-Apps-Umgebung konfigurieren. Weitere Informationen finden Sie unter Benutzerdefinierte Domänennamen und Zertifikate.
  • Der App-Name: Sie können den App-Namen für die Kommunikation zwischen Anwendungen in derselben Umgebung verwenden.

Informationen zum Abrufen des FQDN für Ihre Anwendung finden Sie unter Speicherort.

IP-Einschränkungen

Container-Apps unterstützen IP-Einschränkungen für den Eingang. Sie können Regeln erstellen, um entweder IP-Adressen zu konfigurieren, denen der Zugriff auf Ihre Container-Anwendung erlaubt oder verweigert wird. Weitere Informationen finden Sie unter Konfigurieren von IP-Einschränkungen.

Authentifizierung

Azure Container-Apps bieten integrierte Authentifizierungs- und Autorisierungsfunktionen, um Ihre externe eingangsfähige Container-App zu schützen. Weitere Informationen finden Sie unter Authentifizierung und Autorisierung in Azure Container Apps.

Sie können Ihre Anwendung so konfigurieren, dass Clientzertifikate (mTLS) für die Authentifizierung und Datenverkehrsverschlüsselung unterstützt werden. Weitere Informationen finden Sie unter Konfigurieren von Clientzertifikaten.

Ausführliche Informationen zur Verwendung von mTLS für die Netzwerkverschlüsselung auf Umgebungsebene finden Sie in der Netzwerkübersicht.

Trennung von Datenverkehr

Mit Containers Apps können Sie den eingehenden Datenverkehr zwischen aktiven Revisionen aufteilen. Wenn Sie eine Aufteilungsregel definieren, weisen Sie den Prozentsatz des eingehenden Verkehrs zu, der an verschiedene Revisionen gehen soll. Weitere Informationen finden Sie unter Datenverkehrsaufteilung.

Sitzungsaffinität

Sitzungsaffinität, auch bekannt als „Sticky Sessions“, ist eine Funktion, die es Ihnen ermöglicht, alle HTTP-Anfragen von einem Client an dieselbe Container-App-Replik zu leiten. Diese Funktion ist für zustandsbehaftete Anwendungen nützlich, die eine konsistente Verbindung mit demselben Replikat erfordern. Weitere Informationen finden Sie unter Sitzungsaffinität.

Ursprungsübergreifende Ressourcenfreigabe (CORS)

Standardmäßig werden alle Anforderungen, die über den Browser von einer Seite an eine Domäne vorgenommen werden, die nicht mit der Ursprungsdomäne der Seite übereinstimmt, blockiert. Um diese Einschränkung für Dienste zu vermeiden, die für Container-Apps bereitgestellt werden, können Sie die ursprungsübergreifende Ressourcenfreigabe (CROSS-Origin Resource Sharing, CORS) aktivieren.

Weitere Informationen finden Sie unter Konfigurieren von CORS in Azure-Container-Apps.

Nächste Schritte

Konfigurieren des Eingangs