Existe-t-il une conf nginx commune pour les sites Drupal 7?

15

J'ai jeté un coup d'œil au référentiel Drupal-avec-nginx de Perusio et même si je pense que c'est impressionnant à quel point il est étendu, il peut être un peu trop avancé pour moi en ce moment, en plus j'ai plusieurs sites basés sur Symfony2 en direct sur le serveur et Je ne vais pas commencer à faire des changements importants avant d'avoir bien compris les configurations.

J'ai donc trouvé cela sur un blog et j'ai pensé que cela pourrait faire l'affaire. Y a-t-il des écueils courants avec le service de Drupal 7 sur Nginx? De plus, si la même installation Drupal devait alimenter plusieurs sites, la configuration serait-elle différente?

server {
    server_name example.org;
    root /home/me/sites/example.org;

    index index.html index.htm index.php;

    access_log /var/log/nginx/example.org.access.log;
    error_log /var/log/nginx/example.org.error.log;

    location = /favicon.ico {
            log_not_found off;
            access_log off;
    }

    location = /robots.txt {
            allow all;
            log_not_found off;
            access_log off;
    }

    # For drush
    location = /backup {
            deny all;
    }

    # Prevent user from accessing settings.php directly
    location ~ ^/sites/[^/]+/settings.php$ {
            deny all;
    }

    ## Replicate the Apache <FilesMatch> directive of Drupal standard
    ## .htaccess. Disable access to any code files. Return a 404 to curtail
    ## information disclosure. Hide also the text files.
    location ~* ^(?:.+\.(?:htaccess|make|txt|log|engine|inc|info|install|module|profile|po|sh|.*sql|theme|tpl(?:\.php)?|xtmpl)|code-style\.pl|/Entries.*|/Repository|/Root|/Tag|/Template)$ {
            return 404;
    }

    location ~ \..*/.*\.php$ {
            return 403;
    }

    location / {
            # This is cool because no php is touched for static content
            try_files $uri @rewrite;
    }

    location @rewrite {
            # Some modules enforce no slash (/) at the end of the URL
            # Else this rewrite block wouldn't be needed (GlobalRedirect)
            #rewrite ^/(.*)$ /index.php?q=$1&$args;
            rewrite ^ /index.php last;
    }

    # Use an SSH tunnel to access those pages. They shouldn't be visible to
    # external peeping eyes.
    location = /install.php {
            allow 127.0.0.1;
            deny all;
    }

    location = /update.php {
            allow 127.0.0.1;
            deny all;
    }

    location ~ \.php$ {
            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            #NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_intercept_errors on;
            fastcgi_pass unix:/var/run/php5-cgi/php5.sock;
    }

    ## Drupal 7 generated image handling, i.e., imagecache in core. See:
    ## https://drupal.org/node/371374
    location ~* /sites/.*/files/styles/ {
            access_log off;
            expires 30d;
            try_files $uri @rewrite;
    }

    # Fighting with ImageCache? This little gem is amazing.
    location ~ ^/sites/.*/files/imagecache/ {
            try_files $uri @rewrite;
    }

    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
            expires max;
            log_not_found off;
    }
}
Adam-E
la source
1
aucun piège que je sache. Cette configuration nginx traite déjà chaque répertoire / sites / * / multisite de manière discrète ...
tenken
@tenken nice. Je vais certainement l'essayer. La plupart des configurations que j'ai trouvées sur le net supposaient que nginx n'était pas installé ou qu'aucun site n'avait déjà été configuré, c'est pourquoi je suis un peu prudent. Merci
Adam-E

Réponses:

7

Le principal problème que Drupal 7 a avec nginx est que Drupal est conçu pour Apache, et de nombreux modules supposent qu'Apache est installé (et vous aurez toujours une petite entrée bleue sur votre "Rapport d'état" qui vous indique que vous ne pouvez pas utilisez Upload Progress car mod_php n'est pas installé - ennuyeux).

Cela dit, grâce à perusio et à d'autres, de nombreux modules ont été créés qui traitent davantage de nginx et exploitent bien ses fonctionnalités. Jusqu'à présent, je n'ai rencontré aucun problème avec nginx qui aurait été corrigé par Apache, et nginx est beaucoup plus rapide et a une empreinte beaucoup plus légère. Cela est démontré par de nombreux repères, mais c'est aussi mon expérience. Il a également une meilleure intégration avec php5-fpm, qui surpasse également mod_php.

Au fur et à mesure que Drupal se développe, il devient de plus en plus indépendant du backend. Vous pouvez le voir avec la couche d'abstraction de base de données de 7 qui permet plus de backends de base de données, et je suppose donc que les futures versions seront conçues avec d'autres serveurs Web à l'esprit.

Donc, je n'ai vu aucun piège. Il suffit de faire un peu plus attention à ce que font certains modules, ou du moins à ce qu'ils disent faire. S'ils mentionnent des fichiers .htaccess, assurez-vous que vous avez des entrées correspondantes dans vos fichiers nginx qui font la même chose. Je n'ai pas vu de cas où nginx échoue avec une configuration correcte.

La configuration nginx de Perusio est absolument incroyable, mais il faut un certain temps pour passer à travers tout cela et le comprendre. Vous devrez le personnaliser pour vous-même, et vous pourriez rencontrer des problèmes que vous devrez résoudre si vous utilisez des configurations non standard pour des choses comme imagecaching ou advagg ou d'autres. Il suppose également que vous utilisez plus d'un pool php-fpm. Vous devrez donc passer au travers et retirer ce qui n'est pas nécessaire. Mais cela vaut la peine de prendre le temps de tout parcourir, car vous en apprendrez beaucoup sur le fonctionnement de nginx.

J'ai également rencontré plusieurs erreurs avec mes sites nginx / drupal car j'ai tendance à utiliser php-fpm 5.4 ou 5.5. Les erreurs n'ont rien à voir avec nginx mais avec les fonctions Drupal elles-mêmes car Drupal est en train de terminer une transition vers l'exigence de php 5.3. Cependant, si vous examinez les files d'attente de problèmes, vous trouverez plusieurs correctifs et d'autres solutions pour corriger les modules qui fonctionnent avec les nouvelles versions de php.

À la fin de la journée, je recommanderais à tous ceux qui commencent avec un nouveau serveur d'utiliser nginx au lieu d'Apache. C'est juste mieux.

Shawn Patrick Rice
la source
4

J'ai lu que Nginx ne peut pas tout faire, c'est limité par rapport à Apache. "Apache a un module pour chaque tâche". Dans ma courte expérience, j'utilise Nginx depuis quelques mois avec Drupal et tout fonctionne bien. Si vous utilisez une installation multisite pour Drupal et Nginx, vous pouvez définir plusieurs noms de serveur sur la même configuration de serveur, mais vous ne pourrez pas avoir des journaux différents pour chaque site. J'utilise cette configuration sans (presque) aucun problème: https://www.nginx.com/resources/wiki/start/topics/recipes/drupal/

Beto Aveiga
la source
4
Apache est comme Microsoft Word, il a un million d'options mais vous n'en avez besoin que de six. Nginx fait ces six choses, et il en fait cinq 50 fois plus vite qu'Apache. - Chris Lea sur nginx et Wordpress
SGhosh
2

Je suis entièrement d'accord avec vous que la configuration nginx de Perusio pour Drupal est impressionnante, mais peut-être exagérée pour une instance locale de nginx. J'ai trouvé que le fichier de configuration nginx de Mulkave sur GitHub était la configuration la plus pratique et la plus légère pour exécuter Drupal 7 sur nginx.

pxwise
la source
0
server {

    listen *:80;

    access_log /var/log/nginx/test.access.log;
    error_log /var/log/nginx/test.error.log;

    root /srv/test;
    index index.html index.htm index.php;

    # Enable compression, this will help if you have for instance advagg‎ module
    # by serving Gzip versions of the files.
    gzip_static on;

    location = /favicon.ico {
        log_not_found off;
        access_log off;
    }

    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    # This matters if you use drush prior to 5.x
    # After 5.x backups are stored outside the Drupal install.
    #location = /backup {
    #        deny all;
    #}

    # Very rarely should these ever be accessed outside of your lan
    location ~* \.(txt|log)$ {
        allow 192.168.0.0/16;
        deny all;
    }

    location ~ \..*/.*\.php$ {
        return 403;
    }

    # No no for private
    location ~ ^/sites/.*/private/ {
        return 403;
    }

    # Block access to "hidden" files and directories whose names begin with a
    # period. This includes directories used by version control systems such
    # as Subversion or Git to store control files.
    location ~ (^|/)\. {
        return 403;
    }

    location / {
        # This is cool because no php is touched for static content
        try_files $uri @rewrite;
    }

    location @rewrite {
        # You have 2 options here
        # For D7 and above:
        # Clean URLs are handled in drupal_environment_initialize().
        rewrite ^ /index.php last;
        # For Drupal 6 and bwlow:
        # Some modules enforce no slash (/) at the end of the URL
        # Else this rewrite block wouldn't be needed (GlobalRedirect)
        #rewrite ^/(.*)$ /index.php?q=$1;
    }

    # Fighting with Styles? This little gem is amazing.
    # This is for D6
    #location ~ ^/sites/.*/files/imagecache/ {
    # This is for D7 and D8
    location ~* files/styles {
        access_log off;
        expires 30d;
        try_files $uri @rewrite;
    }

    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
        expires max;
        log_not_found off;
    }

    location ~ [^/]\.php(/|$) {
        fastcgi_index index.php;
        include fcgi.conf;
        fastcgi_pass unix:/var/run/ajenti-v-php-fcgi-test-php-fcgi-0.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}
maestro888
la source