Comment configurer des hôtes virtuels dynamics en masse dans nginx?

Jouez avec nginx pendant environ une heure en essayant d’installer des hôtes virtuels dynamics en masse. Si vous l’avez déjà fait en apache, vous savez ce que je veux dire.

Le but est d’avoir des sous-domaines dynamics pour quelques personnes au bureau (plus de 50)

Vous aurez besoin de certaines connaissances de script pour mettre cela ensemble, j’utiliserais php, mais si vous êtes bon en script bash utilisez cela. Je le ferais comme ça:

  1. Commencez par créer un dossier ( /usr/local/etc/nginx/domain.com/ ).

  2. Dans la commande principale nginx.conf add: include /usr/local/etc/nginx/domain.com/*.conf;

  3. Tous les fichiers de ce dossier doivent avoir des noms de vhost différents sousdomain.conf.

Vous n’avez pas besoin de redémarrer nginx server pour que la configuration prenne des mesures, il vous suffit de la recharger: /usr/local/etc/rc.d/nginx reload

OU vous ne pouvez créer qu’un seul fichier conf, où tous les vhosts doivent être définis. C’est probablement mieux pour que nginx n’ait pas besoin de charger 50 fichiers, mais un seul ….

Si vous avez des problèmes avec les scripts, posez des questions à ce sujet …

Peut-être que cela vous amènera où vous voulez être:

server { root /sites/$http_host; server_name $http_host; ... } 

J’aime cela car je peux littéralement créer des sites à la volée, il suffit de créer un nouveau répertoire nommé d’après le domaine et de pointer le DNS vers l’IP du serveur.

Sur la base de la réponse de user2001260, édité ultérieurement par partlov, voici mon résultat.

Gardez à l’esprit que ceci est pour un serveur de développement situé sur une machine virtuelle locale, où le préfixe .dev est utilisé à la fin de chaque domaine. Si vous souhaitez le supprimer ou utiliser autre chose, la partie \.dev de la directive server_name peut être modifiée ou supprimée.

 server { listen 80 default_server; listen [::]:80 default_server; # Match any server name with the format [subdomain.[.subdomain...]].domain.tld.dev server_name ~^(?([\w-]+\.)*)?(?[\w-]+\.[\w-]+)\.dev$; # Map by default to (projects_root_path)/(domain.tld)/www; set $rootdir "/var/www/$domain/www"; # Check if a (projects_root_path)/(subdomain.)(domain.tld)/www directory exists if (-f "/var/www/$subdomain.$domain/www"){ # in which case, set that directory as the root set $rootdir "/var/www/$subdomain.$domain/www"; } root $rootdir; index index.php index.html index.htm index.nginx-debian.html; # Front-controller pattern as recommended by the nginx docs location / { try_files $uri $uri/ /index.php; } # Standard php-fpm based on the default config below this point location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php7.0-fpm.sock; } location ~ /\.ht { deny all; } 

}

L’expression régulière dans server_name capture le subdomaindomain et le domain variables. La partie subdomain est facultative et peut être vide. Je l’ai configuré pour que, par défaut, si vous avez un sous-domaine, disons admin.mysite.com la racine est définie sur la même racine que mysite.com . De cette façon, le même contrôleur frontal (dans mon cas, index.php ) peut être routé en fonction du sous-domaine. Mais si vous voulez conserver une application complètement différente dans un sous-domaine, vous pouvez avoir un admin.mysite.com et il utilisera ce répertoire pour les appels à admin.mysite.com .

Attention: l’utilisation de if est déconseillée dans la version actuelle de nginx, car elle ajoute une surcharge de traitement supplémentaire à chaque requête, mais elle devrait convenir à une utilisation dans un environnement de développement, ce à quoi cette configuration est destinée. Dans un environnement de production, je recommanderais de ne pas utiliser une configuration d’hôte virtuel de masse et de configurer chaque site séparément pour un meilleur contrôle et une meilleure sécurité.

Une autre solution consiste à inclure quelques niveaux afin que les répertoires puissent être classés comme bon vous semble. Par exemple:

 include sites-enabled/*.conf; include sites-enabled/*/*.conf; include sites-enabled/*/*/*.conf; include sites-enabled/*/*/*/*.conf; 
 server_name ~^(?[^.]*)\.domain\.com$; set $rootdir "/var/www/whatever/$vhost"; root $rootdir; 

Comme @Samuurai l’a suggéré, voici une version courte Angular 5 avec intégration de nginx build:

 server { server_name ~^(?.*)\.staging\.yourdomain\.com$; access_log /var/log/nginx/branch-access.log; error_log /var/log/nginx/branch-error.log; index index.html; try_files $uri$args $uri$args/ $uri $uri/ /index.html =404; root /usr/share/nginx/html/www/theft/$branch/dist; } 

Tant que vous êtes à l’aise avec les scripts, il n’est pas très difficile de mettre en place des scripts permettant de configurer rapidement des vhosts dans nginx. Cet article slicehost passe par la configuration de deux vhosts et le fait d’une manière facilement scriptable et garde les configurations séparées. Le seul inconvénient est de devoir redémarrer le serveur, mais il faut s’y attendre avec les modifications de configuration.


Mise à jour: Si vous ne voulez pas faire la configuration vous-même, vos deux seules options (les plus sûres de toute façon) seraient soit de trouver un programme permettant à vos utilisateurs de gérer leur propre partie de leur configuration nginx (qui leur permettra de créer tous les sous-domaines qu’ils souhaitent) ou de créer vous-même une telle console de gestion.

Faire cela vous-même ne serait pas trop difficile, surtout si vous avez déjà les scripts pour faire le travail de mise en place. L’interface Web peut appeler les scripts pour faire le travail réel, de sorte que toute l’interface Web doit gérer qui a access à quoi.