Jede Site in Vimonto Deploy hat ihre eigene Nginx-Konfiguration: eine Datei mit den Server-Blöcken für ihre Domains, HTTPS und die Anwendung. Vimonto Deploy schreibt diese Datei für dich und hält sie aktuell, wenn du Domains, Zertifikate oder Einstellungen änderst.
Die Seite Nginx einer Site zeigt die Konfiguration und lässt dich sie bearbeiten. Jede Änderung wird mit nginx -t getestet, bevor sie live geht; lehnt Nginx sie ab, bleibt die vorherige Konfiguration aktiv. Du findest die Seite in der Seitenleiste der Site unter Nginx.
Wo liegt die Konfiguration auf dem Server?
| Pfad | Was es ist |
|---|---|
/etc/nginx/sites-available/site-{id} |
Die Konfiguration der Site. {id} ist die Nummer der Site in Vimonto Deploy; der Pfad steht oben auf der Seite. |
/etc/nginx/sites-enabled/site-{id} |
Ein Symlink auf die obige Datei, durch den Nginx sie lädt. |
/etc/nginx/vimonto-conf/site-{id}/*.conf |
Zusätzliche Direktiven, die im Server-Block der Site geladen werden. |
/var/log/nginx/site-{id}-access.log und -error.log |
Die Request- und Fehler-Logs der Site, lesbar auf der Seite Logs. |
Bearbeite diese Dateien nicht von Hand auf dem Server: Wenn Vimonto Deploy die Konfiguration das nächste Mal schreibt, werden deine Änderungen überschrieben. Bearbeite die Konfiguration auf der Seite Nginx oder lege zusätzliche Direktiven im Include-Ordner ab.
Was steht in der generierten Konfiguration?
Die generierte Konfiguration hängt von den Domains der Site, ihrem Zertifikat und ihrem Typ ab.
- Domains. Die Site wird unter ihren eigenen Domains und ihrer generierten Adresse ausgeliefert. Die www-Einstellung jeder Domain wird zu einem Weiterleitungsblock, zum Beispiel von
www.example.comaufexample.com. Siehe Domains und SSL. - HTTPS. Mit einem aktiven Zertifikat beantwortet Port 80 nur noch Let's-Encrypt-Challenges und leitet alles andere auf HTTPS weiter. Der HTTPS-Block lauscht auf Port 443 mit HTTP/2 (
listen 443 ssl http2;, was mit dem Nginx jeder unterstützten Ubuntu-Version funktioniert), TLS 1.2 und 1.3, einem gemeinsamen TLS-Session-Cache und einem HSTS-Header (max-age=31536000). - Web-Root.
rootzeigt auf das Web-Verzeichnis der Site im Live-Release, zum Beispiel/home/vimonto/example.com/current/public. - Logs. Jede Site schreibt ihr eigenes Access- und Error-Log.
- Include. Der Include-Ordner für zusätzliche Direktiven wird im Server-Block geladen.
- Anwendung. Hängt vom Typ der Site ab:
| Site-Typ | Was die Konfiguration tut |
|---|---|
| Laravel und PHP | Schickt Requests, die zu keiner Datei passen, an index.php und übergibt PHP über einen Unix-Socket an PHP-FPM. Laravel-Sites schicken auch 404-Fehler an index.php. |
| Statisch | Liefert Dateien aus und versucht $uri, $uri/ und $uri.html, sonst ein 404. |
| Node.js | Leitet jeden Request per Proxy an deine App auf 127.0.0.1 und dem eingestellten Port weiter, mit WebSocket-Unterstützung und X-Forwarded-*-Headern. |
| Load Balancer | Leitet jeden Request per Proxy an die App-Server in einem upstream-Block weiter oder antwortet mit 503, solange es keine gibt. Siehe Lastverteilung. |
- Schutz. Versteckte Dateien wie
.envund.gitwerden blockiert, außer/.well-known. Requests auffavicon.icoundrobots.txtwerden nicht geloggt. - Hinter einem Load Balancer. Auf einem App-Server hinter einem deiner Load Balancer vertraut die Site diesem Balancer, und nur ihm, für die IP-Adresse des Besuchers (
set_real_ip_from) und für HTTPS (X-Forwarded-Proto). Hat eine Site dort ein eigenes Zertifikat, liefert sie dem Balancer außerdem über einfaches HTTP aus, statt ihn auf HTTPS umzuleiten, damit sich die beiden nicht gegenseitig im Kreis schicken; alle anderen werden weiterhin umgeleitet.
Ein gekürztes Beispiel für eine Laravel-Site mit HTTPS:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/certificate-3/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/certificate-3/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:VimontoSSL:10m;
add_header Strict-Transport-Security "max-age=31536000" always;
root /home/vimonto/example.com/current/public;
index index.html index.htm index.php;
charset utf-8;
access_log /var/log/nginx/site-12-access.log;
error_log /var/log/nginx/site-12-error.log error;
# Extra directives for this site, kept when the config is written again.
include /etc/nginx/vimonto-conf/site-12/*.conf;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
error_page 404 /index.php;
location ~ \.php$ {
fastcgi_pass unix:/run/php/php8.4-fpm.sock;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT $realpath_root;
include fastcgi_params;
fastcgi_hide_header X-Powered-By;
fastcgi_read_timeout 120;
}
location ~ /\.(?!well-known).* {
deny all;
}
}
Durch $realpath_root sieht PHP das echte Release-Verzeichnis statt des Symlinks current, sodass ein neues Release verwendet wird, sobald es live geht. Eine isolierte Site nutzt ihren eigenen PHP-FPM-Socket, /run/php/site-{id}.sock.
Zusätzliche Direktiven hinzufügen, ohne die Konfiguration zu ersetzen
Für die meisten Änderungen musst du die Konfiguration selbst nicht bearbeiten. Lege eine .conf-Datei im Include-Ordner der Site ab, /etc/nginx/vimonto-conf/site-{id}/. Nginx lädt jede .conf-Datei dort im Haupt-Server-Block der Site, und der Ordner bleibt erhalten, wann immer Vimonto Deploy die Konfiguration neu schreibt.
Um zum Beispiel Sicherheits-Header hinzuzufügen, legst du im Terminal die Datei /etc/nginx/vimonto-conf/site-12/headers.conf an:
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
Teste und lade Nginx danach mit sudo nginx -t && sudo systemctl reload nginx neu, oder klicke auf der Seite Services des Servers bei Nginx auf Neu laden.
Site-Features nutzen denselben Ordner: Passwortschutz, Reverb und die WordPress-Härtung schreiben dort jeweils ihre eigene Datei feature-{key}.conf.
Die Konfiguration bearbeiten
- Öffne die Site und wähle in der Seitenleiste Nginx.
- Ändere die Konfiguration im Editor.
- Klicke auf Testen und speichern oder drücke Cmd+S (Strg+S unter Windows und Linux).
Das Speichern läuft als Hintergrundaufgabe mit dem Namen Nginx-Konfiguration von deiner Domain speichern:
- Vimonto Deploy behält eine Kopie der aktuellen Konfiguration und schreibt deine.
- Es führt
nginx -taus, um die gesamte Nginx-Konfiguration zu testen. - Besteht der Test, wird Nginx neu geladen und deine Konfiguration gespeichert.
- Schlägt der Test fehl, wird die vorherige Konfiguration zurückgespielt, Nginx läuft unverändert weiter, und die Aufgabe schlägt fehl mit Nginx hat die Konfiguration abgelehnt; die vorherige ist noch aktiv. Die Ausgabe der Aufgabe zeigt den Fehler von
nginx -t.
Ein Tippfehler kann die anderen Sites des Servers also nie lahmlegen.
Was ändert sich, wenn du deine eigene Konfiguration verwendest?
Sobald du eine eigene Konfiguration gespeichert hast, zeigt die Seite Eigene Konfiguration. Ab dann schreibt Vimonto Deploy die Konfiguration nicht mehr für dich, und du verwaltest Folgendes selbst:
- Domains und Aliasse sowie die www-Weiterleitung;
- HTTPS: Wenn du ein Zertifikat installierst, nennt dir die Aufgabe die Zertifikatspfade, die du selbst ergänzen musst;
- das Web-Verzeichnis, die PHP-Version (den PHP-FPM-Socket) und den Port einer Node.js-App, wenn du sie in den Site-Einstellungen änderst;
- bei einer lastverteilten Site die App-Server und die Methode: Änderungen auf der Seite Lastverteilung werden gespeichert, aber nicht angewendet, bis du die Standardkonfiguration wiederherstellst;
- bei einer Site hinter einem Load Balancer die Zeilen, die dem Balancer vertrauen.
Behalte die Zeile include /etc/nginx/vimonto-conf/site-{id}/*.conf; in deiner Konfiguration. Ohne sie lassen sich die Site-Features, die Nginx-Direktiven hinzufügen, nicht einschalten.
Die generierte Konfiguration wiederherstellen
Klicke auf Standard wiederherstellen und bestätige. Deine eigenen Änderungen gehen verloren, die generierte Konfiguration wird auf dieselbe Weise geschrieben und getestet, und Vimonto Deploy verwaltet Domains und HTTPS wieder für dich.
Wer kann die Konfiguration bearbeiten?
Jedes Mitglied kann die Konfiguration lesen. Speichern und Wiederherstellen erfordern die Berechtigung, Sites zu verwalten (Owner, Administrator, Manager und Developer), und Site und Server müssen aktiv sein; andernfalls ist der Editor schreibgeschützt. Siehe Mitglieder und Rollen.
Häufig gestellte Fragen
Wie erhöhe ich die Upload-Größe für meine Laravel-Site?
Ändere die maximale Upload-Größe auf der Seite PHP des Servers. Sie setzt die Upload-Limits von PHP und Nginx' client_max_body_size für den ganzen Server (standardmäßig 64 MB), du musst also die Konfiguration der Site nicht bearbeiten.
Wie füge ich Header oder Weiterleitungen hinzu?
Nutze den Include-Ordner für Header (add_header) und einfache Weiterleitungen (location = /old { return 301 /new; }). Für Änderungen außerhalb des Server-Blocks, etwa einen neuen server-Block, bearbeitest du die Konfiguration auf der Seite Nginx.
Warum ist meine Änderung nicht live gegangen?
Öffne die Aufgabe in der Aktivität des Servers oder auf der Seite Aktivität und lies die Ausgabe von nginx -t. Sie nennt die Datei und die Zeile, die Nginx abgelehnt hat.
Kann ich die Konfiguration aller Sites eines Servers sehen?
Die Konfiguration jeder Site steht auf ihrer eigenen Seite Nginx. Alle Dateien liegen auf dem Server in /etc/nginx/sites-available.