Cómo mover aplicaciones de un entorno a otro sin problema: contenedores Microsoft Azure

Blog

Cómo mover aplicaciones de un entorno a otro sin problema: contenedores Microsoft Azure

Contenedores Microsoft Azure

De la misma manera que existen contenedores en logística para el transporte de las cargas mediante buques o trenes, las tecnologías responsables de desarrollo de software tienen contenedores. De ahí, el término “contenerización”.

Un contenedor o “paquete de software estándar” se encarga de agrupar el código de una aplicación con las bibliotecas y los archivos de configuración correspondientes. Es así cómo los contenedores con Microsoft Azure permiten abstraer las aplicaciones del entorno donde se ejecutan gracias al mecanismo de empaquetado con el que cuentan. En suma, las aplicaciones se desarrollan de manera sencilla y ordenada con independencia de si nos encontramos en una nube privada, pública o el portátil personal del desarrollador.

¿Por qué deberíamos confiar en los contenedores?

En los últimos 4-5 años, los contenedores se han hecho más presentes en nuestras vidas.

Todo surgió a partir de un problema: la mayoría de desarrolladores administraban máquinas virtuales y eran cosas desordenadas con todo tipo de componentes diferentes. Tenían servidores SSH, supervisión, tenían su propia aplicación. En suma, era difícil saber que estaba pasando y cuando lo gestionábamos lo tenían que hacer bajo un guion pre-establecido.

De las infraestructuras inmutables a las máquinas virtuales

En todo este contexto, hubo un movimiento conocido como “infraestructura inmutable”  que vino a decir que teníamos que capturar todo eso en una imagen de Máquina Virtual con objeto de hacerlo inmutable, implementándose de la misma manera.

Esto nos permitía saber lo que estaba pasando exactamente con independencia de los cambios ejecutados.

Aún así, todavía seguíamos teniendo problemas. El desarrollador se encontraba ante tareas muy arduas desde el punto de vista arquitectónico.

De máquina virtuales a contenedores

Fue así como surgió la idea de capturar esa imagen de Máquina Virtual en realidad para convertirla en un contenedor algo más ligero. De tener cientos de megabytes pasábamos a tener 20 megabytes.

Podíamos así separar el kernel (el núcleo del sistema operativo) y obtener distancia con respecto al contenedor teniendo 2 aspectos o tipos de preocupaciones: “Cuando me preocupo por la aplicación puedo pensar en la imagen de mi contenedor; Cuando me preocupo por el sistema operativo, puedo pensar en el kernel”.

En la separación se encontraba la solución para muchos desarrolladores que podían dedicarse a saber en qué pensar, construir e implementar para su aplicación.

Despliegue hacia la nube

Pero llegó el momento de pensar en el repositorio en la nube, momento que suministró Docker.

Podíamos responder al siguiente planteamiento: tengo una aplicación que he desarrollado en mi portátil. ¿Cómo consigo ahora un centro de datos conectado a la red? ¿Cómo la llevo a la nube y a todas las nubes de todo el mundo?

Servidor de Docker

La solución está en el depósito de los contenedores que proporcionan esa capacidad. Así nos encontramos con un repositorio como Azure Container Registry. De esta manera, el desarrollador sube la imagen de su contenedor y puede sacar una imagen donde sea necesario: en su centro de datos, en la nube, o incluso en todo el mundo.

Conseguimos una infraestructura inmutable que nos permite deshacernos de scripts y nos ofrece garantías de que la aplicación se implementará de manera correcta cada vez.

Finalmente, la propia imagen del contenedor también se convirtió en una forma de poner múltiples aplicaciones en la misma máquina. Si tenemos una máquina virtual o una máquina física, uno de los retos que corre mucha gente, es que solo utiliza un 10%. Eso, obviamente, significa que se está pagando mucho más de lo que se usa y es mejor recurrir a hacer aplicaciones.

Si empaquetamos la aplicación como un contenedor en realidad es relativamente sencillo poner la aplicación 1, la aplicación 2 y aplicación 3 en la misma máquina. Podemos impulsar esa utilización al 50% ó 60%  sin hacer ningún tipo de re-arquitectura en absoluto.

Ahora bien, es importante tener en cuenta que este límite está definido en el kernel. Esto nos guiará por el buen camino para aislar distintas cosas importantes como la memoria (en términos de CPU) pero debemos recordar que no se trata de un límite de seguridad y, por tanto, no estaremos protegidos ante códigos maliciosos.

Importante: si intentamos utilizar contenedores como limites de seguridad, tendremos que agregar otras muchas tecnologías, algo así como un hipervisor u otros tipos de tecnología de aislamiento.

Pero si lo que queremos es poder usarlo para un montón de aplicaciones, el contenedor puede convertirse en un gran artefacto. En este momento entra el juego el orquestador de contenedores de Kubernetes. De esta forma tenemos un sinfín de máquinas y podemos usar la API de Kubernetes para distribuir la imagen  del contenedor o muchas imágenes de contenedores en todas las máquinas.

Los contenedores son los gran aliados para los desarrolladores y profesionales de TI ya que pueden implementar aplicaciones en entornos sin necesidad de ejecutar cambios o con el menor número de cambios.