Schnell? Schneller? NGINX? Performance!!!

Heute beschäftigen wir uns mit dem Thema NGINX und Performance Optimierung. Wir wissen alle das der NGINX der König unter den Webservern ist und deshalb schauen wir uns heute an, wie wir das letzte Fünkchen Geschwindigkeit aus dem Webserver herausholen. Zu dem Zeitpunkt wo ich diesen Beitrag schreibe gibt es den NGINX in der Stable Version 1.12.1 (Download).

Backup der NGINX Config

Als erstes ist es wichtig eure aktuelle funktionierende NGINX Konfiguration zu sichern (Kopie davon erstellen) damit wir nichts zu fürchten haben falls etwas nicht ganz so läuft wie von euch erhofft. Die Konfiguration findet Ihr z.B. bei Ubuntu unter /etc/nginx/nginx.conf

Performance? Optimieren!

Jetzt werde ich euch einzelne NGINX Core Module Direktiven vorstellen die euch helfen werden eure Webserver Performance zu steigern. Ich versuche dabei kurz und verständlich die Werte zu erklären. Alle folgenden Werte können in der nginx.conf bearbeitet oder hinzugefügt werden.

worker_processes auto;

Gibt an wie viele NGINX Worker Prozesse laufen. auto = automatische Erkennung. Generell gilt, man kann auch die Anzahl der verfügbaren CPU Cores angeben. (z.B. VPS mit 2 Kernen = auf 2 stellen).

worker_connections 1024;

Gibt an wie viele gleichzeitige Verbindungen pro Worker aufgebaut werden können. Die maximale Anzahl der Clients wird also wie folgt Berechnet. max Clients = worker_processes * worker_connections. Tip: hier ein wenig testen wie viel euer Server schafft.

use epoll;

Wichtig für Linux Server um viele Clients in einem Thread zu verarbeiten.

multi_accept on;

Dadurch werden so viele neue Verbindungen wie möglich akzeptiert von einem Worker Prozess.

sendfile on;

Kopiert Daten von einem FD (File Descriptor) zu einem innerhalb des Linux Kernels. Das ist schneller als read() + write()

tcp_nopush on;

Sendet den Request Header in einem Stück, dies ist besser als viele kleine.

tcp_nodelay on;

Aktiviert die TCP Option TCP_NODELAY. Daten werden nicht mehr im BUffer zwischen gespeichert, sondern gleich verschickt.

access_log off;

Um schwache Festplatten zu entlasten und den HDD I/O zu verbessern.

gzip on;
gzip_min_length 10240;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/json application/xml;
gzip_disable msie6;

Komprimiert die ausgegebenen Dateien, dies spart Traffic. Sollte nur bei ausreichend CPU Leistung aktiviert werden!

reset_timedout_connection on;

Erlaubt es dem Server die Verbindung zu nicht antwortenden Clients zu schließen. Das spart Arbeitsspeicher.

client_body_timeout 10;

Der Request Timeout. Standard ist bei 60. Falls keine Dateien auf eurer Seite hochgeladen werden sollte der Timeout reduziert werden z.B. auf 10 Sekunden

send_timeout 2;

Wenn der Client nicht mehr reagiert und nichts empfängt dann stoppe (Standard ist 60). Spart Arbeitsspeicher.

keepalive_timeout 30;

Schließt die Verbindung nach der angegebenen Zeit. Standard ist 75. Hier kann etwas experimentiert werden.

keepalive_requests 100;

Wie viele Keep Alive Requests gemacht werden können. Standard ist 100. Beachtet wie viele gleichzeitigen Besucher Ihr auf eurer Seite erwartet.

server_tokens off;

Erhöht die Sicherheit. Der Server schickt keine Version etc mehr heraus.

open_file_cache max=100000 inactive=20s; 
open_file_cache_valid 30s; 
open_file_cache_min_uses 2;
open_file_cache_errors on;

Der Cache kann die Performance steigern, die optimalen Werte solltet Ihr durch testen herausbekommen. Eine detaillierte Erklärung dazu findet Ihr hier

Beispiel Konfiguration für einen 2 Kern VPS (/etc/nginx/nginx.conf)

user www-data;
worker_processes 2;
pid /run/nginx.pid;

events {
        worker_connections 1024;
        use epoll;
        multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 30; # default 75
        keepalive_requests 100;   # default 100
        reset_timedout_connection on;
        client_body_timeout 10; # default 60
        send_timeout 10; # default 60
        types_hash_max_size 2048;
        server_tokens off;
        
        # File Cache
        open_file_cache max=100000 inactive=20s; 
        open_file_cache_valid 30s; 
        open_file_cache_min_uses 2;
        open_file_cache_errors on;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # SSL Settings
        ##

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        ##
        # Logging Settings
        ##

        access_log off;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        #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/javascript text/xml application/xml application/xml+rss text/javascript;

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}

Wichtig für Dateiuploads in Verbindung mit NGINX

Konfiguration neu einlesen oder NGINX neustarten

Einleitung

Im Jahre 2017 sollte SSL Standard für jede Webseite sein. Warum das leider immer noch nicht so ist liegt vielleicht daran, dass viele Leute abgeschreckt sind von der Einrichtung oder nicht wissen wie es umgesetzt wird. In diesem kleinen Tutorial, möchte ich euch Heute zeigen, wie einfach es doch ist SSL unter Ubuntu mit einem NGINX Webserver einzurichten.

Voraussetzungen

Eine kleine Liste mit Dingen die ich für dieses Tutorial voraussetze.

• Ubuntu Server
• NGINX Server installiert
• OpenSSL installiert

Außerdem solltet Ihr auf eurem Server die entsprechenden "root" oder "sudo" Rechte haben. Wenn ihr das alles habt können wir auch schon beginnen.

Schritt 1 - Zertifikat erzeugen

Als erstes brauchen wir einen Ort wo wir das Zertifikat ablegen und speichern wollen. Da es sich hier um ein Zertifikat für den NGINX handelt erzeugen wir einfach im NGINX Ordner einen weiteren Ordner "ssl".

  sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.crt

Kurze Erklärung zu dem Befehl:

• openssl: Standard Konsolen Programm um Zertifikate zu erstellen
• req: sagt aus das wir eine X.509 Signierungsanfrage erstellen wollen. X.509 ist ein Standard für SSL und TSL
• -x509: Die Option sagt aus das wir ein selbst signiertes Zertifikat erstellen wollen
• -nodes: Teilt OpenSSL mit das wir keine Passwortabfrage bei dem Zertifikat benötigen. Wäre auch schlecht da NGINX dann bei Neustarts immer danach fragen würde
• -days 365: Anzahl der Tage wie lange das Zert. gültig ist
• -newkey rsa:2048: Sagt das wir einen neuen Schlüssel und Zertifikat mit einem 2048 Bit Schlüssel möchten
• -keyout: Gibt OpenSSL einen Ort an wo der Schlüssel gespeichert werden soll
• -out: Gibt OpenSSL einen Ort an wo das Zertifikat gespeichert werden soll

Anschließend wirst du nach einigen Angaben gefragt. Diese kannst du leer lassen oder ausfüllen.

Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Die von dir erstelleten Dateien werden in dem angegebenen Ordner abgespeichert.

Schritt 2 - NGINX Konfigurieren

Ein Vorteil von NGINX gegenüber dem Apache ist das man HTTPS/SSL in der selben Vhost Config aktivieren kann wo auch HTTP konfiguriert ist. Wir bearbeiten dazu unsere Standard Konfiguration unter.

nano /etc/nginx/sites-available/default

Wir fügen 4 Zeilen hinzu.

server {
        # ipv4 http
        listen 80 default_server;
        # ipv6 http
        listen [::]:80 default_server;
        # ADDED ipv4 https
        listen 443 ssl default_server;
        # ADDED ipv6 https
        listen [::]:443 ssl default_server;

        server_name default;

        root   /var/www/application/public;

        index index.html index.htm index.php index.cgi index.pl index.xhtml;

        # ADDED ssl settings
        ssl_certificate         /etc/nginx/ssl/nginx.crt;
        ssl_certificate_key     /etc/nginx/ssl/nginx.key;

        # log
        error_log /var/www/application/log/error.log;
        access_log /var/www/application/log/access.log combined;

        # rewrite
        location / {
            try_files $uri $uri/ /index.php;
        }

        # php socket
        location ~ \.php$ {
            try_files $uri =404;
            include /etc/nginx/fastcgi_params;
            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            fastcgi_pass unix:/run/php/php7.1-fpm.sock;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_intercept_errors on;
        }

}

Die ersten beiden hinzugefügten Zeilen kümmern sich darum das der NGINX auf den richtigen Port lauscht und IPv4 und IPv6 anfragen annimmt.

Die anderen 2 kümmern sich darum das der NGINX den Schlüssel und das Zertifikat läd.

Danach starten wir neu uns schauen ob alles klappt.

sudo service nginx restart
ODER
sudo /etc/init.d/nginx restart

Nach erfolgreichem Neustart sollte unsere Seite unter http und https erreichbar sein.

HTTPS testen

Um unsere Konfiguration zu testen erstellen wir in unsrem Verzeichnis (/var/www/application/public) eine index.html zum testen. Unsere Seite dann unter beiden Adressen erreichbar sein

http://server_domain_or_IP
UND
https://server_domain_or_IP:443

Hinweiß: In den meisten Browsern muss man noch das Zertifikat akzeptieren damit die Seite dargestellt wird. Denn euer Lokales Zertifikat gilt in den Browsern als nicht sicher.

Abschluss

Abschließend ist zu sagen, dass der Aufwand SSL einzurichten doch relativ gering ist und für lokale Tests sehr zu empfehlen ist. Wenn eure Applikation lokal zu 100% läuft, solltet Ihr den Schritt nicht scheuen auch Live SSL mit einem richtigen Zertifikat zu verwenden. Richtige Zertifikate bekommt Ihr dank "Lets Encrypt" quasi für 0€.

Viel Spass beim testen. Bei Fragen benutzt bitte die Kommentare.

Ubuntu SSH Key erzeugen und mit Github und Gitlab verwenden

Um sich ohne Passwort zu authentifizieren benötigt man oft einen SSH Key (Public Key). Hier in diesem Artikel erkläre ich euch kurz wie Ihr diesen erzeugen und benutzen könnt. (Artikel ist für Ubuntu/Debian System gedacht).
Bei dem Public-Key-Verfahren wird eine asymmetrische Verschlüsselung genutzt um den Benutzer zu authentifizieren. Der (oder die) öffentliche(n) Schlüssel des Benutzers befindet sich dabei in der Datei ~/.ssh/authorized_keys des Zielsystems, der private Schlüssel in einer Datei (meist id_rsa) im Verzeichnis ~/.ssh auf dem lokalen System, wo er zusätzlich von einer "pass phrase" geschützt wird. Wenn man sich nun mit der Public-Key-Methode auf einem SSH-Server anmelden möchte, so schickt der Server dem Klienten eine zufällig generierte Challenge. Der Klient verschlüsselt diesen Datenblock mit seinem privaten Schlüssel, (wofür nötigenfalls die Passphrase abgefragt wird,) und wenn der Server diesen Chiffre mit dem zugehörigen öffentlichen Schlüssel wieder entschlüsseln kann, ist die Identität des Benutzers bestätigt. Quelle

SSH Key erzeugen

ssh-keygen -t rsa -b 4096 

Erzeugt eine ähnlich aussehende Ausgabe:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
24:55:ee:67:83:72:82:55:5f:b9:b4:09:2a:fa:56:a1 user@client.local
The key's randomart image is:
+--[ RSA 4096]----+
|                 |
|                 |
|                 |
|         +    .  |
|        S    E   |
|         .  + +  |
|          .o . o.|
|         o.oo. oo|
|          ==o.BO+|
+-----------------+

SSH Ordner

Der erstellte Key sollte nun in eurem SSH Ordner unter ... zu finden sein.

/home/user/.ssh/

SSH anzeigen und zu Github/Gitlab kopieren

Nun den Inhalt des Public Keys (.pub) in euren Github / Gitlab Account unter SSH Keys hinterlegen. Einfach den Inhalt der Datei mit dem Befehl cat ausgeben lassen und kopieren.

cat id_rsa.pub

Fertig :)

Du hast einen eigenen Root Server und möchtest diesen in mehrere vServer aufteilen? Und diese dann einfach Verwalten und Konfigurieren? Dann ist diese schöne Tutorial, welches ich auf Youtube gefunden habe genau das richtige für dich. Vielen Dank an BennetRichter98 für diesen ausführlichen Beitrag auf deutsch.