DEVOPS 11 min

Dockerizando Microservicios Java: De Dockerfile Multi-Stage a Google Jib en Producción

Guía avanzada de ingeniería para empaquetar aplicaciones Spring Boot en contenedores Docker: ergonomía de la JVM en cgroups v2, extracción de Layered JARs, compilación sin demonio con Google Jib y runtimes ultraligeros con jlink.

Escrito por Samir El Azem Crovetto • Senior Backend Engineer & DevSecOps

La Fricción entre la JVM y los Contenedores

La adopción de Docker y la orquestación en Kubernetes transformaron la entrega de software, pero en el ecosistema empresarial de Java y Spring Boot, esta transición estuvo lejos de ser transparente.

Tradicionalmente, la Máquina Virtual de Java (JVM) se diseñó bajo la premisa de que disponía del control absoluto sobre los recursos del hardware físico o de una máquina virtual dedicada. Durante años, desplegar un servicio Java dentro de un contenedor provocaba caídas inexplicables por OOM (Out Of Memory): la JVM leía los núcleos de CPU y la memoria RAM del sistema operativo anfitrión (Host OS) en lugar de respetar las cuotas impuestas por los cgroups del contenedor. Si un contenedor se limitaba a 1 GB de RAM en un servidor de 64 GB, la JVM intentaba reservar un heap de hasta 16 GB, provocando que el kernel de Linux liquidara el proceso de forma fulminante mediante el OOM Killer.

Aunque las versiones modernas de Java (OpenJDK 17, 21 y 25) incorporan soporte nativo para cgroups v2 (-XX:+UseContainerSupport), el empaquetado descuidado sigue generando artefactos desproporcionados: imágenes de más de 800 MB, capas monolíticas que invalidan la caché de compilación, tiempos de despliegue lentos y procesos que se ejecutan innecesariamente como usuario root.

En esta guía técnica analizamos la ingeniería de contenedorización para microservicios Java y Spring Boot en entornos de producción: desde el ajuste fino de la memoria y la extracción de capas (Layered JARs), hasta la creación de runtimes mínimos con jlink, el empaquetado sin demonio mediante Google Jib y la integración de defensas de seguridad en pipelines de DevSecOps.

Comparativa Arquitectónica: Fat JAR Tradicional vs. Layered JAR vs. Google Jib

Comprender la disposición de capas en el almacenamiento del contenedor es fundamental para optimizar tanto la velocidad de entrega en CI/CD como la seguridad perimetral:

flowchart TD
    subgraph Traditional ["1. Enfoque Fat JAR Monolitico (Inseguro y Lento)"]
        A1[Imagen Base JDK Completa ~600MB] --> B1[Capa Unica: app.jar Monolitico ~80MB]
        B1 --> C1[Ejecucion como root UID 0]
        C1 --> D1[Invalida 80MB de cache en cada commit]
    end

    subgraph Layered ["2. Dockerfile Multi-Stage + Layered JAR (Hardened)"]
        A2[Etapa Builder: Compilacion Maven/Gradle] --> B2[Extraccion de Capas de Spring Boot]
        B2 --> C2[Runtime Distroless / Alpine JRE ~120MB]
        C2 --> D2[Capas Ordenadas por Frecuencia de Cambio]
        D2 --> E2[Usuario no privilegiado UID 10001]
    end

    subgraph Jib ["3. Google Jib (Daemonless & Reproducible)"]
        A3[Compilacion directa en Maven / Gradle] --> B3[Generacion OCI sin Docker Daemon]
        B3 --> C3[Capas Semanticas Declarativas]
        C3 --> D3[Timestamps Reproducibles para Cache Distribuida]
    end

    classDef trad fill:#181825,stroke:#f38ba8,stroke-width:2px,color:#cdd6f4;
    classDef layered fill:#1e1e2e,stroke:#6366f1,stroke-width:2px,color:#cdd6f4;
    classDef jib fill:#181825,stroke:#a6e3a1,stroke-width:2px,color:#cdd6f4;
    class Traditional trad;
    class Layered layered;
    class Jib jib;

1. Ergonomía de la JVM en Contenedores: Memoria y Manejo de Señales

Para que una aplicación Java opere de forma estable dentro de un clúster de producción, es obligatorio configurar los parámetros del runtime teniendo en cuenta la frontera de aislamiento del contenedor:

Cálculo de Memoria: El Error de Mirar Solo el Heap

La memoria total consumida por un contenedor Java no equivale únicamente al tamaño del Heap (-Xmx). El proceso global consume:

$\text{Memoria Total} = \text{Heap} + \text{Metaspace} + \text{CodeCache} + (\text{ThreadStackSize} \times \text{Hilos}) + \text{DirectMemory} + \text{Sobrecarga JVM}$

Si se asigna un límite de contenedor de 1024 MB en Kubernetes (limits.memory: 1Gi) y se configura -Xmx1024m, el contenedor sufrirá un fallo de OOMKilled de inmediato cuando la JVM reserve memoria para Metaspace o hilos nativos.

La configuración recomendada en producción es utilizar porcentajes dinámicos:

# Flags de ergonomia recomendados para contenedores
-XX:+UseContainerSupport
-XX:MaxRAMPercentage=70.0
-XX:InitialRAMPercentage=50.0
-XX:+ExitOnOutOfMemoryError
  • MaxRAMPercentage=70.0: Asigna hasta el 70% del límite físico del contenedor al Heap, dejando un 30% restante para Metaspace, buffers de red (Direct Memory) y stacks de hilos.
  • ExitOnOutOfMemoryError: En lugar de dejar la JVM en un estado inconsistente o colgada cuando ocurre un fallo de memoria, fuerza la finalización del proceso para que el orquestador (Kubernetes o Docker) reinicie el contenedor de inmediato.
  • Heap Dumps Seguros: En entornos de producción con datos sensibles, debe evitarse escribir volcados de memoria sin cifrar en disco mediante -XX:+HeapDumpOnOutOfMemoryError, ya que estos archivos contienen credenciales, claves criptográficas y datos de clientes en texto plano.

Manejo de Señales UNIX y el Rol de PID 1

Cuando Kubernetes o Docker detienen un contenedor, envían una señal SIGTERM al proceso con PID 1, concediendo un periodo de gracia (por defecto 30 segundos) antes de forzar el apagado con SIGKILL.

Si en el Dockerfile se invoca Java a través de una shell (forma shell: CMD java -jar app.jar), la shell /bin/sh asume el PID 1 y habitualmente no reenvía las señales a la JVM. La aplicación no puede cerrar las conexiones a la base de datos ni finalizar las transacciones en vuelo. Debe utilizarse siempre la forma exec (ENTRYPOINT ["java", "-jar", "..."]).

2. Dockerfile Multi-Stage de Producción con Layered JARs

A partir de Spring Boot 2.3 y consolidado en Spring Boot 3.x, el framework incluye soporte nativo para Layered JARs (JARs por capas).

En un Fat JAR tradicional, cualquier cambio en una línea de código obliga a reconstruir y transferir un archivo de 80 MB completo. Con la extracción de capas, el artefacto se descompone en cuatro estratos ordenados por frecuencia de cambio:

  1. dependencies: Dependencias externas versionadas (Spring, Hibernate, etc.). Cambian raramente.
  2. spring-boot-loader: El cargador interno de clases de Spring. Prácticamente estático.
  3. snapshot-dependencies: Dependencias internas en desarrollo.
  4. application: Las clases compiladas y recursos de la propia aplicación. Cambia en cada commit y suele ocupar menos de 2 MB.

Dockerfile Multi-Stage Optimizado y Hardened

A continuación se presenta un manifiesto de referencia que integra compilación eficiente, extracción de capas, usuario sin privilegios y una base mínima:

# ==========================================
# ETAPA 1: Construccion y Empaquetado
# ==========================================
FROM eclipse-temurin:21-jdk-jammy AS builder
WORKDIR /workspace

# Aprovechamiento de cache para dependencias de Maven
COPY pom.xml .
COPY .mvn .mvn
COPY mvnw .
RUN ./mvnw dependency:go-offline -B

# Compilar y generar el JAR de la aplicacion
COPY src src
RUN ./mvnw clean package -DskipTests

# ==========================================
# ETAPA 2: Extraccion de Capas (Layer Tools)
# ==========================================
FROM eclipse-temurin:21-jre-jammy AS extractor
WORKDIR /workspace
COPY --from=builder /workspace/target/*.jar app.jar
RUN java -Djarmode=tools -jar app.jar extract --layers --destination extracted/

# ==========================================
# ETAPA 3: Runtime de Produccion Blindado
# ==========================================
FROM eclipse-temurin:21-jre-alpine AS runner
WORKDIR /app

# Crear usuario y grupo de sistema sin privilegios (UID 10001)
RUN addgroup -g 10001 -S appgroup && \
    adduser -u 10001 -S appuser -G appgroup -s /sbin/nologin

# Copiar capas de forma ordenada para maximizar el reuso de la cache de Docker
COPY --from=extractor --chown=appuser:appgroup /workspace/extracted/dependencies/ ./
COPY --from=extractor --chown=appuser:appgroup /workspace/extracted/spring-boot-loader/ ./
COPY --from=extractor --chown=appuser:appgroup /workspace/extracted/snapshot-dependencies/ ./
COPY --from=extractor --chown=appuser:appgroup /workspace/extracted/application/ ./

# Establecer permisos de solo lectura en los binarios
USER 10001:10001

# Exponer el puerto de servicio nominal
EXPOSE 8080

# Configuracion de variables de entorno de la JVM
ENV JAVA_TOOL_OPTIONS="-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0 -XX:+ExitOnOutOfMemoryError"

# Entrada determinista utilizando el Launcher optimizado de Spring
ENTRYPOINT ["java", "org.springframework.boot.loader.launch.JarLauncher"]

Con esta arquitectura, un cambio en la lógica de negocio solo invalida la última capa (application), reduciendo el tiempo de subida de la imagen a un registro de 40 segundos a menos de 2 segundos.

3. La Alternativa Cloud-Native: Google Jib

Escribir y mantener Dockerfiles en organizaciones con docenas de microservicios introduce complejidad operativa y riesgos de seguridad si los equipos no aplican las directivas de hardening de manera uniforme.

Google Jib es una herramienta desarrollada para construir imágenes OCI directamente desde el ciclo de vida de compilación de Maven o Gradle, sin requerir la instalación del demonio de Docker ni privilegios de root.

Ventajas Técnicas de Google Jib:

  1. Compilación Daemonless (Sin Docker Daemon): Jib interactúa directamente con los registros de imágenes (Google Artifact Registry, AWS ECR, Docker Hub) mediante llamadas HTTP a la API de OCI, evitando la necesidad de ejecutar Docker-in-Docker (DinD) en los runners de CI/CD.
  2. Capas Semánticas Automáticas: Descompone de forma nativa las librerías, clases y recursos de Java en capas independientes sin requerir scripts auxiliares de extracción.
  3. Reproducibilidad Criptográfica (Reproducible Builds): Jib establece los metadatos temporales de los archivos a la época Unix cero (1970-01-01 00:00:00 UTC) o a un timestamp fijo, garantizando que dos compilaciones con el mismo código fuente generen exactamente el mismo hash SHA-256 de imagen.

Configuración de Jib en pom.xml

<plugin>
    <groupId>com.google.cloud.tools</groupId>
    <artifactId>jib-maven-plugin</artifactId>
    <version>3.4.4</version>
    <configuration>
        <!-- Imagen base minima y segura -->
        <from>
            <image>eclipse-temurin:21-jre-alpine</image>
        </from>
        <!-- Destino de la imagen en el registro corporativo -->
        <to>
            <image>registry.empresa.com/microservicios/auth-service:${project.version}</image>
            <tags>
                <tag>latest</tag>
            </tags>
        </to>
        <container>
            <!-- Ejecucion obligatoria sin root -->
            <user>10001:10001</user>
            <ports>
                <port>8080</port>
            </ports>
            <environment>
                <SPRING_PROFILES_ACTIVE>prod</SPRING_PROFILES_ACTIVE>
            </environment>
            <jvmFlags>
                <jvmFlag>-XX:+UseContainerSupport</jvmFlag>
                <jvmFlag>-XX:MaxRAMPercentage=75.0</jvmFlag>
                <jvmFlag>-XX:+ExitOnOutOfMemoryError</jvmFlag>
                <jvmFlag>-Dfile.encoding=UTF-8</jvmFlag>
            </jvmFlags>
            <!-- Formato OCI universal -->
            <format>OCI</format>
        </container>
    </configuration>
</plugin>

Para construir y publicar directamente la imagen en el pipeline de integración continua:

# Publicacion directa al registro autenticado mediante credenciales de CI
mvn compile jib:build

4. Runtimes Ultraligeros con Jlink: De 300 MB a 45 MB

Cuando se busca la máxima optimización de recursos y la mínima superficie de exposición, la solución avanzada consiste en emplear jlink (Java Linker), introducido con el sistema de módulos de Java (JPMS).

En lugar de empaquetar un JRE completo con cientos de clases que la aplicación nunca utilizará (como módulos gráficos AWT o soporte de sonido), jlink analiza las dependencias reales del bytecode y compila un runtime personalizado que contiene estrictamente los módulos necesarios:

# Comando jlink para ensamblar un JRE minimo
jlink \
  --add-modules java.base,java.sql,java.net.http,java.desktop,jdk.crypto.ec \
  --strip-debug \
  --no-man-pages \
  --no-header-files \
  --compress=2 \
  --output /custom-runtime

El runtime resultante ocupa entre 35 MB y 50 MB, reduciendo drásticamente tanto el uso de disco como los potenciales vectores de explotación.

5. Integración de Seguridad y Escaneo de Vulnerabilidades en CI/CD

El empaquetado de contenedores debe estar gobernado por controles de seguridad automatizados antes de que cualquier artefacto pueda promocionarse a producción:

1. Escaneo de Dependencias y Sistema Operativo con Trivy

La verificación estática de vulnerabilidades (CVEs) debe ejecutarse tanto sobre las librerías Java (SCA) como sobre los paquetes del sistema operativo de la imagen base:

# Analisis de seguridad en el pipeline con criterio de fallo bloqueante
trivy image \
  --severity CRITICAL,HIGH \
  --exit-code 1 \
  --ignore-unfixed \
  registry.empresa.com/microservicios/auth-service:latest

2. Generación de Inventario SBOM

En cumplimiento de normativas como la directiva europea NIS2 y la Cyber Resilience Act (CRA), cada compilación debe generar un inventario formal de componentes en formato CycloneDX:

trivy image \
  --format cyclonedx \
  --output sbom-container.json \
  registry.empresa.com/microservicios/auth-service:latest

3. Firma Criptográfica con Sigstore Cosign

Una vez verificada la imagen, el pipeline firma digitalmente el digest SHA-256 para que el controlador de admisión en Kubernetes impida el despliegue de imágenes no autorizadas o manipuladas:

cosign sign --key k8s-cosign.key registry.empresa.com/microservicios/auth-service@sha256:7b2a9e...

Conclusión

Contenedorizar microservicios Java en producción exige superar el enfoque ingenuo del Fat JAR en imágenes monolíticas. Comprender el comportamiento de la JVM bajo cgroups v2, desacoplar las dependencias mediante Layered JARs o Google Jib y blindar los permisos de ejecución son pasos indispensables para construir arquitecturas cloud nativas fiables y seguras.

Combinar estas técnicas con prácticas de Hardening de Sistemas, autenticación robusta mediante OAuth 2.1 y OIDC y automatización DevSecOps en CI/CD permite alcanzar un estándar de ingeniería de primer nivel.

Si tu equipo necesita optimizar sus tiempos de compilación, implantar pipelines de despliegue seguros para Spring Boot o auditar imágenes de contenedores en Kubernetes, puedes consultar mis Servicios de Ciberseguridad y Consultoría o contactar directamente conmigo en mi perfil Sobre mí.