¿Qué es una Container Image Layer?

Una Container Image Layer es una capa inmutable que aporta cambios al sistema de archivos de una imagen de contenedor. Puede añadir archivos, modificar otros o registrar eliminaciones respecto a las capas anteriores. Al combinar esas capas se obtiene la vista de archivos que necesita la aplicación, sin convertir cada imagen en una copia completamente independiente de todo lo que contiene.

Esta organización explica parte de la reutilización de imágenes y del comportamiento de sus construcciones. Una base compartida puede aprovecharse en varias imágenes, mientras cada aplicación añade sus propios cambios. También explica un error frecuente: borrar un archivo en una capa posterior no garantiza que su contenido haya desaparecido de las capas que ya se distribuyeron.

La imagen y el contenedor tienen escrituras diferentes

Las capas de una imagen permanecen inmutables. Al arrancar un contenedor, el motor añade una capa de escritura para sus modificaciones; la vista final combina ambas partes. Modificar un archivo dentro de un contenedor no reescribe automáticamente la imagen original. Otro contenedor creado desde esa imagen parte de nuevo de sus contenidos de origen.

Ese mecanismo no debería confundirse con almacenamiento persistente para los datos del servicio. Los datos importantes necesitan un diseño explícito de persistencia, por ejemplo mediante volúmenes y su protección correspondiente. Guardarlos sin más en la capa de escritura vincula su ciclo de vida al contenedor y dificulta su gestión operativa.

En una construcción con Dockerfile, instrucciones como COPY, ADD o RUN pueden producir cambios de sistema de archivos que forman capas. No toda línea del Dockerfile añade necesariamente una capa con archivos: algunas instrucciones establecen configuración o metadatos. Contar líneas, por tanto, no sirve como medida fiable del tamaño de una imagen.

-InfraCrew dice: El Dockerfile tiene pocas líneas. La carpeta que acabas de copiar tiene otras ambiciones.-

Reutilizar capas ahorra trabajo, con condiciones

La caché de construcción permite reutilizar resultados cuando las entradas relevantes no han cambiado. En una aplicación típica, puede resultar útil copiar primero los manifiestos de dependencias, instalarlas y después incorporar el código que cambia con más frecuencia. Así se evita repetir una instalación completa por cada pequeño ajuste de la aplicación.

El orden importa porque los pasos dependen de los anteriores. Una modificación temprana puede invalidar el trabajo que viene después, aunque las últimas instrucciones parezcan iguales. La organización debe seguir las dependencias reales del proyecto; mover pasos solo para obtener una imagen aparentemente rápida puede esconder errores de actualización o reproducibilidad.

También hay que distinguir entre una etiqueta y un digest. La etiqueta es un nombre que puede apuntar a contenidos diferentes con el tiempo; el digest identifica un contenido concreto. Registrar la imagen realmente desplegada facilita reproducir y diagnosticar un servicio, en lugar de descubrir que dos equipos descargaron cosas distintas bajo el mismo nombre.

Borrar después no deshace lo que se copió antes

Supongamos que una primera instrucción copia un archivo con credenciales y otra posterior lo elimina. La vista final puede dejar de mostrarlo, pero la capa anterior sigue formando parte de la imagen. Ocultar el archivo en el resultado combinado no retira sus bytes del historial de capas distribuido. Una imagen aparentemente limpia puede conservar ese material accesible.

Para secretos necesarios durante la construcción, Docker documenta mecanismos específicos de montaje temporal. Un secreto no debería viajar mediante argumentos de construcción o variables de entorno como sustituto de ese mecanismo. También conviene limitar el contexto enviado al constructor para evitar que archivos locales ajenos al producto entren accidentalmente en el proceso.

Algo parecido ocurre con paquetes y herramientas temporales. Si se instalan en una capa y se eliminan en otra, su coste puede permanecer en la imagen. Una construcción multietapa permite llevar al resultado final solo los artefactos necesarios, dejando fuera compiladores y material de trabajo que pertenecen a la fase de construcción.

-InfraCrew dice: Borrar la llave de la última foto no la borra de todas las fotos anteriores.-

Qué revisar antes de distribuir una imagen

Comprueba qué archivos necesita realmente la aplicación y qué ha heredado de su base. Una imagen pequeña y una imagen segura son propiedades relacionadas, pero distintas. Reducir tamaño puede simplificar transferencias y mantenimiento, aunque no sustituye a revisar vulnerabilidades, procedencia, permisos y actualizaciones del software incluido.

Después compara el tamaño transferido, el espacio local y los tiempos observados. Las capas compartidas y la compresión hacen que esas cifras no describan exactamente lo mismo. Una descarga inicial puede costar mucho más que una actualización posterior; medir ambas evita atribuir una mejora a la causa equivocada.

Prueba asimismo el resultado final en condiciones equivalentes al despliegue. Una construcción que termina correctamente no demuestra que estén presentes certificados, bibliotecas o archivos requeridos en ejecución. El objetivo es una aplicación reproducible y funcional, no ganar una competición de megabytes a costa de una dependencia que solo aparecía en el equipo del desarrollador.

Conserva el digest desplegado y un procedimiento de actualización verificable. La reutilización debe permitir reconstruir y corregir la imagen con confianza. Cuando se entiende qué aporta cada capa, resulta más sencillo localizar contenido sobrante, reducir transferencias y explicar por qué un cambio aparentemente pequeño volvió a ejecutar media construcción.

-InfraCrew dice: La imagen más ligera del mundo es muy rápida de descargar. Si no arranca, el ahorro dura poco.-

Diccionario de la Crew

Caché de construcción — Reutilización de resultados previos de construcción cuando sus entradas relevantes siguen siendo válidas.

Digest — Identificador calculado a partir del contenido de un objeto de imagen, utilizado para referenciarlo de forma precisa.