BLOG | NGINX

Anleitung: Proxying von .NET Core und Kestrel mit NGINX und NGINX Plus

NGINX-Teil-von-F5-horiz-schwarz-Typ-RGB
Nick Shadrin Miniaturbild
Nick Shadrin
Veröffentlicht am 14. Februar 2017

Vor etwa zwei Jahren kündigte Microsoft® .NET Core an, ein Framework, mit dem Sie .NET-Anwendungen nativ auf Linux- und Mac-Systemen entwickeln und ausführen können. ASP.NET Core enthält Kestrel , eine interne Webserverbibliothek.

Wie in der Dokumentation zu Kestrel auf der Microsoft-Website und im GitHub-Repository angegeben, führen Sie Kestrel normalerweise hinter einem Produktionswebserver wie IIS oder NGINX aus. In diesem Tutorial beschreiben wir, wie Sie Kestrel hinter NGINX und NGINX Plus implementieren.

In diesem Tutorial lernen Sie Folgendes:

Wenn die Installation und Konfiguration abgeschlossen sind:

  • .NET Core und Kestrel:

    • Ausführen des dynamischen Anwendungscodes
    • Lauschen Sie auf einer lokalen IP-Adresse und antworten Sie auf HTTP-Anfragen

  • NGINX oder NGINX Plus als Reverse-Proxy:

    • Akzeptiert HTTP/2-Verkehr über IPv6 und IPv4
    • Bietet SSL-Offload für die .NET-Anwendung
    • Bietet statische Dateibereitstellung
    • Bietet Zugriffsprotokolle
    • Fügt Caching hinzu

  • NGINX Plus:

    • Bietet Live-Aktivitätsüberwachung und Metriken
    • Stellt durch aktive Integritätsprüfungen sicher, dass die App funktioniert

Die Bereitstellungsarchitektur von .NET Core-Anwendungen ähnelt der Bereitstellungsarchitektur von Node.js- oder Go-Anwendungen. NGINX stattet .NET-Apps mit Verkehrsmanagementfunktionen aus, die die Produktionsbereitstellung und Skalierbarkeit der Apps vereinfachen. Sie können mehrere .NET-Anwendungen auf derselben oder auf verschiedenen Maschinen ausführen und NGINX oder NGINX Plus übernimmt den Lastenausgleich und die intelligente Verkehrsweiterleitung zwischen ihnen.

Anweisungen

Die folgenden Anweisungen erläutern, wie Sie mit .NET Core schnell eine „Hello World“-App erstellen, sie unter Linux ausführen und hinter einem NGINX- oder NGINX Plus-Reverseproxy mit erweiterter Verkehrsverwaltungsfunktionalität bereitstellen.

  1. Installieren Sie .NET Core, NGINX und NGINX Plus
  2. Führen Sie die App „Hallo Welt“ aus
  3. Ausführen des Kestrel-HTTP-Servers
  4. Konfigurieren Sie NGINX oder NGINX Plus zum Reverse-Proxy der .NET-Anwendung
  5. Konfigurieren Sie die Live-Aktivitätsüberwachung und aktiven Integritätsprüfungen von NGINX Plus

Installieren Sie .NET Core, NGINX und NGINX Plus

  1. Installieren Sie .NET Core gemäß den Anweisungen auf der Microsoft-Website.

    In unserem Beispiel verwenden wir Ubuntu 16.04. Die folgenden Befehle waren zum Zeitpunkt des Schreibens korrekt, können sich jedoch ändern, da Kestrel sich noch in der Entwicklung befindet. Ziehen Sie bei Bedarf die .NET Core-Dokumentation zu Rate.

    $ sudo apt-get install apt-transport-https $ sudo sh -c 'echo "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet-release/ xenial main" > /etc/apt/sources.list.d/dotnetdev.list' $ sudo apt-key adv --keyserver apt-mo.trafficmanager.net --recv-keys 417A0893 $ sudo apt-get update $ sudo apt-get install dotnet-dev-1.0.0-preview2-003131

  2. Installieren Sie NGINX:

    $ sudo apt-get installiere nginx

  3. Installieren Sie NGINX Plus, wenn Sie eine Live-Aktivitätsüberwachung, aktive Integritätsprüfungen oder beides wünschen. Anweisungen finden Sie im NGINX Plus-Administratorhandbuch .

    1. Bearbeiten Sie die Datei ./project.json , um Kestrel als Abhängigkeit zum Projekt hinzuzufügen.

      { "version": "1.0.0-*", "BuildOptions": { "Debugtyp": "portabel", "emitEntryPoint": true }, "Abhängigkeiten": {}, "Frameworks": { "netcoreapp1.0": { "Abhängigkeiten": { "Microsoft.NETCore.App": { "Typ": "Plattform", "Version": "1.0.1" } , "Microsoft.AspNetCore.Server.Kestrel": "1.0.0" }, "imports": "dnxcore50" } } }

    2. Kopieren Sie diesen Code für eine einfache App in eine neue Datei namens Program.cs . Es gibt das aktuelle Datum und die Uhrzeit zurück und führt Kestrel auf Port 5000 auf dem lokalen Host aus.

      using System; using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;

namespace ConsoleApplication
{
public class Program
{
public static void Main(string[] args)
{
var host = new WebHostBuilder()
.UseKestrel()
.Configure(app =>
{
app.Run(async (context) => await context.Response.WriteAsync("Aktuelles Datum: " + DateTime.Now + "n"));
})
.Build();

host.Run();
}
}
}

    3. Führen Sie den Befehl „dotnet run “ aus, um den .NET Core-Server zu starten:

      $ dotnet run. Die Projekt-App (.NETCoreApp,Version=v1.0) wird kompiliert, da die Eingaben geändert wurden. Die Kompilierung der App für .NETCoreApp,Version=v1.0 war erfolgreich.
    0 Warnung(en) 0 Fehler Verstrichene Zeit 00:00:01.9047678 Hallo Welt!
Hosting-Umgebung: Stammpfad des Produktionsinhalts: /app/bin/Debug/netcoreapp1.0. Derzeit wird überwacht auf: http://localhost:5000. Anwendung gestartet. Drücken Sie zum Herunterfahren Strg+C.

    4. Führen Sie den Curl -Befehl aus, um die Konnektivität und HTTP zu testen:

      $ curl -v localhost:5000 * URL neu erstellt zu: localhost:5000/ * Versuch ::1... * Verbunden mit localhost (::1) Port 5000 (#0) > GET / HTTP/1.1 > Host: localhost:5000 > User-Agent: curl/7.47.0 > Akzeptieren: */* > < HTTP/1.1 200 OK < Datum: Dienstag, 14. Februar 2017, 19:50:59 GMT < Transfer-Encoding: chunked < Server: Turmfalke < Aktuelles Datum: 14.02.17 12:50:59 Uhr * Verbindung Nr. 0 zum Host „localhost“ blieb intakt

    1. Installieren Sie ein SSL-Zertifikat. Es gibt mehrere Möglichkeiten, eines zu erhalten:

      • Kaufen Sie es bei einer bekannten Zertifizierungsstelle (CA).
      • Lassen Sie es von Ihrer Unternehmens-IT-Gruppe oder Zertifizierungsstelle erstellen.
      • Exportieren Sie es von einem vorhandenen IIS-Server
      • Verwenden Sie eine kostenlose Zertifizierungsstelle wie Let’s Encrypt
      • Generieren Sie direkt ein selbstsigniertes Zertifikat

      Um schnell eine Beispiel-.NET Core-App mit SSL zu starten, generieren wir mit diesem OpenSSL -Befehl ein selbstsigniertes Zertifikat und einen zugehörigen Schlüssel. Wir installieren das Zertifikat und den Schlüssel am Standardspeicherort für NGINX, /etc/nginx , Sie können aber einen anderen Speicherort wählen.

      $ openssl req -x509 -subj /CN=localhost -days 365 -set_serial 2 -newkey rsa:4096 -keyout /etc/nginx/cert.key -nodes -out /etc/nginx/cert.pem Einen 4096-Bit-RSA-Privatschlüssel generieren .........++ ............................++ Neuen Privatschlüssel in „/etc/nginx/cert.key“ schreiben -----

    2. Konfigurieren Sie den Reverseproxy in der Standardkonfigurationsdatei von NGINX und NGINX Plus für virtuelle HTTP-Server.

      Die Hauptkonfigurationsdatei von NGINX und NGINX Plus ist /etc/nginx/nginx.conf . Mehrere NGINX-Distributionen (sowie NGINX Plus) folgen jedoch der Konvention, dass Sie nicht viele tatsächliche Konfigurationsdateien in der Hauptdatei platzieren, sondern stattdessen kleinere, funktionsspezifische Dateien in einem Unterverzeichnis von /etc/nginx erstellen:

      • Für von nginx.org bereitgestellte NGINX Open Source-Builds und für NGINX Plus ist das Verzeichnis /etc/nginx/conf.d und die Standarddatei für virtuelle HTTP-Server ist default.conf .
      • Für mit Ubuntu verteilte NGINX Open Source-Builds lautet das Verzeichnis /etc/nginx/sites-enabled und die Standarddatei für virtuelle HTTP-Server ist default .

      Der Inhalt der funktionsspezifischen Dateien in diesen Verzeichnissen wird dann mit einer Include -Direktive in die Hauptdatei ( nginx.conf ) eingelesen, zum Beispiel:

      einschließen /etc/nginx/conf.d/*.conf; einschließen /etc/nginx/sites-enabled/*;

      Wenn Sie nicht sicher sind, welche die Standardkonfigurationsdatei für virtuelle HTTP-Server auf Ihrem System ist, suchen Sie die entsprechende Include- Direktive in /etc/nginx/nginx.conf .

      Um NGINX oder NGINX Plus als Reverseproxy zu konfigurieren, fügen Sie der Standardkonfigurationsdatei für virtuelle HTTP-Server die folgenden drei Konfigurationsblöcke hinzu:

      • Der erste Serverblock nimmt HTTP-Anfragen auf Port 80 entgegen und leitet diese an den virtuellen Server für HTTPS-Anfragen weiter.

      • Der zweite Serverblock akzeptiert HTTPS-Anfragen auf Port 443 und leitet sie an eine Gruppe aus einem oder mehreren Upstream-Servern (Back-End-Servern) weiter, die hier „dotnet“ genannt werden. (Wenn Sie in Schritt 1 Ihr selbstsigniertes SSL-Zertifikat in einem anderen Verzeichnis als /etc/nginx installiert haben, ersetzen Sie den richtigen Pfad in den Anweisungen ssl_certificate und ssl_certificate_key .)

      • Der Upstream- Block definiert die Dotnet- Gruppe der Backend-Server.

        Unter „Kestrel-HTTP-Server ausführen “ haben wir Kestrel auf „localhost:5000“ konfiguriert, was bedeutet, dass es auf diesem Port sowohl auf IPv4- als auch auf IPv6-Verkehr lauscht. (Die Konfiguration von Kestrel für nur ein Protokoll kann zu Instabilität führen und möglicherweise502 Fehler.) In ähnlicher Weise lösen NGINX und NGINX Plus localhost sowohl in seine IPv4- als auch in seine IPv6-Adresse auf (127.0.0.1 und ::1). Der Einfachheit halber bezeichnen wir den Upstream-Server hier als127.0.0.1 anstelle von localhost , sodass nur auf IPv4-Verkehr gewartet wird. Sie können localhost verwenden, wenn Sie mit einer erweiterten Konfiguration, die IPv6 umfasst, vertraut sind.

      Server { abhören 80 Standardserver;
abhören [::]:80 Standardserver;
return 301 https://$host$request_uri;
}

Server {
abhören 443 ssl http2 Standardserver;
abhören [::]:443 ssl http2 Standardserver;

SSL-Zertifikat /etc/nginx/cert.pem;
SSL-Zertifikatschlüssel /etc/nginx/cert.key;

Standort / {
Proxy-Passwort http://dotnet;
Proxy-Set-Header Host $host;
}
}

Upstream dotnet {
Zone dotnet 64k;
Server 127.0.0.1:5000;
}

    3. Führen Sie diesen Curl -Befehl aus, um die Verbindung zur .NET Core-App über HTTPS zu testen. (Sie können Ihren Browser stattdessen auch auf Ihren Linux-Server richten.)

      $ curl -kv https://localhost * URL neu erstellt zu: https://localhost/ * Versuch ::1... * Verbunden mit localhost (::1) Port 443 (#0) ...[ ÜBERSPRINGEN ]... < HTTP/1.1 200 OK < Server: nginx/1.10.0 (Ubuntu) < Datum: Di, 14. Februar 2017 20:22:07 GMT < Übertragungskodierung: chunked < Verbindung: keep-alive < Aktuelles Datum: 14.02.17 13:22:07 Uhr

      Notiz: Wenn Sie sehen 502 Schlecht Tor Fehler, bedeutet dies, dass NGINX oder NGINX Plus keine Verbindung zu Ihrer .NET-Anwendung herstellen können. Stellen Sie sicher, dass es ausgeführt wird und Antworten auf Port 5000 bereitstellt.

      Wenn Sie das Paket nghttp2 installiert haben, können Sie auch den folgenden nghttp -Befehl ausführen, um die Konnektivität über HTTP/2 zu testen. Suchen Sie im folgenden Beispiel nach der orange hervorgehobenen Zeile am Anfang der recht langen Ausgabe.

      $ nghttp -v https://localhost [ 0.000] Verbunden Das ausgehandelte Protokoll: h2 [ 0.009] sende SETTINGS-Frame (niv=2) [SETTINGS_MAX_CONCURRENT_STREAMS(0x03):100] [SETTINGS_INITIAL_WINDOW_SIZE(0x04):65535] [ 0.009] sende PRIORITY-Frame (dep_stream_id=0, weight=201, exclusive=0)
    • Der Antwortcode ist 200OK
    • Der App-Server ist Kestrel und keine andere Software
    • Der Textkörper der Antwort enthält die Worte „Aktuelles Datum“
    • Die App reagiert innerhalb einer Timeout-Periode von 1 Sekunde

    4. Führen Sie die App „Hallo Welt“ aus

    Installieren und initialisieren Sie eine „Hello World“-App im übergeordneten Verzeichnis Ihrer Wahl:

    $ cd übergeordnetes Verzeichnis für Apps $ mkdir app $ cd app $ dotnet restore

    Um zu überprüfen, ob die App funktioniert, führen Sie den Befehl „dotnet run “ aus.

    Ausführen des Kestrel-HTTP-Servers

    Derzeit läuft .NET Core unter Linux und stellt dynamische Daten mit Kestrel als HTTP-Server bereit.

    Konfigurieren Sie NGINX oder NGINX Plus zum Reverse-Proxy der .NET-Anwendung

    Mit NGINX oder NGINX Plus als Reverse-Proxy für die .NET-Anwendung können Sie die Sicherheit einfach mit SSL/TLS, HTTP/2-Unterstützung und vielen anderen Funktionen für eine schnelle Anwendungsbereitstellung auf derselben Maschine konfigurieren, auf der die .NET Core-Anwendung ausgeführt wird. Die folgenden Anweisungen setzen voraus, dass NGINX und NGINX Plus bereits auf Ihrem System installiert sind. Wenn nicht, lesen Sie den Abschnitt „Installieren von .NET Core, NGINX und NGINX Plus“ .

    Konfigurieren Sie die Live-Aktivitätsüberwachung und aktiven Integritätsprüfungen von NGINX Plus

    An diesem Punkt haben wir die Grundkonfiguration von NGINX oder NGINX Plus mit .NET Core abgeschlossen. NGINX oder NGINX Plus bietet HTTP-Verarbeitung, passive Integritätsprüfungen, Sicherheit mit SSL/TLS und HTTP/2-Konnektivität für unsere .NET Core-App.

    Wenn Sie NGINX Plus installiert haben, können Sie zwei zusätzliche Funktionen konfigurieren: Live-Aktivitätsüberwachung und aktive Integritätsprüfungen.

    Konfigurieren der Live-Aktivitätsüberwachung

    [Editor – Dieser Abschnitt wurde aktualisiert, um auf die NGINX Plus API zu verweisen, die das ursprünglich hier besprochene separate erweiterte Statusmodul ersetzt und veraltet.]

    Fügen Sie der Standard-NGINX-Konfigurationsdatei für virtuelle HTTP-Server den folgenden Serverblock hinzu. Wir empfehlen Ihnen dringend, den Zugriff auf die Statistiken und Messwerte einzuschränken . Hier erlauben wir nur Benutzern auf dem lokalen Host und einem lokalen Netzwerk den Zugriff.

    Weitere Informationen zur Live-Aktivitätsüberwachung finden Sie unter „Live-Aktivitätsüberwachung von NGINX Plus in 3 einfachen Schritten“ in unserem Blog und im NGINX Plus-Administratorhandbuch .

    server { listen 8080;
allow 127.0.0.1; # Localhost Zugriff auf die Statistiken erlauben
allow 10.3.3.0/24; # Lokalem Netzwerk Zugriff auf die Statistiken erlauben
deny all; # Zugriff von anderswo verhindern

root /usr/share/nginx/html;

location / {
return 302 /dashboard.html;
}

location /api {
api write=on;
}

location = /dashboard.html {
root /usr/share/nginx/html;
}

# Anfragen an das alte Dashboard umleiten
location = /status.html {
return 301 /dashboard.html;
}
}

    Konfigurieren aktiver Integritätsprüfungen

    Aktive Integritätsprüfungen garantieren, dass NGINX Plus Datenverkehr nur an Anwendungen sendet, die ordnungsgemäß funktionieren. Sie definieren die HTTP-Anfragen, die NGINX Plus regelmäßig an die App sendet, und die Art der Antwort, die die App zurückgeben muss, um als fehlerfrei zu gelten.

    Dabei fordern wir, dass die Antwort der App folgende Bedingungen erfüllt:

    Fügen Sie in der Standardkonfigurationsdatei für virtuelle HTTP-Server dem Hauptserverblock (dem Block für HTTPS-Verkehr, der in Schritt 2 von „NGINX oder NGINX Plus als Reverse-Proxy für die .NET-Anwendung konfigurieren“ definiert wurde) den folgenden Standortblock hinzu:

    Standort @healthcheck { proxy_pass http://dotnet;
proxy_set_header Host localhost;
health_check match=currentdate;
proxy_connect_timeout 1s;
proxy_read_timeout 1s;
}

    Fügen Sie außerdem den folgenden Übereinstimmungsblock auf derselben Ebene in der Hierarchie wie die Server- und Upstreamblöcke hinzu:

    match currentdate { status 200;
header Server = Kestrel;
body ~ "Aktuelles Datum";
}

    Sie können auf der Registerkarte „Upstreams“ des integrierten Dashboards zur Liveaktivitätsüberwachung überprüfen, ob Ihre Back-End-App fehlerfrei ist (richten Sie Ihren Browser auf //http:// nginx-plus-server-address :8080/ ):

    Das NGINX Plus Live-Aktivitätsüberwachungs-Dashboard meldet den Zustand der Backend-.NET-Anwendungen, die NGINX als Proxy verwendet

    Weitere NGINX-Konfigurationsoptionen finden Sie in der Microsoft-Dokumentation .

    Abschluss

    Für produktionsreife Bereitstellungen der Apps, die Sie mit ASP.NET entwickeln, bieten NGINX und NGINX Plus die Verkehrsverwaltungsfunktionen, die Sie in einem Reverseproxy benötigen. NGINX und NGINX Plus bieten Sicherheit, Skalierbarkeit, Authentifizierung, Verkehrsbegrenzung und intelligentes Routing Ihrer HTTP-Anfragen an .NET Core-Anwendungen.

    Um NGINX Plus selbst auszuprobieren, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .

Weitere Blogbeiträge zu F5 NGINX lesen ›

„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."