Einfache Webanwendung

Azure App Service
Azure Monitor
Azure SQL-Datenbank

Dieser Artikel enthält eine grundlegende Architektur, mit der Sie mehr über das Ausführen von Webanwendungen auf Azure App Service in einer einzelnen Region erfahren können.

Wichtig

Diese Architektur ist nicht für Produktionsanwendungen vorgesehen. Sie dient als Einführungseinrichtung für Lern- und Machbarkeits- (Proof-of-Concept, POC)-Zwecke. Informationen zum Entwerfen einer App Service-Anwendung in der Produktion finden Sie unter Referenzmodell für hochverfügbare zonenredundante Webanwendungen.

Aufbau

Diagramm mit einer grundlegenden App Service-Architektur.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Arbeitsablauf

Der folgende Workflow entspricht dem vorhergehenden Diagramm.

  1. Ein Benutzer gibt eine HTTPS-Anforderung an die Standarddomäne des App-Diensts aus azurewebsites.net. Diese Domäne verweist automatisch auf die integrierte öffentliche IP-Adresse Ihrer App-Dienstanwendung. Die Tls-Verbindung (Transport Layer Security) wird direkt vom Client zu App Service hergestellt. Azure das Zertifikat vollständig verwaltet.

  2. Einfache Authentifizierung, die ein Feature von App Service ist, stellt sicher, dass der Benutzer, der auf die Website zugreift, mithilfe von 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-Datenbank Instanz herstellen, indem eine Verbindungszeichenfolge verwendet wird, die in App Service als App-Einstellung konfiguriert ist.

  4. Die Informationen zur ursprünglichen Anforderung an App Service und der Aufruf der SQL-Datenbank werden in Application Insights protokolliert.

Komponenten

  • Microsoft Entra ID ist ein cloudbasierter Identitäts- und Zugriffsverwaltungsdienst, der Authentifizierungs- und Autorisierungsfunktionen bereitstellt. In dieser Architektur wird sie über Easy Auth in App Service integriert, um die Authentifizierung für Benutzer sicherzustellen, die auf die Webanwendung zugreifen. Außerdem wird der Authentifizierungsprozess vereinfacht, ohne dass erhebliche Codeänderungen erforderlich sind.

  • App Service ist eine verwaltete Plattform zum Erstellen, Bereitstellen und Skalieren von Webanwendungen. In dieser Architektur hostet sie den Webanwendungscode, verarbeitet HTTPS-Anforderungen in der Standarddomäne azurewebsites.net und stellt über konfigurierte Verbindungszeichenfolgen eine Verbindung mit der SQL-Datenbank bereit.

  • Azure Monitor ist ein Überwachungsdienst, der Telemetriedaten aus Cloud- und lokalen Umgebungen sammelt, analysiert und verarbeitet. In dieser Architektur werden Informationen zu Anforderungen an App Service und Aufrufe an die SQL-Datenbank über die Application Insights-Integration erfasst und gespeichert.

  • SQL-Datenbank ist ein verwalteter relationaler Datenbankdienst, der SQL Server-Funktionen in der Cloud bereitstellt. In dieser Architektur dient sie als Datenspeicherebene, die es der App-Dienstanwendung ermöglicht, eine Verbindung über Verbindungszeichenfolgen herzustellen, die in den App-Einstellungen definiert sind.

Überlegungen

Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads verwenden können. Weitere Informationen finden Sie unter Well-Architected Framework.

Die in dieser Architektur aufgeführten Komponenten sind mit Well-Architected Diensthandbüchern verknüpft. Dienstleitfäden enthalten detaillierte Empfehlungen und Überlegungen für bestimmte Dienste. Dieser Abschnitt erweitert diese Anleitung, indem wichtige Well-Architected Framework-Empfehlungen und Überlegungen hervorgehoben werden, die für diese Architektur gelten.

Diese grundlegende Architektur ist nur für Evaluierungs- und Lernzwecke konzipiert. Sie priorisiert Einfachheit und Kosteneffizienz gegenüber der Funktionalität auf Produktionsniveau. In den folgenden Abschnitten werden wichtige Einschränkungen dieser Architektur hervorgehoben und Empfehlungen und Überlegungen bereitgestellt, mit denen Sie robustere Bereitstellungen planen können.

Zuverlässigkeit

Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie für Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Zuverlässigkeit.

Diese Architektur wurde nicht für Produktionsbereitstellungen entwickelt. Die folgenden wichtigen Zuverlässigkeitsfeatures werden in dieser Architektur nicht angegeben:

  • Der App Service-Plan ist für die Standardebene konfiguriert, die keine Unterstützung für Azure Verfügbarkeitszonen enthält. Der App-Dienst ist nicht verfügbar, wenn ein Problem mit der Instanz, dem Rack oder dem Rechenzentrum auftritt, das die Instanz hosten soll.

  • DIE SQL-Datenbank ist für die Standardebene konfiguriert, die zonenredundanz nicht unterstützt. Daher werden Daten nicht in Azure-Verfügbarkeitszonen repliziert, wodurch das Risiko eines Verlusts zugesicherter Daten bei einem Ausfall besteht.

  • Bereitstellungen für diese Architektur können zu Ausfallzeiten für Anwendungsbereitstellungen führen, da bei den meisten Bereitstellungstechniken alle ausgeführten Instanzen neu gestartet werden müssen. Während dieses Prozesses treten möglicherweise 503 Fehler auf. Diese Ausfallzeit der Bereitstellung wird in der Basisarchitektur durch Deployment Slots 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.

  • Die automatische Skalierung ist in dieser grundlegenden Architektur nicht aktiviert. Um Zuverlässigkeitsprobleme zu vermeiden, die durch unzureichende Computerressourcen verursacht werden, müssen Sie überdimensionieren, um genügend Kapazität zu haben, um maximale gleichzeitige Anfragen bewältigen zu können.

Weitere Informationen zur Überwindung dieser Zuverlässigkeitsbedenken finden Sie unter Baseline hochverwendbarte zonenredundante Webanwendung – Zuverlässigkeit.

Wenn für die Workload eine aktiv-aktive oder aktiv-passive Architektur mit mehreren Regionen erforderlich ist, finden Sie Informationen zu Ansätzen für den Multi-Region App Service zur Wiederherstellung nach Desastern.

Sicherheit

Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Sicherheit.

Diese Architektur wurde nicht für Produktionsbereitstellungen entwickelt. Die folgenden kritischen Sicherheitsfeatures wurden in dieser Architektur nicht angegeben, zusammen mit anderen Zuverlässigkeitsempfehlungen und Überlegungen:

  • Diese grundlegende Architektur implementiert keinen Netzwerkdatenschutz. Die Daten- und Verwaltungsebenen für die Ressourcen wie App Service und Azure SQL Server sind über das öffentliche Internet erreichbar. Das Weglassen privater Netzwerke erhöht die Angriffsfläche Ihrer Architektur erheblich. Weitere Informationen dazu, wie die Implementierung privater Netzwerke die folgenden Sicherheitsfeatures gewährleistet, finden Sie unter Baseline hochverfügbare zonenredundante Webanwendung – Netzwerke. Die Implementierung privater Netzwerke trägt dazu bei, diese Risiken zu minimieren, indem die folgenden Sicherheitsfeatures bereitgestellt werden:

    • Ein einzelner sicherer Einstiegspunkt für den Clientdatenverkehr.

    • Der Netzwerkdatenverkehr wird sowohl auf Paketebene als auch auf der DDoS-Ebene (Distributed Denial-of-Service) gefiltert.

    • Datenexfiltration wird minimiert, indem der Datenverkehr mithilfe von Azure Private Link in Azure gehalten wird.

    • Netzwerkressourcen werden logisch gruppiert und durch Netzwerksegmentierung voneinander isoliert.

  • Diese grundlegende Architektur enthält keine Bereitstellung von Azure Web Application Firewall. Die Webanwendung ist nicht gegen gängige Angriffsformen und Schwachstellen geschützt. Informationen dazu, wie die Azure Web Application Firewall mit dem Azure Application Gateway in einer App-Services-Architektur implementiert werden kann, finden Sie in der Baseline-Implementierung.

  • Diese grundlegende Architektur speichert geheime Schlüssel wie die SQL Server Verbindungszeichenfolge in den App-Einstellungen. App-Einstellungen sind standardmäßig verschlüsselt. Wenn Sie jedoch zur Produktion wechseln, sollten Sie geheime Schlüssel in Azure Key Vault für eine höhere Governance speichern. Für eine stärkere Sicherheit und verringerten Verwaltungsaufwand sollten Sie die verwaltete Identität für die Authentifizierung verwenden, anstatt geheime Schlüssel in Verbindungszeichenfolgen einzubetten.

  • Remotedebugging- und Kudu-Endpunkte können während der Entwicklung oder der POC-Phase aktiviert bleiben. Wenn Sie zur Produktionsphase übergehen, sollten Sie unnötige Steuerungsebenen, Bereitstellungen oder Remotezugriff deaktivieren.

  • Lokale Authentifizierungsmethoden für FTP-Bereitstellungen (File Transfer Protocol) und Quellcodeverwaltung (Source Control Management, SCM) können während der Entwicklungs- oder POC-Phase aktiviert bleiben. Wenn Sie zur Produktionsphase übergehen, sollten Sie die lokale Authentifizierung für diese Endpunkte deaktivieren.

  • Sie müssen Microsoft Defender für App Service in der POC-Phase nicht aktivieren. Wenn Sie zur Produktion wechseln, sollten Sie Defender für App Service aktivieren, um Sicherheitsempfehlungen zu generieren. Sie sollten diese Empfehlungen implementieren, um Ihren Sicherheitsstatus zu erhöhen und mehrere Bedrohungen für Ihre App Service-Bereitstellung zu erkennen.

  • App Service enthält einen SSL-Endpunkt (Secure Sockets Layer) auf einer Unterdomäne von azurewebsites.net ohne zusätzliche Kosten. HTTP-Anforderungen werden standardmäßig an den HTTPS-Endpunkt umgeleitet. Bei Produktionsbereitstellungen wird in der Regel eine benutzerdefinierte Domäne zusammen mit dem Anwendungsgateway oder dem API Management-Dienst vor der Bereitstellung des App Service verwendet.

  • Verwenden Sie den integrierten Authentifizierungsmechanismus für App Service. Easy Auth vereinfacht den Prozess der 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 verwaltete Identitäten für Workloadidentitäten. Dank verwalteter Identität müssen Entwickler keine Anmeldeinformationen mehr verwalten. Die grundlegende Architektur authentifiziert sich bei SQL Server mithilfe eines Kennworts in einem Verbindungszeichenfolge. Erwägen Sie die Verwendung managed Identity zum Authentifizieren bei SQL Server.

Weitere Informationen finden Sie unter Sichern einer App in App Service.

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Prüfliste zur Design-Überprüfung für Kostenoptimierung.

Diese Architektur optimiert die Kosten durch die vielen Kompromisse gegenüber den anderen Säulen des Well-Architected Frameworks. Diese Kompromisse werden speziell an die Lern- und POC-Ziele dieser Architektur angepasst. Die Kosteneinsparungen im Vergleich zu einer produktionsbereiteren Architektur, z. B. der Basislinie für hochverfügbare zonenredundante Webanwendungen, ergeben sich hauptsächlich aus den folgenden Entscheidungen:

  • Eine einzelne App-Service-Instanz, bei der automatische Skalierung nicht aktiviert ist

  • Standardpreisstufe für App Service

  • Kein benutzerdefiniertes TLS-Zertifikat oder keine statische IP-Adresse

  • Keine Webanwendungsfirewall (WAF)

  • Kein dediziertes Speicherkonto für die Anwendungsbereitstellung

  • Grundlegende Preisstufe für SQL-Datenbank ohne Sicherungsaufbewahrungsrichtlinien

  • Keine Microsoft Defender für Cloud-Komponenten

  • Keine Steuerung des ausgehenden Netzwerkverkehrs durch eine Firewall

  • Keine privaten Endpunkte

  • Minimaler Protokoll- und Protokollaufbewahrungszeitraum in Azure Monitor Protokollen

Um die geschätzten Kosten dieser Architektur anzuzeigen, sehen Sie sich die Preisrechner-Schätzung an, die die Komponenten dieser Architektur verwendet. Die Kosten für diese Architektur können in der Regel mit einem Azure Dev/Test-Abonnement weiter reduziert werden, was ein idealer Abonnementtyp für POCs wäre.

Operative Exzellenz

Operational Excellence deckt die Betriebsprozesse ab, mit denen eine Anwendung bereitgestellt und in der Produktion ausgeführt wird. Weitere Informationen finden Sie unter Checkliste für die Entwurfsüberprüfung zur operativen Exzellenz.

Die folgenden Abschnitte enthalten Anleitungen zur 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. Sie können geheime Schlüssel während der POC-Phase in der App Service-Konfiguration speichern. Sie verwenden keine echten Geheimnisse und benötigen keine Verwaltung von Geheimnissen, die Produktionsworkloads erfordern.

Berücksichtigen Sie die folgenden 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 Ihre App eingefügt werden.

  • Wenn Sie zur Produktion wechseln, speichern Sie Ihre Geheimnisse in Key Vault. Key Vault verbessert die Verwaltung von geheimen Informationen auf zwei Arten:

    • Das Externalisieren Ihrer geheimen Schlüssel zu Key Vault bietet einen einzigen zentralen Ort für die sichere geheime Verwaltung.

    • Mithilfe von Key Vault können Sie jede Interaktion mit geheimen Schlüsseln protokollieren, einschließlich jedes Mal, wenn auf einen geheimen Schlüssel zugegriffen wird.

  • Wenn Sie zur Produktion wechseln, können Sie die Verwendung von Key Vault- und App Service-Konfiguration mithilfe von Key Vault References verwalten.

Container

Sie können die grundlegende Architektur verwenden, um unterstützten Code direkt für Windows- oder Linux-Instanzen bereitzustellen. Alternativ ist App Service auch eine Containerhostingplattform, mit der Sie Ihre containerisierte Webanwendung ausführen können. Der App-Dienst stellt verschiedene integrierte Container bereit. Benutzerdefinierte oder mehrere Container-Apps helfen, die Laufzeitumgebung zu optimieren oder Codesprachen zu unterstützen, die nicht nativ unterstützt werden. Dieser Ansatz erfordert die Einführung einer Containerregistrierung.

Steuerungsebene

Machen Sie sich während der POC-Phase mit der App Service-Steuerungsebene vertraut, die über den Kudu-Dienst zugänglich ist. Dieser Dienst stellt allgemeine Bereitstellungs-APIs wie ZIP-Bereitstellungen bereit und macht unformatierte Protokolle und Umgebungsvariablen verfügbar.

Wenn Sie Container verwenden, stellen Sie sicher, dass Sie die Fähigkeit von Kudu verstehen, eine Ssh-Sitzung (Secure Shell) für einen Container zu öffnen, um erweiterte Debugfunktionen zu unterstützen.

Diagnose und Überwachung

Während der POC-Phase ist es wichtig, zu verstehen, welche Protokolle und Metriken für die Erfassung verfügbar sind. Berücksichtigen Sie die folgenden Empfehlungen und Ideen für die Überwachung in der POC-Phase:

  • Aktivieren Sie die Diagnoseprotokollierung für alle Elementprotokollquellen. Die Konfiguration der Verwendung aller Diagnoseeinstellungen hilft Ihnen zu verstehen, welche Protokolle und Metriken für Sie bereitgestellt werden, und hilft Ihnen dabei, Lücken zu erkennen, die Sie schließen müssen, indem Sie ein Protokollierungsframework in Ihrem Anwendungscode verwenden. Wenn Sie zur Produktion wechseln, entfernen Sie Protokollquellen, die keinen Mehrwert hinzufügen, sondern Rauschen und Kosten zum Protokollsenken Ihrer Workload hinzufügen.

  • Konfigurieren Sie die Protokollierung für die Nutzung von Azure Log Analytics. Azure Log Analytics bietet Ihnen eine skalierbare Plattform, um die Protokollierung zu zentralisieren, die einfach abzufragen ist.

  • Verwenden Sie Application Insights oder ein anderes APM-Tool (Application Performance Management), um Telemetrie und Protokolle auszustrahlen, um die Anwendungsleistung zu überwachen.

Bereitstellung

Die folgenden Punkte enthalten Anleitungen für die 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 dem Aufbau der Bereitstellungslogik in der POC-Phase. Durch die Implementierung von Continuous Integration und Continuous Delivery (CI/CD) frühzeitig im Entwicklungsprozess können Sie Ihre Anwendung schnell und sicher weiterentwickeln, während Sie sich auf den Einsatz in der Produktion vorbereiten.

  • Verwenden Sie Azure Resource Manager-Vorlagen (ARM-Vorlagen), um Azure Ressourcen und deren Abhängigkeiten bereitzustellen. Es ist wichtig, diesen Prozess in der POC-Phase zu starten. 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 Services. 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 in den Designprinzipien der Operational Excellence.

Leistungseffizienz

Die Leistungseffizienz bezieht sich auf die Fähigkeit Ihrer Arbeitslast, die Anforderungen der Benutzer effizient zu skalieren und zu erfüllen. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Leistungseffizienz.

Da diese Architektur nicht für Produktionsbereitstellungen konzipiert ist, beschreibt dieser Abschnitt einige der kritischen Leistungseffizienzfeatures, die in dieser Architektur nicht angegeben wurden, sowie andere Empfehlungen und Überlegungen.

Ein Ergebnis Ihres POC sollte eine SKU-Auswahl sein, die Sie für Ihre Arbeitslast geeignet schätzen. Entwerfen Sie Ihre Workload so, dass die Anforderungen durch horizontale Skalierung effizient erfüllt werden, indem Sie die Anzahl der im App Service-Plan bereitgestellten Computeinstanzen anpassen. Entwerfen Sie das System nicht so, dass es davon abhängt, die Compute-SKU zu ändern, um es an den Bedarf anzupassen.

  • Die App Service-Bereitstellung in dieser grundlegenden Architektur hat keine automatische Skalierung implementiert. Der Dienst skaliert nicht dynamisch nach oben oder unten, um sich effizient an den Bedarf anzupassen.

    • Die Standardebene unterstützt Einstellungen für die automatische Skalierung , damit Sie regelbasierte automatische Skalierung konfigurieren können. Ermitteln Sie im Rahmen Ihres POC-Prozesses effiziente Einstellungen für die automatische Skalierung, die auf die Ressourcenanforderungen ihres Anwendungscodes und die erwarteten Verwendungsmuster zugeschnitten sind.

    • Berücksichtigen Sie bei Produktionsbereitstellungen Premium-Ebenen, die die automatische Skalierung unterstützen, bei der die Plattform automatisch Skalierungsentscheidungen behandelt.

  • 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.

Nächste Schritte

Bereitstellungslernprogramme:

Produktdokumentation:

Microsoft Learn-Module: