¿Existe una configuración nginx común para los sitios de Drupal 7?

Pregunta:

He echado un vistazo al repositorio drupal-with-nginx de Perusio y, aunque creo que es impresionante lo extenso que es, puede que sea demasiado avanzado para mí en este momento, además tengo varios sitios basados ​​en Symfony2 en vivo en el servidor y No debo comenzar a hacer cambios significativos hasta que entienda completamente las configuraciones.

Así que encontré esto en un blog y pensé que podría funcionar. ¿Existen errores comunes al servir drupal 7 sobre nginx? Además, si la misma instalación de Drupal alimentara más de un sitio, ¿la configuración sería diferente?

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;
    }
}

Respuesta:

El principal problema que tiene Drupal 7 con nginx es que Drupal está diseñado para Apache, y muchos módulos asumen que Apache está instalado (y siempre tendrá una pequeña entrada azul en su "Informe de estado" que le indica que no puede use Upload Progress porque mod_php no está instalado (molesto).

Dicho esto, gracias a perusio y otros, se han creado muchos módulos que tratan más con nginx y aprovechan bien su funcionalidad. Hasta ahora, no me he encontrado con ningún problema con nginx que hubiera sido solucionado por Apache, y nginx es mucho más rápido y tiene una huella mucho más ligera. Esto lo demuestran muchos puntos de referencia, pero también es mi experiencia. También tiene una mejor integración con php5-fpm, que también supera a mod_php.

A medida que Drupal se desarrolla, se vuelve más agnóstico al backend. Puede ver esto con la capa de abstracción de la base de datos de 7 que permite más backends de base de datos, por lo que supongo que las versiones futuras se diseñarán teniendo en cuenta otros servidores web.

Entonces, no hay trampas que haya visto en absoluto. Solo debes prestar un poco más de atención a lo que hacen algunos de los módulos, o al menos a lo que dicen que hacen. Si mencionan archivos .htaccess, asegúrese de tener las entradas correspondientes en sus archivos nginx que hagan lo mismo. En realidad, no he visto un caso en el que nginx falle con una configuración adecuada.

La configuración de nginx de Perusio es absolutamente asombrosa, pero lleva bastante tiempo analizarla y comprenderla. Necesitará personalizarlo usted mismo, y es posible que tenga algunos problemas que deberá solucionar si usa configuraciones no estándar para cosas como el almacenamiento en caché de imágenes o advagg u otras. También asume que estás usando más de un grupo php-fpm. Por lo tanto, deberá revisar y extraer lo que no se necesita. Pero vale la pena tomarse el tiempo para repasarlo todo porque aprenderá mucho sobre cómo funciona nginx.

También me encontré con varios errores con mis sitios nginx / drupal porque tengo una tendencia a usar php-fpm 5.4 o 5.5. Los errores no tienen nada que ver con nginx, sino con las funciones de Drupal en sí mismas, ya que Drupal realmente está terminando una transición para requerir php 5.3. Sin embargo, si observa las colas de problemas, encontrará varios parches y otras soluciones para arreglar módulos para que funcionen con versiones más nuevas de php.

Al final del día, recomendaría que cualquiera que esté comenzando con un servidor nuevo use nginx en lugar de Apache. Es simplemente mejor.