Infraestructura como código: crear un blog multirregional en Public Cloud (segunda parte)

Bienvenidos a la segunda entrega de nuestra serie de artículos dedicados a la infraestructura como código con Terraform. Una vez que hemos sentado las bases de nuestro proyecto, ¡llega la hora de configurar la primera instancia y desplegar nuestro blog! 

En un mundo dominado por los devops, es legítimo que uno quiera parchear su infraestructura de la misma forma en que corrige su código, con las mismas posibilidades en cuanto a automatización, reproducibilidad y colaboración. La infraestructura como código nos permite satisfacer este deseo, gestionando los recursos como si se tratase del código de una aplicación. 

Esta serie de artículos pretende ilustrar los beneficios de este enfoque. En lugar de perdernos en consideraciones teóricas, hemos preferido basarnos en un ejemplo concreto y, a partir de él, analizar los grandes principios de la infraestructura como código. Para ello hemos elegido la herramienta Terraform, que se adapta especialmente bien a las necesidades de abstracción de la infraestructura en entornos híbridos. Los fragmentos de código de estos artículos son extractos de una guía que se puede consultar completa en GitHub.

En nuestro primer artículo abordamos las bases del funcionamiento de Terraform, explicando las nociones de provider, resource y variable, y vimos cómo crear un primer entorno de despliegue. En este segundo artículo empezaremos iniciando una instancia y configurando nuestro sitio web. A continuación veremos cómo securizar el conjunto e implementar un primer nivel de balanceo de la carga entre dos regiones.

El uso de los sistemas de gestión de contenidos (content management system, o CMS) no es uno de los temas que nos ocupan, por lo que crearemos nuestro blog con Hugo, un excelente generador de sitios estáticos muy fácil de instalar.

Preparación de la instancia

Para definir la instancia, abra el archivo «main.tf». En primer lugar, deberá parchear el provider (OpenStack en nuestro ejemplo) indicando la versión utilizada (1.5) para evitar que la infraestructura se vea afectada por una actualización de Terraform. Este truco podrá ahorrarle problemas en el futuro. También deberá pasar la región como variable para preparar el uso de varias regiones OpenStack.

provider

Continuamos con la propia instancia. Antes de iniciarla, son necesarios varios elementos. Terraform se encarga de resolver las dependencias y establecer el plan de acción de correspondiente.

instance A

Si nos fijamos en el código utilizado en el ejemplo, veremos cómo Terraform autoriza la interpolación de variables. Esa es la razón por la que el parámetro «var.count» aparece en la propiedad «count» de nuestra instancia.

La sintaxis de interpolación, disponible en JSON o HCL (HashiCorp Configuration Language), nos permite indicar el número de instancias que queremos iniciar. Terraform iterará tantas veces como indique el valor de la variable «count». Pero no es el único uso de esta variable, ya que también permite la ejecución de operaciones lógicas, como comprobar que una variable cumple una condición antes de ordenar la creación de un recurso.

Configurar el sistema tras el inicio

La configuración de la máquina sigue esta misma lógica: los datos del usuario (user_data) se incluyen en un template que define los scripts que se lanzarán o los archivos que se cargarán al crear la instancia. Terraform compila estos templates siguiendo el árbol de dependencia de los recursos. Aquí podrá, por ejemplo, configurar Apache para alojar un archivo de virtual host que haya preparado con antelación.

user_data

También es posible determinar parámetros de aprovisionamiento automático de cada recurso. Así ganaremos en eficacia y podremos gestionar una mayor cantidad de datos. Nosotros, por ejemplo, solicitamos la copia del contenido de nuestro blog en cada instancia iniciada mediante SCP.

Ya podemos crear nuestra primera instancia. Sin embargo, para disfrutar de la máxima seguridad, es recomendable instalar un certificado TLS y una primera versión de redundancia.

Generar un certificado TLS

Evidentemente, el objetivo no es desplegar manualmente un certificado Let’s Encrypt en el servidor Apache, sino planificar en Terraform la generación e integración automáticas del certificado al crear la instancia.

Terraform no incluye esta funcionalidad de forma nativa, pero puede instalar el plugin ACME Provider. Terraform creará la cuenta y el certificado utilizando los recursos dedicados, antes de solicitar la validación.

certificate

Ahora que ya dispone de un certificado TLS, ¿por qué no reforzar la seguridad de la infraestructura con una segunda instancia alojada en otra región? En este artículo nos conformaremos con un balanceo de carga simple mediante Round Robin DNS, aunque, como veremos en próximos artículos, Terraform permite llegar mucho más lejos en materia de alta disponibilidad.

Configurar el Round Robin DNS

Para desplegar la instancia en una nueva región, solo tiene que declarar el provider OpenStack correspondiente (región B) en el archivo «main.tf» y, a continuación, volver a introducir los elementos de configuración de la nueva instancia (puerto de red B, instancia B…). Por último, tendrá que crear la articulación entre las dos instancias mediante el provider OVH, que recoge todos los recursos necesarios para la explotación de nuestra API. El recurso «ovh_domain_zone_record» permite especificar nuestra zona DNS y los registros asociados.

DNS record

Una vez que haya realizado todos los pasos anteriores, dispondrá de un blog operativo, con una primera versión de balanceo de la carga entre dos instancias localizadas en regiones diferentes. Estas acciones nos ayudan a entender mejor el funcionamiento de una instancia en Terraform y cómo se utilizan las distintas propiedades. Sin embargo, Terraform permite hacer muchísimo más, y esto es precisamente lo que veremos en nuestra próxima entrega.

Para más información sobre Terraform, consulte nuestros artículos en GitHub: