Esta publicación de blog es un capítulo del libro electrónico De Admin a DevOps: La forma directa de hacer DevOps en Azure. Asegúrate de revisarlo si quieres sumergirte en lo que se necesita para tener éxito en DevOps en Microsoft Azure, aprendiendo la Infraestructura como Código.
Si alguna vez has creado algún tipo de infraestructura en la nube o virtual en las instalaciones de forma manual, sabrás que hay mucho clic o mucha escritura. La Infraestructura como Código (IaC) se encarga de eso.
Para aprovisionar cualquier cosa, es necesario recordar a qué pantalla ir o qué comando ejecutar. Si solo estás experimentando para aprender Azure, está bien, pero una vez que ese juego se convierte en procesos críticos para el negocio, donde el tiempo es dinero, algo tiene que cambiar.
Cuando tu organización comienza a tomarse en serio la provisión y gestión de la infraestructura, te enfrentarás a muchos desafíos nuevos.
Te encontrarás con duplicación innecesaria de trabajo, casos repetidos del síndrome del dedo gordo, problemas de gestión de cambios, desviación de configuración y más. Cuanto más grande sea la organización y el equipo, mayores serán los problemas. Todos estos problemas pueden eliminarse o, al menos, mitigarse con un concepto llamado Infraestructura como Código (IaC).
Infraestructura como Código (IaC): Ejemplo
IaC es un término de la industria que se refiere a almacenar todo lo necesario para construir componentes de infraestructura en código. Ese código suele definirse en archivos JSON o YAML que representan cómo debería ser tu infraestructura.
Una vez que todos los componentes están definidos en un archivo estructurado, otro proceso entra en acción, comprende el código e inmediatamente comienza a utilizar ese documento como instrucciones para construir la infraestructura.
Para proporcionar un ejemplo genérico, tipo pseudocódigo, tal vez tengas una máquina virtual (VM) que crear. Esa VM tiene necesidades como cómputo, almacenamiento y redes. Un enfoque de IaC básico sería describir la VM y todos sus componentes en una plantilla.
La Plantilla
En el siguiente fragmento de código, puedes ver un ejemplo de cómo se descompone cada componente mediante una jerarquía con atributos definidos sobre cada componente. Este ejemplo ficticio se creó en un archivo JSON que la mayoría de los servicios llamarían plantilla.
Esta plantilla define la VM y todos los atributos asociados con esa VM. Tiene un esquema específico al que los autores de plantillas se adhieren para definir cómo es esa VM. Supongamos que esta plantilla luego se guarda en un archivo llamado myvm.json.
Control de Origen
Ahora tienes todo lo que conforma una VM guardado en un solo archivo. Como buen profesional de DevOps, verificas ese archivo en el control de origen. Ahora tienes una forma de hacer un seguimiento de los cambios en el archivo.
La Herramienta
Ahora que el archivo está creado, necesitas una herramienta o servicio para leer ese archivo que comprenda lo que estás tratando de construir. Esa herramienta utiliza la plantilla como entrada y construye la VM según esas especificaciones exactas sin otra interacción.
¿Buen trato, verdad? Eso no es todo.
Combatir la Deriva de Configuración
Ahora supongamos que necesitas cambiar la dirección IP estática asignada a la NIC de esa máquina virtual. Puedes conectarte por RDP a la VM y cambiar la IP, pero no quieres hacer eso. ¿Por qué?
- Estás haciendo el cambio manualmente, lo cual es una pérdida de tiempo y propenso a errores humanos.
- No hay un registro de auditoría de quién cambió la IP y cuándo.
- No hay una forma automatizada de revertir el cambio en caso de que introduzcas incorrectamente la dirección IP.
La Infraestructura como Código (IaC) puede solucionar todos los desafíos anteriores. Con tan solo unos pocos golpes de teclado, puedes realizar ese cambio de una manera que tu gerente y auditor apreciarán.
Abre myvm.json, cambia el atributo IPAddress, guarda el cambio en el control de origen y ejecuta la herramienta nuevamente. ¡Listo!
La herramienta será lo suficientemente inteligente como para saber qué necesita cambiar. No desmontará la NIC ni reconstruirá toda la VM. Todas las herramientas y servicios de IaC son lo suficientemente inteligentes para comprender cómo realizar el cambio. ¡Magia!
Pero ahora te has dado cuenta de que has utilizado la IP equivocada y necesitas revertir el cambio. No hay problema. Revierte el cambio en el control de origen, guarda, ejecuta la herramienta y vuelves a estar en funcionamiento.
Pero espera, hay más.
Los comienzos de la Entrega Continua.
Cuando tienes la infraestructura almacenada en plantillas bajo control de origen, tienes un conjunto de ingredientes para el inicio de un lanzamiento automatizado o un pipeline de entrega continua.
Recuerda que tenías que ejecutar esa herramienta cada vez que cambiabas la plantilla. En un pipeline/workflow automatizado, esa herramienta se ejecuta automáticamente. Una vez que el proceso para crear o realizar el cambio en el entorno está automatizado, en el momento en que confirmas un cambio en la plantilla, la infraestructura coincide.
Construye suficientes plantillas y eventualmente, toda tu infraestructura podría estar representada en código o como código.
Conclusión
La IaC es una metodología de DevOps que permite a las operaciones tomar un papel del libro de jugadas del desarrollador de software. La IaC trae consigo muchas ventajas que un desarrollador de software ha estado aprovechando durante años y pone esas ventajas en manos del administrador del sistema.
Source:
https://adamtheautomator.com/infrastructure-as-code-iac/