De los hipervisores a Docker: ¿por qué surgió la necesidad de los contenedores?

El problema: eficiencia y portabilidad

Aunque la virtualización solucionó el problema de aprovechar hardware, introdujo nuevos retos:

• Consumo de recursos elevado: varias VMs significan varios sistemas operativos corriendo en paralelo.
  
• Lentitud en despliegues: iniciar una VM puede tardar mucho más que lo que el negocio demanda.
  
• Dificultad para mover aplicaciones: "funciona en esta VM, pero no en otra", porque dependencias y configuraciones variaban.
  

En un mundo donde las aplicaciones empezaban a migrar a la nube y los despliegues debían ser rápidos y reproducibles, las VMs comenzaron a quedarse cortas

El surgimiento de los contenedores

Aquí es donde aparece un cambio de paradigma: los contenedores.
En lugar de virtualizar un sistema operativo completo, los contenedores comparten el mismo kernel del host y solo incluyen lo necesario para correr la aplicación.

Esto trae beneficios inmediatos:

• Ligereza: imágenes mucho más pequeñas que una VM.
  
• Velocidad: arrancan en segundos.
  
• Portabilidad: "si funciona en un contenedor, funcionará en cualquier lugar".
  
• Escalabilidad: puedes correr decenas de contenedores donde antes cabían apenas unas VMs.

Y entonces llega Docker

Aunque los contenedores ya existían en Linux desde hace años (con tecnologías como LXC), Docker (2013) los popularizó al simplificar su uso.
Lo que antes requería configuraciones manuales, ahora se resolvía con un simple docker run.

Docker trajo consigo:

• Un estándar para construir imágenes.
  
• Un ecosistema con Docker Hub (repositorio de imágenes).
  
• Herramientas para redes, volúmenes y despliegues.
  

En otras palabras, Docker democratizó el acceso a los contenedores, convirtiéndolos en la base del desarrollo moderno, especialmente en la nube.

Y dentro de un contenedor… nace synteck.org

Aquí es donde entra en juego synteck.org: un proyecto que surge con la filosofía de los contenedores.
La idea es clara: si una aplicación puede vivir dentro de un contenedor, entonces puede:

• Ser portátil entre distintos servidores o nubes.
  
• Escalar de forma modular sin depender de sistemas pesados.
  
• Mantener un entorno limpio y reproducible, sin la “contaminación” de configuraciones externas.
  

Pero synteck.org no solo se apoya en los contenedores: también contiene un pipeline de CI/CD (Integración Continua y Despliegue Continuo).

Esto significa que cada cambio en el código puede:

1. Construirse automáticamente dentro de un nuevo contenedor.
   
2. Probarse en un entorno controlado antes de pasar a producción.
   
3. Desplegarse de forma ágil y confiable, sin interrupciones y sin el clásico “funciona en mi máquina pero no en producción”.
   

El resultado es un flujo de trabajo mucho más eficiente, donde desarrollo y operaciones se integran de manera natural.

Así como los contenedores cambiaron la manera de pensar la infraestructura, synteck.org nació dentro de uno de ellos, acompañado de CI/CD, para asegurar que su crecimiento sea constante, ordenado y adaptable a cualquier nube.

Aclaremos algo. Para tu construir un contenedor vas a requerir:

1. Imagen(Esta imagen se construye a partir de un Dockerfile)
2. El hardware donde vas a virtualizar
3. Instalar Docker jajaja

Qué es un Dockerfile?

Un Dockerfile es un archivo de texto con instrucciones secuenciales que Docker interpreta para construir una imagen personalizada.
Piensa en él como una receta de cocina: cada instrucción agrega una capa a la imagen final.

Estructura básica de un Dockerfile

1. Imagen base (FROM)

Define de dónde partimos:

---

FROM python:3.10-slim

• Puede ser un sistema operativo (ubuntu, alpine) o un entorno ya preparado (node, python).
  
• Es la “base” sobre la que construiremos todo.
  

2.Metadatos opcionales (LABEL)

Sirven para documentar la imagen.

---

LABEL maintainer="admin@synteck.org"

LABEL version="1.0"

LABEL description="Imagen de ejemplo para synteck.org"

---

3. Directorio de trabajo (WORKDIR)

Indica en qué carpeta se ejecutarán los comandos dentro del contenedor.

---

WORKDIR /app

---

equivalente a hacer un cd en Linux.

4. Copiar archivos (COPY o ADD)

Permite meter archivos de tu máquina dentro de la imagen.

---

COPY requirements.txt .

COPY . .

---

• COPY es lo más usado.
  
• ADD también permite descargar URLs o descomprimir archivos.

5. Instalar dependencias (RUN)

---

RUN pip install -r requirements.txt

---

Cada RUN crea una capa nueva en la imagen.

6. Variables de entorno (ENV)

Definen configuraciones dentro del contenedor.

---

ENV APP_ENV=production

ENV PORT=8000

---

7. Puertos expuestos (EXPOSE)

---

EXPOSE 8000

---

8. Comando de inicio (CMD o ENTRYPOINT)

---

CMD ["python", "main.py"]

---

# 1. Imagen base

FROM python:3.10-slim

# 2. Metadatos

LABEL maintainer="admin@synteck.org"

LABEL version="1.0"

# 3. Directorio de trabajo

WORKDIR /app

# 4. Copiar archivos

COPY requirements.txt .

RUN pip install -r requirements.txt

COPY . .

# 5. Variables de entorno

ENV APP_ENV=production

ENV PORT=8000

# 6. Exponer puerto

EXPOSE 8000

# 7. Comando de inicio

CMD ["python", "main.py"]

Conclusión

La historia de Docker es la evolución natural de la infraestructura:

• Hipervisores solucionaron el problema del desperdicio de hardware.
  
• Contenedores solucionaron el problema de la portabilidad y la eficiencia.
  
• Docker hizo que los contenedores fueran accesibles para todos.
  

Hoy, cuando hablamos de despliegues rápidos, microservicios y aplicaciones en la nube, Docker se ha convertido en un pilar fundamental de la ingeniería de software moderna.

En las siguientes entradas de blog hablaremos sobre los temas inconclusos que dejamos

1. CI/CD
2. Orquestacion de contenedores