Bearbeiten

Einfache Webanwendung

Azure App Service
Azure-Schlüsseltresor
Azure Monitor
Azure SQL-Datenbank

Diese Architektur zeigt die grundlegenden Komponenten einer einfachen Webanwendung. Sie können die Architektur verwenden, um eine Webanwendung zu erstellen und dann die Anwendung an Ihre Anforderungen anzupassen.

Aufbau

Diagram showing the reference architecture for a basic web application in Azure.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Komponenten

  • Azure App Service ist eine umfassend verwaltete Plattform zum Erstellen und Bereitstellen von Cloudanwendungen. Sie ermöglicht das Definieren einer Reihe von Computeressourcen zum Ausführen einer Web-App, das Bereitstellen von Web-Apps und das Konfigurieren von Bereitstellungsslots.
  • Bereitstellungsslots ermöglichen das Stagen einer Bereitstellung und das anschließende Austauschen mit einer Produktionsbereitstellung. Auf diese Weise vermeiden Sie die direkte Bereitstellung in der Produktionsumgebung. Spezifische Empfehlungen finden Sie im Abschnitt Releaseentwicklung und Bereitstellung.
  • IP-Adresse: Die App Service-App verfügt über eine öffentliche IP-Adresse und einen Domänennamen. Der Domänenname ist eine Unterdomäne von azurewebsites.net, z.B. contoso.azurewebsites.net.
  • Azure DNS ist ein Hostingdienst für DNS-Domänen, der die Namensauflösung mithilfe der Microsoft Azure-Infrastruktur durchführt. Durch das Hosten Ihrer Domänen in Azure können Sie Ihre DNS-Einträge mithilfe der gleichen Anmeldeinformationen, APIs, Tools und Abrechnung wie für die anderen Azure-Dienste verwalten. Erstellen Sie zur Verwendung eines benutzerdefinierten Domänennamens (etwa contoso.com) DNS-Einträge, die der IP-Adresse den benutzerdefinierten Domänennamen zuordnen. Weitere Informationen finden Sie unter Konfigurieren eines benutzerdefinierten Domänennamens in Azure App Service.
  • Azure SQL-Datenbank ist eine relationale Datenbank als Dienst (Database-as-a-Service, DaaS) in der Cloud. SQL-Datenbank nutzt diese Codebasis gemeinsam mit der Microsoft SQL Server-Datenbank-Engine. Je nach Ihren Anwendungsanforderungen können Sie auch Azure Database for MySQL oder Azure Database for PostgreSQL verwenden. Bei diesen Alternativen handelt es sich um vollständig verwaltete Dienste, die auf den Open-Source-Datenbank-Engines für MySQL Server und Postgres basieren.
  • Microsoft Entra ID ist ein cloudbasierter Identitäts- und Zugriffsverwaltungsdienst, mit dem Mitarbeitende auf Cloud-Apps zugreifen können, die für Ihre Organisation entwickelt wurden.
  • Azure Monitor ist eine Lösung zum Sammeln und Analysieren von Protokollen und Metriken für Ihre Umgebungen, um entsprechende Maßnahmen zu ergreifen.
  • Azure Key Vault unterstützt die Geheimnis-, Schlüssel- und Zertifikatverwaltung. Die Lösung kann Anwendungsgeheimnisse (beispielsweise Datenbankverbindungszeichenfolgen) speichern.

Empfehlungen

Ihre Anforderungen können von der hier beschriebenen und im Code angegebenen Architektur abweichen. Der Code wird mit Produktionskonfigurationen bereitgestellt. Verwenden Sie die Empfehlungen, um Ihre Bereitstellung an Ihre Anforderungen anzupassen.

App Service-Plan

Der App Service-Plan verfügt über unterschiedliche Tarife. Die einzelnen Tarife unterstützen jeweils verschiedene Instanzgrößen, die sich hinsichtlich der Anzahl von Kernen und des Arbeitsspeichers unterscheiden. Sie können den Tarif nach der Bereitstellung ändern, indem Sie auf der linken Navigationsleiste die Option „Hochskalieren (App Service-Plan)“ auswählen. Im Anschluss folgen einige App Service-Empfehlungen:

  • Führen Sie Ihre Produktionsworkload im Tarif Basic, Standard oder Premium aus. In diesen drei Tarifen wird die App in dedizierten VM-Instanzen ausgeführt und verfügt über zugewiesene Ressourcen, die aufskaliert werden können.
  • Verwenden Sie den Tarif Standard oder Premium, wenn Sie Autoskalierung und TLS/SSL benötigen.
  • Erstellen Sie einen separaten App Service-Plan für Test- und Entwicklungszwecke. Verwenden Sie aus Kostengründen den Tarif Free oder Shared (Vorschau) für Test- und Entwicklungszwecke. Verwenden Sie die Tarife Free und Shared nicht für Produktionsworkloads. Freigegebene Ressourcen können nicht aufskaliert werden.
  • Löschen Sie nicht genutzte Pläne (z. B. Testbereitstellungen). App Service-Pläne werden sekundengenau abgerechnet. Die Instanzen im App Service-Plan werden Ihnen in Rechnung gestellt, auch wenn die App nicht ausgeführt wird. Weitere Informationen zu App Service-Plänen und zur Abrechnung finden Sie hier:

Bei der ARM-Vorlage weiter unten wird der Standard-Tarif für die Bereitstellung verwendet.

SQL-Datenbank

  • Verwenden von Azure SQL-Datenbank, um den Verwaltungsaufwand zu verringern. In Azure SQL-Datenbank wird ein logisches Konstrukt erstellt, das als zentraler Verwaltungspunkt für eine Sammlung von Datenbanken fungiert. Dieses logische Konstrukt verringert den Verwaltungsaufwand. Jede Datenbank innerhalb der Gruppe wird mit einer bestimmten Dienstebene bereitgestellt. Innerhalb der einzelnen Gruppen können die Datenbanken keine Ressourcen freigeben. Es fallen keine Computekosten für den Server an, aber Sie müssen die Ebene für jede Datenbank festlegen. Daher wird aufgrund der dedizierten Ressourcen unter Umständen eine höhere Leistung erzielt, aber die Kosten können höher sein.
  • Führen Sie Kapazitätsplanung durch, und wählen Sie einen Tarif und eine Leistungsstufe aus, die Ihren Anforderungen entsprechen. SQL-Datenbank unterstützt die Dienstebenen „Basic“, „Standard“ und „Premium“ mit mehreren Leistungsebenen innerhalb der einzelnen Tarife, die in Datenbanktransaktionseinheiten (Database Transaction Units, DTUs) gemessen werden.

Region

  • Erstellen Sie den App Service-Plan und die SQL-Datenbank-Instanz in der gleichen Region, um die Netzwerklatenz zu minimieren. Wählen Sie grundsätzlich die Ihren Benutzern am nächsten gelegene Region aus.
  • Die Ressourcengruppe weist ebenfalls eine Region auf. Sie gibt den Speicherort von Bereitstellungsmetadaten an. Platzieren Sie die Ressourcengruppe und ihre Ressourcen in der gleichen Region, um die Verfügbarkeit während der Bereitstellung zu verbessern.
  • Verwenden Sie den Preisrechner, um Ihre Kosten zu ermitteln.
  • Weitere Informationen finden Sie im Abschnitt zu Kosten im Microsoft Azure Well-Architected Framework.

Überlegungen

Die folgenden Überlegungen basieren auf den Säulen des Azure Well-Architected Frameworks. Die Säulen umfassen verschiedene Grundsätze zur Verbesserung der Workloadqualität. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Effiziente Leistung

Ein großer Vorteil von Azure App Service ist die Möglichkeit, Ihre Anwendung abhängig von der Last zu skalieren. Hier sind einige Punkte aufgeführt, die beim Planen der Skalierung für Ihre Anwendung zu bedenken sind.

Skalieren der App Service-App

Es gibt zwei Möglichkeiten zum Skalieren einer App Service-App:

  • Hochskalieren, also das Ändern der Instanzgröße. Die Instanzgröße bestimmt den Arbeitsspeicher, die Anzahl der Kerne und den Massenspeicher für die einzelnen VM-Instanzen. Das Hochskalieren kann manuell erfolgen, indem Sie die Instanzgröße oder den Plantarif ändern.
  • Aufskalieren, also das Hinzufügen von Instanzen, um eine höhere Last zu bewältigen. Für jede Tarifebene gibt es eine Maximalanzahl Instanzen. Zum Aufskalieren können Sie die Instanzanzahl manuell ändern oder die automatische Skalierung konfigurieren, wenn Azure basierend auf einem Zeitplan bzw. auf Leistungsmetriken automatisch Instanzen hinzufügen oder entfernen soll. Die Skalierungsvorgänge dauern normalerweise nicht lange, sondern nur wenige Sekunden.

Erstellen Sie zum Aktivieren der automatischen Skalierung ein entsprechendes Profil, das die Mindest- und Höchstanzahl der Instanzen definiert. Sie können zeitplanbasierte Profile festlegen, um Skalierungsereignisse auszulösen. Beispielsweise können Sie separate Profile für Wochentage und Wochenenden erstellen. Ein Profil kann Regeln dafür enthalten, wann Instanzen hinzugefügt oder entfernt werden sollen. Ein Beispiel wäre etwa das Hinzufügen von zwei Instanzen, wenn die CPU-Auslastung fünf Minuten lang über 70 Prozent liegt.

Empfehlungen zum Skalieren einer Web App:

  • Beschränken Sie das Hoch- und Herunterskalieren so weit wie möglich. Es kann dazu führen, dass eine Anwendung neu gestartet wird. Nutzen Sie stattdessen das Aufskalieren. Wählen Sie einen Tarif und eine Größe aus, der bzw. die Ihre Leistungsanforderungen unter typischer Last erfüllt, und skalieren Sie die Instanzen auf, um Änderungen beim Datenverkehrsvolumen zu bewältigen.
  • Aktivieren Sie die automatische Skalierung. Wenn Ihre Anwendung eine vorhersehbare normale Arbeitsauslastung aufweist, erstellen Sie Profile, um die Instanzanzahl im Voraus zu planen. Ist die Workload nicht planbar, verwenden Sie eine regelbasierte automatische Skalierung, um auf Laständerungen zu reagieren, wenn diese auftreten. Beide Ansätze können kombiniert werden.
  • Nutzen Sie für Autoskalierungsregeln die CPU-Auslastung. Die CPU-Auslastung ist im Allgemeinen eine gute Metrik für Regeln zur automatischen Skalierung. Jedoch sollten Sie einen Auslastungstest Ihrer Anwendung durchführen, potenzielle Engpässe identifizieren und Regeln für die automatische Skalierung auf diesen Daten aufbauen.
  • Legen Sie eine kürzere Abkühlphase für das Hinzufügen von Instanzen und eine längere Abkühlphase für das Entfernen von Instanzen fest. Autoskalierungsregeln beinhalten eine Abkühlphase. Bei der Abkühlphase handelt es sich um die Wartezeit zwischen dem Abschluss einer Skalierungsaktion und dem Start einer neuen Skalierungsaktion. In der Abkühlphase stabilisiert sich das System, bevor eine erneute Skalierung erfolgt. Legen Sie beispielsweise 5 Minuten für das Hinzufügen einer Instanz aber 60 Minuten für das Entfernen einer Instanz fest. Es ist besser, bei hoher Auslastung schnell neue Instanzen hinzuzufügen, um den zusätzlichen Datenverkehr zu bewältigen, und das System dann nach und nach wieder zurückzuskalieren.

Skalieren von SQL-Datenbanken

Wenn Sie eine höhere Dienstebene oder Leistungsstufe für SQL-Datenbank benötigen, können Sie einzelne Datenbanken ohne Downtime der Anwendung hochskalieren.

Weitere Informationen finden Sie unter Skalieren von Einzeldatenbankressourcen in Azure SQL-Datenbank.

Zuverlässigkeit

Zum Zeitpunkt der Artikelerstellung lag die SLA für App Service bei 99,95 Prozent. Die App Service-SLA gilt sowohl für einzelne als auch für mehrere Instanzen. Bei den Tarifen „Basic“, „Standard“ und „Premium“ liegt die SLA für SQL-Datenbank bei 99,99 Prozent.

Backups

Zur Wiederherstellung von Daten bei Datenverlust bietet SQL-Datenbank Zeitpunktwiederherstellung und Geowiederherstellung. Diese Funktionen sind in allen Tarifen verfügbar und automatisch aktiviert. Sie brauchen keine Sicherungen zu planen oder zu verwalten.

Optimaler Betrieb

Erstellen Sie separate Ressourcengruppen für Produktions-, Entwicklungs- und Testumgebungen. Die Trennung von Umgebungen erleichtert das Verwalten von Bereitstellungen, das Löschen von Testbereitstellungen und das Zuweisen von Zugriffsrechten.

Berücksichtigen Sie beim Zuweisen von Ressourcengruppen die folgenden Punkte:

  • Lebenszyklus. Platzieren Sie Ressourcen mit gleichem Lebenszyklus im Allgemeinen in der gleichen Ressourcengruppe.
  • Zugriff. Sie können die rollenbasierte Zugriffssteuerung von Azure (Role-Based Access Control, RBAC) verwenden, um Zugriffsrichtlinien auf die in einer Gruppe enthaltenen Ressourcen anzuwenden.
  • Abrechnung. Sie können die angefallenen Kosten für die Ressourcengruppe anzeigen.

Weitere Informationen finden Sie unter Übersicht über den Azure Resource Manager.

App-Konfigurationen

  • Speichern Sie die Konfigurationseinstellungen als App-Einstellungen. Definieren Sie die App-Einstellungen in Ihren Resource Manager-Vorlagen oder mit PowerShell. Zur Laufzeit stehen App-Einstellungen der Anwendung als Umgebungsvariablen zur Verfügung.
  • Checken Sie niemals Kennwörter, Zugriffsschlüssel oder Verbindungszeichenfolgen in die Quellcodeverwaltung ein. Übergeben Sie Geheimnisse stattdessen als Parameter an ein Bereitstellungsskript, das diese Werte als Anwendungseinstellungen speichert.
  • Wenn Sie einen Bereitstellungsslot tauschen, werden die App-Einstellungen standardmäßig ebenfalls getauscht. Falls Sie unterschiedliche Einstellungen für Produktion und Staging benötigen, können Sie Anwendungseinstellungen erstellen, die fest bei einem Slot verbleiben und nicht getauscht werden.

Diagnose und Überwachung

DevOps

  • Verwenden Sie ARM-Vorlagen, um Azure-Ressourcen und ihre Abhängigkeiten bereitzustellen. Die begleitende ARM-Vorlage stellt eine einzelne Webanwendung bereit. Alle Ressourcen sind in der gleichen grundlegenden Workload isoliert. Diese Isolation vereinfacht die Zuordnung der spezifischen Ressourcen der Workload zu einem Team. Das Team kann dann unabhängig alle Aspekte dieser Ressourcen verwalten. Diese Isolation ermöglicht dem DevOps-Team die Durchführung von Continuous Integration- und Continuous Delivery-Vorgängen (CI/CD).
  • Verwenden Sie verschiedene ARM-Vorlagen, und integrieren Sie sie in Azure DevOps-Dienste. Mit diesem Setup können Sie innerhalb von Minuten verschiedene Umgebungen erstellen. So können Sie beispielsweise produktionsähnliche Szenarien oder Auslastungstestumgebungen bei Bedarf replizieren und dadurch Kosten sparen.
  • Stellen Sie mehrere Instanzen der Webanwendung bereit. Ihre Web-App sollte nicht von einer einzelnen Instanz abhängig sein, was zu einem Single Point of Failure führen würde. Die Verwendung mehrerer Instanzen verbessert die Resilienz und die Skalierbarkeit.

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

Releaseentwicklung und Bereitstellung

  • Verwenden Sie Azure Resource Manager-Vorlagen für die Bereitstellung von Azure-Ressourcen. Mithilfe von Vorlagen können Bereitstellungen über PowerShell oder die Azure-Befehlszeilenschnittstelle einfacher automatisiert werden.
  • Stellen Sie die Anwendung (Code, Binärdateien und Inhaltsdateien) bereit. Es gibt eine Reihe verschiedener Optionen, einschließlich der Bereitstellung aus einem lokalen Git-Repository, der Verwendung von Visual Studio oder Continuous Deployment aus einer cloudbasierten Quellcodeverwaltung. Weitere Informationen finden Sie unter Bereitstellen der App in Azure App Service.

Eine App Service-App verfügt immer über einen Bereitstellungsslot mit dem Namen production. Der Produktionsslot stellt die Produktions-Livewebsite dar. Wir empfehlen, zum Bereitstellen von Updates einen Stagingslot zu erstellen. Zu den Vorteilen beim Verwenden eines Stagingslots gehören:

  • Sie können überprüfen, ob die Bereitstellung erfolgreich war, bevor Sie sie in der Produktionsumgebung nutzen.
  • Das Bereitstellen in einem Stagingslot stellt sicher, dass alle Instanzen warmgelaufen sind, bevor sie in die Produktionsumgebung eingebracht werden. Viele Anwendungen weisen eine erhebliche Aufwärmdauer und Kaltstartzeit auf.
  • Erstellen Sie einen dritten Slot für die letzte als funktionierend bekannte Bereitstellung. Verschieben Sie nach dem Vertauschen von Staging- und Produktionsumgebung die bisherige Produktionsumgebung (die sich jetzt im Stagingslot befindet) in den Slot für die letzte als funktionierend bekannte Bereitstellung. Wenn Sie zu einem späteren Zeitpunkt ein Problem feststellen, können Sie auf diese Weise schnell zur letzten als funktionierend bekannten Version zurückkehren.

Swapping slots for production and staging deployments

  • Wenn Sie eine frühere Version wiederherstellen, achten Sie darauf, dass alle Änderungen am Datenbankschema abwärtskompatibel sind.
  • Verwenden Sie keine Slots in Ihrer Produktionsumgebung für Tests, da alle Apps in einem App Service-Plan die gleichen VM-Instanzen nutzen. Auslastungstests können z.B. den aktiven Produktionsstandort beeinträchtigen. Erstellen Sie stattdessen separate App Service-Pläne für die Produktion und für Tests. Indem Sie Testbereitstellungen in einen separaten Plan aufnehmen, isolieren Sie sie von der Produktionsversion.

Sicherheit

Dieser Abschnitt enthält Sicherheitshinweise, die für die in diesem Artikel beschriebenen Azure-Dienste spezifisch sind. Es handelt sich nicht um eine vollständige Liste der bewährten Sicherheitsmethoden. Weitere Sicherheitshinweise finden Sie unter Schützen einer App in Azure App Service.

SQL-Datenbanküberwachung

Die Überwachung kann Ihnen dabei helfen, die gesetzlichen Bestimmungen einzuhalten und Einblicke in Abweichungen und Unregelmäßigkeiten zu erhalten, die auf Geschäftsvorgänge oder mutmaßliche Sicherheitsverstöße hinweisen können. Weitere Informationen finden Sie unter Erste Schritte mit der Überwachung von SQL-Datenbanken.

Bereitstellungsslots

Jeder Bereitstellungsslot weist eine öffentliche IP-Adresse auf. Schützen Sie die produktionsfremden Slots mittels Microsoft Entra-Anmeldung, sodass nur Mitglieder Ihres Entwicklungs- und DevOps-Teams auf diese Endpunkte zugreifen können.

Protokollierung

Protokolle sollten niemals Benutzerkennwörter oder andere Informationen aufzeichnen, die für Identitätsdiebstähle verwendet werden können. Entfernen Sie diese Details aus den Daten, bevor Sie sie speichern.

SSL

Eine App Service-App beinhaltet einen SSL-Endpunkt in einer Unterdomäne (azurewebsites.net) ohne zusätzliche Kosten. Der SSL-Endpunkt schließt ein Platzhalterzertifikat für die *.azurewebsites.net-Domäne ein. Wenn Sie einen benutzerdefinierten Domänennamen verwenden, müssen Sie ein Zertifikat bereitstellen, das der benutzerdefinierten Domäne entspricht. Die einfachste Möglichkeit besteht darin, ein Zertifikat direkt über das Azure-Portal zu erwerben. Außerdem können Sie Zertifikate von anderen Zertifizierungsstellen importieren. Weitere Informationen finden Sie unter Kaufen und Konfigurieren eines SSL-Zertifikats für Ihren Azure App Service.

HTTPS ist in der ARM-Vorlagenbereitstellung standardmäßig nicht aktiviert. Als bewährte Sicherheitsmethode sollte Ihre Anwendung HTTPS durch Umleitung von HTTP-Anforderungen durchsetzen. Sie können HTTPS innerhalb Ihrer Anwendung implementieren oder eine URL-Rewrite-Regel verwenden, wie unter Aktivieren von HTTPS für eine App in Azure App Service beschrieben.

Authentifizierung

Es wird die Authentifizierung über einen Identitätsanbieter (IDP) wie etwa Microsoft Entra ID, Facebook, Google oder Twitter empfohlen. Verwenden Sie OAuth 2 oder OpenID Connect (OIDC) für den Authentifizierungsablauf. Microsoft Entra ID bietet Funktionen zum Verwalten von Benutzer*innen und Gruppen, Erstellen von Anwendungsrollen, Integrieren lokaler Identitäten und Nutzen von Back-End-Diensten, wie etwa Microsoft 365 und Skype for Business.

Vermeiden Sie die direkte Verwaltung von Benutzeranmeldungen und Anmeldeinformationen durch die Anwendung. Dadurch entsteht eine potenzielle Angriffsfläche. Als Mindeststandard sollten eine E-Mail-Bestätigung, die Kennwortwiederherstellung und die mehrstufige Authentifizierung genutzt werden. Darüber hinaus sollte die Kennwortsicherheit überprüft werden und für die sichere Speicherung von Kennworthashes gesorgt sein. Die großen Identitätsanbieter übernehmen alle diese Dinge für Sie und überwachen und verbessern ihre Sicherheitsverfahren ständig.

Erwägen Sie die Verwendung der App Service-Authentifizierung, um den OAuth- oder OIDC-Authentifizierungsablauf zu implementieren. App Service-Authentifizierung bietet folgende Vorteile:

  • Einfach zu konfigurieren.
  • Für einfache Authentifizierungsszenarien ist kein Code erforderlich.
  • Unterstützt delegierte Autorisierung mithilfe von OAuth-Zugriffstoken, um Ressourcen im Benutzerauftrag zu nutzen.
  • Bietet einen integrierten Tokencache.

Einige Einschränkungen der App Service-Authentifizierung:

  • Eingeschränkte Anpassungsoptionen.
  • Die delegierte Autorisierung ist auf eine Back-End-Ressource pro Anmeldesitzung beschränkt.
  • Bei Verwendung mehrerer IDPs gibt es keinen integrierten Mechanismus für die Startbereichsermittlung.
  • In Szenarien mit mehreren Mandanten muss die Anwendung die Logik für die Überprüfung des Tokenbenutzers implementieren.

Bereitstellen dieses Szenarios

Diese Architektur umfasst einen Azure App Service-Plan und eine leere Anwendung. Sie verwendet Azure SQL-Datenbank, Azure Key Vault zum Speichern der Verbindungszeichenfolge für die Datenbank und Azure Monitor für die Protokollierung, Überwachung und Warnungsanzeige.

Verwenden Sie den folgenden Befehl, um eine Ressourcengruppe für die Bereitstellung zu erstellen. Wählen Sie die Schaltfläche Jetzt testen aus, um eine eingebettete Shell zu verwenden.

az group create --name basic-web-app --location eastus

Führen Sie den folgenden Befehl aus, um die Webanwendung und die unterstützende Infrastruktur bereitzustellen. Geben Sie nach entsprechender Aufforderung einen Benutzernamen und das Kennwort ein. Diese Werte werden für den Zugriff auf die Azure SQL-Datenbankinstanz verwendet.

az deployment group create --resource-group basic-web-app  \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/basic-web-app/azuredeploy.json

Ausführliche Informationen und weitere Bereitstellungsoptionen finden Sie in den ARM-Vorlagen, die für die Bereitstellung dieser Lösung verwendet werden.

Einfache Webanwendung: ARM-Vorlage

Nächste Schritte

Tipps zur Problembehandlung bei der Anwendung:

Produktdokumentation:

Microsoft Learn-Module: