Elke site in Vimonto Deploy heeft een eigen Nginx-configuratie: één bestand met de server blocks voor de domeinen, HTTPS en de applicatie. Vimonto Deploy schrijft dit bestand voor je en houdt het bij als je domeinen, certificaten of instellingen wijzigt.
De pagina Nginx van een site toont de configuratie en laat je die aanpassen. Elke wijziging wordt met nginx -t getest voordat ze live gaat; keurt Nginx haar af, dan blijft de vorige configuratie actief. Je vindt de pagina in de zijbalk van de site onder Nginx.
Waar staat de configuratie op de server?
| Pad | Wat het is |
|---|---|
/etc/nginx/sites-available/site-{id} |
De configuratie van de site. {id} is het nummer van de site in Vimonto Deploy; het pad staat bovenaan de pagina. |
/etc/nginx/sites-enabled/site-{id} |
Een symlink naar het bestand hierboven, waardoor Nginx het laadt. |
/etc/nginx/vimonto-conf/site-{id}/*.conf |
Extra directives, geladen binnen het server block van de site. |
/var/log/nginx/site-{id}-access.log en -error.log |
De request- en foutlogs van de site, te lezen op de pagina Logs. |
Pas deze bestanden niet met de hand aan op de server: de volgende keer dat Vimonto Deploy de configuratie schrijft, worden je wijzigingen overschreven. Pas de configuratie aan op de Nginx-pagina, of zet extra directives in de include-map.
Wat staat er in de gegenereerde configuratie?
De gegenereerde configuratie hangt af van de domeinen, het certificaat en het type van de site.
- Domeinen. De site wordt geserveerd op haar eigen domeinen en haar gegenereerde adres. De www-instelling van elk domein wordt een redirect block, bijvoorbeeld van
www.example.comnaarexample.com. Zie domeinen en SSL. - HTTPS. Met een actief certificaat beantwoordt poort 80 alleen Let's Encrypt-challenges en stuurt al het andere door naar HTTPS. Het HTTPS-block luistert op poort 443 met HTTP/2 (
listen 443 ssl http2;, wat werkt op de Nginx van elke ondersteunde Ubuntu-versie), TLS 1.2 en 1.3, een gedeelde TLS-sessiecache en een HSTS-header (max-age=31536000). - Webroot.
rootwijst naar de webmap van de site in de live release, bijvoorbeeld/home/vimonto/example.com/current/public. - Logs. Elke site schrijft een eigen access- en errorlog.
- Include. De include-map voor extra directives wordt binnen het server block geladen.
- Applicatie. Hangt af van het sitetype:
| Sitetype | Wat de configuratie doet |
|---|---|
| Laravel en PHP | Stuurt requests die niet bij een bestand horen naar index.php en geeft PHP via een Unix-socket door aan PHP-FPM. Laravel-sites sturen ook 404-fouten naar index.php. |
| Statisch | Serveert bestanden en probeert $uri, $uri/ en $uri.html, anders een 404. |
| Node.js | Stuurt elk request door naar je app op 127.0.0.1 en de poort die je instelt, met WebSocket-ondersteuning en X-Forwarded-*-headers. |
| Load balancer | Stuurt elk request door naar de app-servers in een upstream-block, of antwoordt 503 zolang er geen zijn. Zie load balancing. |
- Beveiliging. Verborgen bestanden zoals
.enven.gitworden geweigerd, behalve/.well-known. Requests voorfavicon.icoenrobots.txtworden niet gelogd. - Achter een load balancer. Op een app-server achter een van je load balancers vertrouwt de site die balancer, en alleen die, voor het IP-adres van de bezoeker (
set_real_ip_from) en voor HTTPS (X-Forwarded-Proto). Heeft een site daar een eigen certificaat, dan serveert hij de balancer ook over gewone HTTP in plaats van hem door te sturen naar HTTPS, zodat de twee elkaar niet in een kringetje rondsturen; alle anderen krijgen nog steeds de doorverwijzing.
Een ingekort voorbeeld voor een Laravel-site met 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;
}
}
Door $realpath_root ziet PHP de echte releasemap in plaats van de symlink current, zodat een nieuwe release wordt gebruikt zodra die live gaat. Een geïsoleerde site gebruikt een eigen PHP-FPM-socket, /run/php/site-{id}.sock.
Extra directives toevoegen zonder de configuratie te vervangen
Voor de meeste wijzigingen hoef je de configuratie zelf niet aan te passen. Zet een .conf-bestand in de include-map van de site, /etc/nginx/vimonto-conf/site-{id}/. Nginx laadt elk .conf-bestand daarin binnen het hoofd-server block van de site, en de map blijft bewaard wanneer Vimonto Deploy de configuratie opnieuw schrijft.
Om bijvoorbeeld security-headers toe te voegen, maak je in de terminal het bestand /etc/nginx/vimonto-conf/site-12/headers.conf aan:
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
Test en herlaad Nginx daarna met sudo nginx -t && sudo systemctl reload nginx, of klik bij Nginx op Herladen op de pagina Services van de server.
Sitefuncties gebruiken dezelfde map: Wachtwoordbeveiliging, Reverb en WordPress-Beveiliging schrijven daar elk een eigen bestand feature-{key}.conf.
De configuratie aanpassen
- Open de site en kies Nginx in de zijbalk.
- Wijzig de configuratie in de editor.
- Klik op Testen en opslaan, of druk op Cmd+S (Ctrl+S op Windows en Linux).
Opslaan draait als achtergrondtaak met de naam Nginx-configuratie van je domein opslaan:
- Vimonto Deploy bewaart een kopie van de huidige configuratie en schrijft de jouwe.
- Het voert
nginx -tuit om de hele Nginx-configuratie te testen. - Slaagt de test, dan wordt Nginx herladen en wordt je configuratie opgeslagen.
- Mislukt de test, dan wordt de vorige configuratie teruggezet, draait Nginx ongewijzigd door en mislukt de taak met Nginx keurde de configuratie af; de vorige is nog actief. De uitvoer van de taak toont de fout van
nginx -t.
Een typfout kan de andere sites op de server dus nooit platleggen.
Wat verandert er als je je eigen configuratie gebruikt?
Zodra je een eigen configuratie hebt opgeslagen, toont de pagina Eigen configuratie. Vanaf dan schrijft Vimonto Deploy de configuratie niet meer voor je, en beheer je deze zaken zelf:
- domeinen en aliassen, en de www-redirect;
- HTTPS: als je een certificaat installeert, vertelt de taak je welke certificaatpaden je zelf moet toevoegen;
- de webmap, de PHP-versie (de PHP-FPM-socket) en de poort van een Node.js-app, als je die wijzigt in de site-instellingen;
- bij een load-balanced site de app-servers en de methode: wijzigingen op de pagina Load balancing worden opgeslagen maar niet toegepast, tot je de standaardconfiguratie terugzet;
- bij een site achter een load balancer de regels die de balancer vertrouwen.
Houd de regel include /etc/nginx/vimonto-conf/site-{id}/*.conf; in je configuratie. Zonder die regel kunnen de sitefuncties die Nginx-directives toevoegen niet worden aangezet.
De gegenereerde configuratie terugzetten
Klik op Standaard herstellen en bevestig. Je eigen wijzigingen gaan verloren, de gegenereerde configuratie wordt op dezelfde manier geschreven en getest, en Vimonto Deploy beheert de domeinen en HTTPS weer voor je.
Wie kan de configuratie aanpassen?
Elk lid kan de configuratie lezen. Opslaan en herstellen vereisen het recht om sites te beheren (eigenaar, beheerder, manager en developer), en de site en server moeten actief zijn; anders is de editor alleen-lezen. Zie leden en rollen.
Veelgestelde vragen
Hoe verhoog ik de uploadlimiet van mijn Laravel-site?
Wijzig de maximale uploadgrootte op de pagina PHP van de server. Die stelt de uploadlimieten van PHP en client_max_body_size van Nginx in voor de hele server (standaard 64 MB), dus je hoeft de configuratie van de site niet aan te passen.
Hoe voeg ik headers of redirects toe?
Gebruik de include-map voor headers (add_header) en eenvoudige redirects (location = /old { return 301 /new; }). Voor wijzigingen buiten het server block, zoals een nieuw server-block, pas je de configuratie aan op de Nginx-pagina.
Waarom is mijn wijziging niet live gegaan?
Open de taak in de activiteit van de server of op de activiteitenpagina en lees de uitvoer van nginx -t. Die noemt het bestand en de regel die Nginx afkeurde.
Kan ik de configuratie van elke site op een server zien?
De configuratie van elke site staat op haar eigen Nginx-pagina. Alle bestanden staan op de server in /etc/nginx/sites-available.