Infraestructura como código
- 11 minutos
Antes de la nube, cuando una organización necesitaba compilar su infraestructura informática, implementaba nuevos servidores físicos y los agregaba a la red detrás de un equilibrador de carga y un firewall. Cuando un administrador de operaciones tenía que calcular los gastos de capital necesarios para admitir la capacidad agregada, esas estimaciones se representaban en términos de servidores completos. La "arquitectura" la realizaba una calculadora. En el pasado, una de las sugerencias de planeación de la capacidad era agregar un "cojín", o sobrestimación, del 20 % en caso de que las estimaciones iniciales fueran demasiado bajas.
La nube lo cambió al ofrecer la infraestructura informática como servicio. De repente, para agregar capacidad solo había que hacer clic en los botones de un portal, escribir comandos en una consola o ejecutar scripts. Esta facilidad creó un nuevo conjunto de desafíos. Como una sola persona puede implementar en cuestión de minutos una solución completa formada por decenas o incluso cientos de servicios en la nube, ¿cómo puede asegurarse de que las soluciones se implementan correctamente, que los recursos individuales están configurados correctamente y que el operador no ha cometido un error? ¿Cómo se puede modificar una solución de forma confiable una vez implementada a la vez que se minimizan los posibles errores humanos? El scripting es una solución, pero como se ha visto en la lección anterior, resuelve ciertos problemas e introduce otros.
El siguiente paso en el recorrido para automatizar los procesos que se usan para administrar la infraestructura en la nube es Infraestructura como código o IaC. El concepto de IaC es definir de forma explícita una solución implementada en la nube de forma dinámica, como un programa. Ejecute el programa y se crea una solución; cambie el programa y se cambia la solución. IaC proporciona un mecanismo para definir el aspecto de una solución. Contiene muchos de los elementos de un programa sin depender necesariamente en un lenguaje de programación: declaración de recursos (variables), funciones y procedimientos reutilizables, detección y recuperación de errores y, lo más importante de todo, compatibilidad formal con las pruebas y la depuración (Figura 3).
Figura 3: Paralelos entre programas de infraestructura como código y software.
IaC se basa en archivos de configuración que son similares al código fuente de los programas de aplicación. Es posible que un archivo de configuración de IaC no sea similar al código fuente y probablemente no esté escrito en Python u otro lenguaje de programación tradicional. Pero todos los componentes principales que un desarrollador de software buscaría están presentes, aunque con otra sintaxis. Un archivo de configuración puede carecer de comandos o procedimientos paso a paso que tiene un programa de Python o un script de PowerShell, pero define un resultado y un proceso para lograr ese resultado exactamente igual.
Esta estrategia es el concepto de Infraestructura como código. La dinámica de la nube hace que los recursos de la solución sean fluidos y no estén restringidos por los límites de las máquinas que los admiten. Un sistema que supervisa su administración no debe estar restringido por esos límites, ya sea tratando todo el centro de datos, de forma local y desconectada, como si se tratara de un equipo que se puede crear mediante programación.
La introducción de la administración de configuración
Muchos sectores además de TI se benefician de la administración de configuración (CM), especialmente en el ámbito de la fabricación y la producción. En la producción de automóviles, CM hace referencia a los métodos y procesos que se usan para fabricar un producto que cumple con estándares específicos o los requisitos del cliente. En la fabricación de equipos industriales, donde se generan componentes que se usan para crear máquinas, hay sistemas de numeración de componentes, sistemas de administración de versiones, sistemas de administración de cambios y sistemas de contabilidad de estado, que se deben coordinar para generar un resultado repetible.
En TI, la automatización de la administración de configuración no es tan distinta. Implica la administración de sistemas en estados de transición. Además, implica la coordinación de varios subsistemas para que funcionen de forma conjunta. Las dudas filosóficas son un problema actual para los administradores de TI: ¿El sistema debe mantener y conservar los procesos por los que se aprovisiona y ensambla la infraestructura basada en la nube? ¿O en su lugar debe definir los componentes de infraestructura necesarios para satisfacer los requisitos de clientes o usuarios, y determinar cómo cumplir esos requisitos en función del estado actual de la infraestructura? Actualmente, hay sistemas de CM en uso que adoptan un enfoque o el otro.
En 1993, cuando la noción de virtualización en el centro de datos todavía estaba en sus inicios, un investigador de teoría del campo cuántico de la Universidad de Oslo llamado Mark Burgess produjo en su tiempo libre, mientras realizaba proyectos financiados por el gobierno sobre la teoría del campo térmico1, lo que se cree que es la primera herramienta moderna de administración de la configuración. Llamado CFEngine, comenzó como un lenguaje específico del dominio que implementó pruebas condicionales basadas en criterios de la configuración de un equipo. Estas pruebas se usaban para determinar qué instrucciones ejecutar para llevar al sistema a un estado de configuración deseado.
A medida que evolucionaron, los criterios de estas pruebas condicionales se convirtieron en declaraciones; instrucciones que describían cuál debería ser el estado deseado del sistema. Hasta entonces, una configuración del sistema se describía como el estado inicial de un sistema que se somete a una secuencia de transformaciones. Lo mismo se puede usar para caracterizar un script administrativo típico: una lista de todo lo que debe hacer un intérprete de la CLI para modificar el estado de un sistema existente o para crear algo en un estado partiendo desde cero.
Siete años después, para su importante libro de texto sobre la administración de redes y sistemas2, Burgess definió eficazmente el uso del término "infraestructura" para referirse a los recursos que componen y respaldan colectivamente el centro de datos. También estableció sus cinco requisitos para que la infraestructura de cualquier centro de datos se considere estable: escalabilidad, confiabilidad, redundancia, homogeneidad y reproducibilidad.
Burgess creía que era posible cumplir estos requisitos a través de un sistema de administración de configuración cuyo lenguaje hace que su desarrollador comience con el estado final deseado y deje que el sistema retroceda el desarrollo hasta el estado actual. En un ensayo publicado en su sitio web personal3, Burgess describe la dirección en la que el scripting convencional tiende a ir como congruencia, que él comparó con una receta que guía a alguien a través de los pasos para construir algo sin describir qué es ese algo. La dirección que prefiere es la convergencia, que compara con el uso de un mapa que muestra el destino y planea una ruta que conduce a donde estás ahora.
Administración de configuración de próxima generación
En 2006, el desarrollador de software de código abierto Luke Kanies lanzó bajo la Licencia Pública General (GPL) una herramienta que llamó Puppet. Describiéndolo como "Administración de configuración de próxima generación4", lo presentó a sus compañeros profesionales de TI como una "capa de abstracción del sistema operativo". Esa frase no se cogió, pero la idea lo hizo. Su premisa era que el lenguaje de un sistema de administración de configuración debe declarar los componentes necesarios de un tipo de recursos, como las máquinas virtuales. Después, el sistema se podría encargar de realizar los pasos necesarios para cumplir esos requisitos, u otros similares, incluso cuando la secuencia de esos pasos pudiera cambiar. En la lección siguiente se presentan más detalles sobre el lenguaje Puppet y cómo funciona el sistema.
Con Puppet, un operador puede especificar una clase de servicio, formada por paquetes de aplicación y los demás recursos necesarios para entregar algo a los usuarios. El trabajo del sistema de administración de configuración se convierte en el aprovisionamiento de los recursos adecuados necesarios para prestar ese servicio, ya que se ha clasificado dentro de Puppet. Esto puede implicar el aprovisionamiento de máquinas virtuales o, con los sistemas en contenedores más recientes, la creación de instancias de contenedores y los recursos que las complementan.
DevOps: desarrolladores y operadores
Prácticamente en el mismo instante en que una empresa empieza a pensar en usar infraestructura como código, comienza a analizar si dos departamentos históricamente independientes, los de administración de TI y desarrollo de software, se deben fusionar. El movimiento DevOps proviene de la idea de que dos equipos independientes de la organización no pueden llevar a cabo ningún plan en este nivel de la empresa.
El término "DevOps" se atribuye a la inspiración, durante una conferencia de 2009 del sector informático, en la que dos de los ponentes fueron John Allspaw (en aquel momento director de operaciones técnicas) y Paul Hammond (jefe del equipo de ingeniería) del servicio de uso compartido de fotografías Flickr. En su sesión conjunta presentaron este concepto, que en aquel momento fue revolucionario: si la infraestructura del centro de datos podría ser adaptable y responder a las necesidades cambiantes de las cargas de trabajo, podría admitir aplicaciones y servicios con ciclos de versiones mucho más cortos y velocidades de implementación y mejora continua mucho más rápidas.
IaC, integración continua e implementación continua (CI/CD), y la realineación de los equipos en torno a proyectos y objetivos en lugar de administradores y organigramas, se han unido como parte de la misma tendencia evolutiva. Esta tendencia conduce a cambios de organización empresariales que los usuarios ajenos al departamento de TI pueden reconocer y apreciar:
El impacto de DevOps
- El software se está desarrollando más rápido
- Las pruebas se tratan más en serio y rigurosamente.
- Las herramientas de administración de infraestructura se integran con servidores de automatización
- Los métodos de gestión para equipos de software se están utilizando para equipos de TI
El software se desarrolla más rápido
O en aquellas organizaciones que nunca han desarrollado sus propias aplicaciones o servicios, se desarrolla software donde antes no se hacía. Los ciclos de versiones de software solían alargarse durante meses, incluso años, hasta un tiempo de entrega establecido en el itinerario adecuado para toda la organización. Uno de los motivos de estas extensiones era permitir ventanas de oportunidad para la actualización o el reemplazo del hardware, o bien el establecimiento de centros de datos totalmente nuevos, justo antes de una versión de software que, de otro modo, se vería afectada por un cambio de infraestructura a mitad del ciclo. Gracias a las plataformas en la nube que ahora permiten a los operadores realizar cambios más incrementales en su infraestructura con mayor frecuencia, ya no hay ningún motivo para retrasar los ciclos de versiones de software.
Las pruebas se tratan de forma más seria y rigurosa
En un entorno de centro de datos que haya adoptado CI/CD, el software se prueba en al menos una fase independiente, posiblemente dos, antes de que se publique en producción. Es posible que no resulte práctico construir fases de desarrollo y ensayo similares para la infraestructura de la nube, pero las herramientas de IaC permiten el planeamiento de "simulacros", donde los administradores pueden observar y predecir los efectos de los cambios aplicados a las soluciones en la nube antes de que se confirmen.
Las herramientas de administración de la infraestructura se integran con los servidores de automatización
Los servidores de automatización, como Jenkins, se usan para realizar cambios de infraestructura. Como resultado, el mismo itinerario "canalizado" que se usa para planear los ciclos de versiones de aplicaciones y servicios se sincroniza con planes de infraestructura, recetas (Chef) o cuadernos de estrategias (Ansible), de modo que el estado de la infraestructura siempre está alineado con las cargas de trabajo que admite.
Los métodos de administración de los equipos de software se usan en los equipos de TI
Las metodologías Agile se extienden a los equipos de operaciones. En un marco de trabajo de Agile, un equipo más pequeño con un jefe de proyecto define objetivos más sencillos que se pueden lograr en intervalos más cortos, lo que conduce a esos objetivos de forma más metodológica. Varios equipos se pueden coordinar entre sí y, por tanto, pueden medir su progreso con mayor precisión. Un equipo de operaciones Agile, o similar a Agile, se puede alinear más estrechamente con un equipo de software para garantizar que los recursos de infraestructura están disponibles y se pueda confiar en ellos.
IaC es simplemente un concepto abstracto sin herramientas para implementarlo. En la lección siguiente se presentan algunas de las herramientas de administración de configuración más utilizadas, que adoptan la noción de infraestructura como código en distintos niveles.
Referencias
Página web personal de Mark Burgess. http://markburgess.org/bio.html.
Wiley Publishing. Principios de administración de red y sistema. https://www.wiley.com/Principles+of+Network+and+System+Administration%2C+2nd+Edition-p-9780470868072.
Blog de Mark Burgess. http://markburgess.org/blog_cd.html.
usenix. Puppet: Administración de configuración de próxima generación. https://www.usenix.org/publications/login/february-2006-volume-31-number-1/puppet-next-generation-configuration-management.
Comprobación de conocimientos
Comentarios
¿Le ha resultado útil esta página?
No
¿Necesita ayuda con este tema?
¿Desea intentar usar Ask Learn para aclarar o guiarle a través de este tema?