El proceso de CI pasó de doce a cuatro minutos: el equipo cambió a php:8.3-alpine, eliminó las capas apt y redujo la imagen de 680 MB a 95 MB. Se celebra la fusión. Tres días después, la extensión GD ya no carga una fuente TrueType (faltan musl y bibliotecas) y el generador de miniaturas produce archivos PNG vacíos.
Las imágenes ligeras aceleran la extracción, la implementación y el arranque en frío. No simplifican automáticamente su solicitud. La confusión entre "Dockerfile pequeño" y "pila incluida" genera imágenes que arrancan rápidamente pero fallan silenciosamente en un caso extremo de producción.
Tamaño, capas y lo que realmente cuesta tiempo
Docker envía capas incrementales. Una imagen "pesada" con un buen caché local puede implementarse más rápido que una "ligera" que invalida todo en cada confirmación porque COPY. . está colocado demasiado alto.
| Palanca | Ganancia típica | Riesgo |
|---|---|---|
| Base alpina/delgada | −50 a 80% del tamaño | Incompatibilidades de Libc, paquetes faltantes |
| Prácticas múltiples | Eliminar cadena de herramientas del tiempo de ejecución | Olvídese de una biblioteca en tiempo de ejecución (ssl, tzdata) |
| .dockerignore | Caché más estable | Excluir un archivo requerido de la compilación |
| Combina RUN apto | Menos capas | Imágenes difíciles de parchear línea por línea |
Mida el tiempo de extracción + inicio en su registro y su host, no solo las "imágenes acoplables" localmente.
Una imagen liviana mal probada subcontrata el costo a la depuración nocturna.
Multietapa: compilación y tiempo de ejecución separados
Patrón PHP/nodo clásico:
- Constructor de etapas: instalación de Composer, compilación de ejecución de npm, extensiones de compilación.
- Tiempo de ejecución de la etapa: copie
vendor/,public/build/, solo archivos binarios compilados.
Evite copiar .git, pruebas, desarrollo de node_modules o documentación. Verifique que las extensiones de tiempo de ejecución de PHP (pdo_mysql, intl, opcache) estén instaladas en final, no solo en el generador.
Al alojar con un registro privado (Scaleway, GitLab, Harbour), las imágenes finales compactas también reducen la factura de almacenamiento y salida, especialmente con diez microservicios.
Alpine, delgado, sin distribución: elige la libc
Alpine (musl): muy pequeño, paquetes vía apk. Problemas comunes con wkhtmltopdf, algunas extensiones PECL y binarios relacionados con glibc.
Debian/Ubuntu slim (glibc): un ecosistema un poco más pesado y predecible para PHP y Python.
Sin distribución/Scratch: mínimo, a menudo sin shell: excelente para Go o Java, más exigente para PHP-FPM, donde la depuración cuenta.
Matriz de prueba mínima: inicio del contenedor, verificación de estado, ruta comercial crítica (carga de imagen, PDF, llamada API TLS).
.dockerignore y dependencias ocultas: el camino equivocado
Un .dockerignore demasiado agresivo que excluye composer.lock o los archivos de configuración fuerza una actualización del compositor implícita en la compilación: imagen “ligera”, compilaciones no reproducibles.
Por el contrario, incluir todo el repositorio sin ignorarlo infla el contexto enviado al demonio y rompe el caché en cada confirmación de documento.
Enumere explícitamente lo que entra en el contexto: archivos de bloqueo, parches, extensiones personalizadas. Documente las bibliotecas del sistema requeridas en el Dockerfile (comentario + RUN apk add --no-cache...).
Seguridad, CVE e imágenes “más recientes”
FROM node:latest o php:8-apache sin una etiqueta parcheada infla y ofusca las actualizaciones. Fije php:8.3.12-fpm-bookworm y automatice la reconstrucción en CVE.
Escanee (Trivy, Grype) en la imagen final, no solo en el Dockerfile. Una base alpina minimalista con una apertura vulnerable sigue siendo un riesgo.
La cumbre: la ligereza que enmascara la incomprensión
Ahorrar tiempo en el pull no sirve de nada si pierdes una hora reconstruyendo mentalmente lo que la antigua imagen de Debian instaló implícitamente.
Decide y avanza sin puntos ciegos
Documente las bibliotecas en tiempo de ejecución, adopte múltiples etapas, fije las bases, pruebe el humo en CI. Compara alpine vs slim en tu pila, no en un punto de referencia genérico.
Para alojar el registro, los corredores de CI y Docker VPS en Europa, consulte nuestro directorio y comparador. Las guías cubren el marco del contenedor.
Lista de verificación de lanzamiento: extraer una imagen en blanco, ejecutar el estado, ejecutar un escenario empresarial, escanear CVE, antes de celebrar los megabytes guardados.
Preguntas frecuentes
¿Sigue siendo Alpine la elección correcta para una imagen luminosa?
No, prueba musl vs glibc para tu pila; debian-slim o distroless pueden ser más estables.
¿Qué proporciona una compilación de varias etapas?
Separa la compilación y el tiempo de ejecución; la imagen final no incluye la cadena de herramientas.
¿Cómo acelerar el pull sin reducir la seguridad?
Capas de caché, .dockerignore, etiquetas fijadas: la velocidad proviene tanto del caché como del tamaño.
¿Necesito un shell en la imagen de producción?
Compensación entre depuración y superficie de ataque; elija según su capacidad de observabilidad externa.
Una imagen luminosa se juzga por el despliegue el viernes por la noche, no por las "imágenes acoplables" del lunes por la mañana.