Einfache Webanwendung

Dieser Artikel enthält eine Basisarchitektur zur Information über die Ausführung von Webanwendungen auf Azure App Service in einer einzelnen Region.

Aufbau

Abbildung 1: Grundlegende Azure App Service-Architektur

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

1. Ein Benutzer gibt eine HTTPS-Anforderung an die Standarddomäne des App Services auf azurewebsites.net aus. Diese Domäne verweist automatisch auf die integrierte öffentliche IP-Adresse Ihres App Services. Die TLS-Verbindung wird vom Client direkt zum App Service hergestellt. Das Zertifikat wird vollständig von Azure verwaltet.
2. „Easy Auth“, ein Feature von Azure App Service, stellt sicher, dass der Benutzer, der auf die Website zugreift, mit Microsoft Entra ID authentifiziert wird.
3. Ihr für App Service bereitgestellter Anwendungscode verarbeitet die Anforderung. Beispielsweise kann dieser Code eine Verbindung mit einer Azure SQL-Datenbankinstanz herstellen, wobei eine in App Service konfigurierte Verbindungszeichenfolge als App-Einstellung konfiguriert wurde.
4. Die Informationen zur ursprünglichen Anforderung an App Service und der Aufruf der Azure SQL-Datenbank werden in Application Insights protokolliert.

Komponenten

• Microsoft Entra ID ist ein cloudbasierter Identitäts- und Zugriffsverwaltungsdienst. Es gibt eine einzelne Identitätssteuerungsebene zum Verwalten von Berechtigungen und Rollen für Benutzer, die auf Ihre Webanwendung zugreifen. Sie lässt sich in App Service integrieren und vereinfacht die Authentifizierung und Autorisierung für Web-Apps.
• App Service ist eine vollständig verwaltete Plattform zum Erstellen, Bereitstellen und Skalieren von Web-Apps.
• Azure Monitor ist ein Überwachungsdienst, der Telemetriedaten in Ihrer gesamten Bereitstellung sammelt, analysiert und verarbeitet.
• Azure SQL-Datenbank ist ein verwalteter relationaler Datenbankdienst für relationale Daten.

Empfehlungen und Überlegungen

Die in dieser Architektur aufgeführten Komponenten sind mit Azure Well-Architected-Dienstleitfäden verknüpft. Dienstleitfäden enthalten detaillierte Empfehlungen und Überlegungen für bestimmte Dienste. Dieser Abschnitt erweitert diese Anleitungen, indem wichtige Empfehlungen und Überlegungen zu Azure Well-Architected Framework hervorgehoben werden, die für diese Architektur gelten. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Diese grundlegende Architektur ist nicht für Produktionsbereitstellungen vorgesehen. Bei dieser Architektur geht es vor allem um bevorzugt Einfachheit und Kosteneffizienz gegenüber Funktionalität, damit Sie Azure App Service bewerten und kennenlernen können. In den folgenden Abschnitten werden einige Mängel dieser grundlegenden Architektur sowie Empfehlungen und Überlegungen dazu erläutert.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Zuverlässigkeit.

Da diese Architektur nicht für Produktionsbereitstellungen konzipiert ist, werden einige der kritischen Zuverlässigkeitsfeatures beschrieben, die in dieser Architektur nicht enthalten sind:

• Der App Service-Plan ist für die Standard Ebene konzipiert, die keine Unterstützung für die Azure-Verfügbarkeitszone bietet. Bei einem Problem mit der Instanz, dem Rack oder dem Rechenzentrum, das die Instanz hostet, ist der App Service nicht verfügbar.
• Die Azure SQL-Datenbank ist für die Basic Ebene konfiguriert, die keine Zonenredundanz unterstützt. Dies bedeutet, dass Daten nicht in Azure-Verfügbarkeitszonen repliziert werden, wodurch der Verlust von zugesicherten Daten im Falle eines Ausfalls riskiert wird.
• Bereitstellungen für diese Architektur können zu Ausfallzeiten bei Anwendungsbereitstellungen führen, da bei den meisten Bereitstellungstechniken alle ausgeführten Instanzen neu gestartet werden müssen. Während dieses Prozesses können 503-Fehler auftreten. Dies wird in der Basisarchitektur über Bereitstellungsslots behoben. Eine sorgfältige Vorgehensweise bei Anwendungsentwurf, Schemaverwaltung und Anwendungskonfiguration ist erforderlich, um die Bereitstellung gleichzeitiger Slots zu unterstützen. Verwenden Sie dieses POC, um Ihr slotbasiertes Konzept für die Produktionsbereitstellung zu entwerfen und zu validieren.
• In dieser grundlegenden Architektur ist die automatische Skalierung nicht aktiviert. Um Zuverlässigkeitsprobleme aufgrund fehlender verfügbarer Computeressourcen zu vermeiden, müssen Sie Bereitstellung über den Bedarf hinaus erweitern, damit die Computeressourcen stets ausreichen, um die maximale gleichzeitige Kapazität zu verarbeiten.

Informationen zum Umgang mit diesen Zuverlässigkeitsproblemen finden Sie im Abschnitt „Zuverlässigkeit“ in „Baseline für hochverfügbare zonenredundante Webanwendung“.

Wenn diese Workload letztendlich eine aktiv-aktive oder aktiv-passive Architektur mit mehreren Regionen erfordert, lesen Sie die folgenden Ressourcen:

• Multi-Region App Service-App-Ansätze für die Notfallwiederherstellung für Anleitungen zur Bereitstellung Ihrer von App Service gehosteten Workload in mehreren Regionen.
• Hochverknäufige Webanwendung für eine Referenzarchitektur, die einem aktiv-passiven Ansatz folgt.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Sicherheit.

Da diese Architektur nicht für Produktionsbereitstellungen konzipiert ist, werden einige der kritischen Sicherheitsfeatures beschrieben, die in dieser Architektur nicht enthalten sind, sowie weitere Empfehlungen und Überlegungen zur Zuverlässigkeit:

• Diese grundlegende Architektur implementiert keinen Netzwerkdatenschutz. Die Daten- und Verwaltungsebenen für die Ressourcen, z. B. Azure-App Service und Azure SQL Server, sind über das öffentliche Internet erreichbar. Das Weglassen privater Netzwerke erhöht die Angriffsfläche Ihrer Architektur erheblich. Informationen dazu, wie durch die Implementierung privater Netzwerke die folgenden Sicherheitsfeatures sichergestellt werden, finden Sie im Abschnitt „Netzwerk“ in „Baseline für hochverfügbare zonenredundante Webanwendung“:

  • Einzelner sicherer Einstiegspunkt für Clientdatenverkehr
  • Der Netzwerkdatenverkehr wird sowohl auf Paketebene als auch auf DDoS-Ebene gefiltert.
  • Die Datenexfiltration wird minimiert, indem der Datenverkehr mithilfe von Private Link in Azure beibehalten wird
  • Netzwerkressourcen werden logisch gruppiert und durch Netzwerksegmentierung voneinander isoliert.

• Diese grundlegende Architektur enthält keine Bereitstellung der Azure Web Application Firewall. Die Webanwendung ist nicht gegen gängige Angriffsformen und Schwachstellen geschützt. Siehe grundlegende Implementierung, um zu erfahren, wie die Web Application Firewall mit Azure Application Gateway in einer Azure App Services-Architektur implementiert werden kann.

• Diese grundlegende Architektur speichert Secrets wie die Azure SQL Server-Verbindungszeichenfolge in den App-Einstellungen. Zwar sind die App-Einstellungen verschlüsselt, Sie sollten aber beim Wechsel in die Produktionsumgebung Secrets in Azure Key Vault speichern, um die Governance zu verbessern. Eine noch bessere Lösung besteht darin, verwaltete Identitäten für die Authentifizierung zu verwenden und keine Secrets in der Verbindungszeichenfolge zu speichern.

• Remote-Debugging und Kudu-Endpunkte in der Entwicklungs- oder POC-Phase aktiviert zu lassen, ist unproblematisch. Wenn Sie zur Produktionsphase übergehen, sollten Sie unnötige Steuerungsebenen, Bereitstellungen oder Remotezugriff deaktivieren.

• Lokaler Authentifizierungsmethoden für FTP- und SCM-Standortbereitstellungen aktiviert zu lassen, ist in der Entwicklungs- oder POC-Phase unproblematisch. Wenn Sie zur Produktionsphase übergehen, sollten Sie die lokale Authentifizierung für diese Endpunkte deaktivieren.

• Sie müssen in der POC-Phase Microsoft Defender for App Service nicht aktivieren. Wenn Sie zur Produktionsphase übergehen, sollten Sie Defender for App Service aktivieren, um Sicherheitsempfehlungen zu generieren, die implementiert werden sollten, um Ihren Sicherheitsstatus zu erhöhen und verschiedene Bedrohungen für Ihren App Service zu erkennen.

• Azure App Service beinhaltet einen SSL-Endpunkt in einer Unterdomäne vonazurewebsites.net ohne zusätzliche Kosten. HTTP-Anforderungen werden standardmäßig an den HTTPS-Endpunkt umgeleitet. Bei Produktionsbereitstellungen verwenden Sie in der Regel eine benutzerdefinierte Domäne, die dem Application Gateway oder dem API Management vor der App Service-Bereitstellung zugeordnet wird.

• Verwenden Sie den integrierten Authentifizierungsmechanismus für App Service („EasyAuth“). EasyAuth vereinfacht die Integration von Identitätsanbietern in Ihre Web-App. Es übernimmt die Authentifizierung außerhalb Ihrer Web-App, sodass Sie keine wesentlichen Codeänderungen vornehmen müssen.

• Verwenden Sie die verwaltete Identität für Workloadidentitäten. Dank verwalteter Identität müssen Entwickler keine Anmeldeinformationen mehr verwalten. Die grundlegende Architektur wird über das Kennwort in einer Verbindungszeichenfolge bei SQL Server authentifiziert. Erwägen Sie die Verwendung einer verwalteten Identität zur Authentifizierung bei Azure SQL Server.

Weitere Sicherheitshinweise finden Sie unter Schützen einer App in Azure App Service.

Optimaler Betrieb

Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung des optimalen Betriebs.

In den folgenden Abschnitten finden Sie Anleitungen zu Konfiguration, Überwachung und Bereitstellung Ihrer App Service-Anwendung.

App-Konfigurationen

Da die grundlegende Architektur nicht für die Produktion vorgesehen ist, wird die App Service-Konfiguration zum Speichern von Konfigurationswerten und Secrets verwendet. Das Speichern von Secrets in der App Service-Konfiguration ist für die PoC-Phase unproblematisch. Sie verwenden keine echten Secrets und benötigen keine Secrets-Governance, die für Produktionsworkloads unerlässlich sind.

Im Folgenden finden Sie Konfigurationsempfehlungen und -überlegungen:

• Verwenden Sie zunächst die App Service-Konfiguration, um Konfigurationswerte und Verbindungszeichenfolgen in PoC-Bereitstellungen zu speichern. App-Einstellungen und Verbindungszeichenfolgen werden verschlüsselt und entschlüsselt, bevor sie beim Start in die App eingefügt werden.
• Wenn Sie zur Produktionsphase übergehen, speichern Sie Ihre Secrets in Azure Key Vault. Die Verwendung von Azure Key Vault verbessert den Umgang mit Secrets auf zwei Arten:
  • Durch die Externalisierung des Speicherns von Secrets in Azure Key Vault können Sie die Speicherung von Secrets zentralisieren. Sie verwalten Ihre Secrets an einem einzigen Ort.
  • Mit Azure Key Vault können Sie jede Interaktion mit Secrets protokollieren, einschließlich jedes Zugriffs auf ein Secret.
• Wenn Sie zur Produktionsphase übergehen, können Sie Ihre Verwendung der Azure Key Vault- und der App Service-Konfiguration mithilfe von Key Vault-Referenzen verwalten.

Diagnose und Überwachung

Während der PoC-Phase ist es wichtig zu verstehen, welche Protokolle und Metriken erfasst werden können. Im Folgenden finden Sie Empfehlungen und Überlegungen zur Überwachung in der PoC-Phase:

• Aktivieren Sie die Diagnoseprotokollierung für alle Elementprotokollquellen. Wenn Sie die Verwendung aller Diagnoseeinstellungen konfigurieren, können Sie verstehen, welche Protokolle und Metriken für Sie direkt bereitgestellt werden, und erkennen alle Lücken, die Sie schließen müssen, indem Sie ein Protokollierungsframework in Ihrem Anwendungscode verwenden. Wenn Sie zur Produktionsphase übergehen, sollten Sie Protokollquellen beseitigen, die keinen Wert bieten und Störungen und Kosten für die Protokollsenke Ihrer Workload hinzufügen.
• Konfigurieren Sie für die Protokollierung die Verwendung von Azure Log Analytics. Azure Log Analytics bietet Ihnen eine skalierbare und einfach abzufragende Plattform zur Zentralisierung der Protokollierung.
• Verwenden Sie Application Insights oder ein anderes Application Performance Management (APM)-Tool, um zur Überwachung der Anwendungsleistung Telemetrie und Protokolle auszugeben.

Bereitstellung

Im Folgenden finden Sie Anleitungen zur Bereitstellung Ihrer App Service-Anwendung.

• Befolgen Sie die Anleitungen in CI/CD für Azure-Web-Apps mit Azure Pipelines zur Automatisierung der Bereitstellung Ihrer Anwendung. Beginnen Sie mit der Erstellung Ihrer Bereitstellungslogik in der PoC-Phase. Durch die frühzeitige Implementierung von CI/CD im Entwicklungsprozess können Sie Ihre Anwendung schnell und sicher iterieren, wenn Sie zur Produktionsphase übergehen.
• Verwenden Sie ARM-Vorlagen, um Azure-Ressourcen und ihre Abhängigkeiten bereitzustellen. Es ist wichtig, mit diesem Prozess in der PoC-Phase zu beginnen. Wenn Sie zur Produktionsphase übergehen, sollten Sie die Möglichkeit haben, Ihre Infrastruktur automatisch bereitzustellen.
• Verwenden Sie verschiedene ARM-Vorlagen, und integrieren Sie sie in Azure DevOps-Dienste. Mit diesem Setup können Sie verschiedene Umgebungen erstellen. So können Sie beispielsweise produktionsähnliche Szenarien oder Auslastungstestumgebungen bei Bedarf replizieren und dadurch Kosten sparen.

Weitere Informationen finden Sie unter Azure Well-Architected Framework im Abschnitt zu DevOps.

Container

Die grundlegende Architektur kann verwendet werden, um unterstützten Code direkt in Windows- oder Linux-Instanzen bereitzustellen. App Service ist aber auch eine Container-Hosting-Plattform, um Ihre containerisierte Webanwendung auszuführen. App Service bietet verschiedene integrierte Container. Wenn Sie benutzerdefinierte oder Multicontainer-Apps verwenden, um Ihre Laufzeitumgebung weiter zu optimieren oder eine Codesprache zu unterstützen, die nicht nativ unterstützt wird, müssen Sie eine Containerregistrierung einführen.

Steuerungsebene

Während der POC-Phase sollten Sie sich mit der Steuerebene von Azure App Service vertraut machen, wie über den Kudu-Service verfügbar. Dieser Dienst macht allgemeine Bereitstellungs-APIs verfügbar, z. B. ZIP-Bereitstellungen, sowie rohe Protokolle und Umgebungsvariablen.

Wenn Sie Container verwenden, sollten Sie die Fähigkeit von Kudu zum Öffnen einer SSH-Sitzung für einen Container kennen, um erweiterte Debuggingfunktionen zu unterstützen.

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, eine effiziente Skalierung entsprechend den Anforderungen der Benutzer auszuführen. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Leistungseffizienz.

Da diese Architektur nicht für Produktionsbereitstellungen konzipiert ist, werden einige der kritischen Leistungseffizienzfeatures beschrieben, die in dieser Architektur nicht enthalten sind, sowie weitere Empfehlungen und Überlegungen.

Ein Ergebnis Ihrer PoC-Phase sollte eine Auswahl von SKUs sein, von denen Sie annehmen, dass sie für Ihre Workloads geeignet sind. Ihr Workload sollte so konzipiert sein, dass die Anforderungen durch horizontale Skalierung effizient erfüllt werden, indem die Anzahl der im App Service-Plan bereitgestellten Compute-Instanzen angepasst wird. Entwerfen Sie das System nicht so, dass es von der Änderung der Compute-SKU abhängig ist, um es an dem Bedarf auszurichten.

• In dieser grundlegenden Architektur ist in dem App Service keine automatische Skalierung implementiert. Der Dienst führt nicht automatisch horizontale oder vertikale Skalierungen zur effizienten Ausrichtung am Bedarf durch.
  • Die Standardebene unterstützt keine Autoskalierungseinstellungen zur Konfiguration regelbasierter automatischer Skalierung. Ein Teil Ihres POC-Prozesses sollte darin bestehen, effiziente Einstellungen für die automatische Skalierung auf der Grundlage der Ressourcenanforderungen ihres Anwendungscodes und der erwarteten Nutzungsmerkmale zu erreichen.
  • Berücksichtigen Sie für Produktionsbereitstellungen Premium-Ebenen, die die automatische Skalierung unterstützen, bei der die Plattform automatisch Skalierungsentscheidungen trifft.
• Befolgen Sie die Anleitung für die Aufwärtsskalierung einzelner Datenbanken ohne Anwendungsausfallzeiten, wenn Sie eine höhere Dienstebene für die SQL-Datenbank benötigen.

Bereitstellen dieses Szenarios

Die Anleitung wird durch eine Beispielimplementierung unterstützt, die eine grundlegende App Service-Implementierung auf Azure zeigt.

Nächste Schritte

Zugehörige Ressourcen

• Zonenredundante Baseline-Webanwendung
• Hochverfügbare Webanwendungen für mehrere Regionen
• Multi-Region App Service-Ansätze für die Notfallwiederherstellung

Produktdokumentation:

• App Service-Übersicht
• Azure Monitor – Übersicht
• Azure App Service-Plan – Übersicht
• Übersicht über Log Analytics in Azure Monitor
• Was ist Microsoft Entra ID?
• Was ist Azure SQL-Datenbank?

Microsoft Learn-Module:

• Konfiguration und Verwaltung von Azure Monitor
• Konfigurieren von Microsoft Entra ID
• Konfigurieren von Azure Monitor
• Bereitstellen und Konfigurieren von Servern, Instanzen und Datenbanken für Azure SQL
• Erkunden von Azure App Service
• Hosten einer Webanwendung mit Azure App Service
• Hosten Ihrer Domäne in Azure DNS
• Implementieren von Azure Key Vault
• Verwalten aller Benutzer*innen und Gruppen in Microsoft Entra ID