Modulo 01. Introduccion a contenedores y Docker

Objetivo del modulo

Comprender que resuelve la contenedorizacion y como Docker separa imagen, contenedor y runtime para ofrecer portabilidad, reproducibilidad y aislamiento.

Resultados esperados

• Distinguir imagen de contenedor.
• Explicar por que un contenedor no es una maquina virtual pequena.
• Entender el ciclo basico de build, pull, run y stop.
• Ejecutar un contenedor basico desde linea de comandos.

Desarrollo teorico

Los contenedores encapsulan aplicacion y dependencias en una unidad portable y repetible. A diferencia de una VM, no replican un sistema operativo completo sino que comparten kernel del host y aislan procesos, red y sistema de archivos mediante mecanismos del sistema operativo (namespaces y cgroups en Linux). Docker popularizo este modelo simplificando build, distribucion y ejecucion de contenedores hasta hacerlos accesibles a cualquier equipo de desarrollo u operaciones.

Contenedor vs. VM. Una maquina virtual incluye un sistema operativo completo sobre un hypervisor. Un contenedor comparte el kernel del host y solo contiene la aplicacion y sus dependencias. Esto tiene consecuencias practicas directas:

Esto no significa que los contenedores sean "mejores" que las VMs. Son herramientas diferentes. Las VMs ofrecen aislamiento mas fuerte (kernel propio) y son adecuadas cuando se necesitan sistemas operativos distintos o aislamiento estricto. Los contenedores son ideales para aplicaciones microservicio, pipelines de CI/CD y despliegues rapidos con alta densidad.

Imagen, contenedor y runtime. Estos tres conceptos son la base de Docker y fuente de confusion frecuente:

• Imagen: Plantilla inmutable compuesta por capas. Contiene SO base, dependencias, codigo de la aplicacion y configuracion. Se construye con un Dockerfile y se almacena en un registro.
• Contenedor: Instancia en ejecucion de una imagen. Tiene estado de proceso, red asignada y sistema de archivos efimero. Si se elimina el contenedor, los datos no persistidos se pierden.
• Runtime: Capa que crea y gestiona contenedores. Docker Engine es el runtime mas conocido, pero existen otros como containerd, CRI-O o Podman.

Si confundes imagen y contenedor, aparecen errores frecuentes: creer que modificar un contenedor cambia automaticamente la imagen, asumir que el estado vive dentro del contenedor para siempre o pensar que reiniciar un contenedor equivale a "reiniciar un servidor". El proceso principal del contenedor (PID 1) define su vida: si termina, el contenedor termina.

El ciclo basico de Docker. Los comandos fundamentales son:

# Descargar una imagen desde un registro
docker pull nginx:1.25-alpine

# Ejecutar un contenedor desde la imagen
docker run -d --name web -p 8080:80 nginx:1.25-alpine

# Verificar contenedores en ejecucion
docker ps

# Ver logs del contenedor
docker logs web

# Detener el contenedor
docker stop web

# Eliminar el contenedor
docker rm web

# Listar imagenes locales
docker images

Desglose de docker run -d --name web -p 8080:80 nginx:1.25-alpine:

• -d: Ejecutar en segundo plano (detached).
• --name web: Asignar nombre al contenedor.
• -p 8080:80: Mapear puerto 8080 del host al puerto 80 del contenedor.
• nginx:1.25-alpine: Imagen y tag a usar.

Persistencia y volumenes. Por defecto, los datos dentro de un contenedor son efimeros. Si el contenedor se elimina, los datos desaparecen. Para datos que deben persistir (bases de datos, uploads, configuraciones), Docker ofrece volumenes:

# Crear un volumen
docker volume create datos-app

# Ejecutar contenedor con volumen montado
docker run -d --name db -v datos-app:/var/lib/postgresql/data postgres:16-alpine

El volumen datos-app sobrevive al contenedor: si eliminas y recreas db, los datos siguen ahi.

Redes. Docker crea redes virtuales para conectar contenedores. Por defecto existe la red bridge. Para que dos contenedores se comuniquen por nombre, se crea una red personalizada:

docker network create mi-red
docker run -d --name api --network mi-red node-api:1.0
docker run -d --name db --network mi-red postgres:16-alpine
# Desde el contenedor 'api', se puede resolver 'db' como hostname

Registros. Las imagenes se almacenan en registros: Docker Hub (publico por defecto), GitHub Container Registry (ghcr.io), Amazon ECR, Azure ACR, Google Artifact Registry. En entornos corporativos se usan registros privados para controlar que imagenes se despliegan.

Por que Docker importa para operaciones y plataforma. Docker resuelve el clasico problema de "en mi maquina funciona". Al encapsular aplicacion y dependencias en una imagen, el entorno de ejecucion es identico en desarrollo, CI, staging y produccion. Esto reduce drasticamente los bugs de entorno y simplifica el despliegue. Ademas, las imagenes son la base de Kubernetes, que orquesta contenedores a escala.

Contenido ampliado

Puntos clave

• Contenedor no es sinonimo de VM; comparten kernel y aislan por namespaces.
• La imagen se construye (build); el contenedor se ejecuta (run).
• El proceso principal (PID 1) gobierna el ciclo de vida del contenedor.
• Los datos efimeros desaparecen al eliminar el contenedor; los volumenes persisten.
• Las imagenes son la base de Docker, Kubernetes y los pipelines de CI/CD modernos.
• Docker resuelve problemas de paridad de entorno entre desarrollo y produccion.

Checklist operativa

• Identificar que parte es build (imagen) y cual es runtime (contenedor).
• Confirmar que datos deben persistir fuera del contenedor mediante volumenes.
• Entender como se distribuye la imagen entre entornos via registros.
• Verificar que el proceso principal es el adecuado para el servicio.
• Usar tags especificos, no latest, para reproducibilidad.
• Configurar redes para comunicacion entre contenedores.

Errores frecuentes

• Guardar estado importante dentro del contenedor sin volumen.
• Depender de cambios manuales sobre contenedores corriendo en vez de reconstruir la imagen.
• No entender que proceso mantiene vivo el contenedor.
• Confundir contenedor con VM y esperar comportamiento identico.
• Usar latest como tag y perder reproducibilidad.
• No limpiar imagenes y contenedores antiguos y llenar el disco.

Practica sugerida

Ejecuta los siguientes pasos en tu entorno: (1) descarga la imagen nginx:1.25-alpine, (2) lanza un contenedor mapeando el puerto 8080, (3) accede desde el navegador, (4) inspecciona los logs, (5) detente y elimina el contenedor, (6) verifica que la imagen sigue disponible localmente. Bonus: lanza un segundo contenedor con un volumen montado y verifica que los datos persisten tras eliminar y recrear el contenedor.

Preguntas de autoevaluacion

• Que diferencia fundamental hay entre imagen y contenedor.
• Por que un contenedor no se comporta igual que una VM y que implicaciones tiene.
• Que ocurre si el proceso principal (PID 1) del contenedor termina.
• Cuando necesitas un volumen y que pasa si no lo usas.
• Por que Docker facilita la paridad entre desarrollo y produccion.

Cierre

Entender bien imagen, contenedor y runtime es el fundamento sobre el que se construye todo lo demas: Dockerfiles, Docker Compose, Kubernetes y los pipelines modernos de entrega de software.

Modulo 02. Imagenes, Dockerfiles y registro

Objetivo del modulo

Aprender a construir imagenes reproducibles, pequenas y trazables mediante Dockerfiles bien disenados y a gestionarlas en registros de contenedores.

Resultados esperados

• Redactar un Dockerfile basico con buen orden de capas.
• Entender cache de build y multi-stage builds.
• Versionar y publicar imagenes en un registro.
• Aplicar buenas practicas de seguridad y tamano en la construccion de imagenes.

Desarrollo teorico

El Dockerfile es el plano de construccion de una imagen Docker. Cada instruccion genera una capa que se apila sobre la anterior. Entender este modelo de capas es fundamental porque afecta a tres dimensiones operativas: tamano de la imagen final, velocidad de build (gracias a la cache) y seguridad (por la superficie de ataque incluida en cada capa).

Anatomia de un Dockerfile. Las instrucciones basicas son FROM (imagen base), RUN (ejecutar comandos), COPY y ADD (copiar ficheros al contexto), WORKDIR (directorio de trabajo), ENV (variables de entorno), EXPOSE (puertos documentados), CMD y ENTRYPOINT (comando de arranque). Un Dockerfile minimo para una aplicacion Node.js se veria asi:

FROM node:20-alpine
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

El orden importa. Primero se copian los ficheros de dependencias (package.json) y se instalan. Solo despues se copia el codigo fuente. Esto aprovecha la cache de Docker: si las dependencias no cambian, esa capa se reutiliza y el build es mucho mas rapido. Si copiaras todo el codigo primero, cualquier cambio en un archivo fuente invalidaria la cache de instalacion de dependencias.

Cache de build. Docker cachea cada capa. Si una instruccion y los ficheros que referencia no han cambiado, Docker reutiliza la capa cacheada. La invalidacion es secuencial: si la capa 3 cambia, las capas 4, 5 y siguientes se reconstruyen. Por eso la regla practica es: instrucciones que cambian poco arriba, instrucciones que cambian mucho abajo.

Multi-stage builds. En aplicaciones compiladas (Go, Java, TypeScript que transpila), el entorno de compilacion incluye herramientas que no hacen falta en runtime. Un multi-stage build usa varias instrucciones FROM para separar etapas:

# Etapa de build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

# Etapa de runtime
FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
EXPOSE 3000
CMD ["node", "dist/server.js"]

La imagen final solo contiene el artefacto compilado y las dependencias de runtime. El resultado es una imagen mas pequena, con menos paquetes instalados y menor superficie de ataque. En imagenes de Go es incluso mas dramatico: se puede compilar en una etapa con el SDK completo y copiar el binario a una imagen scratch o distroless de pocos megabytes.

El fichero .dockerignore. Funciona como .gitignore pero para el contexto de build. Todo lo que no necesite estar dentro de la imagen debe excluirse: .git, node_modules locales, ficheros de test, documentacion, .env con secretos. Olvidar el .dockerignore es una de las causas mas frecuentes de imagenes innecesariamente grandes y de filtracion accidental de secretos.

# .dockerignore
.git
node_modules
*.md
.env
tests/
coverage/

Versionado y tags. Cada imagen debe etiquetarse con una version explicita. Depender de latest es peligroso en produccion porque no garantiza reproducibilidad: hoy latest puede ser la version 2.3.1 y manana la 2.4.0 con cambios incompatibles. Una politica sana usa tags semanticos (v1.2.3), el SHA del commit o una combinacion de ambos. Los digests (sha256:...) proporcionan la maxima trazabilidad y son inmutables.

Registros de contenedores. Las imagenes se publican en registros: Docker Hub, GitHub Container Registry (ghcr.io), Amazon ECR, Azure Container Registry, Google Artifact Registry o registros privados como Harbor. El registro es parte de la cadena de suministro del software. Una imagen descargada de un registro no confiable o sin verificacion de firma puede introducir vulnerabilidades o codigo malicioso. En entornos corporativos se recomienda usar registros privados con escaneo de vulnerabilidades integrado.

Buenas practicas de seguridad. No ejecutar como root dentro del contenedor (usar USER para cambiar a un usuario no privilegiado), no incluir secretos en capas de imagen, usar imagenes base minimas (alpine, distroless), escanear vulnerabilidades con herramientas como Trivy o Snyk y firmar imagenes cuando la cadena de suministro lo requiera.

Contenido ampliado

Puntos clave

• Un Dockerfile mal disenado penaliza build, seguridad y operacion.
• El orden de instrucciones determina la eficiencia de la cache.
• Multi-stage builds separan herramientas de compilacion del runtime final.
• latest es comodo pero peligroso para reproducibilidad en produccion.
• El registro forma parte de la cadena de suministro y debe ser confiable.
• Los secretos nunca deben incluirse en capas de imagen.

Checklist operativa

• Revisar imagen base y tamano final de la imagen construida.
• Verificar que existe .dockerignore y que excluye secretos y ficheros innecesarios.
• Confirmar que las instrucciones estan ordenadas de menos a mas cambiante.
• Etiquetar la imagen con version explicita, no solo latest.
• Publicar en un registro autorizado con escaneo de vulnerabilidades.
• Verificar que el contenedor no ejecuta como root.

Errores frecuentes

• Imagenes enormes con toolchains, documentacion y tests innecesarios.
• Copiar secretos o .env al contexto de build.
• Reutilizar tags ambiguos sin politica de versionado clara.
• No usar multi-stage builds para aplicaciones compiladas.
• Invalidar la cache copiando todo el codigo antes de las dependencias.
• Ejecutar el proceso dentro del contenedor como root.

Practica sugerida

Escribe un Dockerfile multi-stage para una aplicacion web Node.js con TypeScript. La primera etapa debe instalar dependencias y transpilar. La segunda etapa debe contener solo el codigo compilado y las dependencias de produccion. Incluye .dockerignore, usuario no root y tag versionado. Justifica el orden de cada instruccion.

Preguntas de autoevaluacion

• Por que importa el orden de instrucciones en un Dockerfile y como afecta a la cache.
• Que problema resuelve multi-stage build y en que tipo de aplicaciones es mas relevante.
• Que riesgo tiene publicar siempre con latest en un entorno de produccion.
• Por que los secretos no deben incluirse en ninguna capa de imagen.
• Que diferencia hay entre CMD y ENTRYPOINT y cuando usar cada uno.

Cierre

Una buena imagen empieza en un buen Dockerfile. La calidad del build se refleja despues en seguridad, velocidad de despliegue y mantenibilidad a largo plazo.