Infrastructure as Code (IaC)
Infraestructura como código es un método de automatización que esta basada en prácticas de desarrollo de software. Los cambios realizados a los sistemas y sus configuraciones específicas son bien definidas y capturadas en archivos de configuración (scripts, playbooks, manifests, módulos).

La idea detrás de IaC es que tratando a una infraestructura como software se pueden aplicar prácticas comunes utilizadas en el desarrollo de software, continous delivery(CD), continous integration (CI), versionamiento, testing driven development (TDD), etc.

El uso de scripts para automatizar la administración de servidores no es particularmente algo nuevo, pero con el auge cloud y sus distintas formas que puede adoptar (IaaS, PaaS, SaaS) y nuevas herramientas como Ansible, Puppet, Chef, Saltstack, que de la mano con DevOps han popularizado a IaC.

¿DevOps?

Es un movimiento cultural que combina filosofías, buenas prácticas y la colaboración entre desarrolladores de software y gente de operaciones. Una de las metas de DevOps es disminuir el ciclo de desarrollo e incrementar la frecuencia de despliegue de nuevas funcionalidades del negocio.

¿Porque debería implementar IaC?

Incluso con las tecnologías más nuevas de virtualización, contenedores y cloud el tiempo que lleva preparar los requisitos necesarios para la implementación de nuevas funcionalidades de negocio en producción es proporcional a la cantidad de servidores a configurar y la criticidad del proyecto.

La realidad del día a día sin infraestructura como código y DevOps es que en el momento que el número de servidores pase de 10 a 100+ la gente de operaciones se encarga mayormente de apagar incendios rutinarios, incluso cuando los problemas son detectados, las soluciones pueden no ser aplicadas a todos los sistemas afectados. Diferencias en versiones y configuraciones en los servidores puede ocasionar que software y scripts que funcionan en un servidor no funcionen en otro, llevando así a un estado de inconsistencia a través de los servidores.

Diferencia entre los servidores no es el problema, el problema está cuando esas variaciones no son capturadas y manejadas de una forma que sea fácil de reproducir y reconstruir, con IaC uno podría capturar y definir esas diferencias.

Un caso puntual donde un grupo de servidores utilizados como loadbalancers en el cual todos comparten configuraciones similares pero algunos manejan una cantidad de request mayor que el resto por tanto necesitan ser tuneados acordemente, esas diferencias son bien definidas en una infraestructura como código, logrando así que el provisionamiento para un proyecto que tomaría 2 semanas te tome 15min.

OK, ¿y Ansible?

Las 2 partes principales de IaC son provicionamiento y configuración, en las cuales definimos el contenido de los servidores, que configuración deben tener, que aplicaciones deben estar instaladas, como deben ser instaladas, etc. Aquí es donde herramientas como ansible entran en juego.

Arquitectura básica de ansible

1. Conexión: Ansible es “agentless”, es decir no requiere de instalación de agentes en los servidores que administra, utiliza SSH para conectarse al servidor y ejecutar comandos.

2. Inventory: Es donde son definidas y agrupadas los hosts a ser administradas por ansible.

En el ejemplo tenemos 4 grupos (dbservers, api, webapp, proxyservers) cada uno con sus respectivos hosts, cada host especifica un target potencial para comandos de ansible que ejecutemos.

1. Playbooks: Con los hosts definidos y agrupados ¿como especificamos a ansible que operación realizar?, el código ansible es definido en “YAML” que consta de tareas o tasks agrupadas a su vez en plays que son ejecutadas en un grupo especificado.

El playbook instala la base de datos postgresql y nginx como load-balancer en los hosts correspondientes.