Versionando los templates con Packer

O del cómo descubrimos que podíamos tener la infraestructura como código

Una de las principales bazas que encontramos al movernos a entornos virtualizados, fue el aprovisionamiento de nuestras máquinas.

Ansible fue la herramienta que despertó en nosotros unas ganas por tenerlo todo versionado y automatizado. Terraform vino después, haciéndonos ver que era posible levantar máquinas sin tener la necesidad de tener que estar logeándonos en nuestro proveedor de cloud y levantar los templates a clickazos. Y por último vino Packer, a pesar de ser el primer paso en la puesta en marcha de nuevas máquinas.

Y hoy vengo a hablaros de eso, de cómo en Uvinum hemos empezado a ser un poco Hashicorp advocates, hoy concretamente sobre Packer, y es que las buenas herramientas valen la pena de ser comentadas.

Qué es Packer?

Packer no es más que una herramienta que nos permite la automatización en la creación de nuevas imágenes desde las que aprovisionar nuestras máquinas.

Para situaros Packer en el mapa dentro de las herramientas de Hashicorp os dejo una imagen que lo refleja claramente.

Organización sobre tecnologias en Hashicorp

Sin entrar en detalles en las especificaciones de Packer y las opciones que nos ofrece la herramienta, intentaremos ir directos a nuestro uso concreto, donde creemos que puede daros más valor.

¿Por qué Packer?

Automatizar siempre es bueno, pero además, uno de los déficits que sufríamos con el aprovisionamiento de nuevas máquinas con Ansible a cada levantamiento era el hecho de que alguna de las versiones de los servicios, pudiera cambiar o pasara a no estar disponible. Con Packer dejamos de tener esa preocupación, ya que los templates base desde los que desplegaremos cada una de nuestras máquinas tendrán, ahora si, siempre la misma versión de los servicios que definimos al haber hecho previamente su Packer build. Ergo infraestructura immutable.

Si recordáis un poco el post de la migración en Uvinum disponemos de diferentes categorías de máquinas, distribuidas en 2 nodos. Nuestro código PHP y donde reside la aplicación es servida por 8 frontales. Pues bien, la idea es presentaros como preparamos la plantilla final desde la que lanzaremos un nuevo frontal a nuestro pool.

Let’s roll

En el momento de adentrarnos en la documentación de Packer, vimos que estila mucho hacia el ecosistema de AWS. Sin embargo, nos sorprendió la cantidad de builders para distintos proveedores que podemos encontrar.
En nuestro caso, necesitamos poder construir estas plantillas conectándonos a nuestro datacenter. Aquí es donde queremos desplegar las nuevas máquinas, del mismo modo que encontramos los distintos templates creados a día de hoy, las interfaces de red, y nuestros datastores.

Por lo que pudimos encontrar en la documentación de Packer, mediante su builder, únicamente podíamos crear las plantillas a través de la imagen base (ISO) o partir de otra máquina (VMX), en ambos casos debíamos de disponer de los recursos en la propia máquina desde la que lanzábamos el build de Packer. Esto es un problema, ya que todos los recursos los disponemos en remoto, dentro del propio datacenter. Así pues, las operaciones deberían de llevarse exclusivamente en remoto.

Por fortuna la gente de Jetbrains mantiene público un plugin que hace uso de de la API de Vsphere, facilitando así toda la ejecución hacia el propio datacenter.

Ellos nos ofrecen la posibilidad de crear templates desde templates existentes (vpshere-clone) o templates desde zero (vsphere-iso), es decir, desde la iso básica.

A día de hoy, y viendo que con Terraform podíamos modificar la cantidad de cores de la CPU y la memoria RAM de manera dinámica al levantar una nueva máquina, únicamente encontramos la limitación de tener que tener definidos templates base con:

1. Una cantidad de espacio en disco bien definida para la máquina que queremos levantar.
2. Las VMWare Tools ya instaladas en la propia máquina para que tanto Packer como Terraform sean capaces de poder conectar con ésta y utilizar la API de VSphere.

Dicho esto os dejamos a continuación el json que utilizamos para generar el template base FrontendProvisioned, es decir, aprovisionado con los servicios necesarios para que sirva de plantilla principal desde la que levantar frontales.

Dando por hecho muchos de los detalles en la nomenclatura de Packer y como podéis observar.

En lo que concierne al Builder:

• Utilizamos el plugin vsphere-clone del que se desprenden distintas variables a definir: vcenter_server, username, password, host, para configurar la conexión.
• Partimos de un template previamente creado FrontendWithVmWareTools, el cual es un template genérico que contiene una partición de disco duro de 50GB y con una configuración por defecto de 1 de CPU y 1024 GB de RAM (os recuerdo, nos da igual, podremos modificarlo a la hora de levantar los nuevas máquinas con Terraform)
• Exportamos esta nueva máquina, una vez terminada, directamente a template y definimos el path en el que queremos que resida dentro de nuestro datacenter. Con lo que terminaremos con FrontendProvisioned dentro del directorio Templates/Provisioned

En lo que concierne al Provisioner:

• Debido a que este proceso actualmente lo tiramos desde nuestro máquinas de desarrollo conectadas a través de la VPN hacia el cluster en producción, lanzamos el aprovisionamiento con Ansible en local (shell-local) para definir todos los servicios que va a necesitar nuestro frontal para poder servir nuestra aplicación. (¡que no la última versión del código!)

Nuestro provision_frontend.yml:

---
- hosts: "frontend"
  sudo: true
  remote_user: root
  handlers:
    - include: handlers/services.yml
  roles:
    - repositories
    - common_packages
    - apache
    - php
    - { role: geerlingguy.composer }
    - logentries
    - newrelic
    - { role: announce.newrelic-php }
    - { role: stackscale, when: uvinum_environment == 'production' }

y el fichero de inventario templates-stackscale:

[frontendtemplate]
X.X.X.150 uvinum_hostname=frontendtemplate

• Flusheamos la dirección MAC que nos genera el SO cada vez que levantamos la máquina, de esta manera evitamos la colisión de con otra que se levante con la MAC por defecto y no podamos conectarnos a ella al reiniciarla.

y todo esto gracias a un:

packer build -only=frontend provisioned_from_templates.json

Next steps:

Basar nuestros templates finales directamente desde la ISO. Para ello tenemos que resolver temas de la instalación base, así como la asignación de la IP al crear una máquina de 0, ya que desconocemos el funcionamiento de DHCP a nivel de VSphere.

Tenéis subidas las slides que usamos en la pasada formación interna:

Packer, de los templates a mano a los templates por código

Y recordad que para estar al corriente de que lo que seguimos haciendo nos tenéis en twitter bajo @UvinumEng
1 clap = 1 ❤ al mundo Devops y 1 incentivo más para el post de Terraform