Freigeben über

Netztechnologie in einer Azure Container Apps-Umgebung

Azure Container Apps wird im Kontext einer Umgebung mit einem eigenen virtuellen Netzwerk (VNet) ausgeführt.

Standardmäßig wird Ihre Container App-Umgebung mit einem VNet erstellt, das automatisch für Sie generiert wird. Für eine optimale Steuerung Ihres Netzwerks können Sie beim Erstellen einer Umgebung ein vorhandenes VNet bereitstellen. Nachdem Sie eine Umgebung mit einem generierten oder vorhandenen VNet erstellt haben, kann der Netzwerktyp nicht mehr geändert werden.

Generierte VNets haben die folgenden Merkmale.

Sie lauten wie folgt:

  • Für Sie nicht zugänglich, da sie im Mandanten von Microsoft erstellt werden
  • Öffentlich zugänglich über das Internet
  • nur in der Lage, internetfähige Endpunkte zu erreichen

Darüber hinaus unterstützen sie nur eine begrenzte Teilmenge von Netzwerkfunktionen, z. B. eingehende IP-Einschränkungen und Eingangssteuerelemente auf Container-App-Ebene.

Verwenden Sie ein vorhandenes VNet, wenn Sie weitere Azure-Netzwerkfeatures benötigen, z. B.:

  • Integration mit Application Gateway
  • Netzwerksicherheitsgruppen
  • Kommunikation mit Ressourcen hinter privaten Endpunkten in Ihrem virtuellen Netzwerk

Die verfügbaren VNet-Features hängen von Ihrer Umgebungsauswahl ab.

Umgebungsauswahl

Container Apps verfügt über zwei verschiedene Umgebungstypen, die viele identische Netzwerkmerkmale mit einigen wichtigen Unterschieden aufweisen.

Umgebungstyp Unterstützte Plantypen Beschreibung
Workloadprofile Verbrauch, dediziert Unterstützt benutzerdefinierte Routen (User-Defined Routes; UDR), den Ausgang über NAT Gateway und das Erstellen privater Endpunkte in der Container Apps-Umgebung. Die minimale erforderliche Subnetzgröße ist /27.
Nur Verbrauch Verbrauch Unterstützt keine benutzerdefinierten Routen (User Defined Routes, UDR), den Ausgang über NAT Gateway, Peering über ein Remotegateway oder einen anderen benutzerdefinierten Ausgang. Die minimale erforderliche Subnetzgröße ist /23.

Virtuelle IP

Je nach Ihrer Konfiguration der virtuellen IP können Sie auf der Umgebungsebene konfigurieren, ob Ihre Container Apps-Umgebung öffentlichen Eingang oder Eingang nur aus Ihrem VNet zulässt. Diese Konfiguration kann nicht geändert werden, nachdem Ihre Umgebung erstellt wurde.

Zugriffsebene Beschreibung
Extern Ermöglicht Ihrer Container-App, öffentliche Anforderungen zu akzeptieren. Externe Umgebungen werden mit einer virtuellen IP über eine externe, über das Internet zugängliche IP-Adresse bereitgestellt.
Intern Interne Umgebungen haben keine öffentlichen Endpunkte und werden mit einer virtuellen IP (VIP) bereitgestellt, die einer internen IP-Adresse zugeordnet ist. Der interne Endpunkt ist ein interner Azure Load Balancer (ILB); IP-Adressen werden aus der Liste der privaten IP-Adressen des benutzerdefinierten VNet ausgegeben.

Benutzerdefinierte VNet-Konfiguration

Wenn Sie ein benutzerdefiniertes VNet erstellen, berücksichtigen Sie die folgenden Situationen:

  • Wenn Ihre Container-App den gesamten externen Zugriff einschränken soll, erstellen Sie eine interne Container Apps-Umgebung.

  • Wenn Sie Ihr eigenes VNet nutzen, müssen Sie ein Subnetz bereitstellen, das ausschließlich der Container Apps-Umgebung zugeordnet ist, die Sie bereitstellen. Dieses Subnetz steht anderen Diensten nicht zur Verfügung.

  • Netzwerkadressen werden aus einem Subnetzbereich zugewiesen, den Sie beim Erstellen der Umgebung definieren.

    • Sie können den Subnetzbereich definieren, der von der Container Apps-Umgebung verwendet wird.

    • Sie können eingehende Anforderungen an die Umgebung ausschließlich auf das VNet beschränken, indem Sie die Umgebung als „intern“ bereitstellen.

Hinweis

Wenn Sie Ihr eigenes virtuelles Netzwerk bereitstellen, werden zusätzliche verwaltete Ressourcen erstellt. Diese Ressourcen verursachen Kosten zu ihren zugeordneten Tarifen.

Wenn Sie mit dem Entwerfen des Netzwerks für Ihre Container-App beginnen, lesen Sie Planen virtueller Netzwerke.

Diagramm der Verwendung eines bestehenden oder eines eigenen VNets durch Azure Container Apps-Umgebungen

Hinweis

Das Verschieben von VNets zwischen verschiedenen Ressourcengruppen oder Abonnements ist nicht zulässig, wenn das VNet von einer Container-Apps-Umgebung verwendet wird.

Verhalten des HTTP-Edgeproxys

Azure Container Apps verwendet den Envoy-Proxy als HTTP-Edgeproxy. TLS (Transport Layer Security) endet am Edge, Anforderungen werden gemäß der zugehörigen Datenverkehrs-Aufteilungsregeln weitergeleitet, und der Datenverkehr wird an die richtige Anwendung weitergeleitet.

HTTP-Anwendungen werden basierend auf der Anzahl der HTTP-Anforderungen und -Verbindungen skaliert. Envoy leitet den internen Datenverkehr innerhalb von Clustern weiter.

Downstreamverbindungen unterstützen HTTP 1.1 und HTTP 2, und Envoy erkennt und aktualisiert Verbindungen automatisch, falls für die Clientverbindung ein Upgrade erforderlich ist.

Die Upstreamverbindungen werden durch Festlegen der transport-Eigenschaft im ingress-Objekt definiert.

Konfiguration des eingehenden Datenverkehrs

Im Abschnitt ingress (Eingang) können Sie die folgenden Einstellungen konfigurieren:

  • Zugriffsebene: Sie können Ihre Container-App in der Umgebung als extern oder intern zugänglich festlegen. Die Umgebungsvariable CONTAINER_APP_ENV_DNS_SUFFIX dient dazu, das FQDN-Suffix (vollqualifizierter Domänenname) für Ihre Umgebung automatisch aufzulösen. Bei der Kommunikation zwischen Container-Apps innerhalb derselben Umgebung können Sie auch den App-Namen verwenden. Weitere Informationen zum Zugreifen auf Ihre Apps finden Sie unter Eingang in Azure Container Apps.

  • Datenverkehrs-Aufteilungsregeln: Sie können Datenverkehrs-Aufteilungsregeln zwischen verschiedenen Revisionen Ihrer Anwendung definieren. Weitere Informationen finden Sie unter Datenverkehrsaufteilung.

Weitere Informationen zu verschiedenen Netzwerkszenarien finden Sie unter Eingang in Azure Container Apps.

Portalabhängigkeiten

Für jede App in Azure Container Apps gibt es zwei URLs.

Die Container Apps-Runtime generiert zunächst einen vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN), der für den Zugriff auf Ihre App verwendet wird. Sehen Sie sich die Anwendungs-URL im Übersichtsfenster Ihrer Container-App im Azure-Portal für den FQDN Ihrer Container-App an.

Eine zweite URL wird auch für Sie generiert. Dieser Speicherort gewährt Zugriff auf den Protokollstreamingdienst und die Konsole. Sie müssen möglicherweise bei Bedarf https://<region>.azurecontainerapps.dev/ der Zulassungsliste Ihrer Firewall oder Ihres Proxys hinzufügen.

Ports und IP-Adressen

Die folgenden Ports werden für eingehende Verbindungen verfügbar gemacht.

Protokoll Port(e)
HTTP/HTTPS 80, 443

IP-Adressen werden in die folgenden Typen unterteilt:

Typ Beschreibung
Öffentliche IP-Adresse für eingehenden Datenverkehr Wird für den Anwendungsdatenverkehr in einer externen ASE und für den Verwaltungsdatenverkehr sowohl bei externen als auch bei internen Bereitstellungen verwendet.
Öffentliche IP-Adresse für ausgehenden Datenverkehr Wird als „von“-IP-Adresse für ausgehende Verbindungen verwendet, die das virtuelle Netzwerk verlassen. Diese Verbindungen werden nicht über ein VPN weitergeleitet. Ausgehende IP-Adressen können sich im Lauf der Zeit ändern. Die Verwendung eines NAT-Gateways oder eines anderen Proxys für ausgehenden Datenverkehr aus einer Container Apps-Umgebung wird nur in einer Umgebung mit Workloadprofilen unterstützt.
IP-Adresse des internen Lastenausgleichs Diese Adresse ist nur in einer internen Bereitstellung vorhanden.

Subnetz

Die VNet-Integration hängt von der Verwendung eines dedizierten Subnetzes ab. Die Zuordnung von IP-Adressen in einem Subnetz und den unterstützten Subnetzgrößen hängt vom Plan ab, den Sie in Azure-Container-Apps verwenden.

Wählen Sie Ihre Subnetzgröße sorgfältig aus. Subnetzgrößen können nicht geändert werden, nachdem Sie eine Container-Apps-Umgebung erstellt haben.

Unterschiedliche Umgebungstypen weisen unterschiedliche Subnetzanforderungen auf:

  • /27 ist die minimale Subnetzgröße, die für die VNet-Integration erforderlich ist.

  • Ihr Subnetz muss an Microsoft.App/environments delegiert werden.

  • Wenn Sie eine externe Umgebung mit externem Eingang verwenden, wird der eingehende Datenverkehr über die öffentliche IP-Adresse der Infrastruktur und nicht über Ihr Subnetz geleitet.

  • Container-Apps reserviert automatisch 12 IP-Adressen für die Integration in das Subnetz. Die Anzahl der für die Infrastrukturintegration erforderlichen IP-Adressen variiert nicht basierend auf den Skalierungsanforderungen der Umgebung. Zusätzliche IP-Adressen werden nach den folgenden Regeln zugewiesen. Je nach Art des von Ihnen verwendeten Workloadprofils werden je nach Workloadprofil Ihrer Umgebung mehr IP-Adressen zugewiesen:

    • Dediziertes Workloadprofil: Wenn Ihre Container-App skaliert wird, wird jede, Knoten eine IP-Adresse zugewiesen.

    • Verbrauchsbasiertes Workloadprofil: Jede IP-Adresse kann für mehrere Replikate freigegeben werden. Wenn Sie planen, wie viele IP-Adressen für Ihre Anwendung benötigt werden, planen Sie eine IP-Adresse pro 10 Replikaten ein.

  • Wenn Sie eine Änderung an einer Überarbeitung im Einzelrevisionsmodus vornehmen, wird der erforderliche Adressraum für einen kurzen Zeitraum verdoppelt, um Bereitstellungen ohne Ausfallzeiten zu unterstützen. Dies wirkt sich auf die tatsächlichen, verfügbaren unterstützten Replikate oder Knoten für eine bestimmte Subnetzgröße aus. Die folgende Tabelle zeigt sowohl die maximal verfügbaren Adressen pro CIDR-Block als auch die Auswirkungen auf die horizontale Skalierung.

    Subnetzgröße Verfügbare IP-Adressen1 Max. Knoten (Dediziertes Workloadprofil)2 Max. Replikate (Verbrauchs-Workloadprofil)2
    /23 498 249 2,490
    /24 242 121 1,210
    /25 114 57 570
    /26 50 25 250
    /27 18 9 90

    1 Die verfügbaren IP-Adressen sind die Größe des Subnetzes abzüglich der 14 IP-Adressen, die für die Azure-Container-Apps-Infrastruktur erforderlich sind, die 5 IP-Adressen enthält, die vom Subnetz reserviert sind.
    2 Dies gilt für Apps im Einzelrevisionsmodus.

Einschränkungen des Subnetzadressbereichs

Subnetzadressbereiche dürfen sich nicht mit den folgenden Bereichen überschneiden, die für Azure Kubernetes Services reserviert sind:

  • 169.254.0.0/16
  • 172.30.0.0/16
  • 172.31.0.0/16
  • 192.0.2.0/24

Darüber hinaus reserviert eine Umgebung mit Workloadprofilen die folgenden Adressen:

  • 100.100.0.0/17
  • 100.100.128.0/19
  • 100.100.160.0/19
  • 100.100.192.0/19

Subnetzkonfiguration mit der Befehlszeilenschnittstelle

Wenn eine Container Apps-Umgebung erstellt wird, geben Sie Ressourcen-IDs für ein einzelnes Subnetz an.

Wenn Sie die CLI verwenden, ist infrastructure-subnet-resource-id der Parameter zum Definieren der Subnetzressourcen-ID. Das Subnetz hostet Infrastrukturkomponenten und Benutzer-App-Container.

Wenn Sie die Azure-Befehlszeilenschnittstelle in einer reinen verbrauchsgesteuerten Umgebung verwenden und der platformReservedCidr-Bereich definiert ist, dürfen sich die Subnetze nicht mit dem in platformReservedCidr definierten IP-Adressbereich überschneiden.

Routen

Benutzerdefinierte Routen (UDR)

Benutzerdefinierte Routen (User Defined Routes, UDR) und der gesteuerte Ausgang über NAT Gateway werden in einer Umgebung mit Workloadprofilen unterstützt. In einer reinen verbrauchsgesteuerten Umgebung werden diese Features nicht unterstützt.

Hinweis

Wenn Sie UDRs mit Azure Firewall in Azure Container Apps verwenden, müssen Sie bestimmte FQDNs und Diensttags der Positivliste für die Firewall hinzufügen. Weitere Informationen finden Sie unter Konfigurieren von UDRs mit Azure Firewall.

  • Sie können UDRs in Umgebungen mit Workloadprofilen verwenden, um ausgehenden Datenverkehr aus Ihrer Container-App über Azure Firewall oder andere Netzwerkgeräte einzuschränken.

  • Das Konfigurieren von UDRs erfolgt außerhalb des Bereichs der Container Apps-Umgebung.

Diagramm der Implementierung von UDRs für Container Apps

Azure erstellt beim Erstellen eine Standardroutentabelle für Ihre virtuellen Netzwerke. Durch die Implementierung einer benutzerdefinierten Routentabelle können Sie steuern, wie Datenverkehr innerhalb Ihres virtuellen Netzwerks weitergeleitet wird. Sie können z. B. ein UDR erstellen, das den gesamten Datenverkehr an die Firewall weiterleitet.

Konfigurieren von UDRs mit Azure Firewall

Benutzerdefinierte Routen (UDRs) werden nur in einer Umgebung mit Workloadprofilen unterstützt. Die folgenden Anwendungs- oder Netzwerkregeln müssen der Zulassungsliste für Ihre Firewall hinzugefügt werden, je nachdem, welche Ressourcen Sie verwenden.

Hinweis

Je nach Den Anforderungen Ihres Systems müssen Sie entweder Anwendungsregeln oder Netzwerkregeln konfigurieren. Das Gleichzeitige Konfigurieren beider Konfigurationen ist nicht erforderlich.

Hinweis

Einen Leitfaden zum Einrichten von UDRs mit Container Apps, um ausgehenden Datenverkehr mit Azure Firewall einzuschränken, finden Sie unter Vorgehensweise für Container Apps und Azure-Firewall.

Anwendungsregeln

Anwendungsregeln erlauben oder verweigern Datenverkehr basierend auf der Anwendungsschicht. Die folgenden ausgehenden Firewallregeln für Anwendungen sind basierend auf einem Szenario erforderlich.

Szenarien vollqualifizierte Domainnamen (FQDNs) Beschreibung
Alle Szenarien mcr.microsoft.com, *.data.mcr.microsoft.com Diese FQDNs für die Microsoft Container Registry (MCR) werden von Azure Container Apps verwendet. Entweder diese Anwendungsregeln oder die Netzwerkregeln für MCR müssen der Zulassungsliste hinzugefügt werden, wenn Sie Azure-Container-Apps mit Azure Firewall verwenden.
Azure Container Registry (ACR) Ihre ACR-Adresse, *.blob.core.windows.net, login.microsoft.com Diese FQDNs sind erforderlich, wenn Sie Azure Container Apps mit ACR und Azure Firewall verwenden.
Azure Key Vault (ein Dienst zur sicheren Verwaltung kryptografischer Schlüssel) Ihre-Azure-Key-Vault-Adresse, login.microsoft.com Diese FQDNs sind zusätzlich zu dem Diensttag erforderlich, das für die Netzwerkregel für Azure Key Vault erforderlich ist.
Verwaltete Identität *.identity.azure.netlogin.microsoftonline.com*.login.microsoftonline.com*.login.microsoft.com Diese FQDNs sind erforderlich, wenn Sie eine verwaltete Identität mit Azure Firewall in Azure Container Apps verwenden.
Aspire Dashboard https://northcentralus.ext.azurecontainerapps.dev Dieser FQDN ist erforderlich, wenn das Aspire-Dashboard in einer Umgebung verwendet wird, die mit einem virtuellen Netzwerk konfiguriert ist.
Docker-Hubregistrierung hub.docker.com, registry-1.docker.ioproduction.cloudflare.docker.com Wenn Sie die Docker-Hubregistrierung verwenden und über die Firewall darauf zugreifen möchten, müssen Sie der Firewall diese FQDNs hinzufügen.
Netzwerkregeln

Netzwerkregeln ermöglichen oder verweigern Datenverkehr basierend auf der Netzwerk- und Transportschicht. Die folgenden ausgehenden Firewallregeln für Netzwerke sind basierend auf einem Szenario erforderlich.

Szenarien Diensttag Beschreibung
Alle Szenarien MicrosoftContainerRegistry, AzureFrontDoorFirstParty Diese Diensttags für die Microsoft Container Registry (MCR) werden von Azure-Container-Apps verwendet. Entweder diese Netzwerkregeln oder die Anwendungsregeln für MCR müssen der Zulassungsliste hinzugefügt werden, wenn Sie Azure-Container-Apps mit Azure Firewall verwenden.
Azure Container Registry (ACR) AzureContainerRegistry, AzureActiveDirectory Wenn Sie ACR mit Azure Container-Apps verwenden, müssen Sie diese Netzwerkregeln konfigurieren, die von der Azure Container Registry verwendet werden.
Azure Key Vault (ein Dienst zur sicheren Verwaltung kryptografischer Schlüssel) AzureKeyVault, AzureActiveDirectory Diese Diensttags sind zusätzlich zum FQDN für die Netzwerkregel für Azure Key Vault erforderlich.
Verwaltete Identität AzureActiveDirectory Wenn Sie verwaltete Identität mit Azure-Container-Apps verwenden, müssen Sie diese Netzwerkregeln konfigurieren, die von verwalteter Identität verwendet werden.

Hinweis

Informationen zu Azure-Ressourcen, die Sie mit der Azure Firewall verwenden, die in diesem Artikel nicht aufgeführt sind, finden Sie in der Dokumentation zu Diensttags.

NAT Gateway-Integration

Sie können NAT Gateway verwenden, um die ausgehende Konnektivität für Ihren ausgehenden Internetdatenverkehr in Ihrem virtuellen Netzwerk in einer Umgebung mit Workloadprofilen zu vereinfachen.

Wenn Sie ein NAT-Gateway in Ihrem Subnetz konfigurieren, stellt das NAT-Gateway eine statische öffentliche IP-Adresse für Ihre Umgebung bereit. Der gesamte ausgehende Datenverkehr aus Ihrer Container-App wird über die statische öffentliche IP-Adresse von NAT Gateway weitergeleitet.

Zugriff aus öffentlichen Netzwerken

Die Einstellung für den öffentlichen Netzwerkzugriff bestimmt, ob aus dem öffentlichen Internet auf Ihre Container Apps-Umgebung zugegriffen werden kann. Ob Sie diese Einstellung nach dem Erstellen Ihrer Umgebung ändern können, hängt von der Konfiguration der virtuellen IP der Umgebung ab. In der folgenden Tabelle sind gültige Werte für den öffentlichen Netzwerkzugriff für unterschiedliche Konfigurationen der virtuellen IP Ihrer Umgebung aufgeführt.

Virtuelle IP Unterstützter öffentlicher Netzwerkzugriff Beschreibung
Extern Enabled, Disabled Die Container Apps-Umgebung wurde mit einem über das Internet zugänglichen Endpunkt erstellt. Die Einstellung für öffentlichen Netzwerkzugriff bestimmt, ob Datenverkehr über den öffentlichen Endpunkt oder nur über private Endpunkte akzeptiert wird. Die Einstellung für den öffentlichen Netzwerkzugriff kann nach dem Erstellen der Umgebung geändert werden.
Intern Disabled Die Container Apps-Umgebung wurde ohne einen über das Internet zugänglichen Endpunkt erstellt. Die Einstellung für den Zugriff auf öffentliche Netzwerke kann nicht geändert werden, um Datenverkehr aus dem Internet zu akzeptieren.

Um private Endpunkte in Ihrer Azure Container Apps-Umgebung zu erstellen, muss der öffentliche Netzwerkzugriff auf Disabled festgelegt werden.

Azure-Netzwerkrichtlinien werden mit dem Flag für den öffentlichen Netzwerkzugriff unterstützt.

Privater Endpunkt

Der private Azure-Endpunkt ermöglicht Clients, die sich in Ihrem privaten Netzwerk befinden, über Azure Private Link eine sichere Verbindung mit Ihrer Azure Container Apps-Umgebung herzustellen. Bei einer Private Link-Verbindung wird der Datenverkehr also vom öffentlichen Internet isoliert. Private Endpunkte verwenden eine private IP-Adresse aus dem Adressraum Ihres virtuellen Azure-Netzwerks.

Dieses Feature wird sowohl für Verbrauchspläne als auch für dedizierte Pläne in Umgebungen mit Workloadprofilen unterstützt.

Tutorials

Überlegungen

  • Um einen privaten Endpunkt mit einer benutzerdefinierten Domäne und einer Apex-Domäne als Datensatztyp „Hostname“ zu verwenden, müssen Sie eine private DNS-Zone mit demselben Namen wie Ihr öffentliches DNS konfigurieren. Konfigurieren Sie im Recordset die private IP-Adresse Ihres privaten Endpunkts anstelle der IP-Adresse der Container App-Umgebung. Wenn Sie Ihre benutzerdefinierte Domäne mit CNAME konfigurieren, bleibt das Setup unverändert. Weitere Informationen finden Sie unter Einrichten einer benutzerdefinierten Domäne mit einem vorhandenen Zertifikat.
  • Das VNet Ihres privaten Endpunkts kann von dem mit Ihrer Container-App integrierten VNet getrennt werden.
  • Sie können einen privaten Endpunkt sowohl zu neuen als auch vorhandenen Workloadprofilumgebungen hinzufügen.

Um eine Verbindung mit Ihren Container-Apps über einen privaten Endpunkt herzustellen, müssen Sie eine private DNS-Zone konfigurieren.

Dienst Unterressource Name der privaten DNS-Zone
Azure-Container-Apps (Microsoft.App/ManagedEnvironments) managedEnvironment Privater Link. {regionName}.azurecontainerapps.io

Umgebungssicherheit

Hinweis

Um den eingehenden Datenverkehr zu steuern, können Sie auch private Endpunkte mit einer privaten Verbindung mit Azure Front Door anstelle von Application Gateway verwenden.

Diagramm der vollständigen Sperrung Ihres Netzwerks für Container Apps

Sie können Ihre Umgebung für ein- und ausgehenden Netzwerkdatenverkehr vollständig schützen, indem Sie die folgenden Aktionen ausführen:

Peer-zu-Peer-Verschlüsselung in der Azure Container Apps-Umgebung

Azure-Container-Apps unterstützen die Peer-to-Peer-TLS-Verschlüsselung innerhalb der Umgebung. Durch Aktivieren dieses Features wird der gesamte Netzwerkdatenverkehr innerhalb der Umgebung mit einem privaten Zertifikat verschlüsselt, das innerhalb des Bereichs der Azure Container Apps-Umgebung gültig ist. Azure Container-Apps verwalten diese Zertifikate automatisch.

Hinweis

Standardmäßig ist die Peer-zu-Peer-Verschlüsselung deaktiviert. Das Aktivieren der Peer-to-Peer-Verschlüsselung für Ihre Anwendungen kann die Antwortlatenz erhöhen und den maximalen Durchsatz in Szenarien mit hoher Auslastung verringern.

Das folgende Beispiel zeigt eine Umgebung mit aktivierter Peer-to-Peer-Verschlüsselung. Diagramm der Ver-/Entschlüsselung von Datenverkehr mit aktivierter Peer-zu-Peer-Verschlüsselung

1 Eingehender TLS-Datenverkehr wird am Eingangsproxy am Edge der Umgebung beendet.

2 Datenverkehr zum und vom Eingangsproxy innerhalb der Umgebung wird mit einem privaten Zertifikat TLS-verschlüsselt und vom Empfänger entschlüsselt.

3 Aufrufe von App A an den FQDN von App B werden zuerst an den Eingangsproxy am Edge gesendet und sind mit TLS verschlüsselt.

4 Aufrufe von App A an App B mithilfe des App-Namens von App B werden direkt an App B gesendet und mit TLS verschlüsselt. Aufrufe zwischen Apps und Java-Komponenten werden auf die gleiche Weise behandelt wie die App für die App-Kommunikation und mit TLS verschlüsselt.

Anwendungen in einer Container Apps-Umgebung werden automatisch authentifiziert. Die Container Apps-Runtime unterstützt jedoch keine Autorisierung für die Zugriffssteuerung zwischen Anwendungen, die die integrierte Peer-zu-Peer-Verschlüsselung verwenden.

Wenn Ihre Apps mit einem Client außerhalb der Umgebung kommunizieren, wird die bidirektionale Authentifizierung mit mTLS unterstützt. Weitere Informationen finden Sie unter Konfigurieren von Clientzertifikaten.

Sie können die Peer-zu-Peer-Verschlüsselung mit den folgenden Befehlen aktivieren.

Beim Erstellen:

az containerapp env create \
    --name <environment-name> \
    --resource-group <resource-group> \
    --location <location> \
    --enable-peer-to-peer-encryption

Für eine vorhandene Container-App:

az containerapp env update \
    --name <environment-name> \
    --resource-group <resource-group> \
    --enable-peer-to-peer-encryption

Regelbasiertes Routing (Vorschau)

Mit regelbasiertem Routing erstellen Sie einen vollqualifizierten Domänennamen (FQDN) in Ihrer Container-Apps-Umgebung. Anschließend verwenden Sie Regeln, um Anforderungen an diesen FQDN abhängig vom Pfad jeder Anforderung an verschiedene Container-Apps weiterzuleiten. Dies bietet die folgenden Vorteile.

  • Isolation: Indem Sie verschiedene Pfade an verschiedene Container-Apps weiterleiten, können Sie einzelne Komponenten bereitstellen und aktualisieren, ohne dass sich die gesamte Anwendung auswirkt.

  • Skalierbarkeit: Mit regelbasiertem Routing können Sie einzelne Container-Apps unabhängig vom Datenverkehr skalieren, den jede Container-App empfängt.

  • Benutzerdefinierte Routingregeln: Sie können z. B. Benutzer zu verschiedenen Versionen Ihrer Anwendung umleiten oder A/B-Tests implementieren.

  • Sicherheit: Sie können Auf jede Container-App zugeschnittene Sicherheitsmaßnahmen implementieren. Dies hilft Ihnen, die Angriffsfläche Ihrer Anwendung zu reduzieren.

Informationen zum Konfigurieren des regelbasierten Routings in Ihrer Container-Apps-Umgebung finden Sie unter Verwenden des regelbasierten Routings.

DNS

  • Benutzerdefiniertes DNS: Wenn Ihr VNet anstelle des standardmäßigen von Azure bereitgestellten DNS-Servers einen benutzerdefinierten DNS-Server verwendet, konfigurieren Sie Ihren DNS-Server so, dass nicht aufgelöste DNS-Abfragen an 168.63.129.16 weitergeleitet werden. Rekursive Resolver von Azure verwenden diese IP-Adresse, um Anforderungen aufzulösen. Wenn Sie Ihre NSG oder Firewall konfigurieren, blockieren Sie die 168.63.129.16 Adresse nicht, andernfalls funktioniert Ihre Container-Apps-Umgebung nicht ordnungsgemäß.

  • Eingehend im VNet-Bereich: Wenn Sie den eingehenden VNet-Bereich in einer internen Umgebung verwenden möchten, konfigurieren Sie Ihre Domänen auf eine der folgenden Arten:

    1. Nicht benutzerdefinierte Domänen: Wenn Sie nicht planen, eine benutzerdefinierte Domäne zu verwenden, erstellen Sie eine private DNS-Zone, die die Standarddomäne der Container Apps-Umgebung in die statische IP-Adresse der Container Apps-Umgebung auflöst. Sie können das private Azure-DNS oder Ihren eigenen DNS-Server verwenden. Wenn Sie privates Azure-DNS verwenden, erstellen Sie eine private DNS-Zone, die als die Standarddomäne der Container Apps-Umgebung (<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io) mit einem A-Eintrag bezeichnet wird. Der A-Eintrag enthält den Namen *<DNS Suffix> und die statische IP-Adresse der Container Apps-Umgebung. Weitere Informationen finden Sie unter Erstellen und Konfigurieren einer Azure Private DNS-Zone.

    2. Benutzerdefinierte Domänen: Wenn Sie benutzerdefinierte Domänen verwenden und eine externe Container Apps-Umgebung verwenden möchten, verwenden Sie eine öffentlich auflösbare Domäne, um der Container-App eine benutzerdefinierte Domäne und ein Zertifikat hinzuzufügen. Wenn Sie eine interne Container-Apps-Umgebung verwenden, gibt es keine Überprüfung für die DNS-Bindung, da auf den Cluster nur innerhalb des virtuellen Netzwerks zugegriffen werden kann. Erstellen Sie außerdem eine private DNS-Zone, die die apex-Domäne in die statische IP-Adresse der Container Apps-Umgebung auflöst. Sie können das private Azure-DNS oder Ihren eigenen DNS-Server verwenden. Wenn Sie privates Azure-DNS verwenden, erstellen Sie eine private DNS-Zone mit demselben Namen wie die apex-Domäne und einen A-Eintrag, der auf die statische IP-Adresse der Container Apps-Umgebung verweist.

Die statische IP-Adresse der Container Apps-Umgebung erhalten Sie im Azure-Portal im benutzerdefinierten DNS-Suffix der Container-App-Seite oder mit dem Azure CLI-Befehl az containerapp env list.

Verwaltete Ressourcen

Wenn Sie eine interne oder externe Umgebung in Ihrem eigenen Netzwerk bereitstellen, wird im Azure-Abonnement, in dem Ihre Umgebung gehostet wird, eine neue Ressourcengruppe erstellt. Diese Ressourcengruppe enthält Infrastrukturkomponenten, die von der Azure Container Apps-Plattform verwaltet werden. Ändern Sie weder die Dienste in dieser Gruppe noch die Ressourcengruppe selbst.

Hinweis

Benutzerdefinierte Tags, die Ihrer Container-Apps-Umgebung zugewiesen sind, werden in alle Ressourcen innerhalb der Ressourcengruppe repliziert, einschließlich der Ressourcengruppe selbst.

Umgebung mit Workloadprofilen

Der Name der Ressourcengruppe, die im Azure-Abonnement erstellt wurde, in dem Ihre Umgebung gehostet wird, ist standardmäßig mit ME_ präfixiert, und der Ressourcengruppenname kann angepasst werden, wenn Sie Ihre Container-App-Umgebung erstellen.

Für externe Umgebungen enthält die Ressourcengruppe eine öffentliche IP-Adresse, die speziell für eingehende Verbindungen mit Ihrer externen Umgebung und einem Lastenausgleich verwendet wird. Für interne Umgebungen enthält die Ressourcengruppe nur einen Lastenausgleich.

Zusätzlich zur standardmäßigen Azure Container Apps-Abrechnung werden Ihnen folgende Abrechnungen in Rechnung gestellt:

  • Eine statische öffentliche Standard-IP für den Ausgang, wenn eine interne oder externe Umgebung verwendet wird, sowie eine statische öffentliche Standard-IP für den Ausgang bei Verwendung einer externen Umgebung. Wenn Sie aufgrund von SNAT-Problemen zusätzliche ausgehende öffentliche IP-Adressen benötigen, erstellen Sie ein Supportticket, um eine Außerkraftsetzung anzufordern.

  • Kein Standard-Load Balancer.

  • Die Kosten der verarbeiteten Daten (in GBs) umfassen sowohl den Eingang als auch den Ausgang für Verwaltungsvorgänge.

Verbrauchsumgebung

Der Name der Ressourcengruppe, die im Azure-Abonnement erstellt wurde, in dem Ihre Umgebung gehostet wird, ist standardmäßig mit MC_ präfixiert, und der Ressourcengruppenname kann nicht angepasst werden, wenn Sie eine Container-App erstellen. Die Ressourcengruppe enthält öffentliche IP-Adressen, die speziell für ausgehende Verbindungen aus Ihrer Umgebung sowie einen Lastenausgleich verwendet werden.

Zusätzlich zur standardmäßigen Azure Container Apps-Abrechnung werden Ihnen folgende Abrechnungen in Rechnung gestellt:

  • Eine statische öffentliche Standard-IP für den Ausgang. Wenn Sie aufgrund von Problemen mit der Quellnetzwerkadressübersetzung (Source Network Address Translation, SNAT) zusätzliche ausgehende IPs benötigen, öffnen Sie ein Supportticket, um eine Außerkraftsetzung anzufordern.

  • Zwei standardmäßige Load Balancers, wenn eine interne Umgebung verwendet wird, oder ein standardmäßiger Load Balancer, wenn eine externe Umgebung verwendet wird. Jeder Lastenausgleich hat weniger als sechs Regeln. Die Kosten der verarbeiteten Daten (in GB) umfassen sowohl den Eingang als auch den Ausgang für Verwaltungsvorgänge.

Nächste Schritte