Integración de Ansible y Terraform

Uniendo Terraform y Ansible

En el tutorial AWS VPC, Route 53, RDS MariaDB, EC2 usando Ansible y Terraform se enseñan buenas prácticas para crear infraestructuras Cloud en AWS usando Terraform.

En este tutorial se muestra como una vez creada la infraestructura se procede a instalar y configurar el software mediante Ansible haciendo uso de las etiquetas configuradas por Terraform en AWS.

Prerrequisitos:

• Creación de un VPC en AWS usando Terraform (1/5)
• Subredes VPC y RDS, Tablas de Rutas, Acceso a Internet con Terraform en AWS (2/5)
• Route 53 y búsqueda de AMI con Terraform (3/5)
• Creación de base de datos RDS MariaDB y etiquetas con Terraform (4/5)
• EC2 Instances and Resource Security (5/5)

Uso de etiquetas de AWS con Ansible

El enlace entre la infraestructura de Terraform y Ansible se realiza mediante las etiquetas creadas con Terraform y asociadas a los elementos de la infraestructura de AWS. Las etiquetas permiten identificar los distintos elementos y aplicar los playbooks de Ansible correctos a cada uno.

La siguiente captura de pantalla de la consola EC2 de AWS muestra las distintas etiquetas aplicadas a una instancia EC2.

Añada al menos las siguientes etiquetas:

• Nombre [name]: el nombre de la instancia o recursos. Debe ser único y seguir el formato Cloud-Resource-Environment-Visibility-Name/ID (vea Creación de instancias EC2 y reglas de seguridad en AWS para más detalles)
• Nombre privado [private_name]: El nombre privado del elemento, se utiliza para el registro en DNS privado y debe seguir un estándar corporativo y ser único. Se puede utilizara para monitorizar y para la identificación de servidores.
• Nombre público [public_name]: El nombre público se utiliza para el registro en DNS público y podría ser el mismo para varias instancias (en el caso de estar detrás de un balanceador de carga). En el caso de RDS se usa el mismo nombre asignado a privado.
• App [app]: El nombre de la aplicación principal que usará el recurso.
• App ID [app_id]: Una característica única o un número que puede ser utilizado para diferencia múltiples instancias de la misma aplicación, por ejemplo el release number para el caso de múltiples instancias de la misma aplicación en el mismo entorno.
• OS [os]: El sistema operativo de la instancia, útil para aplicar configuración básica.
• Entorno [environment]: Utilizado para identificar el entorno, es un acrónimo de 3 letras:
  • dev
  • pre
  • pro
• Centro de coste [cost_center]: uno o varios centros de coste a los que se deben cargar los costes de este recurso. El centro de coste se utiliza en la facturación para clasificar recursos, por ejemplo si es un recurso para un cliente interno / externo o se comparte entre varios su coste será asumido totalmente o de forma parcial.

Todos los valores se deben escribir en minúsculas y sin espacios.

Configuración

Este tutorial asume que ya ha completado el despliegue de la infraestructura en AWS usando Terraform mediante el tutorial AWS VPC, Route 53, RDS MariaDB, EC2 usando Ansible y Terraform.

Clave privada

Copie el fichero con la clave privada creado al desplegar la infraestructura en ${HOME}/keys/ditwl_kp_infradmin.pem

Por simplicidad, estamos usando la misma clave privada para todo, pero en un escenario real, se recomienda disponer de una clave privada diferente para cada una de las siguientes combinaciones:

• cloud
• environment
• user

Vea múltiples entornos para una explicación.

Configure los permisos de acceso adecuados para la clave privada:

chmod 600 $HOME/keys/ditwl_kp_infradmin.pem

Permisos de acceso para AWS Inventory

Fije los permisos de acceso y ejecución adecuados para el script de generación del inventario que forma parte del código descargado:

cd ansible-aws-ec2-terraform-tags
chmod 755 inventory/ec2.py

Configuración de Ansible

Revise la configuración del fichero ditwl_pro.sh

# source this file before using ansible
# source ditwl_pro.sh
export AWS_PROFILE='ditwl_infradmin'
ANSIBLE_PRIVATE_KEY_FILE=${HOME}/keys/ditwl_kp_infradmin.pem

#AWS Region
export EC2_REGION='us-east-1'

#Set
export ANSIBLE_INVENTORY=$(pwd)/inventory/ec2.py
export ANSIBLE_PRIVATE_KEY=$ANSIBLE_PRIVATE_KEY_FILE

El valor de AWS_PROFILE es el nombre del perfil que contiene las credenciales de AWS. Se almacena fuera de Ansible y es el mismo que se utiliza en Terraform.

EC2_REGION es la región en la que los servicios cloud están localizados, fijar este valor permite acelerar la ejecución y creación del fichero Ansible con el inventario de AWS.

ANSIBLE_INVENTORY corresponde a una ruta al directorio y fichero que contiene el inventario o a un script. En nuestro ejemplo usaremos el script ec2.py que genera de forma dinámica un inventario mediante al consulta del API de AWS.

ANSIBLE_PRIVATE_KEY se corresponde a la ruta del fichero que contiene la clave privada que Ansible usará para conectar a las instancias Linux de EC2.

Antes de ejecutar los comandos de Ansible es necesario cargar la configuración del fichero ditwl_pro.sh que fija las variables de entorno ejecutando source ditwl_pro.sh.

ansible-aws-ec2-terraform-tags$ source ditwl_pro.sh
ANSIBLE_INVENTORY: /home/jruiz/.../ansible-aws-ec2-terraform-tags/inventory/ec2.py
ANSIBLE_PRIVATE_KEY: /home/jruiz/keys/ditwl_kp_infradmin.pem

Actividades manuales para la instalación de WordPress

Este tutorial no ha automatizado la creación del esquema en base de datos para WordPress o la delegación de la zona en DNS. Ambas tareas se han de realizar de forma manual.

Inventario dinámico de Ansible

Ansible ejecutará un script para generar el inventario dinámico y guardará los resultados cuando se aplique un playbook.

will run and cache the results of the dynamic inventory when a playbook is applied.

Es posible ejecutar de forma manual el inventario dinámico para obtener una representación de la infraestructura de AWS con sus grupos y propiedades.

ansible-aws-ec2-terraform-tags$ inventory/ec2.py
{
  "_meta": {
    "hostvars": {
      "ditwl_ec2_pro_pub_wp01_1": {
        "ansible_host": "52.3.235.198", 
        "ec2__in_monitoring_element": false, 
        "ec2_account_id": "368675470651", 
        "ec2_ami_launch_index": "0", 
        "ec2_architecture": "x86_64", 
        "ec2_block_devices": {
          "sda1": "vol-07c617da3623854c0"
        }, 
        "ec2_client_token": "", 
        "ec2_dns_name": "ec2-52-3-235-198.compute-1.amazonaws.com", 
        "ec2_ebs_optimized": false, 
        "ec2_eventsSet": "", 
        "ec2_group_name": "", 
        "ec2_hypervisor": "xen", 
        "ec2_id": "i-071566e036e992733", 
        "ec2_image_id": "ami-43a15f3e", 
        "ec2_instance_profile": "", 
        "ec2_instance_type": "t2.micro", 
        "ec2_ip_address": "52.3.235.198", 
        "ec2_item": "", 
        "ec2_kernel": "", 
        "ec2_key_name": "ditwl_kp_infradmin", 
        "ec2_launch_time": "2018-03-15T14:11:57.000Z", 
        "ec2_monitored": false, 
        "ec2_monitoring": "", 
        "ec2_monitoring_state": "disabled", 
        "ec2_persistent": false, 
        "ec2_placement": "us-east-1a", 
        "ec2_platform": "", 
        "ec2_previous_state": "", 
        "ec2_previous_state_code": 0, 
        "ec2_private_dns_name": "ip-172-17-32-217.ec2.internal", 
        "ec2_private_ip_address": "172.17.32.217", 
        "ec2_public_dns_name": "ec2-52-3-235-198.compute-1.amazonaws.com", 
        "ec2_ramdisk": "", 
        "ec2_reason": "", 
        "ec2_region": "us-east-1", 
        "ec2_requester_id": "", 
        "ec2_root_device_name": "/dev/sda1", 
        "ec2_root_device_type": "ebs", 
        "ec2_security_group_ids": "sg-0ec2a678,sg-1fd2b669", 
        "ec2_security_group_names": "ditwl-sg-ec2-pro-pub-01,ditwl-sg-ec2-def", 
        "ec2_sourceDestCheck": "true", 
        "ec2_spot_instance_request_id": "", 
        "ec2_state": "running", 
        "ec2_state_code": 16, 
        "ec2_state_reason": "", 
        "ec2_subnet_id": "subnet-23b4be47", 
        "ec2_tag_Name": "ditwl-ec2-pro-pub-wp01-1", 
        "ec2_tag_app": "wp", 
        "ec2_tag_app_id": "wp-01", 
        "ec2_tag_cost_center": "ditwl-permanent", 
        "ec2_tag_environment": "pro", 
        "ec2_tag_os": "ubuntu", 
        "ec2_tag_os_id": "ubuntu-16", 
        "ec2_tag_private_name": "ditwl-ec2-pro-pub-wp-01", 
        "ec2_tag_public_name": "www", 
        "ec2_virtualization_type": "hvm", 
        "ec2_vpc_id": "vpc-a970cbd2"
      }
    }
  }, 
  "ami_43a15f3e": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "ec2": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "i-071566e036e992733": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "key_ditwl_kp_infradmin": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "platform_undefined": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "security_group_ditwl_sg_ec2_def": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "security_group_ditwl_sg_ec2_pro_pub_01": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "tag_Name_ditwl_ec2_pro_pub_wp01_1": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "tag_app_id_wp_01": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "tag_app_wp": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "tag_cost_center_ditwl_permanent": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "tag_environment_pro": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "tag_os_id_ubuntu_16": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "tag_os_ubuntu": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "tag_private_name_ditwl_ec2_pro_pub_wp_01": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "tag_public_name_www": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "type_t2_micro": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "us-east-1": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "us-east-1a": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "vpc_id_vpc_a970cbd2": [
    "ditwl_ec2_pro_pub_wp01_1"
  ]
}

hostvars

Para cada instancia EC2, se añade un nodo a hostvars, el nodo contiene las propiedades que estarán disponibles al ejecutar un playbook.

Ejemplos:

En el inventario dinámico de Ansible de la instancia EC2 «ditwl_ec2_pro_pub_wp01_1» aparecen las siguientes propiedades:

{
  "_meta": {
    "hostvars": {
      "ditwl_ec2_pro_pub_wp01_1": {
        "ansible_host": "52.3.235.198", 
        ...
        "ec2_id": "i-071566e036e992733", 
        ...
        "ec2_private_ip_address": "172.17.32.217", 
        ...
        "ec2_tag_Name": "ditwl-ec2-pro-pub-wp01-1", 
        ...
      }
    }
  },

Estas propiedades se usan dentro de los playbooks de Ansible, en el siguiente ejemplo accedemos a la etiqueta Name para utilizarla en Ansible como nombre de la instancia a nivel de sistema operativo (hostname)

- name: Set hostname
  hostname:
    name: "{{ ec2_tag_Name }}"

El valor de ec2_tag_Name se extrae del inventario dinámico, corresponde a la propiedad Name fijada por Terraform al crear la instancia en AWS.

Tags

Las etiquetas «Tags» de los elementos de la infraestructura también será añadidas a hostvars mediante la creación de grupos.

El inventario dinámico de Ansible crea un grupo para cada «tag» que encuentra en el VPC y asigna los nombres de las instancias al grupo.

Esta agrupación se utiliza como objetivo target de los playbooks de Ansible para seleccionar determinados sistemas opeativos, aplicaciones y versiones.

El patrón utilizado para los tags es la palabra tag seguida del nombre y del valor utilizando guion bajo entre los elementos:

tag_[tag_name]_[tag_value]:[
 "host_a"
 "host_b"
 "host_c"
]

Ejemplo:

{
  "_meta": {
  ...
  "tag_environment_pro": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "tag_os_id_ubuntu_16": [
    "ditwl_ec2_pro_pub_wp01_1"
  ], 
  "tag_os_ubuntu": [
    "ditwl_ec2_pro_pub_wp01_1"
  ],
  ...
}

El grupo tag_environment_pro corresponde a todas las instancias EC2 que tienen una etiqueta con el nombre environment y valor pro.

El grupo tag_os_ubuntu corresponde a todas las instancias EC2 que tienen un tag con el nombre os y el valor ubuntu.

El grupo tag_os_id_ubuntu_16 corresponde a todas las instancias EC2 con la etiqueta os_id y valor ubuntu_16.

Como vemos en la configuración de Terraform para la instancia WP 01 (aws_ec2_pro_pub_wp_01) se fijan varios tags:

  aws_ec2_pro_pub_wp_01 = {
    name              = "ditwl-ec2-pro-pub-wp01"
    ....
    tag_private_name  = "ditwl-ec2-pro-pub-wp-01"
    tag_public_name   = "www"
    tag_app           = "wp"
    tag_app_id        = "wp-01"
    tag_os            = "ubuntu"
    tag_os_id         = "ubuntu-16"
    tags_environment  = "pro"
    tag_cost_center   = "ditwl-permanent"
    tags_volume       = "ditwl-ec2-pro-pub-wp-01-root"

  }

El inventario dinámico de Ansible convierte el guión bajo «_» en un guión medio «-» como se puede observar en el tag os_id cuyo valor era ubuntu-16 y ha sido convertido a ubuntu_16.

Si tuvieras instancias con un tag environment con valor pre, el inventario dinámico contendría un grupo llamado tag_environment_pre compuesto por esas instancias.

Ejemplo:

{
  "_meta": {
  ...
  "tag_environment_pre": [
    "ditwl_ec2_pre_pub_abc01_1",
    "ditwl_ec2_pre_pub_abc01_2",
    "ditwl_ec2_pre_pub_abc01_3"
  ],
  "tag_environment_pro": [
    "ditwl_ec2_pro_pub_wp01_1"
  ]
  ...
}

Uso de tags AWS como objetivos de Ansible

Los playbooks de Ansible utilizan el filtro hosts para seleccionar los recursos a los que se aplicará cada rol

Todos los recursos creados con Terraform tienen las siguientes etiquetas que serán utilizadas por Ansible para:

Configuración:

• Nombre [name]: Se utiliza para nombrar las instancias pero no será usado para selección de hosts en Ansible (al ser únicos).
• Nombre Privado [private_name]:  Nunca se usará como selector de grupos de hosts en Ansible, pero podría ser utilizado dentro de un playbook para realizar una configuración específica de la instancia (ej. fijar el FQDN de la instancia mediante su nombre privado).
• Public Name [public_name]: Nunca se usará como selector de grupos de hosts en Ansible, pero podría ser utilizado dentro de un playbook para realizar una configuración específica de la instancia (ej. fijar el FQDN de la instancia mediante su nombre público).
• Cost Center [cost_center]:  Actualmente no se usa en ningún playbook de Ansible.

Selección de grupos:

• App [app]:  Para seleccionar todos los host que ejecutan la misma aplicación, por ejemplo los que ejecutan WordPress.
• App ID [app_id]: App ID es una especialización del selector App , se utiliza para seleccionar todos los hosts que ejecutan determinada versión de una aplicación cuando hay varias versiones o tipos de instalación de la aplicación, por ejemplo aquellos hosts que aún ejecutan WordPress 4.9.4.
• OS [os]:  Para seleccionar los hosts que ejecutan un depermiando sistema operativo.
• OS ID [os_id]:  OS ID es una especialización de OS. Se utiliza para seleccionar todos los hosts que ejecutan una versión concreta de un sistema operativo.
• Environment [environment]: Usada para seleccionar los hosts que están en un entorno concreto, normalmente se usará en combinación con otro selector.

Solemos utilizar un único playbook para configurar todo un entorno de tal forma que se consigue configurar toda la infraestructura con un único comando.

El fichero ditwl_pro.yml define los selectoress de host y los roles que se aplicarán a cada grupo usando el operador :& (AND) para indicar que se requiere la pertenencia a todos los grupos indicados en el selector.

  - hosts: tag_os_ubuntu:&tag_environment_pro
    become: yes
    roles:
      - { role: linux/pam_limits, tags: [ 'pam_limits'] }
      - { role: linux/hosts_file, tags: [ 'hosts_file'] }
      - { role: linux/host_name, tags: [ 'host_name'] }
    tags:
      - common

  - hosts: tag_os_id_ubuntu_16:&tag_environment_pro
    become: yes
    roles:
      - { role: linux/add_packages, tags: [ 'add_packages'] }
    tags:
      - ubuntu_16

  - hosts: tag_app_wp:&tag_environment_pro
    become: yes
    roles:
      - { role: linux/wordpress, tags: [ 'wordpress'] }
    tags:
      - wordpress

La línea 1 comienza con un selector que seleccionará los hosts miembros del inventario dinámico que pertenecen al grupo tag_os_ubuntu y simultáneamente al grupo tag_environment_pro.

El resultado será la selección de los hosts que fueron etiquetados por Terraform con:

• environment=pro
• os=ubuntu

Ansible les aplicará los siguientes roles:

• linux/pam_limits
• linux/hosts_file
• linux/host_name

La línea 10, selecciona los hosts que tienen una versión específica de Ubuntu (16) y que se encuentran en el entorno de producción (pro) utilizando las siguientes etiquetas establecidas en Terraform:

• os_id = ubuntu-16
• environment=pro

A esos hosts se les aplicará el rol linux/add_packages.

Este ejemplo demuestra lo sencillo que es realizar variaciones que sólo aplican a determinada versión del sistema operativo o de una aplicación concreta.

La línea 17 selecciona los hosts que están marcados como aplicación «wp» y que se encuentran en el entorno de producción (pro), les aplica el role linux/wordpress.

Si tenemos que seleccionar utilizando más criterios podríamos aplicar además de la aplicación, su ID.

Múltiples entornos

En caso de añadir un entorno de preproducción, se deberá crear un nuevo playbook en su propio fichero llamado ditwl_pre.yml que utiliza el tag_environment_pre en lugar de tag_environment_pro para realizar la selección de hosts.

Cada entorno tendrá:

Un playbook que utiliza el tag_environment_ENV como selector, ejemplo:

  - hosts: tag_os_ubuntu:&tag_environment_ENV
    become: yes
    roles:
      - { role: linux/pam_limits, tags: [ 'pam_limits'] }
      - { role: linux/hosts_file, tags: [ 'hosts_file'] }
      - { role: linux/host_name, tags: [ 'host_name'] }
    tags:
      - common
  ...

Uso de variables de entorno para fijar el fichero de clave privada para SSH.

Imaginemos el terrible error que sería aplicar la configuración específica del entorno de PRE en PRO.

Para evitarlo, nos gusta tener diferentes ficheros de clave privada por entorno y por usuario que requiera usar Ansible o acceder mediante SSH a la consola de los servidores.

El fichero que tiene la clave privada para SSH se configura como una variable de entorno ANSIBLE_PRIVATE_KEY_FILE en el fichero ditwl_ENV.sh

export AWS_PROFILE='ditwl_infradmin'
ANSIBLE_PRIVATE_KEY_FILE=${HOME}/keys/ditwl_kp_ENV_infradmin.pem
...

Dado que el fichero ditwl_ENV.sh se almacena en un repositorio de código común no debe incluir información específica de usuario. El contenido del fichero de clave privada es específico para cada usuario y no debe ser subido al repositorio de código fuente nunca, en su lugar se acuerda que el fichero se llamará ditwl_kp_ENV_infradmin.pem y estará ubicado en una ruta conocida (i.e. ${HOME}/keys/ditwl_kp_ENV_infradmin.pem)

Por tanto cada usuario, deberá crear su propio fichero PEM con el nombre y ubicación acordada y conteniendo su clave privada.

Ansible Playbook Structure

La estructura de los Playbooks de Ansibles está definida en la documentación oficial, pero la forma adecuada para agrupar hosts y aplicar roles es algo que cada usuario puede elegir. Aquí presentamos la estructura y los estándares que nos han dado buenos resultados y por tanto recomendamos.

• Evite usar nombres de host para seleccionar hosts. Se suele decir que en el Cloud, los hosts deben ser tratados como ganado y no como mascotas, esta indica el carácter masivo de la infraestructura y de los sistemas para gestionarla.
• Cree grupos de hosts clasificándolos por:
  • Sistema Operativo y versión (mayor release)
  • Aplicación y versión (mayor release)
  • Entorno
• Asigne valores por defecto a todos los roles y utilice group_vars para redefinir valores donde sea preciso
• Utilice un único playbook por entorno

Granularidad de roles Ansible

Los roles para sistemas y aplicaciones diseñadas para ser independientes, o antes de que existiera el Cloud, se llaman «non-native cloud applications» o aplicaciones no nativas o tradicionales. Normalmente se trata de aplicaciones con estado que no se pueden clusterizar sin compartir algún tipo de almacenamiento o que no han sido diseñadas para ser recreadas o distribuir la carga de trabajo entre servidores.

Para las aplicaciones no nativas, aplicamos pragmatismo y no dedicamos un gran esfuerzo en crear roles reutilizables, en su lugar, creamos un único rol que realiza todos los cambios y configuraciones que la aplicación necesita. Incluso si existen roles independientes que realizan parte de las acciones necesarias, preferimos incorporarlos al rol principal de tal forma que evitamos mantener dependencias complicadas y que incrementan el riesgo de errores.

Un ejemplo de este tipo de rol es la instalación de WordPress. El mismo rol configura Nginx, PHP, WordPress y finalmente añade Let’s Encrypt – Free SSL/TLS Certificates solicitando un certificado y automatizando las tareas de renovación necesarias.

La utilización de un rol individual en lugar de tres o cuatro roles evita las complejidades que un rol independiente de Nginx requeriría para ser reutilizable en múltiples escenarios, al mismo tiempo permite una gran especialización.

Un ejemplo de rol definido pensando en la reutilización es el add_package, se ha diseñado para instalar repositorios de software e instalar paquetes. Se utiliza mediante dependencia en la configuración de todos los hosts y también en el rol de WordPress.

Ansible permite crear dependencias parametrizadas dentro de la carpeta meta. Esto permite crear composiciones añadiendo como dependencia otros roles que deben ser ejecutados como prerrequisito a la ejecución de un rol.

El siguiente extracto muestra el contenido del fichero roles/linux/wordpress/meta/main.yml donde se define la dependencia con el rol add_packages indicándo una lista de variables y sus valores que permiten instalar los paquetes necesarios para la configuración de WordPress.

dependencies:
  - { role: add_packages,
    linux_add_packages_repositories: "{{ wordpress_add_packages_repositories }}",
    linux_add_packages_keys: "{{ wordpress_add_packages_keys }}",
    linux_add_packages_names: "{{wordpress_add_packages_names }}"
    }

Ejecución del playbook de Ansible

Pulse el botón play para ver la ejecución del playbook de Ansible.

Configuración de WordPress

Una vez instalado, puede continuar la configuración vía web en la URL https://www.demo.itwonderlab.com/