Docker
Estructura interna de una imagen, capas, manifests, configs y digests.
Una imagen Docker es un artefacto inmutable que describe el filesystem y la configuración necesaria para crear contenedores. No es un archivo monolítico ni una copia comprimida de una máquina completa. Está formada por objetos relacionados mediante hashes de contenido:
referencia humana
node:22-slim
↓
manifest o image index
↓
config object + layer blobs
↓
filesystem visible + metadata de ejecuciónCuando Docker crea un contenedor, no modifica la imagen. Monta sus capas de solo lectura y añade una capa writable específica para esa instancia. Esta separación permite compartir contenido entre múltiples imágenes y contenedores, verificar integridad y distribuir únicamente los blobs que faltan.
Sin un artefacto versionado, desplegar una aplicación suele significar repetir una secuencia de instalación sobre cada servidor:
Ese procedimiento puede producir drift. Una actualización del package manager, una dependencia que cambió o un archivo residual genera resultados distintos aunque se utilice la misma documentación.
La imagen convierte el resultado del build en contenido identificable. Puede publicarse, descargarse y referenciarse mediante un digest concreto. La máquina de destino no necesita reconstruir la aplicación: necesita obtener el artefacto aprobado y suministrarle configuración de runtime.
Piensa en una imagen como una pila de cambios inmutables aplicada en orden:
Layer 4 COPY dist/ /app/dist
Layer 3 RUN npm ci --omit=dev
Layer 2 COPY package*.json /app/
Layer 1 filesystem de node:22-slim
---------------------------------
Filesystem visible de la imagenCada capa contiene diferencias respecto a la anterior: archivos añadidos, modificados o marcados como eliminados. El runtime presenta la combinación como un solo filesystem.
Al crear dos contenedores desde la misma imagen:
image layers compartidas y read-only
├── writable layer de api-1
└── writable layer de api-2Los cambios de api-1 no aparecen en api-2. Tampoco cambian la imagen original.
Son archivos comprimidos que representan cambios de filesystem. Se identifican mediante digests calculados a partir de su contenido.
Dos imágenes pueden reutilizar el mismo blob. Si ambas parten de la misma base, Docker no necesita guardar o descargar esa capa dos veces.
Es un objeto JSON que incluye metadata como:
ENV definidas en build;ENTRYPOINT y CMD;La config no contiene la configuración concreta de un contenedor, como sus puertos publicados, secretos de runtime o límites de memoria. Esos valores se suministran al crear la instancia.
Relaciona una config con los blobs comprimidos que forman una variante concreta de la imagen.
manifest linux/amd64
├── config digest
├── layer digest 1
├── layer digest 2
└── layer digest 3Una misma referencia puede apuntar a varias imágenes para plataformas diferentes:
node:22-slim
└── image index
├── manifest linux/amd64
├── manifest linux/arm64
└── manifest windows/amd64El cliente selecciona la variante compatible con la plataforma solicitada. Por eso dos equipos pueden hacer pull del mismo tag y obtener manifests específicos diferentes, aunque ambos partan del mismo índice.
Docker y OCI utilizan direcciones basadas en contenido. Un digest tiene una forma similar a:
sha256:6f3c...El hash cambia si cambia el contenido. Esto proporciona dos propiedades importantes:
Después de descargar un blob, el cliente calcula su hash y comprueba que coincide con el esperado. Un contenido alterado accidentalmente no debería aceptarse bajo el mismo digest.
Si el Engine ya posee un blob con ese digest, puede reutilizarlo. No importa de qué repository se obtuvo originalmente: el contenido idéntico tiene la misma identidad criptográfica dentro del modelo.
Content addressing no demuestra automáticamente que el contenido sea seguro o confiable. Solo identifica exactamente qué bytes se recibieron. La confianza requiere además controlar el origen, firmas, provenance, políticas y vulnerabilidades.
Estos identificadores suelen confundirse.
Es una referencia humana y mutable:
registry.example.com/team/api:1.4.0
registry.example.com/team/api:latestEl propietario del repository puede mover un tag para que apunte a otro manifest. Incluso un tag semántico puede cambiar si la política permite sobrescribirlo.
Fija el manifest publicado:
registry.example.com/team/api@sha256:abc...Es la referencia apropiada cuando necesitas desplegar exactamente el artefacto aprobado.
Docker suele mostrar un ID basado en la config de la imagen. Sirve para identificar contenido en el store local, pero no reemplaza necesariamente el digest del manifest usado para distribuirlo.
Una imagen multi-platform hace todavía más importante la diferencia: el digest del índice y el digest del manifest de una arquitectura no son el mismo objeto.
Considera este Dockerfile:
FROM node:22-slim
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "server.js"]De forma conceptual:
FROM selecciona una imagen base y sus capas.WORKDIR cambia metadata y puede crear el directorio.COPY añade los manifestos de dependencias.RUN crea cambios al instalar paquetes.COPY incorpora el código.CMD modifica metadata de ejecución; no inicia Node durante el build.No todas las instrucciones producen necesariamente una gran capa de archivos, pero todas pueden afectar el resultado, la cache o la config.
Este patrón parece limpiar un archivo:
RUN curl -o /tmp/archive.tar.gz https://example.com/archive.tar.gz
RUN tar -xzf /tmp/archive.tar.gz -C /app
RUN rm /tmp/archive.tar.gzSin embargo, la primera capa ya contiene el archivo comprimido. La tercera añade un marcador de eliminación, pero no reescribe la capa anterior. El blob sigue formando parte de la imagen distribuida.
Una alternativa es realizar descarga, extracción y limpieza en la misma instrucción:
RUN curl -o /tmp/archive.tar.gz https://example.com/archive.tar.gz \
&& tar -xzf /tmp/archive.tar.gz -C /app \
&& rm /tmp/archive.tar.gzUna solución aún mejor puede ser un multi-stage build donde el archivo temporal solo exista en una etapa que no se publica.
Cuando una capa elimina un archivo que existía antes, el formato necesita representar esa eliminación sin modificar el blob anterior. Para ello utiliza entradas especiales conocidas como whiteouts.
El filesystem combinado oculta el archivo, pero herramientas que inspeccionan las capas individuales todavía pueden encontrar el contenido original. Esta es una razón crítica para no copiar secretos y después borrarlos: el secreto puede permanecer en una capa publicada.
La capa writable pertenece al contenedor. Si ejecutas:
docker run --name demo alpine sh -c 'echo hola > /message && sleep 300'el archivo /message existe en la writable layer de demo.
Puedes crear una imagen nueva con docker commit, pero ese flujo no es una estrategia normal de construcción reproducible. El resultado depende de cambios manuales, puede omitir mounts y dificulta auditar cómo se produjo.
El enfoque correcto es modificar el Dockerfile o los artefactos de entrada y reconstruir.
Supón que api:1.0 contiene:
base Debian
+ Node.js
+ node_modules
+ dist versión AAl construir api:1.1, solo cambia dist:
base Debian reutilizada
Node.js reutilizada
node_modules reutilizada si lockfile no cambió
dist versión B capa nuevaEl registry y el host descargan únicamente blobs faltantes. Esta eficiencia depende de que el Dockerfile mantenga estable el orden de instrucciones: copiar todo el source antes de instalar dependencias invalidaría esa capa con cada cambio de código.
docker image inspect node:22-slimRevisa arquitectura, config, RepoDigests, RootFS.Layers y tamaño local. La salida exacta depende de la versión y del image store.
docker image history --no-trunc my-api:1.0Ayuda a detectar instrucciones asociadas a capas grandes, pero tiene límites:
docker buildx imagetools inspect node:22-slimPermite observar las plataformas publicadas y sus digests.
docker image ls
docker system df -vEl tamaño mostrado por una imagen no siempre equivale al espacio adicional real porque las capas pueden compartirse. Distingue tamaño lógico, blobs comprimidos en registry y uso físico local.
Dos hosts que ejecutan docker pull app:latest en momentos distintos pueden obtener artefactos diferentes. Para despliegues reproducibles utiliza digests o políticas de tags inmutables.
docker run app:1.0 puede usar el contenido local sin comprobar automáticamente si el registry movió el tag. Decide explícitamente cuándo hacer pull y qué política utiliza el despliegue.
Eliminar una referencia no borra necesariamente los blobs si otra imagen, tag, container o cache los utiliza.
El digest mostrado por un índice puede diferir del manifest ejecutado. Registra tanto la referencia promovida como la plataforma cuando la trazabilidad lo requiera.
Las capas conservan ownership y modos. Un COPY ejecutado como root puede dejar archivos inaccesibles para el usuario final. Usa COPY --chown o corrige permisos durante el build.
Una imagen no es una base de datos ni un volumen. Incorporar datos que cambian obliga a reconstruir y redistribuir todo el artefacto.
Por qué ocurre: parece representar “la versión actual”.
Consecuencia: no existe una identidad estable para auditoría o rollback.
Detección: los despliegues registran solo el tag y no el digest.
Corrección: publica tags trazables y despliega el digest aprobado.
Por qué ocurre: se confunde el filesystem visible con el historial de blobs.
Consecuencia: la credencial puede permanecer recuperable en la imagen.
Corrección: usa secret mounts de BuildKit y rota cualquier secreto publicado.
Por qué ocurre: el tamaño es una métrica visible.
Consecuencia: se eligen bases incompatibles, sin herramientas de diagnóstico o difíciles de actualizar.
Corrección: evalúa transferencia, CVEs, compatibilidad, cold start, soporte y operabilidad.
Por qué ocurre: se intenta inspeccionar o respaldar /var/lib/docker manualmente.
Consecuencia: scripts frágiles o corrupción frente a cambios de storage driver e image store.
Corrección: utiliza APIs y comandos soportados, y respalda los datos de aplicación por mecanismos propios.
Para desarrollo exploratorio, un tag puede ser cómodo, siempre que se comprenda que es una referencia mutable.
Construye esta imagen:
FROM alpine:3.22
RUN dd if=/dev/zero of=/large-file bs=1M count=20
RUN rm /large-file
CMD ["sh"]Después:
docker build -t layer-demo .
docker image ls layer-demo
docker history layer-demoAunque /large-file no aparezca en el filesystem final, el tamaño permanece en una capa anterior.
Ahora combina creación y eliminación en el mismo RUN, reconstruye y compara. El ejercicio demuestra que las capas registran cambios, no una fotografía final compactada automáticamente.
Registries, tags y digests, donde se estudia cómo estos objetos se almacenan, distribuyen, promueven y eliminan sin perder trazabilidad.