Deployer, una buena alternativa a Capistrano

deployer

Durante mucho tiempo hemos dado vueltas en DIGIO a cómo hacer un mejor deploy de los proyectos en el servidor. Nuestra forma de trabajar era sobre un repositorio GIT que se actualizaba desde el servidor con un simple git pull de forma que en caso de problemas podríamos hacer un reset a una versión dentro del histórico de GIT.

Además añadimos algunas cosas más como cargar configuración de cron a través de un fichero .crontab dentro del proyecto de forma que se actualizan los procesos por cron cada vez que hacemos un deploy. También un fichero .deploy que actúa como script de shell permitía ejecutar acciones una vez se había actualizado el código, para hacer migraciones de base de datos por ejemplo o borrar los ficheros de cache.

El mayor problema que veía es en proyectos con mucha afluencia de usuarios, si estamos actualizando el código, puede llegar una petición donde parte del código está actualizado, pero otras partes no, JavaScript, controladores, modelos, etc… Esto puede producir fallos en el sistema por tener código a medio utilizar e incidencias en los usuarios.

En mi última visita a Emagister en Barcelona, me contaron que ellos usaban Capistrano y Jenkins, el proceso de deploy es similar en cuanto podemos lanzar migraciones, y ejecución de otras tareas, pero resolvía el problema que teníamos nosotros de dar la posibilidad de tener código a medio actualizar cuando llega una petición web.

Capistrano, herramienta de deploy sobre múltiples servidores en Ruby

Capistrano genera una carpeta de release con código nuevo (por lo general de un repositorio GIT), y no se hace el cambio en la carpeta raíz hasta que no se haya copiado todo a la nueva carpeta de release, pudiendo configurar cuántas carpetas de releases queremos conservar así como la posibilidad de volver hacia atrás en caso de error de forma inmediata simplemente apuntando el DocumentRoot a la carpeta de release anterior.

Pero tengo una pequeña manía y es que, siendo desarrollador PHP y JS, intento buscar siempre una alternativa a tener que instalar un intérprete de Ruby, Python o cosas similares, igual que no me gustan los Frameworks que trabajan con XML, YAML y PHP al mismo tiempo cuando se puede hacer todo en un solo lenguaje.

Y buscando buscando encontré un par de proyectos interesantes: Rocketeer y Deployer, pero quizás este último por su simplicidad, y por, admitámoslo, tiene una página web más agradable de leer, fue el que más me gustó.

Ambos proyectos son una copia de Capistrano, ambos funcionan con un phar como Composer, por lo que es muy cómodo y solo necesitamos un fichero para poder ejecutarlo. Quizás Deployer tiene algo más de versatilidad con menos configuración.

Deployer versátil y fácil de configurar en PHP

Con Deployer asegurarmos un proceso de deploy seguro, posibilidad de revertir al instante a una versión anterior, lanzar comandos fácilmente en el servidor remoto o en el servidor de deploy, soporte para claves SSH, usuario y password y múltiples servidores por entorno (por ejemplo poder lanzar nuevos cambios a varios servidores de nuestro cluster).

Con Deployer definimos entornos (producción, desarrollo), dentro de cada uno, definimos un grupo de servidores sobre los que mandaremos actualizaciones (normalmente solo hay uno), y finalmente tareas para lanzar a estos servidores. Que en nuestro caso es enviar la última versión del código en Git.

Si juntamos esto con Jenkins o nuestra herramienta de deploy online podremos actualizar el código de nuestro proyecto fácilmente por todo el equipo:

Incrementando la velocidad del log de PHP en nuestro proyecto web

PHP log con Redis y SQLite

Recientemente trabajamos sobre un framework desarrollado por el equipo de Emagister y como es normal aunque tiene similitudes en cuanto a características con nuestro framework Creamture, hay otras cosas que son diferentes y no encontramos un rendimiento óptimo.

Una de estas cosas es el tema del log de errores utilizando para ello una tabla en base de datos. El uso de base de datos para escribir en un log es bastante lento comparado con la escritura directamente en un fichero en disco, aunque mantiene algunas esperadas ventajas como la posibilidad de disponer de un visor de log mediante consultas SQL, lo que permite lectura únicamente de las entradas ordenadas por fecha, paginación, sin tener que volcar todo el fichero de log que podría ser muy grande. Aunque la escritura en base de datos es mucho más lenta que la escritura en fichero, el impacto no es muy grande pues únicamente pasan a log los errores o excepciones.

CodeIgniter, y Creamture crea un fichero de log en formato texto por cada día, lo que minimiza que los ficheros crezcan excesivamente, pero al usar el log no solo para volcar errores graves sino como bitácora para cualquier tipo de información que los desarrolladores queremos visualizar, podemos encontrarnos con ficheros diarios de varios megas.

Reciéntemente he mejorado el visor de log que teníamos en Creamture, que permite visualizar los ficheros de logs de CI 1.7 hasta CI 2.2 (Creamture). Disponiendo de un modo para visualizar el log actual en tiempo real, realizando lecturas parciales del fichero en disco. Podéis descargarlo este GIST.

El caso es que pensando en cómo mejorar, esta tarde me dispuse hacer un pequeño test utilizando una instalación base de CodeIgniter 1.7. Se me ocurrió que podría ser más práctico si se usaba un sistema de almacenamiento más organizado y mejor que un fichero, pero que siga siendo más rápido que una base de datos.

El impacto del log normal sobre un controlador

Activando únicamente el log de errores, y no de debug ni info, para minimizar el impacto (CodeIgniter genera log de debug al pasar por casi cualquier librería), y creamos un controlador con un método muy muy simple:

function index()
{
    echo 'OK';
}

Usaremos para probar el funcionamiento normal en nuestro sistema, un pequeño programa para nodejs, llamado webstress-tool con el que podemos lanzar peticiones concurrentes y obtener una media de las mismas, generaremos 10 bloques de peticiones de 50 peticiones concurrentes, cada bloque estará separado por 1 segundo de diferencia.

$ webstress GET http://www.ci17.com 10 50
about to send 500 GET requests to url http://www.ci17.com over 10 seconds
done, took total over: 12034, avg response time: 240.68
done, took total over: 8849, avg response time: 176.98
done, took total over: 7800, avg response time: 156
done, took total over: 7804, avg response time: 156.08
done, took total over: 7686, avg response time: 153.72
done, took total over: 7636, avg response time: 152.72
done, took total over: 7701, avg response time: 154.02
done, took total over: 7713, avg response time: 154.26
done, took total over: 7171, avg response time: 143.42
done, took total over: 7073, avg response time: 141.46

Entonces modifiqué nuestro pequeño método para añadir una llamada a log_message: log_message('ERROR', 'Hola mundo!'); con lo que al probar de nuevo, encontramos cómo afecta el log a la media de las respuestas:

$ webstress GET http://www.ci17.com 10 50
about to send 500 GET requests to url http://www.ci17.com over 10 seconds
done, took total over: 15360, avg response time: 307.2
done, took total over: 10872, avg response time: 217.44
done, took total over: 11044, avg response time: 220.88
done, took total over: 11931, avg response time: 238.62
done, took total over: 11037, avg response time: 220.74
done, took total over: 10955, avg response time: 219.1
done, took total over: 11189, avg response time: 223.78
done, took total over: 12869, avg response time: 257.38
done, took total over: 11121, avg response time: 222.42
done, took total over: 11744, avg response time: 234.88

Podemos ver como una única llamada al log tiene un importante impacto aunque la llamada sea simple. Por lo que no podemos ignorar que aún utilizando ficheros de texto, el impacto es significativo.

Probando con SQLite

La idea es generar un fichero de SQLite por día, y poder guardar la misma información que los ficheros de log, para eso creamos un método log_message alternativo que abrirá una bbdd sqlite nombrada con la fecha actual, intentamos siempre insertar, en caso de error crearemos la tabla ya que el error será por no existir la tabla, pero será más rápido que comprobar siempre si la tabla existe.

El resultado es desalentador:

$ webstress GET http://www.ci17.com 10 50
about to send 500 GET requests to url http://www.ci17.com over 10 seconds
done, took total over: 30964, avg response time: 619.28
done, took total over: 27871, avg response time: 557.42
done, took total over: 30341, avg response time: 606.82
done, took total over: 28935, avg response time: 578.7
done, took total over: 24958, avg response time: 499.16
done, took total over: 27928, avg response time: 558.56
done, took total over: 21769, avg response time: 435.38
done, took total over: 23220, avg response time: 464.4
done, took total over: 26227, avg response time: 524.54
done, took total over: 25003, avg response time: 500.06

Sí sería posible leer el log mediante un visor con consultas SQL, pero la penalización por insertar una simple entrada resulta excesiva.

Usando Redis para guardar el log

Después de leer la velocidad con la que funcionan los sistemas noSQL de almacenamiento key,value probamos Redis, cuyo funcionamiento es muy muy simple, y tenemos una librería muy probada para PHP.

Así que después de bajarnos una versión de Redis para Windows (existe versión para cualquier Unix, OSX y una compilación para Windows que ocupa algo menos de 2 megas.

El nuevo método que construimos es muy simple:

function log_message2($level = 'error', $message, $php_error = FALSE)
{
    $redis = new Redis();
    $redis->connect('127.0.0.1', 6379);
    $redis->lpush('ci17-'.(date('Y-M-d')), (date('Y-M-d H:i:s')).' - '.$level.' --> '.$message);
}

El resultado es casi tan bueno que el impacto sobre la versión sin log es mínimo, y además podemos recuperar las entradas rápidamente ordenadas por fecha y pudiendo paginar. Vemos que efectívamente Redis es muy útil si queremos guardar una bitácora para proyectos web de uso intensivo.

$ webstress GET http://www.ci17.com 10 50
about to send 500 GET requests to url http://www.ci17.com over 10 seconds
done, took total over: 10579, avg response time: 211.58
done, took total over: 8524, avg response time: 170.48
done, took total over: 8419, avg response time: 168.38
done, took total over: 8616, avg response time: 172.32
done, took total over: 8254, avg response time: 165.08
done, took total over: 8351, avg response time: 167.02
done, took total over: 8383, avg response time: 167.66
done, took total over: 8320, avg response time: 166.4
done, took total over: 8017, avg response time: 160.34
done, took total over: 7932, avg response time: 158.64

Lo próximo será actualizar nuestro framework y el visor de logs para usar Redis y establecer un fallback para utilizar ficheros en caso de no detectar un servidor Redis funcionando.

La verdad de los sistemas operativos, Linux para usuarios.

Beatbox-eos

Hay mucho fanático de Windows, Linux o MacOSX, yo he pasado años usando todos ellos y cada uno ha hecho sus cosas buenas y sus cosas malas. Para los que no los han probado pero tienen curiosidad, aquí van algunas opiniones. En este post hablaremos de Linux, filosofías aparte, para su uso como usuario.

Cuando hablamos de Linux, es muy difícil hablar de algo concreto. Este es uno de los problemas del Software Libre y del planteamiendo del GNU Linux, la costumbre de que cualquier grupo que quiere hacer su propia versión, personaliza y monta una distribución da libertad, si, pero para un usuario de a pie le confunde, cuando el usuario no es un friki o un fanático de la informática, no tiene porqué saber que no es lo mismo usar Ubuntu, que Lubuntu, que Kubuntu, que Fedora, Gentoo y tantos otros, pero lo cierto es que hay múltiples y grandes diferencias de una distribución a otra, tanto en aspecto como en uso, facilidad, manejo, y hasta aplicaciones completamente diferentes.

El mayor problema de Linux es que no ha sabido unificar.Y esto no es solo válido para la distribución, tenemos todo este amalgama de opciones en cualquier cosa, el sistema de sonido, el gestor de ventanas, de Escritorio, de practicamente cualquier cosa, por lo que tendremos que instalar un sinfín de versiones, software de todo tipo y configuraciones para que funcione tal o cual programa.

Para el usuario de a pie lo mejor es que escoja una de las distribuciones con más comunidad pero sobre todo con más soporte comercial, Ubuntu a cada versión mejora, aunque cometa errores y algún que otro acierto, es sin duda una de las distribuciones de referencia y que mejor acompañan a un usuario en su día a día. Además su apuesta por un SO que se adapte a Móvil, Tablet y PC está haciendo trabajar en el rendimiento de la distribución y en un mejor comportamiento para diferentes pantallas.

image-phone-overview

La leyenda urbana alrededor de Linux dice que es perfecto para equipos antiguos con pocos recursos y que se notará muy rápido ya que el 90% de los servidores funcionan con Linux.

Es un mito eso de que Linux ocupa pocos recursos, es cierto que hay distribuciones que se pueden instalar en ordenadores de decenas de años, pero es lo mismo que decir que Windows no se puede instalar en ordenadores antiguos (siempre nos quedará Windows XP, o incluso Windows 95 si aún tiene más años). Las distribuciones actuales requieren una buena gráfica, memoria ram, disco, etc para que tengan un comportamiento fluido e impecable, y siempre que tengamos los mejores drivers para Linux nuestra esperiencia de usuario será muy buena.

Linux para desarrollo web, cómodo de usar y mejores resultados.

Si eres programador web, seguramente este sea tu sistema operativo, ya que su cercanía a los servidores web nos permitirá trabajar directamente sobre un servidor como en un entorno de producción. Además existen editores multiplataforma como Sublime Text así como la mayoría de navegadores conocidos tienen versión para este Sistema Operativo, o bien podemos lanzarlo con un emulador.

Si no eres programador, pero te gusta cambiar el aspecto de tu sistema, iconos, fondos, colores y formas de las ventanas, una completa personalización, también te gustará usar una distribución Linux, aplicaciones como Gnome Tweak lo ponen fáciles para activar temas GTK, para cambiar todo el aspecto, o cambiar los paquetes de iconos.

El apoyo de los grandes como Google, Canonical, IBM, Valve, etc… ha hecho que mejore en rendimiento para entornos de usuario (algo que no se discute en entornos de servidor, pero que sí podemos discutir en entornos de escritorio).

Sin duda un sistema operativo que nos puede durar mucho tiempo.

Por supuesto el handicap aquí es que no tendremos software reconocido en la industria de la imagen y el vídeo, como Photoshop, o Premiere, o Microsoft Office, salvo que nos pongamos a emularlo, y logrando un rendimiento mucho menor, contaremos con alternativas menos conocidas pero igual de válidas que tendremos que aprender a fondo para sacarle el máximo partido, la ventaja, es que no tenemos que piratear ni paga nada por este software alternativo pues suele ser gratuito o de muy poco coste.

Android ha sido el triufo de Linux para el usuario, ha conseguido lo que ningún otro Linux ha podido, ser usado masivamente por cualquier usuario, con un amplio catálogo de aplicaciones propietarias de pago o gratuitas.

Android también funciona sobre Linux, pero no sigue la filosofía de la mayoría de distribuciones, ya que una capa por encima del Kernel gestiona la interfaz de usuario basada en un motor de compilación Java.

La verdad de los sistemas operativos, MacOSX

osx

Después de unos cuantos años como usuario de MacOSX y desengañado en el último año tengo una opinión bastante forjada de las bondades y quebraderos de cabeza que pueda dar un MacOSX.

Los sistemas operativos de Apple siempre se han caracterizado por un buen rendimiento y optimizados para tareas gráficas y vídeo. Uno de los grandes avances y una apuesta de futuro fue la de apostar por un núcleo UNIX pero manteniendo una estupenda capa gráfica y una interfaz de usuario fácil de utilizar, así nació la serie MacOSX.

No os puedo mentir, el uso diario de un MacOSX como usuario o como programador supone toda una experiencia. El sistema operativo está concebido para una extrema facilidad de uso que podemos ver en cuanto intentamos instalar un programa, simplemente arrastrando y soltando a la carpeta de Aplicaciones, viene con una buena cantidad de aplicaciones útiles (un cliente de correo soberbio, visor de mapas, notas, visor de imágenes, etc…) y elementos que crees que nunca vas a poder separarte de ellos como Spotlight, la Vista Rápida (ver cualquier documento con la tecla espaciadora) o el Dock o barra de aplicaciones, mucho más vistosa pero a la vez extraordinariamente ligera y fácil de usar.

Desgraciadamente (no se si tendrá algo que ver) desde la muerte de Steve Jobs, mientras Microsoft hacía cada vez más ligero y rápido su Windows, MacOSX se ha vuelto más lento y con más retardos en tareas tan simples como ver el correo, abrir aplicaciones o el manejo día a día, requiriendo equipos más potentes. Y no porque tuviésemos equipos poco potentes.

He estado trabajando con MacOSX, programando y emulando Windows con aplicaciones sin ningún problema, pero de una versión a otra (de un día para otro) parecía que mi portátil hubiese envejecido varios años y su rendimiento cada vez peor. Mavericks, Yosemite, han añadido pocas mejoras, solo unas pequeñas aplicaciones y algunas ideas de iPhone pero además mayores requerimientos que de forma extraña nunca resultan suficientes…

Cuando empezaron las actualizaciones a Mavericks se encontraban por la red quejas de usuarios con equipos de Apple con 32GB de RAM y potentes procesadores que funcionaban apreciablemente lento una vez actualizados.

Parece que todo haya funcionado bien hasta las versiones 10.8.x, y a partir de aquí cometiendo los errores que en el pasado se atribuían a Microsoft.

Aún así, MacOSX tiene muchos puntos a favor, el corazón UNIX permite qe podamos programar web como si fuese Linux, existen muchas aplicaciones equivalentes y las rutas de los ficheros son similares aunque la parte UNIX suele estar oculta para el usuario, mostrando únicamente las carpetas que le interesa. Las aplicaciones de MacOSX suelen acompañar en intefaz gráfica y facilidad de manejo, los programadores de aplicaciones para MacOSX suelen hacer muy buenas aplicaciones y de las que los usuarios de Windows y Linux suelen ver con envidia.

El precio del software libre para un programador

Open Source - Word Cloud

A menudo mantenemos la relación (incluso en el mundillo de la informática) de Software Libre igual a GRATIS, oigo multitud de clientes que me comentan “Usa software libre que es gratis y así abaratamos”.

Por lo general la forma de discutir esto siempre comienza por Libre es distinto de GRATIS, y que viene de una mala traducción de la palabra FREE en Free Software, la denominación en inglés. Pero aún así, cuando pensamos en Software Libre, pensamos en gratis.

Ahora bien, este planteamiento, no es del todo inválido, pues efectivamente, el Software Libre por lo general no implica un deselvolso de dinero inicial o pago por uso (digo por lo general, lo que no es en todos los casos). Pero esto no quita que, primero, no haya costado tiempo y esfuerzo de alguien el producirlo (y por lo tanto dinero), y segundo, que si en algún momento detectamos un problema y como programadores decidimos resolverlo pues lo usamos en algún proyecto propio, es responsabilidad nuestra también comunicar estos cambios a los creadores originales para que puedan añadir nuestras mejoras.

A menudo en DIGIO hemos mejorado multitud de herramientas de Software Libre y en muchas ocasiones por falta de tiempo, no caemos en la cuenta que comunicar y pasar las mejoras al proyecto original es una responsabilidad, sino que además repercute en mejoras futuras que pueden hacer otros sobre nuestros cambios que de otra manera, no obtendríamos, por lo que es una apuesta por ahorrarnos esfuerzo y trabajo en el futuro.

El coste de comunicar estos cambios a los proyectos de Software Libre suele ser siempre mucho menor que el coste de las mejoras futuras que obtendremos. Y en caso contrario aunque solo sea porque nuestro esfuerzo y dedicación no desaparezca con nuestro proyecto, sino que otros puedan aprovechar nuestro trabajo para mejorarlo y continuarlo.

Todo el que me conoce sabe que no soy un completo fanático del Software Libre, lo uso y he colaborado y aportado muchos cambios en muchos proyectos, pero eso no quita que no pueda ver puntos flacos en el planteamiento como excesiva fragmentación en proyectos derivados, mayor carga de correos (no os podéis imaginar la cantidad de correos que pueden llegar de Github, en cuanto uno hace grandes colaboraciones en proyectos de Software Libre, pero creo que es importante que el trabajo que hacemos tenga más vida fuera de lo poco que podamos desarrollar de forma interna y es el precio que debemos de pagar por desarrollar con Software Libre.

Servicios web JSONP y AJAX – iframe fácil en CodeIgniter

ci_ajax_jsonp

Aunque hace bastante tiempo de esto, aún tiene mucha utilidad. Se ha convertido en una costumbre que las aplicaciones webs estén pobladas de consultas o peticiones AJAX, cargando inicialmente una plantilla, y actualizando los contenidos mediante consultas o peticiones asíncronas.

Cuando queremos subir ficheros en segundo plano sin realizar la carga, en cambio no podemos usar AJAX, teniendo que remitirnos al File API de HTML5 o bien buscar una técnica alternativa que permita enviar un formulario con un formulario en multipart en segundo plano. Esto se puede conseguir mediante iframes, la técnica se basa en crear un iframe no visible (que no oculto, si está display:hidden no funcionará), de un tamaño de 0 pixeles y sin bordes conseguiremos un iframe funcional pero que no es visible por el usuario. Si indicamos como target de un formulario multipart este iframe, podremos subir un fichero sin recargar la página.

El problema será entonces conocer el momento en que el archivo se ha terminado de subir, para esto la respuesta cargada en el iframe debe ejecutar una llamada JavaScript definida en la ventana padre, que como si fuese una función de Callback se ejecutará cuando tengamos subido el fichero.

Poder obtener datos en JavaScript entre diferentes dominios permitirá crear fácilmente servicios web en formato JSON, a esta técnica se le denomina JSONP, consiste en devolver no un objeto JavaScript sino la llamada a una función con el nombre que escojamos (función callback) pasando como parámetro este objeto.
Cuando cargamos una url con la llamada al servicio lanzaremos la ejecución de la función de callback con los datos que esperamos de respuesta. Esto ya lo hace jQuery por detrás cuando ejecutamos el método $.getScript generando una función con un nombre aleatorio.

Para todo esto tenemos una librería que nos ayudará para generar respuestas en formato JSON, JSONP, XML y respuestas a través de iframes, si usamos CodeIgniter 2 o superior, mediante Spark/ajax disponemos de una serie de funciones helpers y métodos útiles para generar respuestas válidas en JSONP, envío de respuestas dentro de un iframe o respuestas en XML.

Con un método $this->ajax->response() podremos generar respuestas para enviar como JSON, JSONP, extender un objeto JS con jQuery, asignar datos generados a una variable, o generar respuestas en XML a partir de un objeto PHP.

Por ejemplo queremos cargar las cadenas de traducción de un array PHP a una variable JavaScript, podríamos añadir una carga de script en HTML

< script type="text/javascript" src="http://url/controller/method"></ script >

y que este método PHP devuelva los datos en una variable:

$this->ajax->response($array_traduccion, null, TRUE, "varjs");

Esto cargará los datos en varjs para poder usarlo en JavaScript. Esto funcionaría también en cualquier dominio, por lo que sería cross-domain.

Buenos propósitos

Servilia-planificacion-propositos-estrategia-objetivos

Comienza el año y vamos con web nueva, simple, simplísima, solo un blog y poco más, por ahora… El problema de un programador web es que nunca es suficiente para su página web, lo que, unido a mi falta de tiempo, se convertía en un contínuo “y si le pongo esto y esto otro…”, “necesito sacar más tiempo para montar una página web que se vea fantástica…” y finalmente nunca la terminaba porque nunca era suficiente.

Así que nos tiramos de cabeza al minimalismo y empezamos un nuevo sitio, borrón y cuenta nueva.

Intentaré ser regular y escribiré cada poco tiempo pues tengo comprobado que blog que no se actualiza, se queda en el olvido, y con este sería ya el 4 blog que comienzo más no sé que versión de página web.