¿Por qué una Infraestructura Inmutable garantiza un cambio constante?

Infraestructura inmutable

Sin duda, para dedicarse a la programación se necesita de conocimientos y dedicación especiales. Ser un buen programador, además requiere de unas aptitudes valiosas; todo esto hace sólida la base y es el punto de partida para los grandes programas y, ¿quién sabe?, ¡hasta podremos producir una aplicación asesina!

Pero con el ensayo y error a lo largo de décadas de uso con ordenadores, se han ido refinando los conceptos y paradigmas a la hora de escribir nuestros algoritmos. Mientras algunos optan por la Arquitectura DevOps u otros por el puro desarrollo en cascada, entre otros esquemas e incluso combinaciones de ellos, hemos visto que la Integración Continua de Software, su Distribución Continua e Implementación Continua ha tomado fuerza en estos últimos años. No tratamos de indicar qué está bien, qué está regular o qué está mal. Tratamos de indicar que tenemos libertad de elegir nuestro modelo de desarrollo.

En Pandora FMS hemos apostado, desde la versión 7.0, al “rolling release” o Desarrollo Continuo de Software, que abarca todo lo anteriormente expuesto… excepto un componente que faltaba por analizar: la Infraestructura Inmutable.

Infraestructura Inmutable como componente

Esta entrada será corta pero densa; vamos de teoría.

Sí, la teoría siempre la tenemos que tener en cuenta. No somos físicos cuánticos que nos pasamos el tiempo ensimismados en matemáticas (tampoco tiene nada de malo dedicarse a ello toda la vida), pero en la dura realidad siempre deberemos tener algo de teoría. Una temeraria afirmación, muy personal, es que la vida es un 90% de práctica y un 10% de teoría.

Parte de esa dura realidad es que en el presente necesitamos disminuir el riesgo en cada versión en nuestro software, estar a la misma rapidez del mercado con una muy alta calidad y con bajos costos… todo eso para mantener felices a nuestros clientes:

• Debemos tener claro que una tarea finaliza cuando entra en funcionamiento pleno de producción (o sea, que llegue a los usuarios).
• Debemos tener, de manera expedita, una o varias formas de que cada una de las tareas llegue a los usuarios.
• Debemos estar prestos a realizar cambios retribuidos por los usuarios y/o por nuestros colegas.
• Los procesos deben ser automatizados.
• Cada tarea o cambio debe ser implementado y esa es la prioridad principal.

Construyendo los binarios una sola vez

Cada tarea (mejora y/o parcheado) es un cambio y un cambio significa una nueva compilación del código fuente. A eso ahora le llaman “fichero binario” o simplemente “binario”, tal vez para que sea menos doloroso -y hasta aséptico- el trabajo de recalentar los procesadores y dispositivos de almacenamiento. Esa compilación contendrá el mismo ejecutable anterior y única y exclusivamente el cambio -tarea- que nos ocupa en ese momento. No debe haber nada más, pero, ¿y si el entorno de destino cambia?

Planteada esta duda ya tendremos no un solo cambio, sino dos o más cambios, y esto aumenta la posibilidad de alguna falla imprevista. Recordemos: “rápido, bueno y barato”, como denota el habla coloquial, y todo eso se viene abajo si arrastramos más tareas -cambios- de las que nos propusimos.

Entra en escena una Infraestructura Inmutable

Una Infraestructura Inmutable, ya sea en concepto o en la práctica, nos garantiza a nosotros los programadores que nuestro esfuerzo va destinado a un nicho que bien conocemos, pero no solo eso: es un ambiente que nosotros mismos diseñamos y que puede ser replicado tantas veces como necesitemos.

De esta manera, todas las máquinas o dispositivos con los que trabajemos estarán normalizados, no cambian, son siempre iguales, pero además de esta evidente ventaja también tendremos la capacidad de ampliar el número de dispositivos de nuestra plataforma de una manera automatizada. También podremos sustituir las máquinas que hayan fallado con nuevas máquinas (reales o virtuales).

Si lo pensamos -o más bien recordamos- las Infraestructuras Inmutables no son para nada novedosas: en los albores de la computación existían uno o dos modelos de ordenadores y no cambiaban durante años. ¿Queréis un ambiente más estable que eso? Lo que es obvio era la cantidad de dispositivos que se podía disponer, y eso lo solucionaron con la virtualización… ¡en 1967!

Características de una Infraestructura Inmutable

• Debe ser predecible: será fiel reflejo del ambiente donde programamos nuestra aplicación, sin ningún fallo.
• Debe ser ampliable: y si se puede ampliar de forma automatizada en cualquier momento, mucho mejor todavía.
• Debe ser resiliente: la recuperación automática asegurará que nuestro equipo pueda enfocarse en construir un mejor producto y dormir durante la noche en lugar de mantener la infraestructura constantemente.

Adaptación de una Infraestructura Inmutable

A pesar de la palabra que usamos, la infraestructura necesita ser cambiada por causas ajenas a nuestra voluntad. El descubrimiento de una vulnerabilidad en la seguridad de los procesadores centrales de los ordenadores nos obliga a actualizar nuestro(s) sistema(s) operativo(s): pues “parchearemos” y procederemos -si es posible todo esto de manera automatizada- a volver a compilar nuestro programa, y le aplicaremos las pruebas necesarias que garanticen su buen funcionamiento. Si todo va bien, procederemos a actualizar toda nuestra Infraestructura Inmutable (que ya vemos por qué no es estricto el término).

La más sencilla Infraestructura Inmutable

El mejor ejemplo de la construcción, uso y mantenimiento de una Infraestructura Inmutable es el de un ordenador virtual y el fichero de imagen que lo contiene. Nuestro hipervisor favorito es VirtualBox, que puede trabajar con ficheros en formato ISO, una norma muy popular hoy en día.

Así las cosas, haremos una máquina virtual con el sistema operativo deseado y todos y cada uno de sus componentes. Cada paso puede ser marcado con tomas instantáneas que permitirán retroceder en el tiempo e incluso bifurcar la imagen ISO deseada. Por ejemplo, si necesitamos una base de datos y un servidor web pero además necesitaramos otros servidores de base de datos para trabajar en racimo con el principal, bifurcaremos una vez hayamos instalado la base de datos necesaria: Percona, MySQL, PostgreSQL, etcétera. Luego, a una de las imágenes le instalaremos un servidor web como Apache, por ejemplo, y así tendremos dos imágenes exportadas en formato ISO.

Dicha(s) imágenes resultantes podremos publicarlas, dado el caso, para que nuestros clientes tengan un demostrativo rápido y funcional. Aquí, en Pandora FMS, ofrecemos descargas en múltiples formatos. Amablemente os invitamos a probarlas, visitad este enlace.

Herramientas para facilitar el trabajo

En la Grecia antigua el Ave Fénix era mítica y cada quinientos años moría abrasada por el fuego para renacer de sus cenizas. Nuestros servidores se calientan, pero no tanto. Lo que sí es igual es que deben “renacer de sus cenizas”: configuraciones celosamente guardadas y que incluso conllevan control de versiones.

Si bien en el punto anterior os ofrecimos un caso sencillo, en realidad para trabajar con grandes grupos de desarrollo necesitaremos de automatizar en todo lo posible todo lo relacionado con el ambiente, y otorgar a los miembros del equipo de desarrollo los derechos necesarios, así como un control sobre quién hizo qué y cuándo lo hizo.

Aunque todo esto sigue representando un fuerte trabajo para un buen administrador de sistemas, existen herramientas que hemos analizado a largo de todo nuestro blog, una suerte de dispensario del conocimiento, que nos ayudarán muchísimo (solo nombramos unas cuantas):

• Git: para llevar no solo un control de versiones del software, sino también de los ficheros de configuración que recrearán nuestra Infraestructura Inmutable.
• Ansible, Puppet, EngineCF, Chef, etc: permiten desde instalar un sistema operativo hasta instalar aplicaciones, preferencias de usuarios, instalar “parches” y mucho más. De las plantillas y guiones, ficheros al fin y al cabo, podremos llevar un control de versiones con Git.
• Jenkis: para hacer pruebas automatizadas de nuestro software.
• Heroku: un excelente caso que ilustra lo anterior; creamos una cuenta en Github, alojamos nuestro código, vamos a Heroku a crear una cuenta conectada a nuestra cuenta Github y se encargará de desplegar todo por nosotros.
• ¡Incluso hay herramientas para generar en gráficos animados la evolución de cualquier proyecto que haya llevado control de versiones!
• Por supuesto, y no menos importante, aunque una Infraestructura Inmutable podrá ser destruida, copiada o creada, necesitaremos una herramienta muy especializada para su monitorización, como Pandora FMS, y eso lo analizaremos en el siguiente punto.

El mercado de las herramientas de monitorización

En Pandora FMS siempre estamos muy atentos a la evolución de las tecnologías, y la Infraestructura Inmutable no es la excepción. Colocando los Agentes Software de Pandora FMS o por medio de monitorización remota podremos centralizar -previa bien estudiada nomenclatura de nombrado de máquinas virtuales y reales- y guardar para la posteridad toda la información relevante que hayamos decidido monitorizar. Recordad que las Infraestructuras Inmutables pueden ser destruidas en cualquier momento, pero debemos tener siempre presente qué ocurrió o salió mal en el ínterin. Para ello, Pandora FMS, sin lugar a dudas, es la solución.

¿Deseáis probar Pandora FMS? Contactadnos en este enlace y gustosamente os atenderemos.