Eine Einführung in NGINX für Entwickler

Stellen Sie sich das vor - Sie haben eine Webanwendung erstellt und suchen nun nach dem richtigen Webserver, auf dem sie gehostet werden kann.

Ihre Anwendung kann aus mehreren statischen Dateien bestehen - HTML, CSS und JavaScript, einem Backend-API-Dienst oder sogar mehreren Webservices. Die Verwendung von Nginx könnte das sein, wonach Sie suchen, und dafür gibt es mehrere Gründe.

NGINX ist ein leistungsstarker Webserver und verwendet eine ereignisgesteuerte Architektur ohne Thread, die es ermöglicht, Apache bei korrekter Konfiguration zu übertreffen. Es kann auch andere wichtige Dinge tun, wie z. B. Lastausgleich, HTTP-Caching oder als Reverse-Proxy verwendet werden.

In diesem Artikel werde ich einige grundlegende Schritte zur Installation und Konfiguration der gängigsten Teile von NGINX behandeln.

Grundinstallation - Architektur

Es gibt zwei Möglichkeiten, NGINX zu installieren, entweder mit einer vorgefertigten Binärdatei oder aus der Quelle.

Die erste Methode ist viel einfacher und schneller, aber wenn Sie sie aus dem Quellcode erstellen, können Sie verschiedene Module von Drittanbietern einbeziehen, die NGINX noch leistungsfähiger machen. Es ermöglicht uns, es an die Anforderungen der Anwendung anzupassen.

Um ein vorgefertigtes Debian-Paket zu installieren, müssen Sie lediglich Folgendes tun:

sudo apt-get updatesudo apt-get install nginx

Nach Abschluss des Installationsvorgangs können Sie überprüfen, ob alles in Ordnung ist, indem Sie den folgenden Befehl ausführen, mit dem die neueste Version von NGINX gedruckt werden soll.

sudo nginx -vnginx version: nginx/1.6.2

Ihr neuer Webserver wird am Standort installiert . Wenn Sie in diesen Ordner gehen, werden mehrere Dateien und Ordner angezeigt. Die wichtigsten, die später unsere Aufmerksamkeit erfordern, sind die Datei und der Ordner ./etc/nginx/nginx.confsites-available

Konfigurationseinstellungen

Die Kerneinstellungen von NGINX befinden sich in der nginx.confDatei, die standardmäßig so aussieht.

user www-data;worker_processes 4;pid /run/nginx.pid;events { worker_connections 768; # multi_accept on;}http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; # server_tokens off; # server_names_hash_bucket_size 64; # server_name_in_redirect off; include /etc/nginx/mime.types; default_type application/octet-stream; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; gzip on; gzip_disable "msie6"; # gzip_vary on; # gzip_proxied any; # gzip_comp_level 6; # gzip_buffers 16 8k; # gzip_http_version 1.1; # gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*;}

Die Datei ist in Kontexte strukturiert . Der erste ist der Ereigniskontext und der zweite ist der http- Kontext. Diese Struktur ermöglicht eine erweiterte Überlagerung Ihrer Konfiguration, da jeder Kontext andere verschachtelte Kontexte haben kann, die alles von ihrem übergeordneten Kontext erben, aber bei Bedarf auch eine Einstellung überschreiben können.

Verschiedene Dinge in dieser Datei können je nach Ihren Anforderungen angepasst werden, aber NGINX ist so einfach zu bedienen, dass Sie auch mit den Standardeinstellungen mitmachen können. Einige der wichtigsten Teile der NGINX-Konfigurationsdatei sind:

  • worker_processes: Diese Einstellung definiert die Anzahl der Worker-Prozesse, die NGINX verwenden wird. Da NGINX Single-Threaded ist, sollte diese Anzahl normalerweise der Anzahl der CPU-Kerne entsprechen.
  • worker_connections: Dies ist die maximale Anzahl gleichzeitiger Verbindungen für jeden Worker-Prozess und gibt unseren Worker-Prozessen an, wie viele Personen gleichzeitig von NGINX bedient werden können. Je größer es ist, desto mehr gleichzeitige Benutzer kann NGINX bedienen.
  • access_log & error_log: Dies sind die Dateien, mit denen NGINX alle Fehler und Zugriffsversuche protokolliert. Diese Protokolle werden im Allgemeinen auf Fehlerbehebung und Fehlerbehebung überprüft.
  • gzip: Dies sind die Einstellungen für die GZIP-Komprimierung von NGINX-Antworten. Wenn Sie diese Option zusammen mit den verschiedenen Untereinstellungen aktivieren, die standardmäßig auskommentiert sind, führt dies zu einer erheblichen Leistungssteigerung. Bei den Untereinstellungen von GZIP sollte auf das gzip_comp_level geachtet werden, das die Komprimierungsstufe darstellt und zwischen 1 und 10 liegt. Im Allgemeinen sollte dieser Wert nicht über 6 liegen - der Gewinn in Bezug auf die Größenreduzierung ist unbedeutend, da Es braucht viel mehr CPU-Auslastung. gzip_types ist eine Liste von Antworttypen, auf die die Komprimierung angewendet wird.

Ihre NGINX-Installation kann weit mehr als eine einzelne Website unterstützen, und die Dateien, die die Websites Ihres Servers definieren, befinden sich im Verzeichnis / etc / nginx / sites-available.

Die Dateien in diesem Verzeichnis sind jedoch nicht "live" - ​​Sie können hier so viele Site-Definitionsdateien haben, wie Sie möchten, aber NGINX wird nichts damit anfangen, es sei denn, sie sind mit / etc / nginx / verknüpft. Sites-fähiges Verzeichnis (Sie können sie auch dort kopieren, aber durch Symlinking wird sichergestellt, dass nur eine Kopie jeder Datei vorhanden ist, um den Überblick zu behalten).

Auf diese Weise können Sie Websites schnell online stellen und offline schalten, ohne Dateien löschen zu müssen. Wenn Sie bereit sind, eine Website online zu schalten, verknüpfen Sie sie mit Websites, die für Websites aktiviert sind, und starten Sie NGINX neu.

Das sites-availableVerzeichnis enthält Konfigurationen für virtuelle Hosts. Auf diese Weise kann der Webserver für mehrere Sites mit unterschiedlichen Konfigurationen konfiguriert werden. Die Sites in diesem Verzeichnis sind nicht aktiv und werden nur aktiviert, wenn wir einen symbolischen Link in den sites-enabledOrdner erstellen .

Erstellen Sie entweder eine neue Datei für Ihre Anwendung oder bearbeiten Sie die Standarddatei. Eine typische Konfiguration sieht wie folgt aus.

upstream remoteApplicationServer { server 10.10.10.10;}upstream remoteAPIServer { server 20.20.20.20; server 20.20.20.21; server 20.20.20.22; server 20.20.20.23;}server { listen 80; server_name www.customapp.com customapp.com root /var/www/html; index index.html location / { alias /var/www/html/customapp/; try_files $uri $uri/ =404; } location /remoteapp { proxy_set_header Host $host:$server_port; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass //remoteAPIServer/; } location /api/v1/ { proxy_pass //remoteAPIServer/api/v1/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; proxy_redirect // //; }}

Ähnlich wie bei nginx.confdiesem wird auch hier das Konzept verschachtelter Kontexte verwendet (und alle diese Kontexte sind auch im HTTP- Kontext von nginx.conf verschachtelt , sodass sie auch alles davon erben).

Der Serverkontext definiert einen bestimmten virtuellen Server, der die Anforderungen Ihrer Clients verarbeitet. Sie können mehrere Serverblöcke haben, und NGINX wählt basierend auf den Anweisungen listenund zwischen diesen aus server_name.

Innerhalb eines Serverblocks definieren wir mehrere Standortkontexte, anhand derer entschieden wird, wie die Clientanforderungen behandelt werden sollen. Immer wenn eine Anfrage eingeht, versucht NGINX, seinen URI mit einer dieser Standortdefinitionen abzugleichen und entsprechend zu behandeln.

Es gibt viele wichtige Anweisungen, die im Standortkontext verwendet werden können, z.

  • try_files versucht, eine statische Datei bereitzustellen , die sich unter dem Ordner befindet, der auf die Root-Direktive verweist.
  • proxy_pass sendet die Anforderung an einen angegebenen Proxyserver.
  • rewrite schreibt den eingehenden URI basierend auf einem regulären Ausdruck neu, sodass ein anderer Standortblock damit umgehen kann.

Der Upstream- Kontext definiert einen Pool von Servern, an die NGINX die Anforderungen weiterleitet. Nachdem wir einen Upstream-Block erstellt und einen Server darin definiert haben, können wir ihn in unseren Standortblöcken mit Namen referenzieren. Darüber hinaus können einem Upstream-Kontext viele Server zugewiesen sein, sodass NGINX beim Proxying der Anforderungen einen Lastausgleich durchführt.

Starten Sie NGINX

Nachdem wir die Konfiguration abgeschlossen und unsere Webanwendung in den entsprechenden Ordner verschoben haben, können wir NGINX mit dem folgenden Befehl starten:

sudo service nginx start

Wenn wir danach etwas an unserer Konfiguration ändern, müssen wir es nur noch (ohne Ausfallzeit) mit dem folgenden Befehl neu laden.

service nginx reload

Zuletzt können wir den Status von NGINX mit dem folgenden Befehl überprüfen.

service nginx status

Fazit

Mit so vielen sofort einsatzbereiten Funktionen kann NGINX eine hervorragende Möglichkeit sein, Ihre Anwendung zu bedienen oder sogar als HTTP-Proxy oder Load Balancer für Ihre anderen Webserver verwendet zu werden. Wenn Sie wissen, wie NGINX funktioniert und Anforderungen verarbeitet, können Sie die Last Ihrer Anwendungen erheblich skalieren und ausgleichen.