Practices for developing maintainable infrastructure code

Este es el título de la charla que expuse el martes pasado en el Meetup de Infra as Code en la UTN.BA. Los slides están disponibles aquí. La idea de la charla estuvo motivada por el hecho de que en los últimos año el uso de esta práctica se ha popularizado mucho y en varios casos he visto que no se la ha prestado la suficiente atención a la forma de escribir el código. El código «no cuidado» puede no tener efectos negativos en lo inmediato, pero en el mediano/largo plazo puede representar un dolor de cabeza. Dicho esto, la idea de la charla era llamar la atención sobre la importancia de escribir «código feliz» y junto con ello compartir algunas técnicas y herramientas para poder hacerlo.

Al comienzo de la charla, hice un breve encuesta de un par de preguntas para entender la audiencia, por un lado pregunté el rol de los participantes y por otro pregunté quién escribía el código de infraestructura. Los resultados a estas preguntas se ven en los gráficos a continuación.

Un dato que me parece interesante analizar es que el ~35 % de los participantes indicó no estar usando InfraAsCode aún. Por otro lado el ~17% indicó que dicho código lo escriben los developers, en este grupo me encontraría yo :-).

Un caso de Infra as Code

El manejo de infrastructura como código es relativamente simple cuando la infraestructura es Kubenernetes, pero cuando no es así la cuestión se puede tornar más compleja.

El proyecto en el que estoy trabajando actualmente no utiliza Kubernetes, sino servidores (VMs) con CentOS 7. El front (ember.js) es servido desde un Web Server Apache y el back (java) corre en un Wildfly (jboss). Por otro lado tenemos un SQL Server (el setup de la instancia está fuera de nuestro alcance, pero nosotros nos encargamos de manejar el esquema de datos)

Para manejar todo esto tenemos:

  • Scripts para levantar la VM en la plataforma de VMWare
  • Scripts Ansible para aprovisionar las VMs instalando y configurando Apache, Wildfly, Java, etc
  • Scripts flyway para evolucionar el esquema de base de datos

Estos scripts los utilizamos para administrar 4 ambientes:

  • Desarrollo / Integración
  • Demo
  • Test / Homologación
  • Producción

Adicionalmente a estos ambientes compartidos cada developer tiene una VM (vagrant) local en su máquina de desarrollo, que también es aprovisionada con los mencionados scritps. Este me parece que es un punto central en un esquema de infraestructura mutable: cada developer tiene en su máquina un ambiente para probar que tiene el mismo runtime que el ambiente productivo. Esto no es menor ni tampoco muy común, ya que en general el ambiente del developer tiene un sistema operativo desktop mientras que el resto de los ambientes tiene un sistema operativo server.

De esta forma, más allá de tener versionada la infraestructura, tenemos ambientes uniformes.

ArqConf: Infrastructure as Code

El próximo 11 de Octubre se realizará una edición especial de la ArqConf sobre la temática particular de Infrastructure as Code.  En ese contexto estaré dando una charla titulada «Consideraciones de Diseño para un modelo de Infraestructura». Lo sé, el nombre no resulta muy atractivo pero confío en que contenido resultará valioso:

De la mano de DevOps, SREs y un conjunto de herramientas, la práctica de Infraestructura como Código ha adquirido una gran popularidad en los últimos años. La adopción de esta práctica implica una toma de decisiones que entre otras cosas incluye el diseño de un modelo de infraestructura y la selección de herramientas asociadas. En esta sesión veremos un conjunto de conceptos y recomendaciones para tomar estas decisiones de cara a una efectiva implementación de la práctica de Infraestructura como Código.

La cita es el 11 de Octubre a partir de las 14.30 en las instalaciones de Universidad Tecnológica Nacional, FRBA en Medrano 951, más info y registración en meetup.