Diferencia entre revisiones de «Ansible»

Última revisión de 15:35 24 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.

Formato

Para empezar, un playbook es un fichero Yaml, y Ansible ha puesto esta página muy interesante con los conceptos básicos de Yaml

Estructura de un playbook

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.

Organización de los playbooks

Parece que al igual que otros sistemas de administración centralizada de la configuración (como puppet) existe el concepto de ROL. Los playbooks se pueden partir en diferentes fichers para poder reusar el código para diferentes propósitos, también existen las variables y se pueden pasar esas variables a los "trozos" de playbooks a los que vayamos llamando.

A estos trozos de playbook se les llama con un include y es en ese momento donde se pueden pasar variables, de la siguiente forma:

tasks:

  - include: wordpress.yml
    vars:
        wp_user: timmy
        ssh_keys:
          - keys/one.txt
          - keys/two.txt

Las variables se añaden en los valores de los Yaml a los que hacemos include y se ponen en el format "Plantilla:Variable"

Un ejemplo de como se organiza un repositorio de Ansible sería algo como así:

site.yml
webservers.yml
fooservers.yml
roles/
   common/
     files/
     templates/
     tasks/
     handlers/
     vars/
     defaults/
     meta/
   webservers/
     files/
     templates/
     tasks/
     handlers/
     vars/
     defaults/
     meta/

y como ejemplo, en el fichero webservers.yaml tendríamos algo tal que así:

---
- hosts: webservers
  roles:
     - common
     - webservers

Si queremos pasar parámetros a los roles también se puede hacer la llamada así:

---
- hosts: webservers
  roles:
    - common
    - { role: foo_app_instance, dir: '/opt/a',  app_port: 5000 }
    - { role: foo_app_instance, dir: '/opt/b',  app_port: 5001 }

y también se pueden aplicar roles de forma condicional, por ejemplo:

---
- hosts: webservers
  roles:
    - { role: some_role, when: "ansible_os_family == 'RedHat'" }

Si un playbook hace llamadas a roles, y también tiene sus propioas tareas, las tareas son ejecutadas después de hacer las llamadas a los roles, si queremos definir ejecuciones antes y después de los roles podemos usar esta estructrua:

---
- hosts: webservers

  pre_tasks:
    - shell: echo 'hello'

  roles:
    - { role: some_role }

  tasks:
    - shell: echo 'still busy'

  post_tasks:
    - shell: echo 'goodbye'

Dependencias de los roles

TODO

Ansible Galaxy

Es un sitio web gratuito donde consultar código de ansible que han hecho otras personas para diferentes propósitos.

https://galaxy.ansible.com/

Ansible con Amazon AWS

Leer doc en pág de ansible

Requisitos

Hace falta tener instalado el paquete de python "boto", que se puede instalar con:

pip install boto

Ejemplo de playbook

Un ejemplo real con el que he estado probando:

- hosts: localhost
  gather_facts: False
  vars_files:
    - vars/main.yml
  tasks:

    - name: Provision a set of instances
      ec2:
         key_name: ardemanskey
#         group: test
         instance_type: t2.micro
         image: "{{ ami_id }}"
         region: "{{ aws_region }}"
         wait: true
         exact_count: 2
         count_tag:
            Name: Demo
         instance_tags:
            Name: Demo
         vpc_subnet_id: subnet-605fc839
      register: ec2

Antes de poder ejecutar este playbook he tenido que exportar dos variables de entorno para las credenciales de Amazon, pero se puede hacer de mejor forma si utilizamos las variables de ansible y admeás está el ansible_vault que se puede estudiar para tener credenciales de forma secreta.

NOTA: Seguir echando un vistazo porque se puede iterar por los servidores resultado de esta creación y añadir a los hosts de forma temporal todos estos nuevos servidores con variables de como conectarse a él, por ejemplo, usar el fichero de clave RSA al que hacemos referencia para poder conectarnos por SSH y ejecutar el resto del 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.

Tareas con las que seguir

- Con mi cuenta de AWS sacar las credenciales de mi usuario, y probar a ejecutar un playbook sobre el host localhost que añada nuevas máquinas. Seguimos la guia que hay en el punto de más arriba sobre uso de AWS con Ansible.

- Echar un vistazo a eso del parámetro REGISTER, para ver si es algo exclusivo del modulo ec2 o si se puede usar con más módulos, para poder coordinar la creación de diferentes recursos o investigar que tipo de utilidad se le puede dar.