Ansible
Contenido
Instalación 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
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
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
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 propositos, 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 ficheor 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'" }
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.
