Mostrando las entradas con la etiqueta managment. Mostrar todas las entradas
Mostrando las entradas con la etiqueta managment. Mostrar todas las entradas

lunes, 28 de octubre de 2013

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

sábado, 26 de octubre de 2013

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.