Interesante material acerca de los esfuerzos de lograr integración continua en NetFlix
http://techblog.netflix.com/2013/08/deploying-netflix-api.html
Deploying the Netflix API
Reply
Centralizando logs de varios servers en uno solo.
Imaginen el siguiente escenario, tenes N servidores de frontend y cada uno genera sus logs (access, error, php, slow) y los almacena localmente en /var/log/nginx. El día que sucede un incidente y tenemos que buscar lo que pasa puede pasarnos que solo uno de los nodos sea el que nos trae el problema pero deberíamos ir uno por uno para identificarlo.
Para mitigar esto lo ideal es agregar los logs de todos los servidores en uno solo. De esta manera podemos ver los logs de todos los servidores en uno y de ahi determinar por donde viene el problema.
Analice varias alternativas para realizar esta tarea, las que mas me llamaron la atención fueron greylog2 y logstash, pero ambas tenían arquitecturas complejas y están orientadas a un tratamiento mucho mas avanzado de los logs. Vale la pena verlas, pero por ahora yo me las salte. Una herramienta mas que me la recomendaron mucho y no la alcance a ver por que es paga es splunk, pero me la recomendaron mucho.
Fuí a los básico, rsyslog, este es el sistema que viene por defecto como syslog en varios Linuxes, yo ya lo tenía instalado así que decidí meterme con este. Tenía que ver como hacer para poner un servidor que este en espera de logs y los nodos de frontend para que envíen sus logs.
Server
Bien, lo primero es configurar el rsyslog para que escuche. Hay que ir /etc/rsyslog.conf y habilitar los modulos para escucha TCP.
#################
#### MODULES ####
#################
$ModLoad imuxsock # provides support for local system logging
$ModLoad imklog # provides kernel logging support
# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514
# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514
Probablemente les aparezcan comentados, descomentenlos.
El segundo paso es crear un archivo .conf en /etc/rsyslog.d/, todos los archivos .conf serán incluidos en la configuración de rsyslog. Llamemos al archivo servers.conf, y este debería tener definido que hacer con cada uno de los flujos de datos que reciba.
*.*;auth,authpriv.none,local0.none -/var/log/syslog
local0.* -/var/log/servers/nginx.access.log
*.*;auth,authpriv.none,local1.none -/var/log/syslog
local1.* -/var/log/servers/nginx.error.log
*.*;auth,authpriv.none,local12.none -/var/log/syslog
local2.* -/var/log/servers/php-error.log
*.*;auth,authpriv.none,local3.none -/var/log/syslog
local3.* -/var/log/servers/www-slow.log
Rsyslog maneja cada flujo con un identificador local[0-7], asi que aquí tomamos los primeros 4.
Los logs agregados quedarán obviamente en /var/log/servers. Al reiniciar rsyslog debería esta todo listo para recibir peticiones.
Cliente
El cliente, este es mas sencillo. Nuevamente van a tener que crear un archivo en /etc/rsyslog.d/, en cada nodo, con la configuración para enviar logs al server. Llamemos al archivo client.conf. Este archivo debe tener lo siguiente.
$ModLoad imfile
$InputFileName /var/log/nginx/[nombre_de_tu_access_log]
$InputFileTag access:
$InputFileFacility local0
$InputFileSeverity info
$InputRunFileMonitor
$InputFileName /var/log/nginx/[nombre_de_tu_error_log]
$InputFileTag nginx_error:
$InputFileFacility local1
$InputFileSeverity info
$InputRunFileMonitor
$InputFileName /var/log/php-fpm/[nombre_de_tu_php_error]
$InputFileTag php_error:
$InputFileFacility local2
$InputFileSeverity info
$InputRunFileMonitor
$InputFileName /var/log/php-fpm/www-slow.log
$InputFileTag php_slow:
$InputFileFacility local3
$InputFileSeverity info
$InputRunFileMonitor
$InputFilePollInterval 1
local0.* @(z7)[IP_DEL_SERVER]:514
local1.* @(z7)[IP_DEL_SERVER]::514
local2.* @(z7)[IP_DEL_SERVER]::514
local3.* @(z7)[IP_DEL_SERVER]::514
Ojo, Reemplacen los datos según corresponda !.
Al reiniciar el server si hace un tail -f a alguno de los archivos de logs del server deberían ver como se cargan los logs en el server y en el cliente. Controlen bien que todos los nodos estan logeando actividad en el server de logeo.
Cerrando
Problemas que pueden tener seguramente esten relacionados a direcciones de red (maquinas que no se ven) o a problemas de firewall. Ojo con esas dos cuestiones.
Obviamente esta conf es para Nginx y PHP-FPM, pero creo que es bastante lógico como configurar el server y el cliente para forwardear cualquier archivo de log.
Gracias a los muchachos de la lista de Dev Ops por los tips, ellos sugirieron estas tools.
Drupal Training – Viernes 15 de Noviembre – 19hs
Este viernes para prendernos de la iniciativa global de Drupal Trainings , desde 42mate decidimos ofrecer un traninig de 3 hs introductorio a Drupal, gratuito.
El lugar será el Salon de Usos multiples de Intecnor en el Anexo de la UTN, Av. Laprida y French, comenzando a partir de las 19hs hasta las 22hs (sean puntales asi arrancamos a tiempo).
La idea del training es presentar Drupal 7, sus elementos de trabajo Nodos, Bloques, Menus, Módulos y Themes haciendo un pequeño ejemplo practico todos juntos, así que no olviden llevar su laptop con Apache, PHP y MYSQL instalado; si no tienen no se preocupen, trabajaremos en grupo.
La invitación es con cupos limitados asi que a anotarse rápido en este form.
Gracias a Luis Eiman, a la UTN y a Intecnor que nos facilitan las instalaciones.
Encontrar donde se define una clase usando el nombre de la clase
En un proyecto en el que me encuentro trabajando surgió la necesidad de implementar un módulo para OAuth, tenía que bajar el módulo y comenzar a usarlo. Cuando quiero comenzar a usarlo me salta un error que la clase OAuthException ya había sido declarada previamente.
Lo primero que se me vino a la mente es que el archivo que tenía la clase estaba siendo incluido mas de una vez, cuando me pongo a debuggear no era el caso, el archivo no estaba siendo incluido mas de una vez.
Lo segundo que pienso es que la clase estaba definida en algún otro módulo, así que grepeo todo el fuente del proyecto para buscar la definición de la clase en otro lado, el resultado fue que no había otra definición, solo la del módulo que acababa de instalar.
Después de mucho buscar y buscar, se me vino a la mente de buscar donde estaba el archivo en función del nombre de la clase, googleando un poco me encontré en stackoverflow con la clase ReflectionClass la cual posee varios métodos interesantes, entre ellos el método getFileName, este a partir del string con el nombre de la clase devuelve el path al archivo donde la clase fue definida. Aquí un ejemplo
$reflector = new ReflectionClass('Foo');
echo $reflector->getFileName();
Ya estamos dije yo, cuando corro esto para ver que me decía mi sorpresa vino de que este me devolvía vacío. Pensando un poco mas me doy cuenta que si la clase es parte de una extensión o nativa de PHP difícilmente este en un archivo, así me encontré con este otro método de la misma clase, isInternal, el cual me dio verdadero.
Con eso me saque la duda de donde venía la clase, el paso siguiente fue revisar mi lista de extensiones y me encontré con que tenía una extensión pecl para oauth (la cual instalé para otro proyecto hace bastante) y la misma definía una clase con el mismo nombre, algo que no debería pasar en las nuevas versiones de PHP si usamos espacios de nombre.
Para solucionarlo desactive la extensión y seguí codeando.
Gitlab, Web Hooks y Jenkins
Desde hace un largo tiempo venimos usando en 42mate Gitlab como nuestra herramienta de control de versiones y Jenkins como servidor de integración continua. La selección de las mismas fue principalmente por que son Open Source y por que están mas que aceptadas por la comunidad, nunca nos arrepentimos de la elección que tomamos.
Hoy me puse a ver alternativas para disparar un deploy en jenkins desde Gitlab después de cada commit y me encontré con que Gitlab implementa web hooks.
La idea es que Gitlab, después de cada push al repositorio, envíe una petición POST a un server remoto, en este caso Jenkins, con la información del push que disparó el evento, el servidor remoto recibe dicha información y toma alguna acción al respecto, en este caso dispara un deploy.
Para que jenkins sea capaz de manejar la request enviada por Gitlab debemos tener instalados el Plugin de Git y el Plugin para Gitlab Hooks, el segundo es el encargado de hacer la magia y manejar la request.
Manos a la Obra
Para poner en marcha esto necesitamos obviamente un server Gitlab con nuestro repositorio y un Job un Jenkis ya totalmente armado para deployear desde el repositorio en Gitlab. Tambien vamos a tener que instalar y configurar el plugin para los hooks “Gitlab Hook Plugin”
Cabe aclarar que el Job en Jenkins debe estar conectado directamente al repositorio en gitlab dado que la información de conexión es utilizada por el plugin de jenkins para gitlab. Para esto deberán tener instalado el plugin de Git, así tienen disponibles las opciones para conectar el Job con Gitlab. Del lado de gitlab van a necesitar un usuario Jenkins configurado para que el usuario con el que se corren los Jobs en Jenkins pueda clonar y pullear cambios del repo.
Para instalar los plugins en jenkins deben ir a Manage Jenkins, Plugins, Buscar el plugin en Available, seleccionarlos, instalar y reiniciar jenkins.
Después de instalarlos
Una vez reiniciado jenkins deberían listarse en installed.
Una vez que tengan el Job listo y los plugins instalados el siguiente paso será ir a Gitlab, entrar a su repositorio > settings > web hooks.
Aquí deberán ingresar la url de su jenkins para que se ejecute el plugin de web hooks, por ejemplo :
http://[dominio]/gitlab/build_now
Poner en dominio la dirección a su Jenkins.
Una vez que esta guardado pueden proceder a testear el web hook con el boton que se provee en dicha pantalla o probar pushear algo al repositorio y ver como en pocos segundos se dispará el proceso de build en Jenkins.
Cerrando
Como ven es muy muy sencillo, mucho mas que enganchar un hook post commit en SVN, y muy eficiente, mucho mas eficiente que verificar si hay cambios cada x segundos.
Tengan en cuenta que esto va a buildear siempre siempre después de cada push al branch que usen para que sea deployeado, consideren los riesgos que pude traer esto.
Para entornos de integración del trabajo de los developers usenlo sin miedos.
Para entornos de QA, recomendaría que usen un branch aparte en el cual se pushen los cambios listos para ser promovidos a QA, previa verificación del equipo.
Para producción no lo recomiendo por mas que tengan una mega batería de tests, usen un branch separado para producción o cualquier otra cosa que les haga pensar que lo pueden hacer, si lo hacen felicito por los cojones bien grande que deben tener 
.