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

DevOps lecciones para CIOs - by ScriptRock

Definir DevOps correctamente

Una buena forma de entender que es DevOps es entender cual fue el origén de este movimiento. En particular el incremento de la desconexión entre las funciones de desarrollo y operaciones en los departamentos de IT. A pesar de que juegan en el mismo equipo, sus objetivos son muy diferentes y suelen chocar entre sí. Mientras a unos les interesa mejorar el producto a través del cambio (desarrollo) otros bregan por el mantenimiento de la calidad del servicio y la disponibilidad (operaciones).

Por consiguiente DevOps es cualquier esfuerzo en una organización para alinear los objetivos de los equipos de Desarrollo y Operaciones. En la práctica esto puede ser un cambio cultural o de procesos. Además puede permitir, pero no deberia centrarse en, la implementación de ciertas herramientas, particularmente herramientas de automatización.

Colaboración primero, especialmente para herramientas

El cambio cultural es dificil. Comprar herramientas es fácil, y con los grandes ahora en DevOps pesa lo que se dice de "Nunca nadie ha sido despedido por comprar le a IBM/Microsoft" [0]
Muchas StartUps apuntan a su uso de Puppet o Jenkins cuando se les pregunta acerca de DevOps.
La forma más sencilla es descomponerlo en dos elementos centrales, colaboración y automatización. Y no es accidental que colaboración sea nombrada en primer lugar. Si se empieza con la automatización la cosas pueden empeorar. Quizás esto se note mejor con un ejemplo.

Un administrador de aplicaciones se dió en la encrucijada de implementar DevOps dentro de su companía con el uso de una herramienta de automatización de configuración llamada Chef. Luego de que su equipo logró sobrellevar el obstaculo de la, nada despreciable, curva de aprendizaje, él quedó conforme con la mejora que observó en el proceso de Build de su ambiente de desarrollo y testing.
El problema vino del hecho de que él no consultó con operaciones sobre este cambio. Como era de esperar, el equipo de operaciones decidió que ellos no iban a usar Chef para que construya dentro de sus ambientes de Staging o Producción. Los beneficios mostrados fueron desvirtuados y el uso de Chef discontinuado.

Para evitar estos problemas recordar esto:

• Una iniciativa no es DevOps si esta contenida en un solo grupo.
• Está BIEN dar lugar a la implementación de una herramienta si el acuerdo es alcanzado con ambos lados de que es la herramienta adecuada para hacer el trabajo.
• Evitar las herramientas que refuercen los silos a toda costa. Una herramienta de funcionalidad cruzada que es solo usada por un equipo solo hace las cosas aún peor.

No Crear otro equipo

Esto no deberia ser mencionada a menos que seas un CIO prodigio de 25 y que lo hayas visto antes. Toma por ejemplo Service Oriented Architecture (SOA) y Business Process Managment (BPM).  Ambas son iniciativas valiosas en si mismas, pero ambos acrónimos fueron victimas de una exaltación innecesaria y de promesas incumplidas de los ansiosos vendedores.

Las lecciones aprendidas por las companias son que construir iniciativas alrededor de nuevos, y separados equipos tiene a lo mejor un efecto negligente. Y en el peor hace el éxito imposible.

Las razones por las que crear otro equipo nuevo no funciona son las mismas razones por las que no funciona su iniciativa DevOps. Eliminar la función de su equipo principal de operaciones y desarrollo elimina su compromiso con él. Se convierte en un problema ajeno. Peor aún, saben que si funciona el éxito es de otro. No es necesario explicar entonces que es lo que esto significa para la colaboración entre los equipos y los nuevos colegas DevOps. Todo lo que se logran con la creación de un nuevo silo es un silo con objetivos nobles pero uno que está condenado al fracaso desde el principio.

DevOps es colaboración. En un ambiente donde la colaboración entre equipos es mala, agregar un nuevo equipo solo hace las cosas peores. DevOps debería ser una responsabilidad de todos, una iniciativa de todos y, finalmente, un éxito de todos.

Esto no es solo DevOps

Que hay en una palabra? La simplicidad y franqueza del término DevOps es algo hermoso. Es difícil lograr una palabra que haga una mejor descripción del objetivo de alinear los intereses y trabajo de los equipos de desarrollo y operaciones. 

se 

Sin embargo hay un problema en esto. Como un CIO Corporativo tu equipo de IT esta mucho más de desarrollo y operaciones. No hay duda que estos dos equipos se beneficiarían de un poco de terapia de pareja pero responda a estas preguntas. Tienen sus desarrolladores nada más que palabras buenas sobre su equipo de Calidad? Su equipo de operaciones canta alabanzas regularmente a la seguridad? Los arquitectos son queridos por alguien más que ellos mismos? 

Desmantelar la pared entre desarrollo y operaciones es un buen lugar para empezar cuando se tiene un departamento de IT disfuncional. Sin embargo existen otras paredes entre otros equipos. Las paredes que no están dentro del enfoque de la iniciativa DevOps seguramente se fortalecerán. 

Puede la mejora en la colaboración y la automatización beneficiar a otras áreas? Por supuesto que se puede. No hacer de DevOps otro silo. Incluya a otros equipos siempre que sea posible. Deberías considerar el uso de otro término para definir este tipo de trabajo.

Esto por supuesto debe ser equilibrado. Su enfoque sobre todo al principio debería ser acotado lo máximo posible para aumentar las probabilidades de éxito. Lo que principalmente se busca es no excluir a los principales interesados. 

Finalizando esta fue una muy interesante lectura (semi traducida por mi :S ) sobre DevOps que nos ofreció ScriptRock [1]

[0] http://c2.com/cgi/wiki?NobodyEverGotFiredForBuyingMicrosoft
[1] https://www.scriptrock.com/devops-lessons-for-cio

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