Übung: Bereitstellen einer n-schichtigen Architektur

  • 20 Minuten

Denken Sie an unser Szenario der Migration einer Anwendung aus der lokalen Umgebung zurück zu Azure. Wie könnte diese Architektur aussehen? In Ihrer Organisation gibt es eine nicht kritische Anwendung, die ein guter Kandidat für einen Test ist. Diese Anwendung wurde geschrieben, um das allzu bekannte Problem zu lösen, das bei der Wahl des Mittagessens entsteht.

Sie erinnern sich sicherlich an das letzte Mittagessen mit Freunden oder Kollegen. Konnten Sie leicht eine Entscheidung treffen, oder haben Sie viel Zeit damit verbracht herauszufinden, was die anderen Personen mit ihrer Aussage „Ich mag alles“ tatsächlich gemeint haben? Wir stellen eine Anwendung bereit, die auf einer Architektur mit drei Schichten basiert und mit der Sie dieses Problem unter Umständen lösen können. Mithilfe dieser Anwendung können Sie Vorschläge zum Mittagessen machen, und die Personen können jeweils ihre bevorzugte Wahl angeben.

Wir haben eine Vorlage für diese Anwendung erstellt, mit der jede Schicht in Form von Azure-Ressourcen und anschließend der eigentliche Code bereitgestellt wird. Dies ist eine ASP.NET Core-MVC-Anwendung, die auf Linux-Servern bereitgestellt wird. Sie können diesen Architekturstil aber unabhängig von den zugrunde liegenden Betriebssystemplattformen bzw. dem SDK verwenden.

Hier ist eine allgemeine Darstellung der Elemente, die mit dieser Vorlage bereitgestellt werden.

Visualization of the N-tier architecture to be deployed in this unit.

Bereitstellen einer n-schichtigen Architektur

  1. Führen Sie den folgenden Befehl aus, um die Bereitstellung zu starten. Mit dem Befehl az deployment group create wird eine Bereitstellung in unserer Sandboxressourcengruppe gestartet, indem die Vorlagendatei und die von uns angegebenen Parameter verwendet werden. Außerdem geben wir eine zufällige Zeichenfolge mit 32 Zeichen, die mit dem Befehl head /dev/urandom | tr -dc A-Za-z0-9 | head -c 32 generiert wird, als Kennwortparameter an.

    Es dauert ungefähr fünf Minuten, bis diese Bereitstellung abgeschlossen ist.

    az deployment group create \
  --resource-group <rgn>[sandbox resource group name]</rgn> \
  --template-uri  https://raw.githubusercontent.com/MicrosoftDocs/mslearn-n-tier-architecture/master/Deployment/azuredeploy.json \
  --parameters password="$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 32)"

Anzeigen von bereitgestellten Ressourcen und Testen der Anwendung

Nachdem die Bereitstellung abgeschlossen ist, testen Sie die Anwendung. Führen Sie den folgenden Befehl aus, mit dem die URL für die App zurückgegeben wird.

az deployment group show \
  --output table \
  --resource-group <rgn>[sandbox resource group name]</rgn> \
  --name azuredeploy \
  --query properties.outputs.webSiteUrl

Öffnen Sie einen Webbrowser, und navigieren Sie zur Website. Es wird ein Feld angezeigt, in dem Sie auswählbare Gerichte hinzufügen können. Nachdem Sie eine Option hinzugefügt haben, wird durch deren Auswahl eine Stimme hinzugefügt.

Screenshot of the sample voting application.

Drei Schichten zum Thema „Was gibt es als Mittagessen?“

Es ist Absicht, dass diese Anwendung nur eine geringe Komplexität aufweist. Es handelt sich um eine Spaßanwendung, die aber über eine Architektur mit drei Schichten verfügt. Die Vorlage erstellt zwei virtuelle Computer (VMs), eine Azure SQL-Datenbank und die erforderlichen Ressourcen zur Unterstützung dieser Ressourcen, z. B. Datenträger, Netzwerkkarten und virtuelle Netzwerke. Darüber hinaus wird der Code zum Ausführen der Anwendung auf jeder Schicht bereitgestellt. Das von uns bereitgestellte virtuelle Netzwerk hat zwei Subnetze – eins für die Präsentationsschicht und eins für die Logikschicht –, um eine Sicherheitsgrenze für jede Schicht zu erhalten.

Wir haben im Rahmen der Bereitstellung auch Tags auf die Ressourcen angewendet, um die Schicht widerzuspiegeln, die von der Ressource unterstützt wird (tier:presentation, tier:application, tier:data). Tags sind eine Methode zum Anwenden von Metadaten auf Azure-Ressourcen. In diesem Fall ermöglichen sie uns ein einfaches Filtern der Ressourcen für jede Schicht.

Wir sehen uns die einzelnen Schichten nun etwas genauer an. Hier ist eine detaillierte Visualisierung der bereitgestellten Ressourcen.

Visualization of the N-tier architecture to be deployed in this unit again.

Präsentationsschicht

Führen Sie den folgenden Befehl aus, um die Ressourcen der Präsentationsschicht aufzulisten.

az resource list --tag tier=presentation --output table

In der Architektur mit drei Schichten, die wir verwendet haben, ist dies die Präsentationsschicht. Der zugrunde liegende Code für die Weboberfläche wurde auf dieser Schicht bereitgestellt. Er dient zur Darstellung der Benutzeroberfläche und zum direkten Verarbeiten von Benutzeranforderungen. Auf dieser Schicht geht es nur um die Präsentation der Website für Benutzer*innen. Es besteht kein direkter Zugriff auf die Daten, und es ist keine Geschäftslogik vorhanden.

Wir haben einen Webserver mit dem Namen demo-web-vm bereitgestellt, auf dem die Website ausgeführt wird, auf die wir zugreifen. Der Server verfügt über die Netzwerkschnittstelle demo-web-vm-nic, der die öffentliche IP-Adresse demo-web-vm-nic-pip zugeordnet ist. Diese IP-Adresse ist die URL, die Sie weiter oben abgerufen haben. Außerdem verfügt er über die Netzwerksicherheitsgruppe demo-web-nsg, die nur eingehenden Internetdatenverkehr über Port 80 (HTTP) zulässt. Mit dieser Netzwerksicherheitsgruppe wird der Zugriff auf die Website beschränkt. Außerdem wird der Zugriff über nicht benötigte Ports verhindert, die missbraucht werden könnten. Diese Schicht kommuniziert mit der Präsentationsschicht per HTTP, um die Anforderung für den Benutzer zu erfüllen.

Logikschicht

Führen Sie den folgenden Befehl aus, um die Ressourcen der Logikschicht aufzulisten.

az resource list --tag tier=application --output table

Die Logikschicht wurde auf der VM demo-biz-vm bereitgestellt, auf der die Geschäftslogik ausgeführt wird. Zusätzlich ist die Netzwerkschnittstelle demo-biz-vm-nic vorhanden. Diese verfügt aber nur über eine private IP-Adresse, sodass mit dem Server keine direkte Konnektivität in eingehender Richtung besteht. Darüber hinaus ist auch die Netzwerksicherheitsgruppe demo-biz-nsg vorhanden, die nur den Zugriff aus dem Subnetz der Präsentationsschicht zulässt.

Über diese Schicht kann die Anwendung auf die Daten zugreifen. Der Code, mit dem die von der Präsentationsschicht aufgerufene API verfügbar gemacht wird, wird auf diesem Server bereitgestellt. Hier werden keine Daten gespeichert, und Benutzer*innen können nicht direkt auf diesen Server zugreifen. Für den Zugriff auf Daten und die Erfüllung von Benutzeranforderungen kommuniziert diese Schicht über T-SQL-Befehle mit der Datenschicht.

In die Anwendung auf dieser Schicht ist ein einfaches Beispiel für Geschäftslogik eingebunden. Die vorgeschlagenen Optionen für Mittagsgerichte werden serverseitig überprüft und mit einer Liste verglichen, die die zulässigen Werte enthält. Wenn Sie versuchen, eine Option hinzuzufügen, die nicht in der Liste enthalten ist, wird dies nicht akzeptiert. Stattdessen wird eine Nachricht mit den zulässigen Optionen für Mittagsgerichte zurückgegeben.

Datenschicht

Führen Sie den folgenden Befehl aus, um die Ressourcen der Datenschicht aufzulisten.

az resource list --tag tier=data --output table

Bei der Datenschicht handelt es sich um den Azure SQL-Datenbank-Server demo-dbserver-abc123 (aus Gründen der globalen Eindeutigkeit fügen wir dem Servernamen eine zufällige Zeichenfolge hinzu). Auf diesem Server werden die Daten für die Anwendung in einer Datenbank mit dem Namen demo-sqldb gespeichert. Bei dieser Schicht der Anwendung geht es ausschließlich um die Datenspeicherung und die Bereitstellung einer Zugriffsmethode. In diesem Fall geschieht dies per T-SQL-Code, den die Anwendung für die Datenbank ausführt. Wir verarbeiten auf dieser Schicht keine Geschäftslogik, und dem Benutzer werden auch keine Daten präsentiert.

Auf dieser Schicht wird Konnektivität über Port 1433 mit einem VNET-Dienstendpunkt verfügbar gemacht. VNET-Dienstendpunkte sind ein Mechanismus zum Verbinden von PaaS-Diensten (z. B. Azure SQL-Datenbank) mit einem Subnetz und zum Einschränken der Konnektivität auf nur die Ressourcen in diesem Subnetz.

Dies ist auch ein Beispiel für die Nutzung von PaaS-Diensten statt IaaS-VMs (Infrastructure as a Service) zum Ausführen einer Schicht einer Anwendung. N-schichtige Anwendungen werden häufig als VM-basierte Anwendungen angesehen, aber dies ist keine Voraussetzung. Wenn Sie anstelle von VMs PaaS-Dienste verwenden, können dadurch die Kosten gesenkt, die Sicherheit erhöht und der Verwaltungsaufwand minimiert werden.