Tabla de contenidos
Infrastructure as Code (Infraestructura como código) o IaC es la continuación de la filosofía Unix con medios DevOps. El concepto de administración para la infraestructura de TI hace que la instalación y configuración individual de hardware y software sea independiente de la interacción manual.
¿Qué significa «Infraestructura como código»?
Con su estructura y la abreviatura IaC, Infrastructure as Code se basa en los términos comunes utilizados en la computación en la nube, como SaaS y especialmente IaaS. La infraestructura como servicio describe una forma de poner ciertos recursos informáticos a disposición de los clientes, es decir, externamente.
Infraestructura como Código, en cambio, se refiere a la organización interna de la provisión y gestión de los recursos correspondientes. Con la formulación «como código» IaC especifica un cierto punto de vista que no es necesariamente fácil de entender.
¿Cómo se puede considerar un sistema como código fuente?
La clave para esto son las herramientas de software especiales, las herramientas de gestión de la configuración. Abstraen la configuración específica de componentes individuales de hardware y software para que sus funciones puedan definirse en términos generales y transferirse a diferentes instalaciones.
Estas herramientas generalmente se controlan mediante lenguajes de programación e interfaces similares que están abiertas al procesamiento y la gestión mediante herramientas de desarrollo de software. También se centra en la automatización de los procesos de configuración.
Una categoría de herramientas de la cadena de herramientas DevOps
El término Infraestructura como código (IaC) está estrechamente relacionado con DevOps. Este concepto combina el desarrollo y la operación (operaciones) de software en una sola unidad, por lo que también incluye la administración del sistema.
Como IaC trata la infraestructura de TI como un código y lo habilita a través de herramientas y medidas adecuadas, el concepto hace que la administración sea accesible a las herramientas y procedimientos habituales del desarrollo de software, por ejemplo, el control de versiones. Esto, a su vez, facilita la vinculación del desarrollo y las operaciones con DevOps. En el modelo común de siete etapas de la cadena de herramientas de DevOps, IaC proporciona herramientas adecuadas para la sexta fase, la configuración.
¿Qué herramientas utiliza IaC?
El entorno de nube, la virtualización y especialmente las arquitecturas de contenedores como Docker utilizan el término orquestación para el proceso de control y seguimiento de la infraestructura de TI correspondiente. En el campo de la administración de sistemas clásicos, es común el término software de administración de configuración para herramientas de orquestación de la generación en la nube.
Estos incluyen, por ejemplo, Ansible , Chef, Salt y Puppet, pero también herramientas más antiguas como CFEngine. Todos se pueden utilizar para IaC. Esto ya muestra que este concepto no surgió de la nada con la nube y DevOps, sino que tiene sus raíces en la administración de sistemas.
Enfoque tradicional con una nueva apariencia
La estrecha relación entre el desarrollo de software y la administración de sistemas tiene una larga tradición, especialmente en el entorno Unix. La programación de scripts de shell y el conocimiento de lenguajes de script como Perl o Python pertenecen a las herramientas básicas de un administrador de sistemas. La administración de archivos de configuración con sistemas de control de versiones también es común.
Hasta la introducción de los sistemas de gestión de paquetes en la década de 1990, la compilación de programas de aplicación o incluso todo el sistema operativo a partir del código fuente era una de las tareas habituales del administrador. También se pueden encontrar más similitudes más profundamente en los conceptos.
¿Qué tienen en común IaC y la filosofía Unix?
Infrastructure as Code prefiere el uso de archivos de configuración, cuyo contenido puede ser evaluado directamente por máquinas, sobre herramientas interactivas y configuraciones físicas que se realizarán en componentes de hardware.
Ya se pueden encontrar demandas similares en la primera versión de la filosofía Unix, documentada por Doug Ilroy en 1978. Allí dice en el punto 2: «No insista en la entrada interactiva». Ayuda para simplificar una tarea de programación»- indica una preferencia por la automatización.
También se pueden encontrar similitudes en el punto 3: «Diseñar y construir software, incluso sistemas operativos, para ser probado temprano». Mientras que en 1978 todavía era «idealmente en unas semanas», la introducción del concepto DevOps en 2009 en Flickr ya logró 10 entregas por día.
El enfoque de «entrega continua» incluso promete la entrega de software en cualquier momento. En este contexto, IaC asegura una configuración suficientemente rápida y escalable del software recién entregado, pero debe tenerse en cuenta durante el desarrollo del software al menos en la medida en que el diseño del software no impida su uso. Una aplicación configurable exclusivamente de forma interactiva sería, por ejemplo, inaccesible para la instalación y administración automatizadas utilizando software de gestión de la configuración.
Sin DevOps sin IaC, sin IaC sin DevOps
Vincular el desarrollo y las operaciones para un uso más eficiente de los recursos requiere recursos que permitan automatizar la provisión y gestión de la infraestructura de TI. Ya se dispone de los medios adecuados para el desarrollo de software. Por el contrario, la interpretación de la infraestructura como texto fuente requiere una estrecha cooperación entre el desarrollo de software y el funcionamiento de la infraestructura de TI.
Por un lado, el equipo de operaciones debe estar familiarizado con las herramientas de desarrollo de software para la provisión y administración. Por otro lado, el desarrollo prevé el uso de herramientas de automatización y gestión de la configuración en el diseño de software. Como beneficio, la implementación del concepto de Infraestructura como Código ofrece un mayor rendimiento, reducción de costos y minimización de riesgos al eliminar las fuentes de error.