Infraestructura como código: una guía esencial

Automatización de infraestructura con código

Hola a todos, mi nombre es Sai Venom y estoy en el equipo de IBM Cloud. Hoy vamos a hablar sobre la automatización de infraestructura con código. En estos días, es cada vez más crucial automatizar tu infraestructura, ya que las aplicaciones se pueden implementar en producción hasta cientos de veces al día. Además, la infraestructura es fugaz y puede ser aprovisionada o desaprovechada en respuesta a la carga.

Comencemos con un ejemplo. Supongamos que estás construyendo una aplicación y has elegido una nube pública. Lo primero que decides hacer es construir tu aplicación en Kubernetes. Entonces, tendríamos una pila de aplicaciones de Kubernetes. Ahora, no es necesario adentrarse más en Kubernetes, ya que aisla el hardware de la capa de aplicación y se encarga de la gestión por nosotros.

Ahora supongamos que, después de una semana de desarrollo, decidimos incorporar una máquina virtual que aloja una aplicación heredada que aún no hemos modernizado. Para conectar esos puntos, necesitaremos una VPC. Así que ahí lo tienes, tenemos una infraestructura básica en su lugar.

Ahora que he desarrollado esto, es genial que todos los detalles de la infraestructura estén documentados, ahora estoy listo para pasar a la fase de pruebas. Pero, según las mejores prácticas, lo que debería hacer es crear un nuevo entorno que imite mi entorno de desarrollo. Para hacerlo, volveré a mi documentación y comenzaré a seguir los pasos para implementar esa infraestructura. Sin embargo, supongamos que tal vez olvidé documentar uno de los cambios de configuración o tal vez la plataforma es diferente en la forma en que maneja la aprovisionamiento de la infraestructura. En cualquier caso, la aplicación y las pruebas no funcionan de la misma manera en el nuevo entorno. Decido que necesitamos solucionar este problema y para evitar tener este problema en el futuro, necesitamos aprovechar la infraestructura como código.

Enfoques para la automatización de infraestructura

Primero, hablemos sobre el enfoque imperativo. Este enfoque permite definir paso a paso cómo llevar tu infraestructura a un estado determinado. Por lo general, se utiliza una interfaz de línea de comandos (CLI) junto con un script de bash. Por ejemplo, en este caso, podríamos hacer algo como «CLI crear Kubernetes» y luego definir algunos comandos adicionales para personalizar esa implementación de Kubernetes. Haríamos lo mismo para la máquina virtual (VM) y la VPC. Un enfoque imperativo tiene una ventaja, te permite definir paso a paso cómo se provisiona tu infraestructura, y generalmente viene con más potencia porque estás utilizando herramientas en la nube y lo haces en un proceso paso a paso. Sin embargo, esto puede ser complejo, por ejemplo, si quieres eliminar tus VM o tus entornos, o si quieres escalarlos, tendrías que escribir scripts personalizados para manejarlo, y esto generalmente no se escala bien.

Otro enfoque para la automatización de infraestructura es el enfoque declarativo, y este es mi enfoque favorito. Un enfoque declarativo sería algo como Terraform, lo que básicamente te permite definir el estado final de tu infraestructura y dejar que el proveedor se encargue del resto. En lugar de definir cada paso, solo defines el estado final. En este ejemplo, tal vez definirías un recurso Kubernetes, un recurso VM y un recurso VPC, y otra gran ventaja es que generalmente se gestiona a través de sencillos mapas de configuración (config maps). Por ejemplo, si quisieras definir un host, podrías hacerlo, o un dominio, o incluso las subredes. En general, un enfoque declarativo te permite administrar la configuración de manera más fácil y es mi enfoque preferido para automatizar la infraestructura.

Tomemos este ejemplo simple. Si ejecutaras el script imperativo varias veces, terminarías con varios entornos y, además, supongamos que uno de los pasos falla a la mitad, tendrías que agregar manejo de errores para deshacer los pasos que sí se completaron. En cambio, con el enfoque declarativo, sin importar cuántas veces ejecutes este script, terminarás con la misma infraestructura. Podrías hacerlo la primera vez para aprovisionar tu entorno y luego ejecutarlo nuevamente más tarde para asegurarte de que tu entorno no haya cambiado. Así que diría que es muy importante comprender los diferentes enfoques para la infraestructura como código, pero en general, prefiero un buen enfoque declarativo.

DevOps e infraestructura como código

Ahora hablemos de DevOps. Todos entendemos lo importante que es DevOps al desarrollar una aplicación. Primero programas algo de código, quieres probar que realmente funciona, y luego quieres implementarlo en producción y asegurarte de que todo eso siempre esté funcionando y puedas repetir esos procesos. Sé que hay equipos que tienen un flujo de trabajo ágil y de DevOps perfecto, pero debido a que están trabajando con una infraestructura heredada, tienen que abrir un ticket cada vez que quieren obtener una nueva VM, y eso es simplemente debido a la infraestructura en la que están trabajando. Eso realmente les frena.

Con la infraestructura como código, cuando se admite, te permite tratar tu infraestructura con el mismo nivel de calidad con el que tratas tu código. Esto incluye cosas como versionado, así que esencialmente quieres asegurarte de que cada vez que tu infraestructura cambie, lo estás rastreando, y generalmente es un enfoque más automatizado.

Infraestructura inmutable y mutable

Por último, hablemos de la infraestructura inmutable versus mutable. Básicamente, una infraestructura inmutable es aquella que no se puede cambiar, no se puede mutar. A primera vista, puede parecer algo malo, pero analicemos esto con un ejemplo utilizando un enfoque mutable para la arquitectura de infraestructura.

En este ejemplo, estamos construyendo una aplicación y decidimos que necesitamos una base de datos. Para hacerlo, ejecutamos un script en nuestro entorno de desarrollo y esto crea esa base de datos dentro de nuestra VPC. Todo esto funciona bien, así que decimos: «Hey, simplemente ejecutemos ese script en todos los entornos que tengamos». Pero supongamos que el 99% de las veces funciona bien, pero algunas veces falla y te encuentras en un estado extraño. En este ejemplo, estamos pasando de la versión uno a la versión dos. Tenemos código de infraestructura en su lugar para crear la versión uno, pero ahora ejecutamos este script personalizado para pasar de la versión uno a la versión dos. Lo que tenemos ahora es algo que se llama «drift» de configuración o «drift» de entorno. Nuestro entorno existente ya no coincide con lo que tenemos en nuestra automatización. El problema es que, para ayudar a solucionar estas situaciones problemáticas, tendrías que eliminar todo el entorno y luego volver a implementar la versión uno y ejecutar esos scripts. Puede parecer bien las primeras veces que lo hagas, pero cuando quieras escalar, se vuelve extremadamente difícil de mantener.

Con un enfoque inmutable de infraestructura y automatización de infraestructura, cada vez que quieras hacer un cambio en la infraestructura, creas un nuevo entorno junto con el anterior y, una vez que verificas que ambos funcionan, puedes cerrar la versión anterior. Puede ser un poco costoso, ya que debes imaginar que estás ejecutando ambos entornos al mismo tiempo, pero en general es la mejor práctica para asegurarte de que tu infraestructura pueda escalar.

Preguntas frecuentes

1. ¿Cuál es la diferencia entre enfoque imperativo y enfoque declarativo para la automatización de infraestructura?

El enfoque imperativo te permite definir paso a paso cómo se provisiona la infraestructura, mientras que el enfoque declarativo te permite definir el estado final de la infraestructura y dejar que el proveedor se encargue del resto.

2. ¿Por qué es importante la infraestructura como código?

La infraestructura como código te permite tratar tu infraestructura con la misma calidad que el código, lo que incluye el versionado y facilita la automatización del aprovisionamiento y la gestión de la infraestructura.

3. ¿Cuál es la diferencia entre infraestructura inmutable e infraestructura mutable?

La infraestructura inmutable es aquella que no se puede cambiar una vez creada, lo que evita problemas de deriva de la configuración. La infraestructura mutable permite cambios, pero puede generar problemas de coherencia a medida que se escalan los entornos.

Gracias por acompañarme en este breve resumen de la automatización de infraestructura con código. Si deseas obtener más información sobre este tema o DevOps, consulta el enlace a continuación. Recuerda que siempre puedes comenzar con una cuenta gratuita en IBM Cloud.

Hasta pronto y no olvides revisar nuestros artículos relacionados.

Mila y César

Hola, somos Mila Jiménez y César Sánchez. Dos apasionados de la ciberseguridad con muchos años de experiencia. Hemos trabajado en muchas empresas del mundo TI y ahora nos apetece compartir nuestro conocimiento con cualquiera que lo necesite.

¡Si te gusta nuestro contenido puedes invitarnos a un café AQUÍ!