Diferencia entre revisiones de «Ansible»
| Línea 86: | Línea 86: | ||
Se puede consultar la lista de módulos disponibles de base en Ánsible en [https://github.com/ansible/ansible-modules-core esta URL] y tambien la de los módulos extra que tambíen van incluidos [http://docs.ansible.com/ansible/modules_extra.html aqui] | Se puede consultar la lista de módulos disponibles de base en Ánsible en [https://github.com/ansible/ansible-modules-core esta URL] y tambien la de los módulos extra que tambíen van incluidos [http://docs.ansible.com/ansible/modules_extra.html aqui] | ||
| + | |||
| + | |||
| + | == Playbooks == | ||
| + | |||
| + | Los playbooks es una forma de especificar una lista de tareas, usando los módulos, y orquestar de alguna forma la ejcució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 configuracion, en el que la aplicación de la configuración se hace desde el propio host 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) | ||
Revisión de 14:28 17 ago 2016
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 una lista de tareas, usando los módulos, y orquestar de alguna forma la ejcució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 configuracion, en el que la aplicación de la configuración se hace desde el propio host 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)
