Analizando Quiper - Compará precios descuidados

Quiper[0], es una aplicación móvil desarrollada en la empresa donde trabajo, que se llama Quicuo[1].

Su nombre es principalmente una fusión de la palabra Quicuo y Super. Es una aplicación que permite comparar los precios de todo tipo de productos en los supermercados más grandes del país y en principio funciona bastante bien para los que son de Capital y Gran Buenos Aires.

Aplicación Movil
La aplicación móvil está desarollada en HTML, CSS y Javascript. Con una terrible ayuda de PhoneGap [2] para hacerla multi plataforma. Principalmente fue creada para Android[3] pero con muy pocos cambios puede ser y va a ser generada para IPhone muy pronto.

Backend - API
La API de consulta está desarrollada sobre node.js[4], con expressjs[5] como Framework de desarrollo y sequelize[6] como ORM[7] para las consultas a la base de datos.
Todo esto es servido a tráves de pm2[15] como supervisor de procesos en nodejs y con Nginx[16] como WebServer.

Backend - DB, Extracción y Analisis
La extracción que es parte principal del desarrollo está escrita sobre Python[9], en principio se analizó un Scrappeador profesional pero para los primeros intentos nos pareció un poco complejo así que se optó por hacer un Scrapper propio bien amoldado para nuestro propósito. Por consiguiente, se utilizaron diferentes librerías que son bastante típicas en verdad para esto. BeautifulSoup[10] como parseador de las respuestas HTML para extracción de datos. Mechanize[11] como generador de requests dinamicas y crawler de webs, en principio fue generado todo con Mechanize y luego en algunos casos simples se usó requests[12] una librería con una API mucho más elegante. Además para guardar estos datos de forma más programática se uso SQLObject[13] como ORM en esta etapa.

Finalmente el análisis y unión de datos fue escrito en PHP[14] y se usó su conector para MySQL limpio sin ORM.

Servidores
Básicamente los servidores están en Amazon EC2[17] y por el momento son Dos uno como WebServer para los servicios que corren Nodejs. La Api que consume la app móvil y la Web que todavia no se lanzó.
Y otro server que es el más grande y es el de la DB que tiene MySQL y corre periódicamente la extracción y análisis de datos.
Los servidores fueron ambos desplegados con Ansible [18]

Un crisol de tecnologías libres que unidas generan una aplicación que funciona y cumple su objetivo, principalmente participaron de este proyecto Dos Desarrolladores(principalmente uno para Phonegap css html y js y otro para el Analisis de datos con PHP), un ProjectLeader, el CEO de Quicuo y un SysAdmin/Desarrollador Python (este soy yo).

[0] http://www.quiper.com.ar
[1] http://www.quicuo.com.ar
[2] http://phonegap.com/
[3] https://play.google.com/store/apps/details?id=com.quicuo.quiper
[4] http://nodejs.org/
[5] http://expressjs.com/
[6] http://sequelizejs.com/
[7] http://en.wikipedia.org/wiki/Object-relational_mapping
[8] http://www.mysql.com/
[9] https://www.python.org/
[10] http://www.crummy.com/software/BeautifulSoup/
[11] http://wwwsearch.sourceforge.net/mechanize/
[12] http://docs.python-requests.org/en/latest/
[13] http://sqlobject.org/
[14] http://php.net/
[15] https://github.com/Unitech/pm2
[16] http://nginx.org/
[17] http://aws.amazon.com/es/ec2/
[18] http://www.ansible.com/home

El cambio continúa

Teniendo como base el proverbio taoista que dice algo así como "el cambio es la única constante". Avancé con una cantidad de cambios. Cambié definitivamente mi Ubuntu 13.10, por Huayra [0]el Sistema Operativo que se usa en la Netbooks del programa Conectar Igualdad [1] y que ahora uso como SysAdmin de la empresa Quicuo.

Es muy bonito mejoraron mucho el diseño si mal no recuerdo antes era demasiado violeta, me gusta ver como "vuela la vaca" cuando la Notebook arranca, con respecto al funcionamiento, el debian wheezy que tiene como base y el gestor de ventanas Mate son muy livianos. Lo que me hizo recordar que me estaba faltando archey en mi terminal [2].

Otra cuestión es con el tema del trabajo. En Quicuo estamos en pleno proceso de cambio de los servidores físicos a servidores virtuales en Amazon.  Hoy en día ya tenemos 3 servidores que son los que se usan para desarrollo, testing y producción funcionando en instancias EC2 [3] por ahora desarrollo y testing funcionan con instancias Micro y producción se la banca bastante bien con una Medium [4]. Esto seguido del uso de Ansible[5] ha hecho bastante fácil la migración sobre todo teniendo en cuenta que la migración más importante que era Producción ya la hice hace tiempo cuando nos mudamos de oficinas. En cuanto a arquitectura de redes y servidores aún hay varias cosas por hacer como dividir a Producción en diferentes servidores por funcionalidad ya que hoy en un mismo servidor está la DB, el WebServer y otros muchos servicios corriendo ahí, la idea sería optimizar cada server para una sola funcionalidad (uno como Servidor de Base de Datos, otro como servidor web y así). Esto además lo hace más modular y más fácil de intercambiar o hacer cambios aunque no encontré o no sé como buscar documentación que avale esto.

Con respecto al aprendizaje, en estos días con el mismo cambio de la Notebook a Huayra (haciendo el backup por las dudas), encontré unos videos [7] de Amazon que son aparentemente para dar la certificación y me los puse a ver gracias a eso terminé de aprender algunas cosas con respecto a los Security groups [6] y otras cuestiones del funcionamiento de los servicios Route 53, S3 y otros que son muy interesantes y que voy a ver como implementar por lo pronto.

Finalmente es un año de muchos desafios entre ellos están organizar o al menos conocer mejor a la comunidad de software libre en San Martin [8] y ver si podemos hacer aunque sea un evento pequeño al menos.

Igualmente el año recién comienza y todavía no me tome vacaciones parece cansador tanta cosa por hacer pero no es cansador cuando uno ama lo que hace.

[0] http://huayra.conectarigualdad.gob.ar
[1] http://www.conectarigualdad.gob.ar
[2] http://www.taringa.net/posts/linux/14628839/Archey-una-nueva-imagen-a-la-terminal.html
[3] http://aws.amazon.com/es/ec2/
[4] http://aws.amazon.com/es/ec2/instance-types/
[5] http://www.ansible.com/
[6] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html
[7] http://www.cbtnuggets.com/
[8] http://www.facebook.com/SanMarTux

Automatizando Quicuo - La charla DevOps

Para uno que generalmente es tímido o le cuesta entrar en confianza una vez que esa barrera es tirada abajo es fácil para uno hablar sobre lo que sabe, cuando no solamente lo sabe sino que, lo probó y trabaja con eso hoy en día.

La gente de "DevOps en Español" [0] que son todos chabones grosos con varios años de experiencia me dieron la oportunidad de dar a conocer mi experiencia.

Entonces intenté preparar una charla de nivel técnica inicial ya que no es nada complejo pero con experiencias verdaderas sobre Automatización basada en un post mío de este mismo blog[1].

Cuenta la historia que un SysAdmin llegó a la onda DevOps de la mano Python, luego de ir a un PyDay en Junin, y asistir a una charla muy interesante de Andres Riancho[2] de w3af[3] llamada "Infraestructure as a code"[4] ahí fue donde empecé realmente a entender el funcionamiento de Fabric anteriormente lo había leido pero no le habia prestado tanta atención.

El viernes confiado por la experiencia adquirida, y nuevamente gracias a la apertura y muy buena onda de la gente de DevOps pude contar muy humildemente mi experiencia automatizando un entorno de deploys sencillo de Desarrollo a Producción. No lo puse en la presentación por que haciendo ahora la retrospectiva es que recuerdo que todo nació de aquellas charlas muy interesantes en el PyDay de Junin. (Huff y ni hablar la charla de escalabilidad que dió un Mendocino ex Google).

Entonces les dejo el Link de mi presentación con el fruto de un poco de esfuerzo, una buena libreria js y una gran buena onda de Quicuo (empresa donde trabajo que siempre me permitió innovar)

www.deploshark.com.ar/automatizando-quicuo/

Mil Gracias a todos... Y no puedo dejar de nombrar a la excelente presentación improvisada de Alejandro Ferrari que no solo me dió una sana envidia sino que así como la de Andres en su momento me inspira a hacer cosas aún más grosas.

[0] http://www.meetup.com/DevOps-en-Espanol/
[0] bis @devops_es
[0] bis2 www.devops-es.com
[1] http://blog.deploshark.com.ar/2013/09/fabric-automatizando-quicuo.html
[2] https://twitter.com/w3af
[3] http://w3af.org/
[4] http://w3af.org/infrastructure-as-code

ansible - Python para SysAdmins 2da Parte

Luego de jugar con la linea de comandos de ansible[0], y tomarme no mucho tiempo pese a que no me cae muy bien YAML se me hizo muy fácil generar mi primera configuración.

Definiciones:
playbook [1]: es el nombre que le da ansible al archivo donde se define la configuración que se desea tener en los servidores. Este está definido con una sintaxis YAML. [2]
plays: un playbook está compuesto por varios "plays". El objetivo de un "play" es mapear un grupo de hosts en roles bien definidos. representado por lo que ansible llama "tasks". A nivel básico, una "task" es nada más que una llamada a un modulo de ansible.

Esta es mi configuración de ejemplo que no es ni siquiera util pero es una forma de empezar a probarlo.

---
- hosts: epas.dev
  user: www-data
  sudo: yes
  tasks:
    - name: Apache2 no tiene que estar
      apt: pkg=apache2 state=absent
    - name: Confirmando funcionamiento de Nginx
      service: name=nginx state=started

Lo interesante es ver que cuando defino un servicio no defino el Comando a ejecutarse para dejarlo en el estado necesario como si hacemos en Fabric [3] y sino que solamente Declaramos nuestra intención de como queremos que este funcionando.

En este caso previamente voy a parar nginx solamente para que vean que sucede.

admin@quicuo-kaizen:/home/proyectos/serviquo/plays$ ansible-playbook playbook.yml 

PLAY [epas.dev] *************************************************************** 

GATHERING FACTS *************************************************************** 
ok: [epas.dev]

TASK: [Apache2 no tiene que estar] ******************************************** 
ok: [epas.dev]

TASK: [Confirmando funcionamiento de Nginx] *********************************** 
changed: [epas.dev]

PLAY RECAP ******************************************************************** 
epas.dev                   : ok=3    changed=1    unreachable=0    failed=0

Vemos como cada "task" es ejecutada, e idempotente [4] donde cada tarea si no es necesaria no se vuelve a ejecutar solamente es comprobada. y al final hay un resumen con las tareas que fueron ejecutadas.

Hay muchas cosas más que todavia no pude poner en práctica por cuestión de tiempo pero que son muy poderosas como:
templating
Se puede definir un template armado en el bonito jinja2[5] y después subirlo a al servidor.
handlers
Son eventos en el caso de que se hagan cambios el siguiente "task" es un ejemplo sacado directamente de la web de ansible [6]

- name: template configuration file
  template: src=template.j2 dest=/etc/foo.conf
  notify:
     - restart memcached
     - restart apache

handlers:
    - name: restart memcached
      service:  name=memcached state=restarted
    - name: restart apache
      service: name=apache state=restarted

Los handlers son básicamente otros task que se ejecutan solamente en el caso de un cambio en el task donde fue configurado.
En este caso se reinicia el memcached y el apache solamente en el caso de que se copie el template y el archivo sea reemplazado efectivamente.

Los invito a seguir investigando y seguir leyendo!!! más sobre python, sobre ansible, sobre sysadmins!

[0] http://www.ansibleworks.com/docs/intro_adhoc.html
[1] http://www.ansibleworks.com/docs/playbooks.html
[2] http://www.ansibleworks.com/docs/YAMLSyntax.html
[3] http://gonzamartinez.blogspot.com.ar/2013/09/fabric-automatizando-quicuo.html
[4] http://es.wikipedia.org/wiki/Idempotencia
[5] http://jinja.pocoo.org/docs/
[6] http://www.ansibleworks.com/docs/playbooks.html#handlers-running-operations-on-change

ansible - un Configuration Management en Python

Ansible [0] es parte de los denominados configuration managments, es una de las herramientas más nuevas dentro del sector donde son más reconocidas Puppet (Ruby), Chef (Ruby), y tal vez Salt (Python) entre otras.[1]

Despues de mi fatidico intento con su versión Web (escrita en Django + Celery) [2] (que igualmente tengo que terminar de probar). Y luego de asistir al debate de "DevOps en Español" el dia de ayer. Ayer mismo me puse a instalar ansible en su versión CLI que no solo en Ubuntu es una trivialidad sino que es sencillo de hacer andar con una configuración muy sencilla para empezar.

Instalando Ansible en Ubuntu

$ sudo add-apt-repository ppa:rquillo/ansible
$ sudo apt-get update
$ sudo apt-get install ansible

para instalaciones en otras distros pueden leer por acá [3]

El problema de instalarlo de esta manera es que en el repo está la versión 1.1 y si te pasa como a mi podés actualizarlo con 

$ sudo pip install ansible --upgrade

Pero a mi me paso que el pip me lo instala en /usr/local/bin/ asi que tuve que hacer lo siguiente

$ sudo rm /usr/bin/ansible*
$ sudo ln -s /usr/local/bin/ansible* /usr/bin/.

Una vez instalado uno tiene unos comandos nuevos llamados ansible y ansible-playbook entre otros.

Jugando con ansible en cli

En /etc/ansible/hosts configuramos los hosts con los que vamos a jugar.

$ sudo vim /etc/ansible/hosts
# acá puse un par de hosts contra los que 
# ya estoy validado con mi llave pública
# por lo que no me va a preguntar clave :P

Y entonces  probamos nuestro primer comando

$ ansible all -m ping
# En estos hosts no tengo el mismo usuario que en mi notebook
# por lo que tengo que hacer un pequeño cambio a este comando
$ ansible all -m ping -u www-data
epas.prod | success >> {
    "changed": false, 
    "ping": "pong"
}

epas.dev | success >> {
    "changed": false, 
    "ping": "pong"
}

epas.test | success >> {
    "changed": false, 
    "ping": "pong"
}

De esta forma se puede ejecutar comanditos locos sin tener que hacer ninguna configuración 

$ ansible all -a "/bin/echo hello"
epas.dev | success | rc=0 >>
hello

epas.test | success | rc=0 >>
hello

epas.prod | success | rc=0 >>
hello

Pero bueno ese no es el objetivo principal de ansible pero para esa parte vamos a hacerlo en próximo post ya que no quisiera que se haga muy largo.

[0] http://www.ansibleworks.com/why-ansible/

[1] http://en.wikipedia.org/wiki/Comparison_of_open_source_configuration_management_software

[2] http://www.ansibleworks.com/ansibleworks-awx/

[3] http://ansibleworks.com/docs/intro_installation.html