Diferencia entre revisiones de «Ansible»

Revisión de 14:21 18 ago 2016

Instalación de Ansible

Leer doc de ansible

En Centos ha sido tan fácil como instalar el repositorio de EPEL e instalar el paquete de ansible.

Inventario

Un ejemplo de fichero con mis máquinas en Vagrant sería:

[local]
localhost	ansible_connection=local

[vagrant]
test1		ansible_host=192.168.5.211
test2		ansible_host=192.168.5.212

[vagrant:vars]
ansible_user=vagrant
ansible_ssh_pass=vagrant

Una máquina puede estar en un grupo o en varios y tambien se pueden crear hijos de un grupo, lo que heredaría sus valores por defecto

Los valores por defecto de un grupo se definen con el [<grupo>:vars]

También se puede usar un fichero con la clave RSA privada para conectarse a un servidor, tendrímos que poner el siguiente parámetro:

ansible_ssh_private_key_file = <path>

Ansible con inventarios dinámicos

Leer doc de ansible

Si se administran muchos hosts con Ansible, mantener un fichero de hosts quizás no sea lo más óptimo, y por eso existen los inventarios dinámicos.

Cobbler inicialmente es un proyecto separado de Ansible pero que ha sido recuperado por el equipo de Ansible. Se puede ver este productio como una especie de CMDB ligera, y existe este script en Ansible que conecta el inventario con cobbler.

También hay conectores contra AWS y muchos más

Ejecuciońes Ad-Hoc

Leer doc de ansible

Sería algo así como hacer ejecuciones de comandos en concreto en una serie de máquinas. Es o más básico de Ansible.

# ansible -i hosts vagrant -a "cat /etc/hosts"
test1 | SUCCESS | rc=0 >>
127.0.0.1   test1.vag.ardemans.com test1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

test2 | SUCCESS | rc=0 >>
127.0.0.1   test2.vag.ardemans.com test2 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

Elevacion

Si queremos hacer la ejecución en todos los servidores como root, y la configuracion de cada host es con usuarios normales, tendremos que especificar en el comando ansible el parámetro

--become

Tambien podemos incluso especificar una contraseña para la elevacion de permisos, o hacer que nos la pida por consola

--become-pass
--ask-become-pass

Shell (-m shell)

Es el módulo por defecto, es decir, que si en una ejecución de ansible no ponemos el -m <modulo> será este el que se ejecute.

Los argumentos que pasamos en el -a será la línea de comandos que queremos ejecutar.

Lista de módulos

Leer doc de ansible

Se puede consultar la lista de módulos disponibles de base en Ánsible en esta URL y tambien la de los módulos extra que tambíen van incluidos aqui

Playbooks

Los playbooks es una forma de especificar en un documento una lista de tareas, usando los módulos que ya se usan en Ad-Hoc, y orquestar de alguna forma la ejecución de estos módulos. La idea que más destaca de este método es que se puede ejecutar tareas en diferentes hosts desde un único playbook, lo que de entrada parece una ventaja frente a otros tipos de gestión de configuración, en el que la aplicación de la configuración se hace desde el propio host o se hace desde un servidor central pero solo se aplica la configuración a un servidor en concreto, y si hay que orquestar configuraciones entre diferentes hosts hay que contar con otras herramientas como exportación de recursos, uso de DB's de configuracion (como etc), u operaciones post configuración.

Esta muy bien explicado en la documentación de ansible sobre playbooks, y aqui intentaré resaltar lo que más me llama la atención.

Estructura de un playbook

Para empezar, un playbook es un fichero Yaml, y Ansible ha puesto esta página muy interesante con los conceptos básicos de Yaml Un playbook consta de un array de N elemetos, cada elementos del array es un hash con las siguientes tres secciones diferenciadas: - host & users - tasks - handlers

En la primera sección se identifican las máquinas a las que va destinado este playbook, en la segunda sección las tareas que hay que ejecutar y en la tercera acciones que se van a ejecutar en las máquinas, sobre todo para reinicio de servicios y demás.

Un ejemplo sería:

---
- hosts: webservers
  remote_user: root

  tasks:
  - name: ensure apache is at the latest version
    yum: name=httpd state=latest
  - name: write the apache config file
    template: src=/srv/httpd.j2 dest=/etc/httpd.conf

- hosts: databases
  remote_user: root

  tasks:
  - name: ensure postgresql is at the latest version
    yum: name=postgresql state=latest
  - name: ensure that postgresql is started
    service: name=postgresql state=started

En este ejemplo no aparece un handler, pero sería añadir un nuevo elemento al hash de este tipo

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

y desde una tarea se podría hacer una llamada a estos handlers con algo como esto:

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

En ansible 2.2 se puede poner una clausula "listen", que es como una etiqueta que se puede añadir a varios "manejadores" y que después se puede llamar desde una única tarea.

handlers:
    - name: restart memcached
      service: name=memcached state=restarted
      listen: "restart web services"
    - name: restart apache
      service: name=apache state=restarted
      listen: "restart web services"

tasks:
    - name: restart everything
      command: echo "this task will restart the web services"
      notify: "restart web services"

Ejecutando un playbook

Algo tan sencillo como ejecutar:

ansible-playbook playbook.yml -f 10

Como en el caso de ejecutar el modo Ad-Hoc, el -f significa que paralelismo que queremos tener ejecutando ansible en las máquinas.

Si antes de ejecutar en playbook queremos ver las máquinas que van a estar afectadas podemos ejecutar:

ansible-playbook playbook.yml --list-hosts

Al parecer la salida de ansible es mucho mejor si está instalado el "cowsay"

También existe una forma de invertir la ejecución de ansible, y que sea modo pull en vez de push desde un servidor central. Precisamente se llama ansible-pull. Este lo que hace es descargar un repositorio de git donde están los playbooks, y después ejecuta ansible-playbook.

Cosas por averiguar

Aplicación de mismas configuraciones en diferentes entornos

Duda inicial: Por comparar, con Puppet se dispone de hiera, con el cual se pueden hacer cargas de diferentes valores para los parámetros de las "clases", y estos valores dependen de los facters de las máquinas o del entorno en el que se ha configurado la máquina (desarrollo, producción, webservers-producción), etc. Tendría que existir una forma de cargar diferentes valores para configuración de servicios. Existen los "Facters" mismo nombre que en puppet, pero faltaría por saber si se pueden cargar valores diferentes para cada entorno, o donde meter esos parámetros de configuración.

Gestión de los logs de resultados de aplicar ansible

Duda inicial: En puppet, lo bueno de que aplicar puppet sea atómico a una máquina es que el resultado de aplicarlo en dicha máquina va a un repositorio central de "logs", y después es faćilmente consultable que es lo que ha pasado con la máquina en las últimas aplicaciones de puppet. Con ansible parece que se aplica todos desde una misma máquina y afecta a varias, y todavía no se si es lógico tener un resultado de aplicar un playbook sobre varias máquinas o que cada máquina afectada por un playbook guarde su resultado. En cualquier caso todaǘia no se ni como se almacena el historico de aplicar ansible cada vez.