Cómo aprovisionar un servidor Ubuntu con scripts de Ansible

Introducción

Ansible es una plataforma simple de automatización de IT de código abierto. Puede configurar sistemas, implementar software, ejecutar trabajos ad hoc y organizar tareas de IT más avanzadas como implementaciones o actualizaciones continuas sin tiempo de inactividad.

A continuación, te mostramos algunas características que hacen que Ansible sea único:

• Gestiona las máquinas sin agentes mediante el aprovechamiento del demonio SSH existente, por lo que no se necesitan puertos abiertos adicionales ni agentes personalizados adicionales en máquinas remotas.
• Permite describir la infraestructura en un lenguaje que sea amigable tanto para las máquinas como para las personas.
• Tiene una rica colección de Roles.
• Se centra en la seguridad aprovechando los estándares existentes.
• Sigue un ciclo de lanzamiento predecible presentado en la Hoja de Ruta Pública.
• Permite el desarrollo de módulos en cualquier lenguaje dinámico, no sólo en Python.

En este sencillo tutorial, aprovisionaremos un servidor Ubuntu 18.04 con Ansible. Además, exploraremos cosas como módulos de Ansible, playbooks y roles.

Requisitos Previos

• Ansible 2.9+ instalado en una máquina local. Si lo necesitas, puedes consultar estas instrucciones de instalación.
• Conocimientos básicos de sistemas Unix (SSH, paquetes Deb).
• Servidor Ubuntu 18.04 con acceso SSH (a través de un par de claves SSH públicas y privadas).

Archivo de Inventario

Antes de que podamos hacer algo con Ansible, debemos especificar una lista de hosts que Ansible va a controlar. La forma más fácil es crear un archivo de inventario estático, como presentamos a continuación:

[web]
85.208.21.90

[web:vars]
ansible_user=root
ansible_port=22
ansible_ssh_private_key_file=privateKey.pem

Algunas cosas a tener en cuenta aquí antes de seguir adelante:

• Hemos creado un grupo de inventario web con la dirección IP pública de nuestro servidor Ubuntu 18.04. Hay mucho más, así que puedes echarle un vistazo a la Primera Guía de Inventario para comprender mejor lo que puedes conseguir.
• También hemos definido variables compartidas para la web grupal, instruyendo a Ansible qué clave privada SSH, puerto y usuario usar.
• Hemos utilizado el Inventario Estático, pero Ansible también es compatible con el Inventario Dinámico, que es particularmente útil cuando las máquinas remotas se encienden y apagan con frecuencia.

Si quisiéramos aprovisionar más servidores web, agregaríamos más IPs, cada una bajo la nueva línea del grupo web. Incluso podríamos usar diferentes claves SSH privadas por host, como se muestra más abajo. 

[web]
85.208.21.90 ansible_ssh_private_key_file=privateKey1.pem
85.208.21.95 ansible_ssh_private_key_file=privateKey2.pem

[web:vars]
ansible_user=root
ansible_port=22

Módulos Ansible 

La forma más rápida de ver Ansible en acción es experimentar con su interfaz básica de línea de comandos Ansible.

# ansible web -i inventory -m ping

 En el ejemplo anterior, hemos utilizado el módulo ping y lo ejecutamos en todas las máquinas del grupo web definido en nuestro archivo de inventario. Ping es un módulo que se usa comúnmente para verificar la capacidad de iniciar sesión y verificar si el ejecutable de Python se ha configurado correctamente en las máquinas remotas.

Veamos otro ejemplo que usa el indicador --check para habilitar un modo de ejecución en seco:

# ansible web --check -i inventory -m apt -a "name=nodejs state=latest"

Aquí hemos utilizado el módulo apt para instalar el último paquete nodejs en las mismas máquinas de nuestro grupo web. Si el paquete nodejs ya se ha instalado, Ansible no lo volverá a hacer, como se muestra más abajo:

85.208.21.90 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "cache_update_time": 1586849592,
    "cache_updated": false,
    "changed": false
}

Aunque estos ejemplos ad hoc muestran cómo trabajar con hosts remotos utilizando módulos Ansible y CLI Ansible, la mejor parte está por venir. Exploremos juntos los playbooks de Ansible.

Ansible playbooks

Los playbooks de Ansible contienen el lenguaje de configuración, implementación y orquestación de Ansible. Tienen el formato YAML, están diseñados para ser legibles por personas y están destinados a mantenerse en  el control de código fuente.

Comenzamos con un sencillo libro de estadísticas stats.yml que recopilará información variada sobre nuestras máquinas remotas: 

- name: Stats
  hosts: all
  gather_facts: True
  tasks:
    - name: Debug Gathered Facts
      debug:
        var: item
      with_items:
        - "{{ ansible_lsb }}"
        - "{{ ansible_default_ipv4 }}"
        - "{{ ansible_date_time }}"
        - "{{ ansible_dns }}"
        - "{{ ansible_env }}"
        - "{{ ansible_hostname }}"
        - "{{ ansible_memory_mb }}"
        - "{{ ansible_memfree_mb }}"

    - name: Capture OS Name
      command: uname -a
      register: os_name

    - name: Debug OS Name
      debug:
        var: os_name.stdout

Antes de seguir adelante, intentemos comprender lo que acaba de suceder.

• collect_facts es un booleano que controla si la obra ejecutará automáticamente la tarea de setup para recopilar datos para los hosts. Podríamos omitirlo ya que es True por defecto.
• hosts define una lista de grupos, hosts o patrones de host que se traduce en una lista de hosts remotos a los que nos dirigiremos. Hemos utilizado el grupo predeterminado all, ya que queremos obtener estadísticas de todos nuestros hosts.
• remote_user define un usuario utilizado para iniciar sesión en el destino a través del plugin conexión. En nuestro caso, es redundante porque también hemos definido ansible_user en nuestro archivo de inventario.
• Los módulos de setup y debug ayudan a depurar las variables de host recopiladas por Ansible. Si deseas ver todas las variables posibles, puedes hacerlo en la Documentación de Variables de Datos de Ansible.

Como ya tenemos el conocimiento básico del playbook de Ansible, intentemos ejecutarlo con el CLI ansible-playbook como se muestra a continuación:

# ansible-playbook -i inventory stats.yml

Como resultado, deberíamos ver algo similar al fragmento a continuación. (Ten en cuenta que parte del fragmento se ha eliminado por razones de brevedad).

PLAY [Stats] ************************************************************************************************************************************************

TASK [Gathering Facts] **************************************************************************************************************************************
ok: [85.208.21.90]

TASK [Debug Gathered Facts] *********************************************************************************************************************************
ok: [85.208.21.90] => (item={'id': 'Ubuntu', 'description': 'Ubuntu 18.04 LTS', 'release': '18.04', 'codename': 'bionic', 'major_release': '18'}) => {
    "ansible_loop_var": "item",
    "item": {
        "codename": "bionic",
        "description": "Ubuntu 18.04 LTS",
        "id": "Ubuntu",
        "major_release": "18",
        "release": "18.04"
    }
}
...
ok: [85.208.21.90] => (item={'nameservers': ['127.0.0.53']}) => {
    "ansible_loop_var": "item",
    "item": {
        "nameservers": [
            "127.0.0.53"
        ]
    }
}
...
ok: [85.208.21.90] => (item=578) => {
    "ansible_loop_var": "item",
    "item": 578
}

TASK [Capture OS Name] **************************************************************************************************************************************
changed: [85.208.21.90]

TASK [Debug OS Name] ****************************************************************************************************************************************
ok: [85.208.21.90] => {
    "os_name.stdout": "Linux tekmi 4.15.0-96-generic #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux"
}

PLAY RECAP **************************************************************************************************************************************************
85.208.21.90               : ok=4    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0  

Con esto,hemos probado el poder de automatización de Ansible. Aún así, para ir más allá, exploremos juntos la Galaxia Ansible y el Ecosistema de Roles.

Playbooks de Ansible con Roles

Puedes escribir un playbook complejo en un archivo largo, pero ¿no sería más práctico reutilizar los archivos y organizarlo todo mejor? Por suerte, Ansible se ha ocupado de esto y ofrece tres formas de hacerlo:

• includes
• imports
• roles

Includes e imports fueron añadidos en Ansible 2.4 y permiten romper playbooks grandes en archivos más pequeños, que se pueden usar en varios playbooks padres o incluso varias veces en el mismo playbook.

Roles permite más que el hecho de que las tareas sean paquetizadas juntas y puede incluir variables, manipuladores o incluso módulos y otros plugins. También se pueden compartir a través de la Galaxia Ansible, una site grauita para encontrar, descargar y compartir roles desarrollados por la comunidad.

En este tutorial, instalaremos dos roles: el Rol PHP y el Rol Composer, como se muestra más abajo:

# ansible-galaxy install --roles-path . geerlingguy.php geerlingguy.composer

Después de descargar estos roles en el directorio actual (gracias a --roles-path.), creemos nuestro segundo playbook, como se muestra a continuación:

- name: PHP and Composer
  hosts: web
  gather_facts: True
  vars:
    php_default_version_debian: "7.2"
    php_enable_webserver: false
  roles:
    - geerlingguy.php
    - geerlingguy.composer

Hay dos partes importantes que están teniendo lugar ahí:

• la opción vars, que en nuestro caso sobrescribe dos variables desde el rol PHP. Esta opción tiene más que ofrecer, para lo que puedes explorar la Guía de Variables de Playbook.  
• la opción roles, que permite usar de forma estática cualquier rol local o descargado. Por lo que respecta a Ansible 2.4,  también hay una opción include_role para usar roles en línea y de forma dinámica. Puedes consultar la Guía de Uso de Roles para más información. 

Como con cualquier playbook, el último paso es el de ejecutar a través del CLI ansible-playbook:

# ansible-playbook -i inventory php_composer.yml

Y con este último comando, hemos terminado nuestro recorrido breve a lo largo de Ansible. ¡Felicidades!

Sumario

Hemos explorado juntos varias partes interesantes de la herramienta de automatización Ansible. Para resumir nuestro viaje, recapitulemos lo que hemos hecho:

• Hemos aprendido a crear un inventario simple y estático.
• Hemos conocido varios módulos Ansible, incluyendo depuración, configuración y ping.
• Hemos creado un playbook simple y hemos depurado algunas variables de hosts recopiladas por Ansible.
• Hemos descubierto Ansible Galaxy y hemos descargado roles PHP y Composer desde allí.

Ansible es una potente plataforma de automatización y lleva tiempo dominar todas sus funciones. Si quieres ampliar tus conocimientos, puedes leer el libro completo Ansible: Up and Running: Automation Configuration Management and Deployment the Easy Way.