In unserem Grund­la­gen-Artikel "NGINX – der schnelle und res­sour­cen­scho­nen­de Webserver" haben wir bereits für Sie zu­sam­men­ge­fasst, was NGINX ausmacht und wie Sie es auf Ihrem System in­stal­lie­ren und ein­rich­ten. In dem folgenden Tutorial bieten wir Ihnen einen Überblick über die grund­le­gen­den Befehle und Kon­fi­gu­ra­ti­ons­mög­lich­kei­ten der modernen Webserver-Software.

Die zentrale Steu­er­ein­heit: nginx.conf

NGINX arbeitet anders als bei­spiels­wei­se Apache event­ba­siert. Einzelne Anfragen werden nicht jeweils als neuer Ar­beits­pro­zess ein­ge­stuft, für den sämtliche Module geladen werden müssen, sondern als Event. Diese Events werden auf exis­tie­ren­de Ar­beits­pro­zes­se auf­ge­teilt, die durch den über­ge­ord­ne­ten Haupt­pro­zess auf­recht­erhal­ten werden. Wie viele Ar­beits­pro­zes­se letzt­end­lich exis­tie­ren und auf welche Art und Weise die Ser­ver­an­fra­gen (also die Events) auf­ge­teilt werden, ist in der Kon­fi­gu­ra­ti­ons­da­tei nginx.conf definiert. Diese finden Sie stan­dard­mä­ßig in den Ver­zeich­nis­sen /usr/local/nginx/conf, /etc/nginx oder /usr/local/etc/nginx.

Prozesse verwalten und neue Kon­fi­gu­ra­tio­nen über­neh­men

NGINX startet nach der In­stal­la­ti­on au­to­ma­tisch, was Sie al­ter­na­tiv aber auch mithilfe des folgenden Befehls in die Wege leiten können:

sudo service nginx start

Läuft die Webserver-Software, kon­trol­lie­ren Sie diese, indem Sie die Prozesse (in erster Linie den Haupt­pro­zess) mit dem Parameter -s und einem be­stimm­ten Signal an­spre­chen. Die Syntax der ent­spre­chen­den Befehle ist relativ un­spek­ta­ku­lär:

sudo nginx -s signal

Für „signal“ haben Sie unter anderem die folgenden vier Mög­lich­kei­ten:

  • stop: NGINX wird sofort beendet.
  • quit: NGINX wird beendet, nachdem alle aktive Anfragen be­ant­wor­tet worden sind.
  • reload: Die Kon­fi­gu­ra­ti­ons­da­tei wird neu geladen.
  • reopen: Die Log-Files werden neu gestartet.

Die Reload-Option, mit der die Kon­fi­gu­ra­ti­ons­da­tei neu geladen wird, ist eine gute Mög­lich­keit, um Ver­än­de­run­gen an selbiger zu über­neh­men, ohne die Webserver-Software beenden und neu­star­ten zu müssen. In jedem Fall müssen Sie sich für eine Variante – Komplett-Neustart des Servers oder einen einfachen NGINX-Reload – ent­schei­den, damit die Än­de­run­gen über­nom­men werden. Wenn Sie sich für letztere, ele­gan­te­re Version ent­schie­den und den un­ten­ste­hen­den Befehl aus­ge­führt haben, erhält der Haupt­pro­zess die Anweisung, die Än­de­run­gen in der nginx.conf-Datei zu über­neh­men:

sudo nginx -s reload

Zu diesem Zweck wird zunächst die Kor­rekt­heit der Syntax überprüft. Bei positiver Rück­mel­dung startet der Haupt­pro­zess neue Ar­beits­pro­zes­se mit den neuen Ein­stel­lun­gen und initiiert gleich­zei­tig den Stopp der alten Prozesse. Schlägt die Va­li­die­rung der Syntax fehl, wird der alte Kon­fi­gu­ra­ti­ons­stand bei­be­hal­ten. Alle aktiven Ar­beits­pro­zes­se werden beendet, sobald sämtliche aktiven Anfragen be­ar­bei­tet wurden.

Im Übrigen können Sie NGINX-Prozesse auch ganz gezielt mithilfe von Tools wie kill an­spre­chen. Sie benötigen lediglich die ent­spre­chen­de Prozess-ID, die Sie in der nginx.pid-Datei im Ver­zeich­nis /usr/local/nginx/logs oder al­ter­na­tiv im Ver­zeich­nis /var/run finden. Hat der Haupt­pro­zess zum Beispiel die ID 1628, kann er mit kill und dem Quit-Signal im Schongang beendet werden:

sudo kill -s quit 1628

Mit dem Dienst­pro­gramm ps können Sie sich darüber hinaus eine Liste aller aus­ge­führ­ten NGINX-Prozesse anzeigen lassen:

sudo ps -ax | grep nginx

So regeln Sie die Aus­lie­fe­rung sta­ti­scher Inhalte

Mit großer Wahr­schein­lich­keit nutzen Sie Ihren Webserver, um Dateien wie Bilder, Videos oder statische HTML-Inhalte aus­zu­lie­fern. Aus Gründen der Effizienz bietet es sich an, ver­schie­de­ne lokale Ver­zeich­nis­se für die un­ter­schied­li­chen In­halts­ty­pen zu wählen. Beginnen Sie damit, das ex­em­pla­ri­sche Ver­zeich­nis /data/html anzulegen und dort ein bei­spiel­haf­tes HTML-Dokument index.html zu plat­zie­ren sowie einen Ordner /data/bilder mitsamt einigen Bei­spiel­bil­dern zu erzeugen.

Im nächsten Schritt müssen die beiden Ver­zeich­nis­se in der Kon­fi­gu­ra­ti­ons­da­tei ein­ge­tra­gen werden, indem man beide in der Server-Block-Direktive festhält, die ih­rer­seits Sub-Direktive der Http-Block-Direktive ist. Stan­dard­mä­ßig sind hier bereits ver­schie­de­ne An­wei­sun­gen fest­ge­hal­ten, die Sie zunächst aus­schal­ten können (off). Legen Sie an­schlie­ßend einfach eine separate Server-Block-Anweisung an:

http {
    server {
    }
}

In diesem Server-Block sollen nun die beiden Ver­zeich­nis­se angegeben werden, in denen Bilder und HTML-Dokumente liegen. Das ent­spre­chen­de Resultat sieht fol­gen­der­ma­ßen aus:

server {
    location / {
        root /data/html;
    }
    location /bilder/ {
        root /data;
    }
}

Bei dieser Kon­fi­gu­ra­ti­on handelt es sich um eine Stan­dard­ein­stel­lung eines Servers, der auf Port 80 lauscht und über den Localhost zu­gäng­lich ist. Alle Anfragen, deren URIs mit /bilder/ beginnen, werden nun Dateien aus dem /data/bilder-Ver­zeich­nis anfordern. Existiert ent­spre­chen­de Datei dort nicht, erscheint eine Feh­ler­mel­dung. Alle NGINX-Events, deren URIs hingegen nicht mit /bilder/ beginnen, werden in das /data/html-Ver­zeich­nis wei­ter­ge­lei­tet.

Denken Sie daran, NGINX im Anschluss neu zu laden oder neu zu starten, um die Än­de­run­gen zu über­neh­men.

Ein­rich­tung eines einfachen NGINX-Proxy-Servers

Sehr häufig wird NGINX zum Betreiben eines Proxy-Servers ein­ge­setzt, um anstelle des ei­gent­li­chen Servers ein­ge­hen­de Anfragen ent­ge­gen­zu­neh­men, diese nach ver­schie­dens­ten Kriterien zu filtern und wei­ter­zu­lei­ten sowie die jeweilige Antwort an die Clients aus­zu­lie­fern. Besonders beliebt sind Cache-Proxys, die lokal ge­spei­cher­te, statische Inhalte direkt aus­lie­fern und nur alle weiteren Anfragen an den Server wei­ter­lei­ten. Ebenfalls sehr ver­brei­tet sind Firewall-Proxys, die unsichere bzw. un­er­wünsch­te Ver­bin­dun­gen her­aus­fil­tern. Im folgenden Beispiel geht es um den erst­ge­nann­ten Cache-Proxy, der an­ge­for­der­te Bilder aus dem lokalen Ver­zeich­nis aus­spie­len und alle weiteren Anfragen an den Webserver wei­ter­lei­ten soll. Im ersten Schritt de­fi­nie­ren Sie in der nginx.conf den Haupt­ser­ver:

server {
    listen 8080;
    root /data/up1;
    location / {
    }
}

Im Gegensatz zum vor­he­ri­gen Beispiel nutzen Sie hierbei die Listen-Direktive, da nicht der Standard-Port, sondern Port 8080 für ein­ge­hen­de Anfragen genutzt werden soll. Legen Sie außerdem das an­ge­peil­te Ver­zeich­nis /data/up1 an und dort die index.html-Seite ab.

Als zweites werden der Proxy-Server und seine Funktion, Bild­in­hal­te aus­zu­lie­fern, definiert, indem die Proxy-pass-Direktive inklusive der Angaben über den Haupt­ser­ver – Protokoll (http), Name (localhost) und Port (8080) – zum Einsatz kommt:

server {
    location / {
        proxy_pass http://localhost:8080;
    }
    location ~ \.(gif|jpg|png) $ {
        root /data/bilder;
    }
}

Der zweite Location-Block weist den Proxy-Server an, alle Anfragen selbst zu be­ant­wor­ten, deren URIs auf den bil­der­ty­pi­schen Endungen .gif, .jpg und .png enden, indem der ent­spre­chen­de Inhalt aus dem lokalen Ver­zeich­nis /data/bilder abgerufen wird. Alle anderen Anfragen werden zum Haupt­ser­ver wei­ter­ge­lei­tet. Wie auch bei den Ein­stel­lun­gen zuvor, speichern Sie Ihren Bilder-Proxy per Reload-Signal an den Haupt­pro­zess bzw. mit einem Restart von NGINX. Weitere mögliche Di­rek­ti­ven für kom­ple­xe­re Proxy-Ein­stel­lun­gen finden Sie im of­fi­zi­el­len NGINX-On­line­hand­buch.

Zum Hauptmenü