Entorno de pruebas en AWS 1: Elegir Ansible o Terraform

Vamos a plantear un entorno de pruebas en AWS ya que el diseñado en anteriores capítulos está al límite de lo que es un portátil y muchas veces vamos a necesitar que dicho entorno sea accesible por un cliente al que no tenemos acceso.

Hablaremos de un entorno en Amazon Web Service, aunque la idea es utilizar herramientas que puedan adaptarse a otros proveedores, intentando no casarnos de ninguna manera con el proveedor, pensando especialmente en lo que sería un entorno de demostración.

Diseño de referencia

Entorno de pruebas en AWS 1: Elegir Ansible o Terraform 1

Para empezar plantemos una arquitectura de referencia, para ello tomamos lo que es un diseño tradicional con MZ y DMZ, evitando en lo posible elementos que salgan fuera de lo que sería un entorno de demostración (por ejemplo balanceadores, CDN, caché, etc) ya que nos interesa que el despliegue sea rápido y la pretensión es que dure poco en el tiempo (y por lo tanto reducir en lo posible sus costes).

De manera resumida tenemos los siguientes elementos:

  • Entorno de pruebas: Máquinas virtuales con Kubernetes y los servicios desplegados que formarán parte de la prueba. No serán accesibles desde internet.
  • Bastión: Máquina virtual que será accesible desde Internet y cuya principal función será desplegar servicios.
  • DMZ: Red donde están las máquinas virtuales con Kubernetes, accesible desde la red de bastión (MZ), pero no desde Internet, para salir a Internet requiere de NAT.
  • MZ: Red que dispone de salida a Internet y cuyos dos elementos (NAT GW y bastión) dispone de IP de Internet accesible.

En este primer capítulo vamos a plantear dos posibles opciones de infraestructura como código (IaC) para desplegar el entorno y las ventajas/desventajas de cada una. Las soluciones que vamos a plantear son Ansible y Terraform. En el segundo artículo iremos revisando como son los elementos en cada una de las soluciones y que opciones tenemos ante las deficiencias de cada uno.

Los ejemplos de código se basan en el disponible en https://github.com/aescanero/disasterproject, tanto para Ansible como para Terraform.

Instalar

Para instalar Ansible lo haremos como se han indicado en artículos anteriores (como KVM, Ansible y como hacer un entorno de pruebas), para el caso de Terraform, simplemente lo descargamos de https://releases.hashicorp.com/terraform/ para nuestro sistema operativo, para ubuntu, para instalar la versión 0.12.18 seguimos lo siguiente:

curl -sLO https://releases.hashicorp.com/terraform/0.12.18/terraform_0.12.18_linux_amd64.zip
unzip terraform_0.12.18_linux_amd64.zip
chmod u+x terraform
sudo mv terraform /usr/local/bin

En este punto podemos ver que efectivamente es más fácil la instalación inicial de Terraform, pero hemos de tener en cuenta que Ansible trae en el paquete todas las librerías necesarias para trabajar con AWS.

Para poder trabajar con Terraform y AWS vamos a necesitar en el directorio de trabajo de un archivo “provider.tf” donde indiquemos el proveedor (provider) de servicio con el que vamos a trabajar, el contenido del archivo debe ser parecido al siguiente:

variable "region" {}

provider "aws" {
  profile = "default"
  region  = "${var.region}"
}

Para instalar las librerías necesarias para el acceso a AWS ejecutaremos terraform init.

Un detalle importante que diferencia ambas herramientas es la forma de conectarse, mientras Terraform puede utilizar el archivo ~/.aws/credentials o variables de entorno, Ansible permite además guardar la configuración en un archivo vault (codificado), para ello en el grupo de hosts que vamos a utilizar (como ejemplo aws) vamos a ejecutar ansible-vault create group_vars/aws/vault, nos pedirá una contraseña y como contenido ponemos:

aws_access_key: CLAVE_ACCESO
aws_secret_key: CLAVE_SECRETA

De está manera es más seguro gestionar las credenciales de acceso a AWS, evitando poner las credenciales en consola o en fichero sin codificar. Lo que es un punto a favor de Ansible.

Dependencias

En este punto hay una importante superioridad por parte de Terraform, ya que es capaz de identificar todos los elementos que vamos a desplegar y organizarlos.

En el caso de Ansible las dependencias las debemos añadir nosotros, básicamente utilizando “include”, por lo que debemos tener muy clara la solución final que queremos montar.

Uso de variables

En este campo ambas soluciones tienen una perspectiva muy diferente, Ansible es capaz de crear variables que podremos usar en el despliegue a partir de otros elementos de manera dinámica, pero para almacenar el resultado de las operaciones realizadas (por ejemplo la IP de una instancia) para futuros usos hay que configurar específicamente Ansible por ejemplo añadiendo el archivo ansible.cfg:

[defaults]
gathering = smart
fact_caching = jsonfile
fact_caching_connection = ./files
fact_caching_timeout = 864000

Que nos permitirá guardar las variables correspondientes a un equipo, y utilizar set_fact (con cacheable: yes) para guardar información entre ejecuciones.

Aunque Terraform no dispone de variables que puedan ser generadas dinámicamente a partir de otros elementos, y requiere que las variables sean definidas (aunque definir las variables en el archivo terraform.tfvars simplifica especialmente el trabajo), si es capaz de mantener un fichero de estado que nos permite no tener en pensar como identificar el elemento en AWS que estamos intentando modificar.

Ansible es capaz a partir de un inventario simple crear una estructura compleja y ocultar la mecánica de los roles a los desarrolladores, añadiendo elementos a partir de otros datos (llamadas a APIs, scripts, etc).

Tiempo de despliegue/eliminación

Terraform es muy superior en ambos casos, ya que no depende de la ejecución de una larga serie de roles para detectar la infraestructura y crearla/eliminarla, sin embargo, para despliegues complejos y dinámicos es muy posible que no solo sea más interesante Ansible, sino incluso combinaciones de ambos.

Conclusiones

En el siguiente artículo vamos a examinar como podemos usar las dos soluciones para desplegar el entorno de referencia, Terraform es más preciso en que elementos van a configurarse o están ya configurados en la plataforma, así como la velocidad de despliegue.

Pero por otro lado Ansible nos permite ocultar el diseño final de la solución al partir de un fichero de inventario que tendrá el diseño que nosotros deseemos darle, sin embargo no disponer de un fichero de estado como Terraform lo hace mucho menos eficiente.

Deja un comentario

Volver arriba