La frase "Infraestructura como código" se ha mencionado varias veces en las últimas dos semanas en diferentes contextos. ¿Qué significa realmente en un sentido práctico tener Infraestructura como Código?
TL; DR : Infraestructura como código es una forma de automatizar y respaldar su entorno. En el caso ideal, después de un desastre, puede restaurar su infraestructura de forma completa y automática aprovisionando nuevos recursos, restaurando la configuración del repositorio de código y recuperando datos de la copia de seguridad.
Infraestructura como Código se basa en tres conceptos principales:
Automatización de la gestión de la configuración , denominada Automatización continua de la configuración, un campo promovido por el prof. Mark Burgess
Repositorio de código para cambios en la infraestructura, donde los cambios primero se confirman, documentan, revisan, prueban y luego se implementan a través de la automatización.
Aprovisionamiento de infraestructura gestionada . Infraestructura como servicio (IaaS). Ya sea a través de Cloud Computing , Private o Managed Cloud o Managed Datacenter Services
Configuration Management está en su tercera generación de herramientas. Basándose en CFEngine, ahora se está implementando ampliamente un nuevo conjunto de herramientas para la Gestión de configuración automatizada. Los más populares en orden alfabético son Ansible, CFEngine, Chef, Puppet, PowerShell DSC y SaltStack . Cada uno tendrá un Idioma para describir el estado de su infraestructura, Módulos de código para aplicar esos cambios y proporcionar la capacidad de ampliar las herramientas, algunos Agentes para ejecutarlos en los servidores y un Repositorio central de información.
Generalmente operarán en modo push o pull, ya sea conectándose a servidores desde una ubicación central (es) y ejecutando cambios de forma remota o ejecutándose en cada servidor y obteniendo información sobre el estado de la ubicación central y que ya sea en el modelo cliente / servidor o en un modelo distribuido camino.
El concepto importante es que el administrador del sistema o el ingeniero de confiabilidad del sitio no realicen cambios directamente en la infraestructura, sino que permitan que la automatización haga cambios. Cualquier cosa hecha manualmente por un humano debe considerarse como perecedera, ser corregida rápidamente por la automatización o en forma más estricta, violando la integridad de la infraestructura y desencadenando la destrucción y reconstrucción de los componentes afectados.
El repositorio de código, idealmente separado del software de almacenamiento de repositorio, se usaría para administrar todos los cambios en la infraestructura y la automatización relacionada. Debe contener archivos y plantillas de configuración, libros de jugadas (libros de cocina) que describan el proceso de cambios que se revisarán, código que extiende las herramientas de automatización CM, configuraciones de aprovisionamiento, pruebas y alertas de infraestructura, pruebas de puesta en marcha / implementación, documentación, descripciones de procesos manuales (aún no automatizados) .
El concepto importante es instituir revisiones por pares para los cambios, tener un registro de todos los cambios y la capacidad de volver automáticamente al estado anterior en caso de problemas impredecibles y / o no probados, la capacidad de implementar en el entorno de ensayo y probar los cambios de configuración y la capacidad de implementar automáticamente cambios sin variación causados por error humano.
La gestión de la infraestructura física es una tarea del mundo real que va más allá del software y requiere un conjunto muy diferente de habilidades. Al poder abstraer esta capa a través de Cloud Computing o un Centro de datos administrado, su equipo se enfoca en la parte de la administración de Infraestructura que agrega valor comercial.
Si bien Cloud Computing ofrece una forma de comenzar y escalar rápidamente en una etapa posterior, las empresas a menudo obtienen algunos beneficios e incluso ahorros significativos en partes móviles de la Infraestructura en sus propios centros de datos para un modelo híbrido. Ser propietario o alquilar el hardware no significa que también deba emplear a las personas que lo manejan. A esta escala, necesita centros de datos distribuidos geográficamente en todo el mundo y tener personas con todas las habilidades requeridas en todos los lugares sería muy costoso. Volarlos por todo el mundo agrega una alta latencia a cualquier cambio y un nivel adicional de ineficiencias operativas, que es otra razón para externalizar la gestión del centro de datos.
La conclusión importante es que la Infraestructura física administrada a menudo se olvida o se pasa por alto , pero es igual de importante. Incluso si tiene todo automatizado, toda la configuración almacenada en un repositorio de código respaldado, a menos que tenga una forma de aprovisionar rápidamente , tiene un enorme cuello de botella , que podría borrar fácilmente todos los beneficios que ha obtenido con los otros dos pasos .
Antes de explicar qué es exactamente, permítanme citar una definición realmente agradable, directamente de Wikipedia :
Infraestructura como código (IaC) es el proceso de gestión y aprovisionamiento de infraestructura informática (procesos, servidores básicos, servidores virtuales, etc.) y su configuración a través de archivos de definición procesables por máquina, en lugar de la configuración de hardware físico o el uso de la configuración interactiva herramientas.
Bien, ahora veamos una de esas herramientas de IaC, Terraform, para comprender mejor el concepto: https://www.terraform.io/
Además, esto es lo que Terraform dice sobre sí mismo:
Terraform le permite crear, cambiar y mejorar de manera segura y previsible la infraestructura de producción. Es una herramienta de código abierto que codifica las API en archivos de configuración declarativos que pueden compartirse entre los miembros del equipo, tratarse como código, editarse, revisarse y versionarse.
Esto significa que uno puede codificar todo el infra. que incluye la creación de recursos en la nube (/ infra) como las instancias del servidor, equilibradores de carga, etc., junto con las configuraciones completas (que incluye ajustes de configuración básicos, configuraciones de seguridad, regiones, etc.) como código, que puede ser editable, versionable y Por supuesto, revisable.
Este es un ejemplo de código de Terraform para aprovisionar recursos de AWS:
resource "aws_elb" "frontend" {
name = "frontend-load-balancer"
listener {
instance_port = 8000
instance_protocol = "http"
lb_port = 80
lb_protocol = "http"
}
instances = ["${aws_instance.app.*.id}"]
}
resource "aws_instance" "app" {
count = 5
ami = "ami-408c7f28"
instance_type = "t1.micro"
}
Bonus PS : Además, uno necesita comprender las diferencias entre las herramientas de aprovisionamiento y orquestación . Los desarrolladores confunden uno con el otro muy a menudo y tienden a cometer el error de tratar de ajustar y usar una herramienta para lo que no está destinado a ser utilizado.