MAISON CODE .
/ Tech · DevOps · Docker · Kubernetes · Containers

Docker y Kubernetes: contenedores de envío, no código

"Funciona en mi máquina" no es una excusa aceptable. Cómo la contenedorización garantiza la coherencia desde el desarrollo hasta la producción.

AB
Alex B.

El síndrome “Funciona en mi máquina”

Desarrollador A: “El inicio de sesión funciona en mi Mac”. Desarrollador B: “Falla en mi PC con Windows”. Servidor: “Se bloquea en Linux porque la versión de Node.js no coincide”. Esto es Deriva ambiental. Pierde miles de horas. Docker resuelve esto. No enviamos “Código”. Enviamos un “Contenedor”. Un contenedor es una máquina virtual liviana que contiene el sistema operativo (Alpine Linux), el tiempo de ejecución (nodo 18), las dependencias (node_modules) y el código. Si el contenedor se inicia en su computadora portátil, se iniciará en el servidor. Garantizado. Es la unidad estándar de despliegue.

Por qué Maison Code analiza esto

En Maison Code valoramos la Reproducibilidad. Si un nuevo desarrollador se une al equipo, no debería pasar 3 días instalando Redis, Postgres e ImageMagick. Deberían ejecutar “docker-compose up” y estar codificando en 10 minutos. Usamos Kubernetes (K8) para nuestros clientes empresariales que necesitan escala masiva y capacidades de autorreparación. Hablamos de esto porque DevOps no es una idea de último momento; es la base de la Velocidad del Desarrollo.

El Dockerfile: la receta

El Dockerfile define cómo construir el contenedor.

# 1. Imagen base (pequeña y segura)
DESDE nodo: 18-constructor de AS alpino

# 2. Establecer directorio
DIRTRABAJO /aplicación

# 3. Instalar dependencias (capa de caché)
COPIAR paquete*.json ./
EJECUTAR npm ci

# 4. Copiar código
COPIAR. .

# 5. Construir
EJECUTAR npm ejecutar compilación

# --- Construcción de múltiples etapas (optimización) ---
# Descartamos la etapa de 'constructor' y conservamos solo los artefactos de producción.
DESDE nodo: corredor AS alpino 18
DIRTRABAJO /aplicación
COPIAR --from=builder /app/.next ./.next
COPIAR --from=builder /app/public ./public
COPIAR --from=builder /app/node_modules ./node_modules
COPIAR --from=builder /app/package.json ./package.json

# 6. Empezar
CMD ["npm", "inicio"]

Consejo de optimización: Compilaciones de varias etapas. En el ejemplo anterior, utilizamos una etapa “constructor” para compilar el código. Luego copiamos solo el resultado a la etapa runner. Dejamos atrás el “Código Fuente”, el “Compilador TypeScript” y las “DevDependencies”. Resultado: utilice una imagen de 100 MB en lugar de una imagen de 1 GB. Implementación más rápida y tiempo de ejecución más seguro.

Docker Compose: orquestación local

Rara vez se ejecuta un solo contenedor. Ejecuta una aplicación web, una base de datos y un caché. docker-compose.yml los orquesta.

versión: '3'
servicios:
  web:
    construir: .
    puertos: ["3000:3000"]
    ambiente:
      DATABASE_URL: postgres://usuario:contraseña@db:5432/miaplicación
  base de datos:
    imagen: postgres:15
    ambiente:
      POSTGRES_PASSWORD: pasar
  Redis:
    imagen: redis: alpino

Ahora, “docker-compose up” hace girar toda la pila. El contenedor “web” puede comunicarse con “db” simplemente usando el nombre de host “db”. DNS mágico.

Kubernetes (K8s): El Capitán

Docker ejecuta contenedores. Kubernetes Los administra. Si tiene 1 servidor, use Docker. Si tiene 100 servidores, utilice Kubernetes. Mangos K8:

  1. Autorreparación: “El contenedor A falló. Reinícielo”.
  2. Escalado automático: “El uso de CPU es alto. Agregue 5 contenedores más”.
  3. Actualizaciones continuas: “Actualice la versión 1 a 2. Hágalo uno por uno. Si los errores aumentan, retroceda automáticamente”.

La advertencia de “exceso”

Kubernetes es complejo. Tiene una curva de aprendizaje pronunciada (pods, implementaciones, servicios, ingreso, gráficos de timón). Para el 90% de las empresas emergentes, los K8 son excesivos. Utilice una PaaS (plataforma como servicio) como Vercel, Railway o AWS App Runner. Ejecutan contenedores por usted sin el dolor de cabeza de administrar el plano de control del clúster. Pase a los K8 solo cuando necesite:

  • Cumplimiento (Hospedaje local).
  • Optimización de costes a escala masiva.
  • Mallas de redes complejas.

7. Helm: el administrador de paquetes para K8

Los archivos YAML de K8 son detallados. deployment.yaml (50 líneas). service.yaml (20 líneas). ingress.yaml (30 líneas). Multiplicar por 3 entornos (Dev, Staging, Prod). Es inmanejable. Solución: Timón. Los gráficos de timón son plantillas. helm instala mi-aplicación ./charts/mi-aplicación --set image.tag=v2 Reemplaza variables en la plantilla e implementa los manifiestos. Es “NPM para Kubernetes”.

8. GitOps (ArgoCD): La verdad está en Git

Nunca ejecute kubectl apply -f file.yaml desde su computadora portátil. Esto crea una “deriva de configuración”. Solución: GitOps.

  1. Almacene todos los YAML en un Git Repo (infra-repo).
  2. Instale ArgoCD en el clúster.
  3. ArgoCD vigila el Git Repo.
  4. Si envía un cambio a Git, ArgoCD lo aplica automáticamente al clúster.
  5. Si alguien piratea manualmente el clúster, ArgoCD detecta la diferencia y la revierte (Configuración de autorreparación). El estado del clúster siempre coincide con Git.

10. Imágenes sin distribución: seguridad mediante el minimalismo

Alpine Linux es pequeño (5 MB). Pero tiene un shell (/bin/sh). Si un hacker entra, puede ejecutar comandos. Solución: Imágenes “sin distribución” de Google. Contienen sólo tu aplicación y sus dependencias. Sin concha. Sin administrador de paquetes. Sin “les”. Si un hacker explota una vulnerabilidad, verifica “¡Estoy dentro!”… y luego no puede hacer nada. Utilice gcr.io/distroless/nodejs.

11. Presupuestos de disrupción de cápsulas (PDB)

Tienes 3 réplicas de tu API. Kubernetes quiere actualizar el nodo (parche del sistema operativo). Drena el nodo. Mata las 3 réplicas a la vez. El sitio se cae. Solución: Defina una PDB. minDisponible: 2. K8s se ve obligado a matar uno, esperar a que comience el nuevo y luego matar el siguiente. Esto garantiza Implementaciones sin tiempo de inactividad incluso durante el mantenimiento de la infraestructura.

12. La visión del escéptico

“Docker es lento en Mac”. Contrapunto: Cierto. Se ejecuta en una VM. Pero depurar “¿Por qué falla bcrypt en Linux?” lleva más tiempo que el 5% de rendimiento. Consistencia > Velocidad bruta.

Preguntas frecuentes

P: ¿Docker frente a máquina virtual (VM)? R: Una VM captura el hardware (pesado). Un contenedor captura el espacio de usuario del sistema operativo (ligero). Puede ejecutar 100 contenedores en un servidor que solo puede contener 5 máquinas virtuales.

P: ¿Es Docker seguro? R: Por defecto, sí (aislamiento). Pero si ejecuta como “root” dentro del contenedor y hay un exploit en el kernel, el atacante puede escapar. Mejor práctica: cree un usuario genérico (RUN adduser app) y cámbielo (USER app) en lo profundo del Dockerfile.

Conclusión

Los contenedores son los contenedores de envío del código. Antes de los contenedores de envío estándar, cargar un barco era un caos (barriles, sacos, cajas). Ahora todo cabe en una caja estándar. A la grúa no le importa lo que hay dentro. Docker convierte su código en un cuadro estándar. AWS es la grúa. Empaquételo bien y podrá enviarlo a cualquier parte.

¿Pesadillas de implementación?

Si sus implementaciones son situaciones inestables de “funcionó en mi máquina”, Maison Code puede acoplar su pila. Implementamos canales de CI/CD que construyen, prueban y envían contenedores automáticamente.



¿Dolores de cabeza durante la implementación?

Creamos contenedores de aplicaciones utilizando Docker y las organizamos con Kubernetes para implementaciones a prueba de balas. Contrata a nuestros Arquitectos.