Visión general de una arquitectura de microservicios basada en yarn

Siguiendo con la evolución de las arquitecturas orientadas a servicios ... ahí va un gráfico que completa la visión general explicada en anteriores post

Los servicios son servicios modelados con avro/RP y pueden operar en tres modalidades

  • POJOs
  • Como servicio RPC en local
  • Como servicio RPC en un cluster de yarn (escalado, tolerancia a fallos etc..)
Entrada publicada en Sin categoría | Comentarios cerrados

Prototipando un servicio de validación de tickets usando códigos QR

El otro día me propusieron a ver si era posible desarrollar un servicio de validación de entradas, vamos a llamarlo, que permitiera validar las entradas y fuera ágil. El servicio debía cumplir las siguientes especificaciones

  • Estar en producción en 10-12 días
  • Permitir acceder al recinto usando una entrada impresa en papel
  • Permitir acceder al recinto usando la entrada sin imprimirla en papel
  • Comunicarse con los servicios centrales del cliente para integrar la información de quién había entrado y cuando

Nos pusimos a pensar y planteamos las siguientes ideas

  1. Papel/Móvil y Boli
  2. Papel/Móvil y Ordenador
  3. Papel/Móvil y lector de código de barras
  4. Papel/Móvil y móvil


Si alguna vez has estado en un evento en el que la lista de acceso se valida con papel y boli sabrás que tienen varias desventajas (pese a tener una gran ventaja ... que es no necesita desarrollo):

  • Si acude mucha gente no es fácil que todo el mundo le de tiempo a entrar antes de que empiece el evento
  • Si hay varias puertas …. el sistema tiene puntos de fallo si no se organiza quién entra por qué puerta

Por tanto las dos primeras opciones quedan descartadas.
Las otras dos que nos quedan estarían vinculadas al hecho de disponer de un lector de códigos de barras y un servicio que recoja la lectura y la envíe a algún lado.... Si descartamos la del lector porque habría que comprarlos etc... nos quedamos con que lo mejor sería desarrollar un poco más la cuarta opción a ver hasta donde nos lleva.

La opción cuarta aún así tiene una gran debilidad y es la de desarrollar la APP para el dispositivo móvil que permite validar la entrada. Con esto en mente desarrollamos los siguientes diagramas que nos permitían aclarar un poco el panorama .... pintar siempre es una buena idea




Donde se ve que necesitamos un sistema que genere códigos QR para las entradas y un QR que sirva para registrar el móvil que está haciendo de lector de QR. La idea es olvidarnos de desarrollar una app para el móvil y que de alguna forma cualquier móvil que tenga un cámara se puede usar como lector de QR.
 


Si no vamos a tener una app propia disponible tenemos que hacer que no todos los móviles sirvan para enviar la información al servidor, por un tema de seguridad principalmente. Además como queremos poder dar feedback a la persona que está en la puerta vamos a vincular el móvil con un PC que estará también en la puerta. Este gráfico representa cómo se ha diseñado el protocolo que vincula ambos dispositivos... Esto se haría una vez por cada puerta/persona que está validando los accesos.
Por último la fase de validación de las entradas



Donde vemos que la persona que va a entrar, presenta la entrada en la puerta. Esta entrada se escanea con el lector de QR estándar del móvil (hay muchos en el mercado) y al leer la URL que está en el QR la APP que ha leido el QR lanza el navegador con dicha URL que se procesa en el servidor. Esta URL genera una llamada de vuelta al PC vinculado a este móvil (paso 3.2-3.3) y el proceso de validación y registro se da por finalizado.


Ahora bien esto es en teoría y son papeles pintados … así que para probarlo hemos desarrollado una  PoC que usa los siguientes elementos

  • Librería ZXING para generara códigos QR
  • Servicios REST desarrollados usando JAXRS
  • WebSockets para comunicar eventos del servidor al cliente
  • Servidor tomcat 7

En total hemos desarrollado las siguientes clases java

  • QRGenerator
  • RegistService
  • WebSocketService

Con estas tres clases y el programa de lectura de QRs del móvil hemos hecho una PoC plenamente funcional que cumple los requisitos. (Hemos tardado 8 horas, post incluido). Evidentemente faltaría hacer bastantes cosas para poner el desarrollo en producción pero con esta orientación creemos que se podría hacer el proyecto en 10 -12 días

Las grandes ventajas que creemos que tiene este modelo son

  • Poco código desarrollado
  • No depende de una aplicación específica desarrollada para el móvil
  • Permite usar cualquier dispositivo con cámara como lector de códigos
  • Tiene un modelo de seguridad, que sin ser el más seguro del mundo, sirve.

Tiene muchos puntos de mejora está claro

  • Modelo de seguridad
  • Usar una APP propia para controlar mejor el feedback al usuario

En realidad el punto más fuerte de este modelo creemos que es que es facilmente convertible en un sistema de autenticación de dos fases … Adjunto el código del WAR de la PoC para el que tenga interés en ver el código.

Entrada publicada en Sin categoría | Comentarios cerrados

Timetracking system for taiga using slack integration

En zylk.net llevamos unos diez años gestionando los proyectos y los soportes con el bugtracker (mantis). En este último mes estamos probando distintas herramientas más próximas a la gestión de proyectos que a la gestión de issues/tasks etc.. Hemos probado algunas SAAS otras on premise etc... De momento con la que más a gusto nos estamos encontrando es con taiga...

Una de las cosas que no tiene taiga es la posibilidad de imputar horas reales en las notas de las historias de usuario, issues, tasks etc.. Con lo que hace un poco más compleja la gestión de las horas reales imputadas en un proyecto. Por esa razón y dado que estamos usando también el sistema de mensajería slack a nivel interno he desarrollado este fin de semana un modulo (no lo llamaría módulo de taiga ya que en realidad no lo es) para permitir hacer el seguimiento de tiempos de las tareas definidas en un proyecto del taiga.

Para ello contaba con los siguientes ingredientes

  • Pocos o nulos conocimientos de la arquitectura de taiga (Python pip etc..)
  • Un sistema de mensajería basado en slack con un bot que procesa la información de los canales de slack (Proyecto interno que estamos desarrollando en zylk.net que esperamos poder presentar el año que viene). Hay un montón de post relacionados con el tema en el blog de zylk [1][2][3] que aunque parecen inconexos tiene un objetivo común.
  • Modulo de integración entre taiga y slack

Visto el primer ingrediente ... quedaba descartada la mejor opción a nivel técnico que era hacer un módulo de taiga. Así que lo que diseñe fue lo siguiente

  1. Mandar los mensajes de las acciones realizadas en taiga a un canal de slack, usando el módulo de taiga disponible a tal efecto
  2. Parsear esos mensajes y extraer la información de seguimiento de tiempos, una expresión regular ... [".*<https://taiga.zylk.net/project/(.*?)/task/(.*?)\\|#.*?:(.*)>.*\\n+.*Comment by (.*?):(.*@timetracking\\s{1}(\\S*)\\s?.*)"]
  3. Guardar esa información un backend y notificar que se ha realizar la acción. De momento en una base de datos relacional.

Para ello bastó con diseñar la siguiente tabla

 

CREATE TABLE timetracking
(
   project VARCHAR(255),
   taskId VARCHAR(255),
   task VARCHAR(255),
   channel VARCHAR(255),
   timestamp BIGINT,
   message TEXT,
   timetrack DOUBLE,
   user VARCHAR(255)
);

Y usar el BOT que ya tenemos en zylk para que respondiera a la expresión regular. Con este sencillo modelo hemos conseguido que si se añade la siguiente instrucción (@timetracking 1:00) a un comentario de una tarea en taiga se añada esa imputación a la tabla anteriormente descrita ...

El sistema tiene una enorme cantidad de mejoras posibles... pero tiene una virtud, que no tendría un módulo de taiga, y es que nos permite realizar imputación sobre proyectos tanto desde la interfaz de taiga, como desde el propio sistema de mensajería de slack. A continuación mostramos unas imágenes de cómo sería el flujo de una imputación, el flujo sigue la el siguiente esquema

  1. Se crear una nota en una tarea de un proyecto de taiga, que tenga el texto @timetracking 2:00
  2. El mensaje se envía al canal de slack del proyecto en cuestión
  3. El BOT que tenemos desarrollado en zylk, interpreta ese mensaje, extrae la información necesaria (proyecto, task, timetracking, usuario etc...) y la añade a la tabla
  4. El BOT notifica que ha realizado la acción con éxito

 

Entrada publicada en Sin categoría | Comentarios cerrados

Simulando errores de red o mejorando la calidad de nuestro software

Una de las cosas que no se suelen probar en los proyectos de desarrollo de software es cómo operan los desarrollos realizados antes situaciones en las que la red falla (los famosos micro-cortes de red tan utilizados para justificar el mal funcionamiento de un software)

Hay proyectos, como el ejercito de monos de netflix ... que sirven para probar estas cosas (hay un mono que se dedica a hacer putadas en la red para ver si los componentes son tolerantes a fallos o no y sobre todo si tenemos efecto de bola de nieve, que es el peor de los problemas cuando diseñas sistemas complejos).

Teniendo claro que lo mejor sería integrar el ejército de monos en los sistemas de calidad de zylk, vamos, de momento, a ser un poco menos ambiciosos y vamos a usar únicamente un conjunto de comandos de sistema operativo para simular problemas en la red.

Para ello haremos uso del comando netem desde el que podemos simular caídas de red, latencia variable, perdidas de paquetes etc... Los comandos base que podemos usar son

 

>sudo tc qdisc add dev eth0 root netem delay 900ms 10ms distribution normal

Que nos permite añadir un delay a las peticiones de red (eth0) que corresponde a una distribución gaussiana con un máximo de delay de 900ms y un mínimo de 10ms centrada en el 900 y con una campana de 10 de ancho.

>sudo tc qdisc add dev eth0 root netem loss 0.1%

Que nos permite simular una perdida de paquetes del 0.1%

Existen comandos equivalentes para forzar la corrupción de paquetes, duplicidad de los mismos y un montón de cosas más...

La conclusión, una vez que usas este tipo de técnicas para realizar las QA de los proyectos, es que ... Ohhh dios mio!!! (que dirían en friends) los patrones que usa la gente no suelen ser los correctos y fallan estrepitosamente ante este tipo de problemas. Además ahora hay que tener especial cuidado ya que todo se ve como un servicio y un cliente que se conecta a dicho servicio.... Habrá que repasar este patrón. Y estar más atento a lo que hace la gente de netflix que de este tema parece saber mucho mucho mucho... En zylk ya llevamos algún tiempo usando estas técnicas para probar, en condiciones adveras, algunos de los proyectos que realizamos.

Entrada publicada en Sin categoría | Comentarios cerrados

How to control public shared content in Alfresco

Last day, I was asked for a client about how to control "public" shared content in Alfresco Share in a simple way. These are some of the ideas of the support conversation:
 
[me] First, just write in the Alfresco Share search box, the next querys. You should see your shared content. 
 
ASPECT:"qshare:shared" 
ASPECT:"qshare:shared" AND @cm:creator:"ccl001"
ASPECT:"qshare:shared" AND @qshare:sharedBy:"ccl001"
ASPECT:"qshare:shared" AND @cm:modified:["2014-12-31" TO NOW]
ASPECT:"qshare:shared" AND @cm:modified:[MIN TO "2013-12-31"]
 
[client] OMG! There exists a lot of public documents... What can we do for managing this ? Querys are right but many final users do not understand complex queries, and they are not familiar with aspects.
 
[me] Right, we can implement a document filter query in sites and/or in My documents dashlet, for final users.
 
[client] We are not sure about document library filters... because filters will appear in all sites, for all users. What about for Alfresco Admins ? May we get a list of public nodes ? How can we unshare these public urls ? 
 
[me] Just removing qhare:shared aspect. For alfresco admins, we can run a simple script in Javascript API for getting a brief report in CSV, via Alfresco Javascript Console. This should be valid also for users that create rules on their sites, executing the JS code. This is only valid for 1000 items, although you can run it several times (which is not always possible). 
 
var nodes = search.luceneSearch('ASPECT:"qshare:shared"');
var count = 0;
for each(var node in nodes) {
        count = count + 1;
        logger.log(count + ": "+node.displayPath+"/"+node.name);           
        // Uncomment these two lines for unsharing
        //logger.log("  Cleaning the aspect..");    
        //node.removeAspect("qshare:shared");
        //node.save();
        //logger.log("  Done");                        
}
 
[client] Mmm... I don't see the full picture, yet.
 
[me] Ok, we can filter query by modified date too. You can assume that content is shared before being modified and then to unpublish them if the content was modified many time ago.
 
var nodes = search.luceneSearch('ASPECT:"qshare:shared" AND @cm\\:modified:["2014-12-31" TO NOW]'); 
 
[client] This is a little tricky... but I'm not sure about it.
 
[me] Ok, you can use cm:effectivity aspect in Alfresco content, and use cm:to property for controlling the end lifecycle on your public nodes and urls. So, add aspect Effectivity, to the node to be shared, and then edit effectivity properties.
 
[client] I don't see it, this implies more work for final users.
 
[me] Well, you may also use content rules, for setting cm:to by a default relative date, if the content is shared.
 
[client] Better. Something more ?
 
[me] Then, we can write another script that checks the expiration date cm:to (i.e. today), and then remove the aspect or aspects.
 
var today  = new Date();
var month = today.getMonth() + 1; //months from 1-12
var day     = today.getDate();
var year    = today.getFullYear();
var mydate = year+"-"+month+"-"+day;
var nodes = search.luceneSearch('ASPECT:"qshare:shared" AND @cm\\:to:"'+mydate+'"');
var count = 0;
for each(var node in nodes) {
  count = count + 1;
  logger.log(count + ": "+node.displayPath+"/"+node.name);
  logger.log(" This public url is expired --> "+node.properties["cm:to"]);
  logger.log(" Cleaning the aspect..");
  node.removeAspect("qshare:shared");
  //node.removeAspect("cm:effectivity");
  node.save();
  logger.log("Done");
}
 
[client] It sounds even better.
 
[me] And finally, we can do a daily quartz executing the javascript code, to unshare the public urls.
 
 
[client] Ok, let's do it. 
 
P.S: Tested in Alfresco 4.2.4 EE (although it may work in other versions).
Entrada publicada en Sin categoría | Comentarios cerrados

Avro RCP yarn and slider II

Siguiendo con la visión de una arquitectura basada en yarn y mirco servicios ... os dejo un diagrama completo de los componentes y su comportamiento

 

 

Entrada publicada en Sin categoría | Comentarios cerrados

Avro RCP yarn and slider

Siguiendo con los artículos relacionados con YARN, SLIDER y arquitecturas relacionadas con BigData mostramos a continuación una posible arquitectura basda en los siguientes tres elementos

Donde lo importante es que con este tipo de arquitectura podríamos disponer de servicios con las caraterísticas indicadas

La idea en este caso es desplegar los servicios que se pueden generar con AVRO en un cluster de yarn empaquetando estos servicios como aplicaciones YARN.

Entrada publicada en Sin categoría | Comentarios cerrados

Online edition with Libreoffice in Alfresco 5

Last days I was asked for a tip (again) for enabling online edition via webdav with Libreoffice in Alfresco 5. It is tested with this setup:
  • Ubuntu 14.04 LTS (although it can work in other Linux)
  • Libreoffice 4.2.8.2 (it comes with the Linux distro)
  • Alfresco CE 5.0c && 5.0d (the jar is valid for Alfresco 4 too)
  • Last versions of Firefox and Chrome
So, in your Alfresco 5 server you need to download the jar file and copy in $ALF_HOME/tomcat/shared/lib directory, restarting alfresco service:
 
 
Once, you should see "Edit. Online" action for MS-Office and Libreoffice mimetypes. It is clear that you need webdav enabled in your repository (and access to the webdav context).
 
Then, for make it work, you need to register an url-handler based protocol for dav:// and davs:// urls with Libreoffice. This can be done via two methods (that can work in different versions of Linux).
 
Method 1:
 
Create the next file, and the corresponding path, if it does not exist.
 
$ vim ~/.local/share/applications/libreoffice-alf.desktop 
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Name=LibreOffice for Alfresco
GenericName=LibreOffice for Alfresco
Comment=Online Editing in Alfresco via webdav
Icon=libreoffice-writer
TryExec=soffice
Exec=soffice %U
Terminal=false
Type=Application
Categories=Office;
MimeType=x-scheme-handler/davs;x-scheme-handler/dav
 
2. Create the mimeapps.list file, if it does not exist. If it exist, just add the two x-scheme handlers,
 
$ vim ~/.local/share/applications/mimeapps.list
[Added Associations]
x-scheme-handler/davs=libreoffice-alf.desktop;
x-scheme-handler/dav=libreoffice-alf.desktop;
 
Method 2: 
 
This is done for all users of the operating systems, you need sudoer privileges
 
1. Just create the file in the next path:
 
$ sudo vim /usr/share/applications/libreoffice-alf.desktop
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Name=LibreOffice for Alfresco
GenericName=LibreOffice for Alfresco
Comment=Online Editing in Alfresco via webdav
Icon=libreoffice-writer
TryExec=soffice
Exec=soffice %U
Terminal=false
Type=Application
Categories=Office;
MimeType=x-scheme-handler/davs;x-scheme-handler/dav
 
2. Add x-scheme-handlers to mimeinfo.cache
 
$ sudo vim /usr/share/applications/mimeinfo.cache
 
# Add to the file
x-scheme-handler/davs=libreoffice-alf.desktop;
x-scheme-handler/dav=libreoffice-alf.desktop;
 
3. Update desktop cache
 
$ sudo update-desktop-database 
 
Then when you "Edit. online", you see some dialog for remembering the action for opening the url. Libreoffice asks for your credentials once in a session.
 
For Windows users, it is possible to register the protocol too, with the help of (there is also a .reg file in the downloads section of the googlecode project - put the correct path for the Libreoffice command):
 
Entrada publicada en Sin categoría | Comentarios cerrados

Usando yarn y slider para levantar procesos en un cluster de hortonworks

Siguiendo con las pruebas y las arquitecturas relacionados con bigdata vamos a inspeccionar las capacidades de yarn para levantar procesos en un cluster HDP. Lo primero que habría que introducir es el producto yarn. De la página siguiente de hortonworks podemos obtener la siguiente definición

YARN is the prerequisite for Enterprise Hadoop, providing resource management and a central platform to deliver consistent operations, security, and data governance tools across Hadoop clusters.
YARN also extends the power of Hadoop to incumbent and new technologies found within the data center so that they can take advantage of cost effective, linear-scale storage and processing. It provides ISVs and developers a consistent framework for writing data access applications that run IN Hadoop.


Por tanto como podemos ver yarn es una suerte de sistema operativo para interactuar con hadoop y que éste (yarn) gestione los recursos del cluster de hadoop/hortonworks.

Sobre Yarn existen varios APIs que podemos usar para desplegar nuestros propios procesos.

  • YARN (API de más bajo nivel sobre el que se montan, TEZ y SLIDER)
  • TEZ (API para simplificar el desarrollo de aplicaciones que se pueden ejecutar sobre YARN, se puede ver como un API para ejecutar procesos, por ejemplo scripts de PIG, HIVE etc...)
  • SLIDER (API que simplifica el desarrollo de aplicaciones que se pueden ejecutar sobre YARN, a diferencia de TEZ slider está diseñado para es levantar servicios, como explican el la página de howtonworks, Slider is a framework for deployment and management of these long-running data access applications in Hadoop)


Una vez presentados los tres "sabores" principales vamos con el caso de uso que estamos probando. En este caso lo que vamos a crear es bot para slack que va a leer los mensajes de un canal y va a contestar a los mensajes de dicho canal. La idea es que una vez que tengamos esa aplicación java desarrollada la levantemos sobre el cluster de hdp/yarn usando slider.

La arquitectura general de la solución es la siguiente




Donde podemos ver que los eventos producidos en un canal de slack son consumidos por el bot que se ha levantado en un cluster de hadoop usando slider. Para desarrollar esta prueba de concepto los requisitos son

El primer requisito se ha tratado en otros posts en este blog. El segundo requisito es la parte en la que nos hemos centrado para crear esta entrada. Un paquete slider se compone (a grandes rasgos) de los elementos que vemos en la siguiente imagen



Donde lo principal son los ficheros de configuración, los scripts de arranque, y los binarios que se ejecutan. Los binarios son la parte que en este caso hemos desarrollado en java. Los archivos de configuración nos permiten definir las siguientes características:

  • classloader de la aplicación
  • version de java que se quiere usar
  • memoria reservada para el proceso
  • nombre del paquete/servicio
  • parámetros extra que se pasan al proceso (pueden ser parámetros gestionados por el que despliega el proceso o por el propio nodo donde se levanta el proceso)
  • threshold que nos permite definir los límites que hacen que un proceso que se ha detenido se vuelva a levantar automáticamente. Por ejemplo si se ha producido un error de comunicación y el proceso se muere según definamos los límites el proceos se volverá a levantar de manera automática.
  • numero mínimo y máximo de procesos que se deben levantar
  • ... y un montón más de características que podemos ver en el site del proyecto

Una vez que tenemos el paquete creado podríamos desplegarlo usando los siguientes comandos de slider

  • slider  package --install --replacepkg  --name MOMO_BOT --package /home/hadoop/jenkins/jobs/slack_bot/slack_bot-0.0.1-SNAPSHOT-slider-package.zip
  • slider stop momo_bot
  • slider  destroy momo_bot
  • slider  create momo_bot --template /home/hadoop/jenkins/jobs/slack_bot/appConfig-default.json --resources /home/hadoop/jenkins/jobs/slack_bot/resources-default.json

Una vez ejecutada esta secuencia podremos ver nuestro proceso desde la vista slider de nuestro ambari.

Para la generación del paquete hemos usando maven y para el despliegue automatizado jenkins. El objetivo de esta prueba era analizar las características de slider como modelo de despliegue de aplicaciones. El hecho de desplegar una aplicación usando este modelo dota al servicio de las siguientes características

  • auto-escalado
  • monitorización y re-arranque de containers en base de los parámetros definidos en la configuración del paquete slider
  • gestión de los recursos asociados al servicio usando del modelo de containers de yarn
  • registro automático del servicio etc..

En esta página se puede ver todo lo que slider puede hacer (https://slider.incubator.apache.org/docs/manpage.html). Lo más destacable a nuestro modo de ver sería

  • A user can create an application instance.
  • Users can flex an application instance: adding or removing components dynamically. If the application instance is live, the changes will have immediate effect. If not, the changes will be picked up when the instance is next started.

Y como última conclusión ... slider es mucho más que de lo que se ha explicado en este post... parafraseando a pedro salinas ... Eso no es nada aún. Buscaos bien, hay más.

Entrada publicada en Sin categoría | Comentarios cerrados