Chaque site dans Vimonto Deploy a sa propre configuration Nginx : un fichier avec les server blocks de ses domaines, de HTTPS et de l'application. Vimonto Deploy écrit ce fichier pour vous et le tient à jour quand vous modifiez les domaines, les certificats ou les réglages.
La page Nginx d'un site affiche la configuration et vous permet de la modifier. Chaque modification est testée avec nginx -t avant d'être mise en ligne ; si Nginx la rejette, la configuration précédente reste active. Vous trouvez la page dans la barre latérale du site sous Nginx.
Où se trouve la configuration sur le serveur ?
| Chemin | Ce que c'est |
|---|---|
/etc/nginx/sites-available/site-{id} |
La configuration du site. {id} est le numéro du site dans Vimonto Deploy ; le chemin est affiché en haut de la page. |
/etc/nginx/sites-enabled/site-{id} |
Un lien symbolique vers le fichier ci-dessus, qui fait charger le fichier par Nginx. |
/etc/nginx/vimonto-conf/site-{id}/*.conf |
Des directives supplémentaires, chargées dans le server block du site. |
/var/log/nginx/site-{id}-access.log et -error.log |
Les logs de requêtes et d'erreurs du site, consultables sur la page Logs. |
Ne modifiez pas ces fichiers à la main sur le serveur : la prochaine fois que Vimonto Deploy écrira la configuration, vos modifications seront écrasées. Modifiez la configuration sur la page Nginx, ou placez des directives supplémentaires dans le dossier d'include.
Que contient la configuration générée ?
La configuration générée dépend des domaines du site, de son certificat et de son type.
- Domaines. Le site est servi sur ses propres domaines et sur son adresse générée. Le réglage www de chaque domaine devient un bloc de redirection, par exemple de
www.example.comversexample.com. Consultez domaines et SSL. - HTTPS. Avec un certificat actif, le port 80 ne répond qu'aux challenges Let's Encrypt et redirige tout le reste vers HTTPS. Le bloc HTTPS écoute sur le port 443 avec HTTP/2 (
listen 443 ssl http2;, qui fonctionne avec le Nginx de chaque version d'Ubuntu prise en charge), TLS 1.2 et 1.3, un cache de sessions TLS partagé et un en-tête HSTS (max-age=31536000). - Racine web.
rootpointe vers le répertoire web du site dans la release en ligne, par exemple/home/vimonto/example.com/current/public. - Logs. Chaque site écrit ses propres logs d'accès et d'erreurs.
- Include. Le dossier d'include des directives supplémentaires est chargé dans le server block.
- Application. Dépend du type de site :
| Type de site | Ce que fait la configuration |
|---|---|
| Laravel et PHP | Envoie les requêtes qui ne correspondent à aucun fichier vers index.php et transmet le PHP à PHP-FPM via un socket Unix. Les sites Laravel envoient aussi les erreurs 404 vers index.php. |
| Statique | Sert les fichiers en essayant $uri, $uri/ et $uri.html, sinon une 404. |
| Node.js | Transmet chaque requête à votre application sur 127.0.0.1 et le port défini, avec la prise en charge des WebSockets et les en-têtes X-Forwarded-*. |
| Load balancer | Transmet chaque requête aux serveurs d'application d'un bloc upstream, ou répond 503 tant qu'il n'y en a aucun. Consultez répartition de charge. |
- Protection. Les fichiers cachés comme
.envet.gitsont refusés, sauf/.well-known. Les requêtes versfavicon.icoetrobots.txtne sont pas journalisées. - Derrière un load balancer. Sur un serveur d'application placé derrière l'un de vos load balancers, le site fait confiance à ce load balancer, et à lui seul, pour l'adresse IP du visiteur (
set_real_ip_from) et pour HTTPS (X-Forwarded-Proto). Un site qui y a son propre certificat sert aussi le load balancer en HTTP simple au lieu de le rediriger vers HTTPS, pour que les deux ne se renvoient pas la balle en boucle ; tous les autres sont toujours redirigés.
Un exemple abrégé pour un site Laravel avec 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;
}
}
$realpath_root fait voir à PHP le vrai répertoire de la release au lieu du lien symbolique current : une nouvelle release est donc utilisée dès sa mise en ligne. Un site isolé utilise son propre socket PHP-FPM, /run/php/site-{id}.sock.
Ajouter des directives sans remplacer la configuration
Pour la plupart des modifications, vous n'avez pas besoin de modifier la configuration elle-même. Placez un fichier .conf dans le dossier d'include du site, /etc/nginx/vimonto-conf/site-{id}/. Nginx charge chaque fichier .conf de ce dossier dans le server block principal du site, et le dossier est conservé chaque fois que Vimonto Deploy réécrit la configuration.
Par exemple, pour ajouter des en-têtes de sécurité, créez /etc/nginx/vimonto-conf/site-12/headers.conf dans le terminal :
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
Testez ensuite et rechargez Nginx avec sudo nginx -t && sudo systemctl reload nginx, ou cliquez sur Recharger pour Nginx sur la page Services du serveur.
Les fonctionnalités de site utilisent le même dossier : Protection par mot de passe, Reverb et le Durcissement WordPress y écrivent chacun leur propre fichier feature-{key}.conf.
Modifier la configuration
- Ouvrez le site et choisissez Nginx dans la barre latérale.
- Modifiez la configuration dans l'éditeur.
- Cliquez sur Tester et enregistrer, ou appuyez sur Cmd+S (Ctrl+S sous Windows et Linux).
L'enregistrement s'exécute sous forme de tâche en arrière-plan nommée Enregistrement de la configuration Nginx de suivi de votre domaine :
- Vimonto Deploy conserve une copie de la configuration actuelle et écrit la vôtre.
- Il exécute
nginx -tpour tester toute la configuration Nginx. - Si le test réussit, Nginx est rechargé et votre configuration est enregistrée.
- Si le test échoue, la configuration précédente est remise en place, Nginx continue de tourner sans changement, et la tâche échoue avec Nginx a rejeté la configuration ; la précédente est toujours active. La sortie de la tâche affiche l'erreur de
nginx -t.
Une faute de frappe ne peut donc jamais mettre hors ligne les autres sites du serveur.
Qu'est-ce qui change quand vous utilisez votre propre configuration ?
Une fois votre propre configuration enregistrée, la page affiche Configuration personnalisée. Dès lors, Vimonto Deploy n'écrit plus la configuration pour vous, et vous gérez vous-même :
- les domaines et alias, ainsi que la redirection www ;
- HTTPS : quand vous installez un certificat, la tâche vous indique les chemins du certificat à ajouter vous-même ;
- le répertoire web, la version de PHP (le socket PHP-FPM) et le port d'une application Node.js, quand vous les modifiez dans les paramètres du site ;
- pour un site à charge répartie, les serveurs d'application et la méthode : les modifications faites sur la page Répartition de charge sont enregistrées mais pas appliquées, jusqu'à ce que vous restauriez la configuration par défaut ;
- pour un site derrière un load balancer, les lignes qui font confiance au load balancer.
Gardez la ligne include /etc/nginx/vimonto-conf/site-{id}/*.conf; dans votre configuration. Sans elle, les fonctionnalités de site qui ajoutent des directives Nginx ne peuvent pas être activées.
Restaurer la configuration générée
Cliquez sur Restaurer la configuration par défaut et confirmez. Vos propres modifications sont perdues, la configuration générée est écrite et testée de la même façon, et Vimonto Deploy gère de nouveau les domaines et HTTPS pour vous.
Qui peut modifier la configuration ?
Chaque membre peut lire la configuration. Enregistrer et restaurer nécessitent la permission de gérer les sites (propriétaire, administrateur, manager et développeur), et le site et le serveur doivent être actifs ; sinon, l'éditeur est en lecture seule. Consultez membres et rôles.
Questions fréquentes
Comment augmenter la taille d'upload de mon site Laravel ?
Modifiez la taille d'upload maximale sur la page PHP du serveur. Elle définit les limites d'upload de PHP et le client_max_body_size de Nginx pour tout le serveur (64 Mo par défaut) : vous n'avez donc pas besoin de modifier la configuration du site.
Comment ajouter des en-têtes ou des redirections ?
Utilisez le dossier d'include pour les en-têtes (add_header) et les redirections simples (location = /old { return 301 /new; }). Pour les modifications hors du server block, comme un nouveau bloc server, modifiez la configuration sur la page Nginx.
Pourquoi ma modification n'a-t-elle pas été mise en ligne ?
Ouvrez la tâche dans l'activité du serveur ou sur la page Activité et lisez la sortie de nginx -t. Elle indique le fichier et la ligne que Nginx a rejetés.
Puis-je voir la configuration de chaque site d'un serveur ?
La configuration de chaque site se trouve sur sa propre page Nginx. Tous les fichiers sont dans /etc/nginx/sites-available sur le serveur.