¿Cuál es la mejor manera de ejecutar Wordpress en el mismo dominio que una aplicación de Rails?

Question

Tengo una aplicación estándar de Rails con Nginx y Mongrel ejecutándose en http://mydomain. Necesito ejecutar un blog de Wordpress al http://mydomain.com/blog. Mi preferencia sería alojar el blog en Apache ejecutándose en el mismo servidor o en un cuadro separado, pero no quiero que el usuario vea un servidor diferente en la URL. Es eso posible y si no, ¿qué recomendarías para lograr el objetivo?

Answer 1

Creo que la solución de joelhardi es superior a la siguiente. Sin embargo, en mi propia aplicación, me gusta mantener el blog en un VPS separado del sitio Rails (separación de problemas de memoria). Para hacer que el usuario vea la misma URL, utiliza el mismo truco de proxy que normalmente usa para enviar a un clúster mongrel, excepto su proxy al puerto 80 (o lo que sea) en otro cuadro. Pan comido. Para el usuario es tan transparente como proxying para mestrel: solo "ve" que NGINX responde en el puerto 80 en su dominio.

upstream myBlogVPS { 
     server 127.0.0.2:80; #fix me to point to your blog VPS 
} 

server { 
    listen  80; 


    #You'll have plenty of things for Rails compatibility here 

    #Make sure you don't accidentally step on this with the Rails config! 

    location /blog { 
     proxy_pass   http://myBlogVPS; 
     proxy_redirect  off; 

     proxy_set_header Host    $host; 
     proxy_set_header X-Real-IP  $remote_addr; 
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
    } 

Puede utilizar este truco para que los rieles jueguen junto con CUALQUIER tecnología de servidor que desee, por cierto. Proxy directamente al servidor/puerto apropiado, y NGINX lo ocultará del mundo exterior. Además, dado que las URL se referirán al mismo dominio, puede integrar sin problemas un blog basado en PHP, un sistema de seguimiento basado en Python y la aplicación Rails, siempre que escriba sus URL correctamente.

Answer 2

Me parece que algo así como un manipulador de reescritura haría lo que quisiera. Lo siento, no tengo más detalles, solo pienso en voz alta :)

Answer 3

En realidad, ya que estás usando Nginx, ya estás en gran forma y no necesitas Apache.

Puede ejecutar PHP a través de fastcgi (hay ejemplos de cómo hacerlo in the Nginx wiki) y usa un patrón de correspondencia de URL en su configuración de Nginx para dirigir algunas URL a Rails y otras a PHP.

He aquí un ejemplo de configuración de Nginx para el funcionamiento de un blog de WordPress a través fastcgi PHP (tenga en cuenta que también he puesto en el equivalente Nginx del .htaccess WordPress, por lo que también tendrá URL de lujo que ya trabajan con esta configuración):

server { 
    listen  example.com:80; 
    server_name example.com; 
    charset  utf-8; 
    error_log /www/example.com/log/error.log; 
    access_log /www/example.com/log/access.log main; 
    root   /www/example.com/htdocs; 

    include /www/etc/nginx/fastcgi.conf; 
    fastcgi_index index.php; 

    # Send *.php to PHP FastCGI on :9001 
    location ~ \.php$ { 
     fastcgi_pass 127.0.0.1:9001; 
    } 

    # You could put another "location" section here to match some URLs and send 
    # them to Rails. Or do it the opposite way and have "/blog/*" go to PHP 
    # first and then everything else go to Rails. Whatever regexes you feel like 
    # putting into "location" sections! 

    location/{ 
     index index.html index.php; 
     # URLs that don't exist go to WordPress /index.php PHP FastCGI 
     if (!-e $request_filename) { 
      rewrite ^.* /index.php break; 
      fastcgi_pass 127.0.0.1:9001; 
     } 

    } 
} 

Aquí está el archivo fastcgi.conf que incluyo en la configuración anterior (lo puse en un archivo separado para que todos mis archivos de configuración de host virtual puedan incluirlo en el lugar correcto, pero no tiene que hacer esto):

# joelhardi fastcgi.conf, see http://wiki.codemongers.com/NginxFcgiExample for source 
fastcgi_param GATEWAY_INTERFACE CGI/1.1; 
fastcgi_param SERVER_SOFTWARE nginx; 

fastcgi_param QUERY_STRING  $query_string; 
fastcgi_param REQUEST_METHOD  $request_method; 
fastcgi_param CONTENT_TYPE  $content_type; 
fastcgi_param CONTENT_LENGTH  $content_length; 

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 
fastcgi_param SCRIPT_NAME  $fastcgi_script_name; 
fastcgi_param REQUEST_URI  $request_uri; 
fastcgi_param DOCUMENT_URI  $document_uri; 
fastcgi_param DOCUMENT_ROOT  $document_root; 
fastcgi_param SERVER_PROTOCOL $server_protocol; 

fastcgi_param REMOTE_ADDR  $remote_addr; 
fastcgi_param REMOTE_PORT  $remote_port; 
fastcgi_param SERVER_ADDR  $server_addr; 
fastcgi_param SERVER_PORT  $server_port; 
fastcgi_param SERVER_NAME  $server_name; 

# PHP only, required if PHP was built with --enable-force-cgi-redirect 
#fastcgi_param REDIRECT_STATUS 200; 

Yo también hago lo que t El wiki de Nginx sugiere, y usa spawn-fcgi de Lighttpd como mi CGI-spawner (Lighttpd es una compilación bastante rápida sin dependencias extrañas, por lo que es fácil de instalar), pero también puedes usar una shell corta/Perl guión para eso.

Answer 4

Las respuestas anteriores abordan su pregunta.

Un FCGI alternativo sería usar php-fpm. Los documentos son un poco escasos pero funciona bien.

Answer 5

Nginx ahora provides a script for doing this si se encuentra en el entorno EC2/AWS.

Puede ser fácilmente adaptable a su situación. Es bastante útil.