Infraestructura como código
La infraestructura como código (IaC) (en inglés: Infrastructure as Code) es el proceso de gestión y aprovisionamiento de centros de datos informáticos a través de archivos de definición legibles por máquina, en lugar de configuración de hardware físico o herramientas de configuración interactiva. La infraestructura de TI gestionada comprende desde equipo físico como servidores bare metal hasta máquinas virtuales y los recursos de configuración asociados. Las definiciones pueden estar en un sistema de control de versiones. Puede utilizar tanto scripts como definiciones declarativas en lugar de procesos manuales, pero el término se utiliza más a menudo para promover los enfoques declarativos.
Visión general
[editar]IaC creció como respuesta a la dificultad planteada por dos piezas de tecnología: la computación bajo demanda y los marcos web de segunda generación. En 2006, el lanzamiento de la Nube de Computación Elástica de Amazon Web Services y la versión 1.0 de Ruby on Rails unos meses antes provocó problemas de escalamiento generalizados para muchas empresas, problemas que antes sólo eran presenciados por grandes compañías.[1] Con la aparición de nuevas herramientas para manejar este campo siempre creciente, nació la idea de IaC. La idea de modelar la infraestructura con código, y luego tener la capacidad de diseñar, implementar y desplegar la infraestructura de las aplicaciones con las mejores prácticas de software conocidas atrajo a los desarrolladores de software y a los administradores de la infraestructura de TI. La capacidad de tratarlo como código y utilizar las mismas herramientas que cualquier otro proyecto de software permitiría a los desarrolladores desplegar rápidamente las aplicaciones.[2]
Valor añadido y ventajas
[editar]El valor de las IaC puede desglosarse en tres categorías medibles: costo (reducción), velocidad (ejecución más rápida) y riesgo (eliminación de errores y violaciones de seguridad). La reducción de costos tiene como objetivo ayudar no sólo a la empresa financieramente, sino también en términos de personas y esfuerzo, lo que significa que al eliminar el componente manual, las personas son capaces de reenfocar sus esfuerzos hacia otras tareas empresariales. La automatización de la infraestructura permite la velocidad a través de una ejecución más rápida al configurar su infraestructura y tiene como objetivo proporcionar visibilidad para ayudar a otros equipos en toda la empresa a trabajar de forma rápida y más eficiente. La automatización elimina el riesgo asociado a los errores humanos, como la mala configuración manual; eliminarlos puede disminuir el tiempo de inactividad y aumentar la fiabilidad. Estos resultados y atributos ayudan a la empresa a avanzar hacia la implementación de una cultura de DevOps, el trabajo combinado de desarrollo y operaciones.[3]
Tipos de enfoques
[editar]En general, hay tres enfoques de la IaC: declarativo (funcional) vs. imperativo (de procedimiento) vs. inteligente (consciente del entorno). La diferencia entre el enfoque declarativo, el imperativo y el inteligente es esencialmente "qué" vs. "cómo" vs. "por qué". El enfoque declarativo se centra en cuál debería ser la configuración objetivo eventual; el imperativo se centra en cómo la infraestructura debe ser cambiada para cumplir con esto; el enfoque inteligente se centra en por qué la configuración debería ser de una cierta manera considerando todas las co-relaciones y co-dependencias de las múltiples aplicaciones que se ejecutan en la misma infraestructura, típicamente encontradas en producción.[4] El enfoque declarativo define el estado deseado y el sistema ejecuta lo que necesita suceder para alcanzar ese estado deseado. El imperativo define comandos específicos que deben ser ejecutados en el orden apropiado para terminar con la conclusión deseada. El inteligente determina el estado deseado correcto antes de que el sistema ejecute lo que debe suceder para alcanzar un estado deseado que no afecte a las aplicaciones codependientes. El estado deseado consciente del entorno es la próxima generación de IaC.[5]
Métodos
[editar]Hay dos métodos de IaC: "push" y "pull". La principal diferencia es la manera en que se le dice a los servidores cómo deben ser configurados. En el método pull el servidor a configurar sacará su configuración del servidor de control. En el método push el servidor controlador empuja la configuración al sistema de destino.[6]
Herramientas
[editar]Hay muchas herramientas que cumplen con las capacidades de automatización de la infraestructura y utilizan IaC. En términos generales, cualquier marco o herramienta que realice cambios o configure la infraestructura de forma declarativa o imperativa basada en un enfoque programático puede considerarse IaC. Tradicionalmente, se utilizaban herramientas de automatización de servidores (ciclo de vida) y de gestión de la configuración para lograr IaC. Ahora las empresas también utilizan herramientas de automatización de la configuración continua o marcos de IaC independientes, como el DSC de Microsoft PowerShell[7] o el CloudFormation de AWS.
Automatización de la configuración continua
[editar]Todas las herramientas de automatización de la configuración continua (CCA) pueden ser pensadas como una extensión de los marcos tradicionales de IaC. Aprovechan el IaC para cambiar, configurar y automatizar la infraestructura, y también proporcionan visibilidad, eficiencia y flexibilidad en la gestión de la infraestructura.[1] Estos atributos adicionales proporcionan seguridad y conformidad a nivel empresarial, lo que hace que las empresas se interesen por la implementación de este tipo de herramientas.
Contenido de la comunidad
[editar]Un aspecto importante al considerar las herramientas de CCA, si son de código abierto, es el contenido comunitario. Como afirma Gartner, el valor de las herramientas CCA "depende tanto del contenido y el apoyo aportado por la comunidad de usuarios como de la madurez comercial y el rendimiento de las herramientas de automatización".[1] Chef tiene Chef Community Repository y Puppet tiene PuppetForge.[8] Otros vendedores dependen de comunidades adyacentes y aprovechan otros marcos de IaC como PowerShell DSC.[7] Están surgiendo nuevos vendedores que no están impulsados por el contenido, sino por el modelo con la inteligencia en el producto para entregar el contenido. Estos sistemas visuales orientados a objetos funcionan bien para los desarrolladores, pero son especialmente útiles para los DevOps orientados a la producción y los componentes de operaciones que valoran los modelos frente a los scripts para el contenido. A medida que el campo continúa desarrollándose y cambiando, el contenido basado en la comunidad será cada vez más importante para la forma en que se utilizan las herramientas de IaC, a menos que estén dirigidas por modelos y orientadas a objetos.
Relación con DevOps
[editar]El IaC puede ser un atributo clave para permitir las mejores prácticas en los DevOps - Los desarrolladores se involucran más en la definición de la configuración y los equipos de Ops se involucran más temprano en el proceso de desarrollo[9] Las herramientas que utilizan IaC aportan visibilidad al estado y la configuración de los servidores y, en última instancia, proporcionan la visibilidad a los usuarios dentro de la empresa, con el objetivo de reunir a los equipos para maximizar sus esfuerzos La automatización en general tiene como objetivo tomar el aspecto de confusión y propensión a errores de los procesos manuales y hacerlo más eficiente y productivo. Permitiendo que se creen mejores programas y aplicaciones con flexibilidad, menos tiempo de inactividad y una manera rentable para la empresa. IaC tiene como objetivo reducir la complejidad que mata la eficiencia de la configuración manual. La automatización y la colaboración se consideran puntos centrales en DevOps; las herramientas de automatización de la infraestructura a menudo se incluyen como componentes de una cadena de herramientas de DevOps.
Relación con la seguridad
[editar]El Informe de Cloud Threat Report 2020 publicado por Unit 42 (la unidad de inteligencia de amenazas del proveedor de seguridad cibernética Palo Alto Networks) identificó alrededor de 200.000 posibles vulnerabilidades en la infraestructura como plantillas de código.[10]
Véase también
[editar]Referencias
[editar]- ↑ a b c «My Gartner». www.gartner.com. Consultado el 30 de junio de 2020.
- ↑ «Version your infrastructure - DevOps.com». web.archive.org. 29 de julio de 2018. Archivado desde el original el 29 de julio de 2018. Consultado el 30 de junio de 2020.
- ↑ «Moving from Infrastructure Automation to True DevOps - DevOps.comDevOps.com». web.archive.org. 26 de mayo de 2015. Archivado desde el original el 26 de mayo de 2015. Consultado el 30 de junio de 2020.
- ↑ «Declarative vs. Imperative Models for Configuration Management: Which Is Really Better?». web.archive.org. 31 de marzo de 2015. Archivado desde el original el 31 de marzo de 2015. Consultado el 30 de junio de 2020.
- ↑ Loschwitz, Martin. «Chef or Puppet? » ADMIN Magazine». ADMIN Magazine (en inglés estadounidense). Consultado el 30 de junio de 2020.
- ↑ Venezia, Paul (21 de noviembre de 2013). «Puppet vs. Chef vs. Ansible vs. Salt». Network World (en inglés). Archivado desde el original el 18 de julio de 2018. Consultado el 30 de junio de 2020.
- ↑ a b «DevOps, Infrastructure as Code, and PowerShell DSC: The Introduction – PowerShell Magazine» (en inglés estadounidense). Consultado el 30 de junio de 2020.
- ↑ «Puppet or Chef? | Phil Sturgeon». web.archive.org. 1 de febrero de 2016. Archivado desde el original el 1 de febrero de 2016. Consultado el 30 de junio de 2020.
- ↑ «Continuous Integration: Infrastructure as Code in DevOps». web.archive.org. 6 de febrero de 2016. Archivado desde el original el 6 de febrero de 2016. Consultado el 30 de junio de 2020.
- ↑ «Cloud Threat Report Shows Need for Consistent DevSecOps». InformationWeek (en inglés). Consultado el 30 de junio de 2020.
| Control de autoridades |
|
|---|
Datos: Q24964334