Migrar de Apache/PHP a Nginx/PHP en CentOS

24 febrero 2015 at 12:49 by Adrián Pérez

nginx2Si contamos con un servidor Apache, quizá nos interese pasarlo a nginx con el menor downtime posible. Yo he hecho alguna prueba partiendo del siguiente entorno:

  • CentOS release 6.6
  • Apache/2.2.15 sin módulos adicionales
  • VirtualHosts para un proyecto PHP 5.3.3

Lo que haremos con nginx es instalarlo y configurarlo de forma muy básica en un puerto diferente y posteriormente una vez esté todo bien, cambiar puertos de escucha.

ATENCIÓN: Si estás pensando en migrar de Apache a Nginx, en producción, ten en cuenta que dependiendo de tu entorno, deberás hacerlo de una u otra manera. No es lo mismo migrar un proyecto python que sirve Apache via mod_wsgi, que un proyecto PHP que ni si quiera usa mod_rewrite (como en este ejemplo). Este post, por tanto, te puede servir de punto de partida, pero no es la "guía definitiva".

Instalación de nginx

En primer lugar, deberemos crear el fichero para acceder al repositorio de nginx, pues éste no viene en los repositorios de CentOS.

[root@lab01 ~]# vi /etc/yum.repos.d/nginx.repo
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=0
enabled=1

Tras configurar el repo, ya podremos instalar nginx via yum:

[root@lab01 ~]# yum install nginx

Default VirtualHost en Apache

10 julio 2014 at 8:48 by Adrián Pérez

Black Hole

A continuación, algunas notas sobre el comportamiento del primer VirtualHost definido en Apache.

En un entorno Apache con VirtualHosts, el primer VirtualHost es importante, pues será el VirtualHost por defecto. Ésto significa que será el VirtualHost con mayor prioridad, y por tanto atenderá a cualquier petición al server contra un dominio no especificado en ningún VirtualHost.

Usualmente tendremos definidos VirtualHost *:80 así como *:443. En este caso, tendremos un default para *:80 y un default para *:443. Si definieramos nuestros VirtualHost especificando IP:puerto, entonces tendríamos un default para cada IP:puerto definido.

El primer VirtualHost, no es más que el primer VirtualHost definido en el httpd.conf. Si usamos como es habitual un fichero de configuración por cada VirtualHost, dentro del directorio "conf.d" incluido por el httpd.conf, entonces el primer VirtualHost será el que primero aparezca, ordenado por nombre. Por esta razón se suele especificar el VirtualHost "default" en un archivo con nombre "_defaul.conf", para que se liste primero.

En la documentación oficial de Apache, además, comentan que este primer VirtualHost debería tener un ServerName y un DocumentRoot iguales a los definidos de forma global en el fichero de configuración global de Apache.

Fuentes:

http://httpd.apache.org/docs/2.2/vhosts/details.html

http://httpd.apache.org/docs/2.2/vhosts/name-based.html

Flickr! Foto por ( (( marS )) )

Cómo configurar VirtualHosts para HTTPS

8 octubre 2013 at 16:10 by Adrián Pérez

ApacheEn Apache, usamos los VirtualHosts para poder definir diferentes proyectos web, cada uno con su propio dominio (o dominios), escuchando tras el mismo puerto e IP. Ésto podemos hacerlo para conexiones HTTP normales, pero antiguamente no se podía para HTTPS, puesto que la conexión venía cifrada y por tanto Apache no podía saber a qué dominio se quería acceder.

Al parecer, desde el 2006 se incorporó una extensión que le permitía al cliente (el navegador del usuario) enviar el dominio a consultar en la primera petición, antes de iniciar la transferencia cifrada de datos, permitiéndo así al servidor poder usar el mecanismo de VirtualHosts para tener varios sitios web HTTPS escuchando por el mismo puerto (típicamente el 443).

Requisitos

Seguramente nuestro servidor Linux con Apache ya tenga instalados los requisitos para funcionar, pero para asegurarnos, bastará con confirmar que tenemos:

  • openSSL 0.9.8f o posterior instalado
  • mod_ssl instalado en Apache

En mi ejemplo, un Fedora release 13 (Goddard) con Apache 2.2.15, lo he confirmado así:

[root@myServer]# openssl version
OpenSSL 1.0.0d-fips 8 Feb 2011

[root@myServer]# httpd -M | grep -i ssl
ssl_module (shared)

[root@myServer]# grep -i ssl /var/log/httpd/error_log*
Apache/2.2.15 (Unix) DAV/2 PHP/5.3.3 mod_ssl/2.2.15 OpenSSL/1.0.0-fips mod_wsgi/3.4 Python/2.7.5 configured -- resuming normal operations

Si no tienes openssl ni mod_ssl, puedes instalarlo con yum y posteriormente reiniciar Apache:

[root@myServer]# yum install openssl mod_ssl
[root@myServer]# /etc/init.d/httpd restart

Python 2.7 en CentOS 6 con mod_wsgi

5 junio 2013 at 19:12 by Adrián Pérez

python2En este post, veremos cómo instalar una nueva versión de Python (la 2.7.5) manteniendo la versión del sistema (2.6.6 en CentOS 6), forzando al mod_wsgi de Apache a usar la nueva versión en lugar de la de sistema. La idea es no tocar la versión de sistema, puesto que si cambiamos dicha versión, seguramente nos encontraremos más adelante con problema de dependencias en prácticamente cualquier actualización o instalación que queramos hacer con yum.

De esta manera, lo que haríamos sería hacer una segunda instalación de la nueva versión de Python, que no comprometiera la instalación original. En el ejemplo, estamos usando un servidor CentOS 6.4 que por defecto, viene con Python 2.6.6, con un servidor Apache con mod_wsgi 3.2. Lo que queremos, es instalar Python 2.7.5 sin comprometer el Python del sistema, instalar los módulos de Python necesarios para nuestra aplicación, pero únicamente para la nueva versión 2.7.5, y finalmente, reconfigurar mod_wsgi para usar la nueva versión.

Para ello, podríamos seguir los pasos descritos a continuación:

Entorno

Comprobamos los detalles del sistema operativo:

[root@MyServer]#cat /etc/redhat-release
CentOS release 6.4 (Final)

Verificamos la versión de python del sistema:

[root@MyServer]# python --version
Python 2.6.6

Apuntes de mod_rewrite

20 septiembre 2012 at 15:29 by Adrián Pérez

httpd ApacheEste post es una breve introducción a mod_rewrite, que puede servir como punto de partida, pero que no servirá ni mucho menos, como manual ni como guía. Por favor, mira las fuentes al final del mismo, para acceder a las fuentes originales y ampliar la información sobre mod_rewrite.

Mod_rewrite es uno de los módulos de Apache más importantes. Nos permitirá manipular urls (reescribiendo urls al vuelo), redirigir una url a otra o invocar un proxy interno, mediante una serie de reglas y condiciones.

En primer lugar, activaremos el motor de reescritura (en el .htaccess o en el virtualhost correspondiente), en el caso de que esté instalado mod_rewrite. Una vez activado, pondremos las reglas a continuación:

<IfModule mod_rewrite.c>
RewriteEngine On
## Aquí las reglas
</IfModule>

Optimización de Apache

17 julio 2012 at 12:38 by Adrián Pérez

httpd Apache
Siguiendo con el último post sobre fine tuning de MySQL para mejorar el rendimiento, me lanzo con otro post recopilatorio con un resumen de algunas de las recomendaciones oficiales de Apache, completadas con otras fuentes listadas al final del post.

Hardware y SO

En la documentación oficial de Apache se comenta, que el factor más importante para el rendimiento de un servidor es la RAM, lo cual me recuerda a una frase que reproduzco casi literalmente, pero de la cual no consigo recordar la fuente:

"Aumentar la RAM es la manera más rápida, barata y eficaz de mejorar el rendimiento"

Además de la RAM, se deberá prestar atención a la i/o de los discos, CPU y finalmente a la velocidad de la tarjeta de red, que deberán ser suficientes (ésto se deberá determinar por experimentación).

Configuración básica de Apache

24 abril 2012 at 19:13 by Adrián Pérez

httpd ApacheEn este post se trata de dar una idea de los que pueden ser los primeros pasos a dar tras la instalación de un servidor Apache con PHP.

/etc/php.ini

En primer lugar, podríamos mirar el archivo de configuración del php en busca de las líneas correspondientes a la gestión de la visualización de los mensajes de error. Se recomienda que ambos parámetros estén a Off si se quiere evitar que tras un error en el servidor, se le muestre al usuario el código relativo al error, o incluso el fragmento de código php que lo ha provocado:

display_errors = Off
display_startup_errors = Off

Instalar y configurar un servidor LAMP

27 marzo 2012 at 11:28 by Adrián Pérez

Hoy me lanzo a la piscina con un paso a paso para instalar un servidor LAMP (Linux, Apache, Mysql, Php) y realizar los primeros pasos, en entornos tipo servidor Red Hat (Fedora, CentOS, etc.). Hay muchas formas de hacer ésto, pero la descrita a continuación siempre me suele funcionar:

Primer paso, instalar todos los componentes con yum:

yum install -y httpd php mysql-server mysql php-mysql

Generar petición CSR para HTTPS

11 enero 2012 at 20:17 by Adrián Pérez

Apache HTTPSi se quiere montar un servidor que soporte HTTPS, se deberá contar un certificado válido para el sitio web. Para ello, una opción es directamente, comprar dicho certificado, en alguno de los múltiples sitios web que ofrecen esta opción, como GoDaddy, los cuales, ya tienen las instrucciones para generar la petición del certificado aquí:

Para generar la petición para el certificado, se deberán seguir una serie de pasos:

  • Crear el certificado y la petición CSR (Solicitud para Firma del Certificado), ejecutando en el servidor web, el siguiente comando (NOTA: yourdomain puede ser cualquier texto, por ejemplo, para dominio.com podríamos usar dominio.key y dominio.csr respectivamente):

openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr

Ej. openssl req -new -newkey rsa:2048 -nodes -keyout www_domain_com.key -out www_domain_com.csr

¿Cuándo reiniciar Apache?

29 agosto 2011 at 22:43 by Adrián Pérez

RAID
Dos preguntas cortas con respuestas de copy&paste sobre Apache.

¿Una modificación en el archivo php.ini requiere reiniciar apache para aplicarse?
"Si tenemos PHP como módulo del servidor, el archivo php.ini se lee cada vez que se reinicia. Por lo tanto tienes que reiniciar para que actualice los cambios. "
Fuente: http://www.ignside.net/man/servidores/phpini.php

¿Y qué pasa si no puedo reiniciar apache porqué está en producción sirviendo una aplicación crítica?
"Las señales USR1 o graceful hacen que el proceso padre indique a sus hijos que terminen después de servir la petición que estén atendiendo en ese momento (o de inmediato si no están sirviendo ninguna petición). El proceso padre lee de nuevo sus ficheros de configuración y vuelve a abrir sus ficheros log. Conforme cada hijo va terminando, el proceso padre lo va sustituyendo con un hijo de una nueva generación con la nueva configuración, que empeciezan a servir peticiones inmediatamente."
Fuente: http://httpd.apache.org/docs/2.0/stopping.html

Actualización Noviembre 2013

Aprovecho para actualizar este post con un par de apuntes:

  • Ante cualquier cambio en la configuración de Apache, podemos verificar si hay problemas con la nueva configuración, antes de aplicar los cambios, ejecutando:
/etc/init.d/httpd configtest
  • Una vez verificada la configuración, podemos reiniciar la configuración (sin necesidad de reiniciar Apache y por tanto sin afectar al servicio) símplemente haciendo un reload:
/etc/init.d/httpd reload

Flickr! Foto por US Mission Geneva