BuildKit

Paralelismo y mejoras

BuildKit representa la evolución natural del sistema de construcción de imágenes de Docker, convirtiéndose en el motor por defecto desde Docker Engine 20.10 y manteniendo esta posición en las versiones más recientes. Este nuevo motor no solo reemplaza al legacy builder, sino que introduce mejoras sustanciales en rendimiento, funcionalidad y experiencia de usuario.

BuildKit por defecto

En Docker Engine 28, BuildKit se ejecuta automáticamente sin necesidad de configuración adicional. A diferencia del builder clásico que procesaba las instrucciones del Dockerfile de forma secuencial y lineal, BuildKit implementa un enfoque completamente diferente basado en la construcción de un grafo acíclico dirigido (DAG) de las operaciones a realizar.

# BuildKit se activa automáticamente
docker build -t mi-app .

# El output muestra el progreso mejorado
[+] Building 12.3s (8/8) FINISHED
 => [internal] load build definition from Dockerfile
 => [internal] load .dockerignore
 => [internal] load metadata for nginx:alpine
 => [stage-1 1/3] FROM nginx:alpine
 => [internal] load build context
 => [stage-1 2/3] COPY index.html /usr/share/nginx/html/
 => [stage-1 3/3] COPY styles.css /usr/share/nginx/html/
 => exporting to image

Paralelización inteligente

La arquitectura DAG permite a BuildKit analizar todas las instrucciones del Dockerfile antes de comenzar la ejecución, identificando qué operaciones pueden ejecutarse en paralelo. Esta capacidad resulta especialmente beneficiosa en escenarios complejos donde múltiples operaciones independientes pueden procesarse simultáneamente.

FROM node:18-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:18-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY src/ ./src/
RUN npm run build

FROM nginx:alpine
# BuildKit puede ejecutar las copias en paralelo
COPY --from=deps /app/node_modules ./node_modules/
COPY --from=build /app/dist ./dist/

En este ejemplo, BuildKit puede procesar simultáneamente las operaciones COPY --from=deps y COPY --from=build una vez que sus respectivas etapas han completado, reduciendo significativamente el tiempo total de construcción.

Optimización de transferencia de contexto

BuildKit introduce mejoras en la transferencia del contexto de build, enviando solo los archivos necesarios cuando es posible y utilizando técnicas de streaming más eficientes. Esta optimización resulta particularmente notable en proyectos con contextos grandes o cuando se trabaja con Docker remoto.

# El progreso muestra las transferencias optimizadas
[+] Building 8.7s (12/12) FINISHED
 => [internal] load build definition from Dockerfile          0.1s
 => [internal] load .dockerignore                            0.0s
 => [internal] load metadata for node:18-alpine             2.3s
 => [internal] load build context                           0.2s
 => => transferring context: 2.84MB                         0.1s

Visor de progreso mejorado

Una de las mejoras más visibles de BuildKit es su sistema de progreso en tiempo real. A diferencia del output lineal del builder clásico, BuildKit muestra el estado de todas las operaciones concurrentes, proporcionando una visión clara del progreso general del build.

El progreso se presenta en formato jerárquico donde cada línea representa una operación específica, con indicadores de tiempo y estado que se actualizan dinámicamente:

[+] Building 15.2s (14/14) FINISHED
 => [internal] load build definition from Dockerfile          0.1s
 => [internal] load .dockerignore                            0.0s
 => [internal] load metadata for postgres:15                 2.1s
 => [internal] load metadata for node:18-alpine             2.1s
 => [deps 1/4] FROM node:18-alpine@sha256:...                0.0s
 => [database 1/2] FROM postgres:15@sha256:...               0.0s
 => [internal] load build context                           0.3s
 => [deps 2/4] WORKDIR /app                                 0.1s
 => [deps 3/4] COPY package*.json ./                        0.1s
 => [deps 4/4] RUN npm ci                                   8.4s
 => [app 1/3] COPY --from=deps /app/node_modules ./         1.2s
 => [app 2/3] COPY src/ ./src/                              0.2s
 => [app 3/3] RUN npm run build                             2.1s
 => exporting to image                                      0.6s

Gestión inteligente de dependencias

BuildKit analiza las dependencias entre capas de forma más sofisticada, evitando rebuilds innecesarios y optimizando el orden de ejecución. Cuando una instrucción no depende del resultado de otra, BuildKit puede ejecutarlas en paralelo, maximizando el uso de recursos disponibles.

Esta optimización automática es especialmente efectiva en builds complejos donde el desarrollador no necesita preocuparse por el orden específico de las operaciones independientes - BuildKit se encarga de organizarlas de la manera más eficiente posible.

La transición a BuildKit como motor por defecto marca un salto cualitativo en la experiencia de construcción de imágenes Docker, proporcionando builds más rápidos, mejor feedback visual y una base sólida para las funcionalidades avanzadas que exploraremos en las siguientes secciones del curso.

Secrets y SSH mounts

BuildKit introduce capacidades avanzadas de montaje que permiten acceder a información sensible durante el proceso de construcción sin comprometer la seguridad. Los mounts de secrets y SSH proporcionan mecanismos seguros para manejar credenciales, claves privadas y otros datos confidenciales que las aplicaciones necesitan durante el build, pero que no deben persistir en las capas finales de la imagen.

Montajes de secrets

Los secret mounts permiten proporcionar información confidencial a los contenedores durante la fase de construcción sin que estos datos queden almacenados permanentemente en las capas de la imagen. Esta funcionalidad resulta esencial cuando necesitamos acceder a tokens de API, credenciales de bases de datos o certificados durante el build.

La sintaxis básica utiliza la instrucción RUN con el flag --mount=type=secret:

FROM node:18-alpine
WORKDIR /app

# Montar un secret para acceder a un registry privado
RUN --mount=type=secret,id=npm_token \
    npm config set //registry.npmjs.org/:_authToken=$(cat /run/secrets/npm_token) && \
    npm install @empresa/libreria-privada

COPY package*.json ./
RUN npm install
COPY . .
CMD ["npm", "start"]

Para utilizar este Dockerfile, proporcionamos el secret durante el build:

# Crear el secret desde un archivo
echo "npm_AbC123XyZ" > .npm_token
docker build --secret id=npm_token,src=./.npm_token -t mi-app .

# O desde una variable de entorno
export NPM_TOKEN="npm_AbC123XyZ"
docker build --secret id=npm_token,env=NPM_TOKEN -t mi-app .

Configuración avanzada de secrets

Los secret mounts ofrecen opciones de configuración para controlar cómo y dónde se montan los datos sensibles:

FROM alpine:latest

# Secret con ruta personalizada y permisos específicos
RUN --mount=type=secret,id=db_password,target=/tmp/db_pass,mode=0400 \
    DB_PASS=$(cat /tmp/db_pass) && \
    echo "Configurando conexión a base de datos..." && \
    # El secret está disponible solo durante esta instrucción
    setup_database.sh "$DB_PASS"

# Secret opcional que no falla si no existe
RUN --mount=type=secret,id=optional_config,required=false \
    if [ -f /run/secrets/optional_config ]; then \
        echo "Aplicando configuración opcional..." && \
        apply_config.sh /run/secrets/optional_config; \
    fi

Montajes SSH

Los SSH mounts facilitan el acceso a repositorios privados o servicios que requieren autenticación SSH durante el proceso de construcción. Esta funcionalidad es especialmente útil para clonar repositorios Git privados o instalar dependencias desde fuentes que requieren autenticación por clave pública.

FROM golang:1.21-alpine
WORKDIR /app

# Instalar git y configurar SSH
RUN apk add --no-cache git openssh-client

# Montar el SSH agent para acceder a repositorios privados
RUN --mount=type=ssh \
    mkdir -p ~/.ssh && \
    ssh-keyscan github.com >> ~/.ssh/known_hosts && \
    go mod download github.com/empresa/libreria-privada

COPY go.mod go.sum ./
RUN go mod download

COPY . .
RUN go build -o app .
CMD ["./app"]

Para usar SSH mounts, necesitamos iniciar el SSH agent y cargar las claves antes del build:

# Iniciar SSH agent y cargar la clave
eval $(ssh-agent)
ssh-add ~/.ssh/id_rsa

# Ejecutar el build con acceso SSH
docker build --ssh default -t mi-app-go .

# O especificar una clave específica
docker build --ssh default=~/.ssh/id_rsa_empresa -t mi-app-go .

Casos de uso prácticos

Los mounts de secrets y SSH resultan fundamentales en escenarios empresariales comunes:

1. Instalación de paquetes privados:

FROM python:3.11-slim
WORKDIR /app

# Usar secret para PyPI privado
RUN --mount=type=secret,id=pypi_token \
    pip config set global.extra-index-url \
    https://token:$(cat /run/secrets/pypi_token)@pypi.empresa.com/simple/

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .
CMD ["python", "app.py"]

2. Clonado de repositorios durante el build:

FROM node:18-alpine
RUN apk add --no-cache git openssh-client
WORKDIR /app

# Clonar dependencias privadas con SSH
RUN --mount=type=ssh \
    ssh-keyscan github.com >> ~/.ssh/known_hosts && \
    git clone git@github.com:empresa/shared-components.git /tmp/shared && \
    cp -r /tmp/shared/dist ./vendor/

COPY package*.json ./
RUN npm install
COPY . .
CMD ["npm", "start"]

Ventajas de seguridad

La principal ventaja de seguridad de estos mounts radica en que los datos sensibles no se almacenan en las capas de la imagen final. A diferencia de usar variables de entorno o copiar archivos directamente, los secrets y SSH mounts:

• No persisten en la imagen final
• No aparecen en el historial de capas
• Se eliminan automáticamente al finalizar la instrucción RUN
• Proporcionan control granular sobre permisos y ubicación

Esta aproximación permite construir imágenes que han tenido acceso a información sensible durante el build, pero que mantienen la seguridad necesaria para su distribución y despliegue en diferentes entornos.