Ansible (software)

De Wikipedia, la enciclopedia libre
Saltar a: navegación, búsqueda
Ansible
Ansible Logo
Desarrollador(es)
Michael DeHaan
http://www.ansible.com
Información general
Autor(es) Michael DeHaan
Última versión estable 2.0.1.0 (info)
25 de febrero de 2016 (1 año, 1 mes y 2 días)
Género Automatización Orquestación Administración de Configuración
Programado en Python
Sistema operativo GNU/Linux Unix
Licencia GNU GPL v3
[editar datos en Wikidata]

Ansible es una plataforma de software libre para configurar y administrar computadoras. Combina instalación multi-nodo, ejecuciones de tareas ad hoc y administración de configuraciones. Adicionalmente, Ansible es categorizado como una herramienta de orquestación.[1] Maneja nodos a través de SSH y no requiere ningún software remoto adicional (excepto Python 2.4 o posterior[2] para instalarlo. Dispone de módulos que trabajan sobre JSON y la salida estándar puede ser escrita en cualquier lenguaje. Nativamente utiliza YAML para describir configuraciones reusables de los sistemas.[3]

La plataforma fue creada por Michael DeHaan, también autor de la aplicación de aprovisionamiento Cobbler y co-autor del framework para administración remota Func.[4] Es incluido como parte de la distribución de Linux Fedora, heredada de Red Hat Inc., y también está disponible para Red Hat Enterprise Linux, CentOS y Scientific Linux a través de los Paquetes Extras para Enterprise Linux (EPEL) como también para otros sistemas operativos.[5] Ansible tiene soporte comercial de Ansible, Inc.[6]

El nombre fue puesto por DeHaan a partir del sistema de comunicación instantáneo del hiperespacio ficcionado por Orson Scott Card en la novela El juego de Ender,[7] y originalmente inventado por Ursula K. Le Guin en su novela de 1966 El mundo de Rocannon.

Arquitectura[editar]

Como la mayoría del software para administrar configuración, Ansible distingue dos tipos de servidores: controladores y nodos. Primero, está una única máquina de control donde la orquestación comienza. Los nodos son manejados desde esa máquina de control por SSH. La máquina de control conoce a los nodos a través de un inventario.

Para organizar los nodos, Ansible despliega módulos a los nodos el protocolo SSH. Los módulos son guardados temporalmente en los nodos y se comunican con la máquina de control a través del protocolo JSON sobre una salida estándar.[8] Cuando Ansible no controla los módulos, estos no consumen recursos porque no existen procesos o programas ejecutándose en segundo plano.[9]

En contraste con otros programas de control de configuración como Chef y Puppet, Ansible usa una arquitectura sin agentes[9] Con la arquitectura basada en agentes, los nodos deben instalar localmente un proceso de comunicaciones con la máquina de control. Con la arquitectura sin agentes los nodos no necesitan instalar ni ejecutar en segundo plano ningún proceso que se comunique con la máquina de control. Este tipo de arquitectura reduce la sobrecarga de la red y previene el uso de estrategias de control más agresivas por parte del servidor (como puede ser la realización de polling, con sus constantes operaciones de consulta).[9]

Propósito[editar]

El diseño de Ansible[8] incluye:

  • Mínimo por naturaleza. Los sistemas de administración no deben imponer dependencias adicionales.[9]
  • Consistente.
  • Seguro. Ansible no instala agentes vulnerables en los nodos. Solamente se requiere OpenSSH que es considerado crítico y altamente testeado.[9]
  • Alta confiabilidad. El modelo de idempotencia es aplicado para las instalaciones y configuraciones, para prevenir efectos secundarios en la ejecución repetitiva de scripts.[1]
  • Suave curva de aprendizaje. Los playbooks usan un lenguaje descriptivo simple, basado en YAML.

Módulos[editar]

Los módulos son considerados las unidades de trabajo en Ansible. Cada módulo es auto-suficiente y puede ser escrito en lenguaje estándar de scripting, como ser Python, Perl, Ruby, Bash, etc. Una de las popiedades principales de los módulos es la idempotencia la cual asegura que ninguna operación se realizara una vez que el sistema ha alcanzado el estado deseado.[8]

Configuración de inventario[editar]

El inventario es una descripción de los nodos que pueden ser accedidos por Ansible. El inventario está descrito por un archivo de configuración, en formato INI, cuya ubicación por defecto es /etc/ansible/hosts. En el archivo de configuración se listan las direcciones IP o hostname de cada nodo que es accesible por Ansible.

Además, los nodos pueden ser asignados a grupos.[10] Un ejemplo de archivo de configuración:

192.168.6.1

[webservers]
foo.example.com
bar.example.com

Este archivo de configuración específica 3 nodos. El primer nodo está específicado a través de su dirección IP y los siguientes 2 por su nombre de host. Además, los últimos 2 nodos fueron agrupados bajo el nombre de grupo webservers.

Playbooks[editar]

Playbooks describen configuraciones, despliegue, y orquestación en Ansible.[11] El formato del Playbook es YAML. Cada Playbook asocia un grupo de hosts a un conjunto de roles. Cada rol está representado por llamadas a lo que Ansible define como Tareas.

Básicamente una tarea no es más que una llamada a un módulo de Ansible.

Al componer un Playbook con múltiples "jugadas", es posible orquestar despliegues de múltiples máquinas, ejecutando ciertos pasos en todas las máquinas del grupo de servidores web, otros pasos en el grupo de servidores de base de datos, y luego más comandos en los servidores web, etc.

Un Playbook que contiene una sola jugada:

---
- hosts: webservers
  vars:
    http_port: 80
    max_clients: 200
  remote_user: root
  tasks:
  - name: Asegurarse que Apache este en la última versión
    yum: pkg=httpd state=latest
  - name: Escribir el archivo de configuracion de apache
    template: src=/srv/httpd.j2 dest=/etc/httpd.conf
    notify:
    - restart apache
  - name: Asegurarse que Apache esta ejecutando (y habilitarlo al iniciar el sistema)
    service: name=httpd state=started enabled=yes
  handlers:
    - name: Reiniciar Apache
      service: name=httpd state=restarted

Lista de tareas[editar]

Cada jugada contiene una lista de tareas. Las tareas son ejecutadas en orden, de una en una, contra cada máquina que encaja con el patrón del host, para luego seguir con la próxima tarea. Es importante entender que, dentro de una jugada, todos los host van a obtener las mismas directivas de tarea. Es el objetivo de un Playbook el mapear un grupo de host a tareas.

Al correr una jugada, que corre de arriba hacia abajo, los host donde fallen las tareas son sacados de la rotación de las jugadas restantes. Si las cosas fallan, simplemente hay que corregir el libro de jugadas y ejecutar de vuelta.

El objetivo de cada tarea es ejecutar un módulo, con parámetros muy específicos. Variables, como ya se mencionó, pueden ser usadas como argumentos de los módulos.

Los módulos son idempotente, lo que significa que si se los ejecuta de vuelta, solo van a generar los cambios en el sistema que sean necesarios para llegar al estado deseado. Esto da seguridad para ejecutar el mismo libro de jugadas varias veces. No va a cambiar nada salvo que sea necesario hacerlo.

Cada tarea debe tener un nombre, que está incluido en la salida de la ejecución del libro de jugadas. Esta es una salida para humanos, por lo cual es deseable tener una buena descripción de cada paso de la tarea.

Las tareas pueden declararse usando el formato legado action : module options, pero es recomendable usar el formato más convencional module : options. Este es el formato recomendando en la documentación, pero se pueden encontrar libros de jugadas con el formato antiguo.

Plataformas soportadas[editar]

Las máquinas orquestadoras deben tener Python 2.6. Los sistemas operativos soportados en las máquinas controladoras incluyen la mayoría de las distribuciones de Linux y Unix, tales como Red Hat, Debian, CentOS, OSX, y BSD, entre otros excepto Windows.[12] Los nodos orquestados deben tener Python 2.4 o posteriores. Además los nodos orquestados que tengan Python 2.5 o anteriores, el paquete python-simplejson es también requerido.

Integración con la nube[editar]

Ansible puede instalarse en ambientes virtualizados, nubes públicas y privadas, incluyendo VMWare, OpenStack, AWS, Eucalyptus, KVM y CloudStack.[8]

Integración con Big Data[editar]

Ansible puede instalar entornos para analizar y archivar big data, incluyendo Hadoop, Riak, y Aerospike.

El problema sobre el cual se apoya Ansible es que estos entornos incluyen la administración de recursos que se consumen en cada nodo. En particular, big data, archivo y análisis buscan hacer un uso eficiente de los recursos mediante el consumo de pequeñas tiempos de CPU y cantidad de memoria como sea posible. Adicionalmente, Ansible permite tener monitor de cantidades como los recursos de CPU disponibles, que pueden ayudar a la vigilancia de los nodos.[8]

Usuarios[editar]

Ansible es utilizado por Atlassian, Twitter, OneKingsLane, EverNote, TrunkClub, edX, hootsuite, GoPro y Care.com, además de muchos otros.[13]

Véase también[editar]

Referencias[editar]

  1. a b «Achieving Rolling Updates and Continuous Deployment with Zero Downtime» (pdf). 
  2. «Getting Started | Ansible». 6 de febrero de 2014. 
  3. «Ansible: CM, Deployment, and Ad Hoc Task Execution All in One». DZone. 18 de abril de 2012. 
  4. «An Interview with Ansible Author Michael DeHaan». Colo and Cloud. 17 de abril de 2012. 
  5. «Ansible». Linux Packages Search. 
  6. «Ansible». Ansible. Consultado el 9 de marzo de 2013. 
  7. «Ansible FAQ». 
  8. a b c d e «Ansible in Depth» (pdf). 
  9. a b c d e «The Benefits of Agentless Architecture» (pdf). 
  10. «Inventory | Ansible». 26 de abril de 2014. 
  11. «Playbooks | Ansible». 26 de abril de 2014. 
  12. «Getting | Started». 6 de febrero de 2014. 
  13. «Ansible is Simple IT Automation». 26 de abril de 2014. 

Enlaces externos[editar]