Es que no funciona en producción

La labor de desarrollo de aplicaciones conlleva problemas que no logramos reconocer a primera vista. Este post tiene por finalidad ayudarnos a detectar los errores más comunes cuando hacemos el paso a producción (deployment) de nuestra aplicación hecha con KumbiaPHP. Va especialmente dedicado a nuestros colegas que alguna vez han llegado al chat grupal con la frase “no funciona”.

La primera pregunta que debemos resolver es: ¿Por qué no funciona?

A continuación presentamos una lista de los temas más comunes que deberíamos tener en cuenta para resolver la pregunta que impulsa este artículo.

  1. ¿El servidor apache está ejecutándose?
  2. ¿El mod rewrite está activo?
  3. ¿El mod rewrite está configurado para nuestra ruta en el servidor?
  4. ¿PHP está instalado y configurado?
  5. ¿El servidor de bases de datos está activo?
  6. ¿La cuenta en el servidor de bases de datos es la que corresponde en la configuración de nuestra aplicación?
  7. ¿Hemos trasladado todos los cambios desde el servidor de bases de datos de desarrollo hacia el servidor de producción?
  8. ¿Nuestra aplicación tiene los permisos bien configurados?
  9. ¿Hemos copiado completamente la aplicación desde el servidor de desarrollo (incluidos todos los archivos .htaccess)?
  10. ¿Hemos configurado correctamente la constante PUBLIC_PATH?
  11. ¿Podemos usar PATH_INFO o necesitamos cambiar la estrategia de generación de URL?
  12. Si estamos completamente a ciegas, ¿hemos activado la visualización de errores?

NOTA: Si es la primera vez que haces un paso a producción (deployment) a un servidor dedicado o en un hosting compartido, te recomendamos leer los siguientes artículos que hemos alojado en nuestra wiki.

Continuemos entonces con el checklist:

¿El servidor Apache está ejecutándose?

Nuestra primera tarea será revisar que el servicio de Apache se encuentre activo y en el puerto necesario. Asumiendo que la tarea de despliegue (deployment) se realiza en un servidor linux, podemos revisar si el servicio está activo y si acaso el puerto está escuchando.

Revisemos el servicio web con los siguientes comandos:

ps -fea | grep -i http
ps -fea | grep -i apache

Si encontramos resultados, es decir, al menos 2 líneas se visualizan como salida a nuestro comando*, es que el servicio está activo.

*el comando ps es “process status” o estado del proceso. Las opciones -fea son para indicar que nos liste los procesos de nuestro usuario como del resto, así como algo de información relacionada con el proceso. Para realizar el filtro entre todos los procesos hemos usado un pipe | o tubería para enviar el resultado del comando ps al comando grep que buscará en la lista si acaso existe algo que contenga el texto “http”, o algo que contenga “apache”. Se usa con -i para que no discrimine entre mayúsculas y minúsculas o alguna combinación de ellas. Para más ayuda sobre estos comando les recomendamos usar el comando man ps o también pueden usar man grep.

NOTA: si usan el comando man (manual) para ps o para grep lo más seguro es que se encuentren con el editor vi. Para salir de él bastará con presionar Esc (escape), luego : (dos puntos) y luego q (la letra q para quit).

Revisemos ahora que el servicio está activo y escuchando peticiones.

Para eso nos bastará en primera instancia abrir un navegador y apuntarlo a la dirección de nuestro servidor. Si tenemos respuesta de la página de bienvenida del servicio (apache) ya tendremos este tema resuelto.

Ahora, si tenemos acceso por consola, podemos probar usando el comando

netstat -av | grep http

En mi caso, uso apache y su nombre de servicio es http. En otros Sistemas Operativos o paquetes de software que incluyen Apache, el servicio web puede encontrarse como apache o apache2.

¿El mod rewrite está activado?

Esta pregunta no es difícil de responder si usamos un pequeño archivo PHP al que llamaremos info.php. En él escribiremos <?php phpinfo(); ?> y luego lo abriremos desde el navegador (normalmente http://localhost/info.php)

Así aprovecharemos para revisar que PHP está activo y en la versión del mismo.

Una vez cargue la página de información de php buscaremos (en general con Ctrl + F o Cmd + F) la palabra rewrite. Deberíamos encontrarla en la sección apache2handlers, en la fila Loaded Modules.

Información del php info

Como se aprecia en la imagen anterior también está activo mod_php7 :-)

En caso que no lo encontremos, o que el archivo info.php no nos dé información, bastará con hacer la activación desde la consola (en el caso de tener servidor con shell activa). Vamos a asumir que usamos un servidor con un sistema operativo derivado de debian (ubuntu o similar). Entonces escribiremos en la consola como root

a2enmod rewrite

Y luego reiniciamos el servicio de apache (también como root)

service apache2 restart

Con esto ya deberíamos tener activado el módulo de sobrescritura de url.

¿El mod rewrite está configurado para nuestra ruta en el servidor?

Bueno, no basta con activar el mod rewrite, hay que configurarlo también.

Nota del autor: esto es lo que normalmente hago en mi configuración de apache. 
No sé si es lo más recomendado. Los comentarios son bienvenidos :)

Para realizar este cambio iremos al archivo de configuración de apache (generalmente alojado en /etc/apache2/apache2.conf)

Lo editaremos y buscaremos una sección llamada Directory.

Buscaremos aquella cuya línea sea Directory /var/www y cambiaremos la opción AllowOverride None por AllowOverride All. Guardaremos la configuración y procederemos a reiniciar el servicio apache.

En las imágenes siguientes se ve el antes y el después de la configuración.

antes de la configuración
Antes de la configuración
luego de cambiar la configuración
luego de cambiar la configuración

Con estos pasos el mod rewrite estará activo y configurado.

¿PHP está instalado y configurado?

Si hemos llevado a cabo los pasos anteriores para saber si el mod rewrite estaba activo, y lo hemos encontrado en el archivo info.php, entonces es que tenemos PHP bien instalado.

En caso que no hayamos logrado entonces deberemos instalar el módulo PHP en nuestro servidor.

Para hacer esta tarea usaremos nuevamente la consola (shell) para hacer la instalación.

La instalación varía un poco entre distribuciones de servidor, pero haremos la instalación pensando en algún derivado de debian (como si fuéramos root)

apt-get install libapache2-mod-php php

Una vez que la instalación haya finalizado necesitaremos reiniciar el servicio web (como root)

service apache2 restart

Si tenemos aún el archivo info.php, pues lo abriremos desde el navegador (normalmente http://localhost/info.php)

Si logramos ver el resultado de nuestro archivo, entonces ya tendremos claro que PHP está activo en nuestro servidor.

¿El servidor de bases de datos está activo?

Si usamos MySQL o MariaDB bastará con intentar hacer login con la cuenta que tenemos en la configuración de nuestra aplicación desde la consola.

mysql nombredelabasededatos -u miusuario -p

Digitamos la contraseña y presionamos enter para lograr acceso.

Si nos da un error como el que se ve en la imagen siguiente es porque el servicio no está activo.

Para activarlo deberemos ejecutar un comando como el que sigue desde la consola (como si fuéramos root):

service mysqld start

Si ahora logramos acceso y todo va bien, es decir, logramos conectarnos al servidor mysql, sería bueno saber si tenemos acceso a la base de datos que usará la aplicación.

Para eso, estando en la consola interactiva de mysql, escribimos el comando use mibasededatos; (donde mibasededatos es el nombre de la base de datos que está configurado en el archivo database.ini) seguido de punto y coma. Y presionamos enter.

Nos debe aparecer un mensaje como “database changed”.

Seleccionamos alguna de las tablas del sistema (podemos listarlas usando el comando show tables;), y escribimos alguna instrucción y le ejecutamos, por ejemplo;

SELECT * FROM tablaseleccionada;

Si todo ha ido bien, ya podemos pasar al siguiente punto.

¿La cuenta en el servidor de bases de datos es la que corresponde en la configuración de nuestra aplicación?

Bueno, en el punto anterior ya hemos realizado esta prueba usando el comando:

mysql nombrebasedatos -u usuario -p

Si esto no resulta, será necesario crear un usuario de mysql con los permisos necesarios sobre la base de datos correcta. Para eso te recomendamos leer el siguiente artículo que ya explica muy bien cómo lograr esta labor.

https://www.digitalocean.com/community/tutorials/crear-un-nuevo-usuario-y-otorgarle-permisos-en-mysql-es

¿Hemos trasladado todos los cambios desde el servidor de bases de datos de desarrollo hacia el servidor de producción?

A veces el error se produce porque tenemos tablas en el servidor de desarrollo que no hemos pasado al servidor de producción o porque alguna de las tablas de producción no tiene atributos (campos) nuevos que sí hemos estado usando en desarrollo. Hacer una revisión de las estructuras de las tablas será de gran ayuda si comparas cómo es el estado en ambos servidores.

¿Nuestra aplicación tiene los permisos bien configurados?

Si hemos leído los artículos de la wiki, y hemos comprobado que los permisos son los correctos, sólo nos quedará pasar al siguiente punto.

¿Hemos copiado completamente la aplicación desde el servidor de desarrollo (incluidos todos los archivos .htaccess)?

Por obvia que parezca la pregunta resulta que en ocasiones el cliente que usamos para copiar los archivos omite los archivos que comienzan en punto (los dot files). En KumbiaPHP se usan varios archivos que comienzan en punto, y aunque todos se llaman igual, cada uno cumple una misión diferente dependiendo del lugar en el que esté alojado. Este archivo es el .htaccess.

Personalmente la forma que más me resulta para lidiar con este problema es comprimir el sitio, copiarlo comprimido al servidor de producción y luego descomprimirlo en él. Si esto no fuera posible (porque por ejemplo no tienes acceso a la shell o si el panel web de administración no provee de gestión de archivos), toma en cuenta que el cliente de ftp que uses lleve todo lo que necesitas al servidor de producción.

¿Hemos configurado correctamente la constante PUBLIC_PATH?

Aunque también es parte de lo que se habla en los artículos escritos y mencionados de la wiki, uno de nuestros colegas ha escrito un artículo interesante sobre este tema y el siguiente en el blog de KumbiaPHP https://www.kumbiaphp.com/blog/2018/07/31/no-input-file-specified-arreglar-el-error/

¿Podemos usar PATH_INFO o necesitamos cambiar la estrategia de generación de URL?

Al igual que el punto anterior, nuestra recomendación es leer el artículo que ya se mencionó en él.

Si estamos completamente a ciegas, ¿hemos activado la visualización de errores?

Si el servidor no nos da información alguna sobre el error, podemos aprovechar una configuración especial que está alojada dentro del archivo default/public/index.php para activar el registro de los errores y permitir visualizarlos directamente en el navegador web.

Para eso iremos archivo mencionado (default/public/index.php) y buscaremos la línea

//error_reporting(E_ALL ^ E_STRICT);ini_set('display_errors', 'On');

Y le quitaremos los comentarios iniciales, es decir, los dos primeros caracteres iniciales //

Adicionalmente debemos asegurarnos que KumbiaPHP no esté en modo producción, así que en el mismo archivo default/public/index.php verificamos que la constante PRODUCTION sea igual a false:

const PRODUCTION = false;

Esto hará que las excepciones que ocurran sean mostradas en pantalla evitando la redirección a la página de error 404, que es comportamiento por defecto de KumbiaPHP cuando está en producción.

Con eso ya tendremos alguna idea a partir de la presentación de los errores en pantalla.

Existe una forma extra de visualizar errores, pero para ello hay que tener acceso al servidor en modo consola (shell) y tener acceso al log de errores del servidor web (apache generalmente). Normalmente este archivo se aloja en /var/log/apache2/error.log

Si se tiene acceso a él, usar el comando tail -f error.log será de gran utilidad pues cada vez que recargues tu navegador, los errores se verán reflejados en tu terminal. Los mensajes que recibas serán de gran utilidad al momento de buscar posibles soluciones, o para pedir apoyo a algún colega.

Una recomendación final

Si hemos pasado de PRODUCCION = true a false y viceversa, es necesario recordar eliminar el contenido de la carpeta de cache que genera KumbiaPHP cuando estamos en modo producción. Para ello iremos a la carpeta default/app/temp/cache y borraremos su contenido para evitar que no logremos visualizar los errores porque el framework está presentando los contenidos “cacheados” en vez de las vistas reales.

Con todo esto, te deseamos lo mejor y mucho ánimo cuando te encuentres con un problema, pues recuerda que resolverlos es parte de nuestro aprendizaje y nuestra labor como desarrolladores.

Un abrazo cordial,

El equipo de KumbiaPHP


Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

© Kumbia Team