Freigeben über

Übersicht zu .NET in Azure Container Apps

  • Artikel

Wenn Sie eine .NET-Anwendung in einer cloudnativen Umgebung wie Azure Container Apps bereitstellen möchten, müssen Sie einige Entscheidungen treffen, um sicherzustellen, dass Ihre Anwendung reibungslos und sicher ausgeführt wird. Diese Anleitung befasst sich mit den wichtigsten Konzepten für die Bereitstellung einer .NET-Anwendung in Azure Container Apps.

Azure Container Apps ist ein vollständig verwalteter serverloser Containerdienst, mit dem Sie containerisierte Anwendungen ausführen können, ohne die zugrunde liegende Infrastruktur verwalten zu müssen. Container Apps bietet integrierte Unterstützung für Features wie automatische Skalierung, Integritätsprüfungen und TLS-Zertifikate (Transport Layer Security).

In diesem Artikel werden die Konzepte und Bedenken erläutert, die für die Bereitstellung einer .NET-Anwendung auf Azure Container Apps wichtig sind.

Auswählen eines Ressourcentyps

Azure Container Apps unterstützt zwei Arten von Ressourcen: Apps und Aufträge. Apps führen kontinuierlich Dienste aus, während Aufträge kurzlebige Aufgaben sind, die bis zum Abschluss ausgeführt werden sollen.

Berücksichtigen Sie bei der Vorbereitung auf die Bereitstellung Ihrer App Unterschiede zwischen diesen beiden Anwendungstypen, da sich ihr Verhalten darauf auswirkt, wie Ihre .NET-Anwendung verwaltet werden. In der folgenden Tabelle werden die Unterschiede zwischen Anwendungsfällen und Aufträgen beschrieben.

Anwendungsfall Ressourcentyp
Eine ASP.NET Core-Web-API, die HTTP-Anforderungen bedient App
Eine .NET Core-Konsolenanwendung, die Daten verarbeitet und dann beendet wird Job
Ein fortlaufend ausgeführter Hintergrunddienst, der Nachrichten aus einer Warteschlange verarbeitet App
Ein Imageoptimierungsdienst, der nur ausgeführt wird, wenn große Bilder in einem Speicherkonto gespeichert werden Job
Eine Anwendung mit einem Framework wie Hangfire, Quartz.NET oder dem Azure WebJobs SDK App

Containerisieren und Bereitstellen Ihrer .NET-Anwendung

Für Apps oder Aufträge müssen Sie ein Containerimage erstellen, um Ihre .NET-Anwendung packen zu können. Weitere Informationen zum Erstellen von Containerimages finden Sie unter Docker-Images für ASP.NET Core.

Nach der Einrichtung können Sie Ihre Anwendung in Azure Container Apps bereitstellen, indem Sie den folgenden Anleitungen folgen:

Verwenden von eingehendem HTTP-Datenverkehr

Azure Container Apps beinhaltet einen integrierten HTTP-Eingang, mit dem Sie Ihre Apps für Datenverkehr, der von außerhalb des Containers stammt, verfügbar machen können. Der Azure Container Apps-Eingang befindet sich zwischen Ihrer App und dem Endbenutzer. Da der Eingang als Vermittler fungiert, endet alles, was der Endbenutzer oder die Endbenutzerin sieht, am Eingang, und was ihre App sieht, beginnt an diesem Eingang.

Der Eingang verwaltet den TLS-Abschluss und benutzerdefinierte Domänen, sodass Sie diese nicht in Ihrer App manuell konfigurieren müssen. Über den Eingang wird Port 443 für HTTPS-Datenverkehr und optional Port 80 für HTTP-Datenverkehr verfügbar gemacht. Der Eingang leitet Anforderungen an Ihre App am Zielport weiter.

Wenn Ihre App Metadaten zu der ursprünglichen Anforderung benötigt, kann sie X-weitergeleitete Header verwenden.

Weitere Informationen finden Sie unter HTTP-Eingang in Azure Container Apps.

Definieren eines Zielports

Für den Empfang eingehenden Datenverkehrs wird der Eingang für einen Zielport konfiguriert, den Ihre App auf Datenverkehr überwacht.

Wenn ASP.NET Core in einem Container ausgeführt wird, lauscht die Anwendung an Ports, die im Containerimage konfiguriert sind. Wenn Sie die offiziellen ASP.NET Core-Imagesverwenden, ist Ihre App so konfiguriert, dass sie einen Standardport auf HTTP überwacht. Der Standardport hängt von der ASP.NET Core-Version ab.

Laufzeit Zielport
ASP.NET Core 7 und frühere Versionen 80
ASP.NET Core 8 und höher 8080

Wenn Sie den Eingangkonfigurieren, legen Sie den Zielport auf die Nummer fest, die dem verwendeten Containerimage entspricht.

Definieren von X-weitergeleiteten Headern

Da der Eingang die ursprüngliche HTTP-Anforderung verarbeitet, sieht Ihre App den Eingang als Client. Es gibt einige Situationen, in denen die App die IP-Adresse des ursprünglichen Clients oder das ursprüngliche Protokoll (HTTP oder HTTPS) kennen muss. Sie können über den X-Forwarded-*-Header der Anforderung auf die Protokoll- und IP-Informationen zugreifen.

Sie können Originalwerte aus diesen Headern lesen, indem Sie auf das ForwardedHeaders-Objekt zugreifen.

builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders =
        ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
    options.KnownNetworks.Clear();
    options.KnownProxies.Clear();
});

Weitere Informationen zum Arbeiten mit Anforderungsheadern finden Sie unter Konfigurieren von ASP.NET Core für die Arbeit mit Proxyservern und Lastenausgleichsmodulen.

Erstellen cloudnativer .NET-Anwendungen

Anwendungen, die in Azure Container Apps bereitgestellt werden, funktionieren häufig am besten, wenn Sie auf den Grundlagen von cloudnativen Prinzipienaufbauen. In den folgenden Abschnitten werden allgemeine Bedenken in Bezug auf cloudenative Anwendungen erläutert.

Anwendungskonfiguration

Verwenden Sie beim Bereitstellen Ihrer .NET-Anwendung in Azure Container Apps Umgebungsvariablen anstatt appsettings.json zum Speichern von Konfigurationsinformationen. Auf diese Weise können Sie Ihre Anwendung in verschiedenen Umgebungen auf unterschiedliche Weise konfigurieren. Zudem erleichtert die Verwendung von Umgebungsvariablen die Verwaltung von Konfigurationswerten, ohne das Containerimage neu erstellen und erneut bereitstellen zu müssen.

In Azure Container Apps legen Sie Umgebungsvariablen fest, wenn Sie den Container Ihrer App oder Ihres Auftrags definieren. Speichern Sie vertrauliche Werte in geheimen Schlüsseln, und referenzieren Sie sie als Umgebungsvariablen. Weitere Informationen zum Verwalten von geheimen Schlüsseln finden Sie unter Verwalten von geheimen Schlüsseln in Azure Container Apps.

Verwaltete Identität

Azure Container Apps unterstützt verwaltete Identitäten, mit denen Ihre App auf andere Azure-Dienste zugreifen kann, ohne Anmeldeinformationen austauschen zu müssen. Weitere Informationen zur sicheren Kommunikation zwischen Azure-Diensten finden Sie unter Verwaltete Identitäten in Azure Container Apps.

Logging

In einer cloudnativen Umgebung ist die Protokollierung für die Überwachung und Problembehandlung Ihrer Anwendungen von entscheidender Bedeutung. Standardmäßig verwendet Azure Container Apps Azure Log Analytics zum Sammeln von Protokollen aus Ihren Containern. Sie können andere Protokollierungsanbieter konfigurieren. Weitere Informationen zur Anwendungsprotokollierung finden Sie unter Protokollspeicher- und Überwachungsoptionen in Azure Container Apps.

Wenn Sie einen Protokollierungsanbieter konfigurieren, der Protokolle in die Konsole schreibt, sammelt und speichert Azure Container Apps Protokollnachrichten für Sie.

Integritätstests

Azure Container Apps enthält eine integrierte Unterstützung für Integritätssonden, mit denen Sie die Integrität Ihrer Anwendungen überwachen können. Wenn ein Prüfpunkt feststellt, dass sich die Anwendung in einem fehlerhaften Zustand befindet, wird der Container automatisch neu gestartet. Weitere Informationen zu Integritätsüberprüfungen finden Sie unter „Integritätssonden“ in Azure Container Apps.

Um die Möglichkeit zum Implementieren einer benutzerdefinierten Logik zur Ermittlung des Status Ihrer Anwendung zu erhalten, können Sie einen Integritätsprüfungsendpunkt konfigurieren. Weitere Informationen zu Integritätsprüfungsendpunkten finden Sie unter Integritätsüberprüfungen in ASP.NET Core.

Überlegungen zur automatischen Skalierung

Standardmäßig skaliert Azure Container Apps Ihre ASP.NET Core-Apps automatisch basierend auf der Anzahl eingehender HTTP-Anforderungen. Sie können auch benutzerdefinierte Regeln für die automatische Skalierung basierend auf anderen Metriken konfigurieren, z. B. CPU- oder Arbeitsspeicherauslastung. Weitere Informationen zur Skalierung finden Sie unter Festlegen von Skalierungsregeln in Azure Container Apps.

In .NET 8.0.4 und höher werden ASP.NET Core-Apps, die Schutz von Daten verwenden, automatisch konfiguriert, um geschützte Daten für alle Replikate zugänglich zu halten, während die Anwendung skaliert wird. Wenn Ihre App mit der Skalierung beginnt, verarbeitet ein Schlüssel-Manager die Schreib- und Freigabeschlüssel über mehrere Revisionen hinweg. Wenn die App bereitgestellt wird, wird die Umgebungsvariable autoConfigureDataProtection automatisch auf true festgelegt, um dieses Feature zu aktivieren. Weitere Informationen zu dieser automatischen Konfiguration finden Sie in diesem Pull Request auf GitHub.

Durch die automatische Skalierung wird die Anzahl der Replikate Ihrer App basierend auf den von Ihnen definierten Regeln geändert. Standardmäßig leitet Container Apps eingehenden Datenverkehr wahlfrei an die Replikate Ihrer ASP.NET Core-App weiter. Da der Datenverkehr zwischen verschiedenen Replikaten geteilt werden kann, sollte Ihre App zustandslos sein, sodass in der Anwendung keine Probleme im Zusammenhang mit dem Zustand auftreten.

Features wie Anti-Forgery, Authentifizierung, SignalR, Blazor Server und Razor Pages stützen sich auf den Schutz von Daten. Sie erfordern eine zusätzliche Konfiguration, damit sie bei der Skalierung auf mehrere Replikate ordnungsgemäß funktionieren.

Konfigurieren von Datenschutzeinstellungen

ASP.NET Core verfügt über spezielle Features zum Schutz und Aufheben des Schutzes von Daten, z. B. Sitzungsdaten und Anti-Fälschungstoken. Standardmäßig werden Datenschutzschlüssel im Dateisystem gespeichert, was nicht für eine cloudnative Umgebung geeignet sind.

Wenn Sie eine .NET Aspire-Anwendung bereitstellen, wird der Schutz von Daten automatisch für Sie konfiguriert. In allen anderen Situationen müssen Sie den Schutz von Daten manuell konfigurieren.

Konfigurieren der ASP.NET Core SignalR

ASP.NET Core SignalR erfordert eine Rückwandplatine zum Verteilen von Nachrichten an mehrere Serverreplikate. Wenn Sie Ihre ASP.NET Core-App mit SignalR in Azure Container Apps bereitstellen, müssen Sie eine der unterstützten Rückwandplatinen konfigurieren, z. B. Azure SignalR Service oder Redis. Weitere Informationen zu Rückwandplatinen finden Sie unter ASP.NET Core SignalR-Hosting und -Skalierung.

Konfigurieren von Blazor Server

ASP.NET Core Blazor Server-Apps speichern den Zustand auf dem Server. Das bedeutet, dass jeder Client während seiner Sitzung mit demselben Serverreplikat verbunden sein muss. Wenn Sie Ihre Blazor Server-App in Azure Container Apps bereitstellen, müssen Sie die Sitzungsaffinität aktivieren, um sicherzustellen, dass Clients an dasselbe Replikat weitergeleitet werden. Weitere Informationen finden Sie unter Sitzungsaffinität in Azure Container Apps.