Guía práctica para devs que necesitan entender contenedores sin convertirse en DevOps.
Dockerfile optimizado para Java/Spring Boot
El error más común: un Dockerfile que copia todo el proyecto y compilar dentro del contenedor. Resultado: imágenes de 1.5GB y builds de 10 minutos. La solución: multi-stage builds.
# Stage 1: Build FROM maven:3.9-eclipse-temurin-17 AS build WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package -DskipTests # Stage 2: Run FROM eclipse-temurin:17-jre-alpine COPY --from=build /app/target/*.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]
Health checks que importan
Kubernetes necesita saber si tu pod está sano. Configura liveness probe (el pod está vivo?), readiness probe (puede recibir tráfico?) y startup probe (ya terminó de iniciar?). Spring Boot Actuator te da estos endpoints gratis con /actuator/health.
Resource limits: no son opcionales
Siempre configura requests y limits de CPU/memoria. Sin limits, un pod con memory leak puede tumbar todo el nodo. En SAGCOM usamos: requests 256Mi/250m, limits 512Mi/500m para servicios estándar. Ajusta según tu profiling real.
Debugging en producción
Cuando algo falla en un pod: kubectl logs, kubectl describe pod, kubectl exec para entrar al contenedor. Pero lo más importante: logs estructurados en JSON que puedas buscar en tu herramienta de observabilidad. Sin esto estás ciego.
