Contenedores Linux: qué son, cómo funcionan y para qué sirven

Cuando visitamos una página web, usamos un sistema empresarial o abrimos una aplicación, rara vez pensamos en todo lo que ocurre detrás. Para nosotros simplemente funciona. Pero detrás de esa aplicación puede haber un servidor, una base de datos, varias librerías, una determinada versión de PHP, Java o Node.js, configuraciones de red, certificados, almacenamiento y muchos otros componentes que deben trabajar juntos.

Y ahí aparece uno de los problemas clásicos de la informática: ¿cómo logramos que una aplicación funcione igual aunque cambiemos de servidor?

Una de las respuestas más utilizadas actualmente son los contenedores Linux. Aunque el nombre puede sonar bastante técnico, la idea que hay detrás es mucho más sencilla de lo que parece.

Pensemos primero en una aplicación

Imaginemos que una empresa desarrolla un sistema para gestionar pedidos. Ese sistema no funciona por sí solo. Puede necesitar:

• una determinada versión de PHP;
• algunas librerías;
• una base de datos;
• configuraciones específicas;
• archivos adicionales;
• determinadas variables del sistema.

Ahora imaginemos que el desarrollador termina el proyecto y lo entrega al área de infraestructura. Allí aparece una frase bastante conocida en tecnología:

“En mi computadora funciona.”

El problema es que la computadora del desarrollador y el servidor de producción pueden ser muy diferentes. Quizás utilizan versiones distintas del software. Quizás falta una librería. Quizás existe una configuración diferente. Y una pequeña diferencia puede ser suficiente para que una aplicación deje de funcionar correctamente.

Los contenedores nacieron, entre otras cosas, para reducir este tipo de problemas.

Entonces, ¿qué es un contenedor?

Podemos imaginar un contenedor como una especie de caja preparada específicamente para ejecutar una aplicación. Dentro de esa caja se encuentran la aplicación y buena parte de los componentes que necesita para funcionar. De esta manera, en lugar de instalar y configurar manualmente todo cada vez que queremos desplegar la aplicación en un nuevo servidor, podemos llevarnos la caja completa. La aplicación llega acompañada de su entorno.

No importa tanto si el servidor anterior era uno y el nuevo es otro: mientras la infraestructura sea compatible con esa tecnología de contenedores, el comportamiento será mucho más predecible. Ese es uno de los grandes atractivos de los contenedores.

Una comparación sencilla: mudarse de casa

Podemos imaginar una aplicación tradicional como una persona que se muda de casa llevando sus pertenencias por separado. Primero lleva los muebles. Después la ropa. Después los electrodomésticos. Luego descubre que en la nueva casa los enchufes son diferentes. O que falta una conexión. O que determinado mueble ya no entra.

Con los contenedores, la idea se parece más a transportar una unidad previamente preparada, donde gran parte de lo necesario ya está organizado. Al llegar al nuevo lugar hay menos cosas que reconstruir.

En informática esto puede significar menos diferencias entre el ambiente donde se desarrolla una aplicación y el servidor donde finalmente se ejecuta.

¿Un contenedor es una máquina virtual?

No exactamente. Esta es probablemente una de las confusiones más frecuentes. Tanto una máquina virtual como un contenedor permiten separar aplicaciones, pero lo hacen de maneras diferentes.

Una máquina virtual intenta comportarse como una computadora completa dentro de otra computadora. Tiene su propio sistema operativo, memoria asignada, almacenamiento y otros recursos. Por ejemplo, dentro de un servidor físico podríamos crear:

• una máquina virtual con Linux;
• otra con Windows;
• otra con otro Linux diferente.

Cada una funciona casi como una computadora independiente. Un contenedor es más ligero. En lugar de crear una computadora completa para cada aplicación, varios contenedores pueden compartir partes importantes del sistema operativo que existe debajo. Podríamos imaginarlo así:

• Máquina virtual: una casa completa.
• Contenedor: un departamento dentro de un edificio.

Cada departamento está separado y tiene su propio espacio, pero todos utilizan la misma estructura principal del edificio. No es una comparación técnicamente perfecta, pero ayuda bastante a entender la diferencia.

¿Por qué los contenedores consumen menos recursos?

Porque no necesitan crear un sistema operativo completo para cada aplicación. Imaginemos que queremos ejecutar diez aplicaciones diferentes.

Con máquinas virtuales podríamos terminar teniendo diez sistemas operativos independientes funcionando al mismo tiempo. Cada uno consume memoria, espacio en disco y capacidad de procesamiento.

Con contenedores, muchas de esas aplicaciones pueden compartir la misma base del sistema operativo. Eso permite aprovechar mejor un servidor.

Por esta razón, en determinadas circunstancias, una misma infraestructura puede ejecutar una mayor cantidad de aplicaciones utilizando contenedores.

Pero ¿cómo evita un contenedor que una aplicación interfiera con otra?

Aquí aparece la parte un poco más técnica, aunque el concepto sigue siendo bastante sencillo. Linux posee mecanismos que permiten separar procesos y controlar cuánto puede utilizar cada uno. Dos de los más importantes se llaman:

• namespaces;
• cgroups.

No es necesario memorizar estos nombres para entender los contenedores. Lo importante es entender qué hacen. Los namespaces ayudan a que cada contenedor vea su propio entorno. Los cgroups permiten controlar cuánta memoria, procesamiento y otros recursos puede consumir. En otras palabras, Linux crea una especie de frontera alrededor de cada aplicación. Esto permite que varias aplicaciones compartan un servidor sin mezclarse completamente entre ellas.

¿Dónde entra Docker en todo esto?

Docker hizo populares los contenedores porque simplificó muchísimo su creación y utilización. Por eso muchas personas utilizan las palabras Docker y contenedor como si significaran exactamente lo mismo. Pero no es así. Un contenedor es la tecnología o el concepto. Docker es una de las herramientas que permite trabajar con ellos. Existen otras alternativas como Podman, LXC o containerd. Una comparación podría ser:

• Contenedor es el concepto de automóvil.
• Docker sería una marca o una plataforma que facilita utilizar ese automóvil.

Docker tuvo un papel enorme en popularizar esta forma de desplegar aplicaciones.

¿Y qué es una imagen de Docker?

Aquí aparece otro concepto frecuente. Antes de ejecutar un contenedor normalmente existe una imagen. Podemos imaginar la imagen como una plantilla. Dentro de ella se define qué necesita la aplicación para funcionar. Por ejemplo:

• determinada versión de PHP;
• determinadas librerías;
• determinados archivos;
• una configuración inicial.

A partir de esa imagen podemos crear uno o muchos contenedores. La imagen sería el molde. El contenedor sería la instancia funcionando.

Un ejemplo bastante cotidiano

Supongamos que una empresa tiene una aplicación desarrollada en Laravel. La aplicación necesita PHP 8.3. El servidor actual utiliza PHP 8.3 y funciona perfectamente. Pero unos meses después otra aplicación instalada en ese mismo servidor necesita PHP 8.5. Comienzan entonces los posibles conflictos.

• ¿Actualizamos PHP?
• ¿Podría dejar de funcionar la primera aplicación?
• ¿Instalamos dos versiones?
• ¿Creamos otro servidor?

Con contenedores podríamos tener algo parecido a esto:

Ambas pueden vivir en el mismo servidor manteniendo separados sus entornos. Para las empresas que administran muchas aplicaciones, esta característica puede simplificar muchísimo las cosas.

¿Para qué se utilizan los contenedores?

Actualmente pueden utilizarse prácticamente en cualquier tipo de aplicación. Pero existen algunos escenarios donde resultan especialmente útiles.

¿Los contenedores sirven únicamente para grandes empresas?

No. Esa es otra percepción bastante común. Muchas veces escuchamos hablar de Docker, Kubernetes y microservicios en proyectos enormes como Netflix, Google o grandes plataformas tecnológicas. Pero los contenedores también pueden resultar útiles en proyectos bastante pequeños. Por ejemplo:

• una empresa podría tener un WordPress;
• un sistema desarrollado en Laravel;
• un pequeño ERP;
• una API;
• y una aplicación Node.js.

Cada una podría ejecutarse dentro de su propio entorno sin necesidad de instalar todos los componentes directamente sobre el mismo sistema operativo. Esto facilita mantener separados los proyectos.

¿Y Kubernetes?

Cuando se habla de contenedores, tarde o temprano aparece Kubernetes. El problema es que muchas veces se presentan ambos conceptos juntos y parece que fueran inseparables. No lo son, de hecho, podemos utilizar contenedores perfectamente sin Kubernetes. Kubernetes empieza a tener más sentido cuando tenemos una infraestructura mucho más grande. Imaginemos cientos de contenedores distribuidos entre distintos servidores. Entonces aparecen preguntas como:

• ¿Dónde debería ejecutarse cada contenedor?
• ¿Qué sucede si un servidor falla?
• ¿Cómo levantamos automáticamente otra copia?
• ¿Cómo distribuimos el tráfico?
• ¿Cómo actualizamos cientos de aplicaciones?

Kubernetes ayuda a automatizar este tipo de operaciones.

Pero utilizar Kubernetes para una aplicación pequeña puede ser como utilizar un centro logístico de aeropuerto para organizar tres maletas. La herramienta es muy poderosa, pero también introduce complejidad.

¿Los contenedores reemplazan a las máquinas virtuales?

No. En realidad, ambas tecnologías suelen trabajar juntas. Por ejemplo, una infraestructura podría ser:

Servidor físico

↓

Máquinas virtuales

↓

Linux

↓

Contenedores

↓

Aplicaciones

La máquina virtual proporciona un entorno aislado. Dentro de ella los contenedores permiten organizar las aplicaciones. Esta combinación es extremadamente común. Por eso la conversación no debería ser necesariamente: “¿Contenedores o máquinas virtuales?” Muchas veces la respuesta correcta es: “Los dos.”

¿Cuándo sigue teniendo sentido una máquina virtual?

Las máquinas virtuales siguen siendo muy útiles. Por ejemplo, cuando necesitamos ejecutar diferentes sistemas operativos. Podríamos tener:

• Windows Server;
• Ubuntu;
• Debian;
• FreeBSD.

También pueden resultar más adecuadas para aplicaciones antiguas que esperan funcionar dentro de una máquina completa. O cuando necesitamos entregar al cliente control total sobre un sistema operativo. Los contenedores no eliminan estas necesidades. Simplemente resuelven otro tipo de problema.

¿Qué ventajas tienen entonces los contenedores?

Para una empresa, probablemente las ventajas más fáciles de entender sean estas.

Pero los contenedores tampoco son magia

Existe una tendencia en tecnología a presentar algunas herramientas como soluciones universales. Los contenedores no lo son. Utilizarlos correctamente requiere pensar en otras partes de la infraestructura. Por ejemplo:

Especialmente importante es el almacenamiento. Un contenedor debería poder desaparecer y ser reemplazado. Por eso la información importante no debería depender exclusivamente del interior del contenedor. Los datos deben almacenarse en sistemas persistentes y contar con copias de seguridad.

El problema no suele ser crear el contenedor

Crear un contenedor puede ser relativamente sencillo. El verdadero trabajo aparece después.

• ¿Quién actualiza el servidor?
• ¿Quién monitorea la aplicación?
• ¿Quién revisa el consumo de memoria?
• ¿Quién configura los backups?
• ¿Quién administra los certificados SSL?
• ¿Quién detecta que un servicio dejó de funcionar?
• ¿Quién revisa la seguridad?

Aquí encontramos una diferencia importante entre tener tecnología y tener infraestructura administrada. Una empresa puede instalar Docker en un VPS en pocos minutos. Eso no significa que automáticamente tenga una plataforma confiable para alojar aplicaciones.

Entonces, ¿necesito un VPS o un contenedor?

En realidad, esa pregunta puede estar planteada de manera incorrecta. Un VPS es infraestructura. Un contenedor es una forma de ejecutar una aplicación. Podemos perfectamente ejecutar contenedores dentro de un VPS. La verdadera pregunta sería:

¿Quiero administrar yo mismo toda la infraestructura o simplemente quiero que mi aplicación funcione?

Son dos necesidades diferentes. Un desarrollador puede querer acceso completo al servidor. Otra empresa puede preferir simplemente entregar su aplicación y dejar que otra persona se encargue de mantener la infraestructura.

El hosting está cambiando

Durante muchos años el hosting funcionaba de una manera bastante sencilla. Una empresa contrataba espacio en un servidor y colocaba allí su página web. Pero las aplicaciones actuales son mucho más variadas. Hoy podemos tener:

Cada aplicación puede tener requisitos completamente diferentes. Por eso el concepto de hosting también está evolucionando. Ya no se trata únicamente de almacenar páginas web. Cada vez se trata más de proporcionar entornos preparados para ejecutar aplicaciones. Y los contenedores tienen un papel importante en esa evolución.

Un ejemplo práctico

Imaginemos una empresa que desarrolla un ERP en Laravel. Podría contratar un VPS. Después alguien tendría que:

Otra alternativa sería separar las responsabilidades. El desarrollador mantiene la aplicación. La infraestructura mantiene el entorno donde esa aplicación funciona. Podríamos tener:

Internet

↓

Proxy reverso

↓

Aplicación dentro de un contenedor

↓

Base de datos

↓

Almacenamiento

↓

Backups

El desarrollador puede concentrarse en su software. El proveedor de infraestructura puede concentrarse en servidores, redes, seguridad y disponibilidad.

Entonces, ¿qué son realmente los contenedores?

Quitando todos los términos técnicos, podemos resumirlos de una manera bastante sencilla. Los contenedores son una forma de empaquetar y ejecutar aplicaciones dentro de entornos aislados y reproducibles. Permiten separar aplicaciones entre sí. Permiten utilizar mejor los recursos de un servidor. Facilitan mover aplicaciones. Y ayudan a reducir las diferencias entre un ambiente de desarrollo y uno de producción. No reemplazan completamente a las máquinas virtuales. Tampoco hacen innecesaria la administración de servidores. Pero se han convertido en una de las piezas fundamentales de la infraestructura moderna. Y posiblemente esa sea la mejor forma de entenderlos:

una máquina virtual organiza servidores; un contenedor ayuda a organizar aplicaciones.

En SCIWebHosting seguiremos explorando estas tecnologías desde una perspectiva práctica: qué problema resuelven, cuándo tiene sentido utilizarlas y cuándo una solución más sencilla puede ser mejor.