latest no es una version, es una promesa que nadie te hizo
Fijar la version de cada imagen cuesta diez minutos y evita el peor tipo de falla: la que aparece sin que nadie haya cambiado nada. Con los tamanos reales de mis imagenes y por que latest a veces no es la ultima.
En mis compose.yml no hay una sola imagen con :latest. Todas llevan versión:
image: postgres:17-alpine
image: n8nio/n8n:2.34.6
image: louislam/uptime-kuma:1.23.17
image: nginx:alpine
No es disciplina. Es que latest me costó una noche.
Lo que latest no significa
latest es una etiqueta como cualquier otra. No la calcula Docker: la pone quien publica la imagen, apuntándola a donde se le ocurra. No hay ninguna regla que obligue a que sea la versión más reciente.
El ejemplo que me tocó: en Docker Hub, el latest de Uptime Kuma sigue apuntando a la línea 1.x —la 1.23.17— aunque la 2.x existe desde hace tiempo. Alguien que escribe louislam/uptime-kuma:latest creyendo que instala lo último instala una versión mayor atrás. Y alguien que lo escribió hace un año creyendo lo mismo, y hoy reconstruye, puede llevarse un salto de versión mayor sin haberlo pedido.
Las dos direcciones son malas. La segunda es peor, porque llega en el peor momento: cuando reconstruyes por otra razón, a las once de la noche, y de pronto el servicio no arranca por un cambio de esquema que no leíste.
La falla que hace más daño
Con latest, dos personas que construyen el mismo compose.yml con una semana de diferencia pueden obtener cosas distintas. Y tú mismo, en el mismo servidor, obtienes algo distinto si borras la imagen local y vuelves a bajarla.
Eso rompe lo mejor que tiene Docker, que es que el archivo describe el sistema. Con latest, el archivo describe una parte del sistema y el resto depende de qué día lo corras.
Cuando algo se rompe así, el diagnóstico es cuesta arriba: git log no muestra ningún cambio, porque nadie cambió nada. Lo que cambió fue a qué apunta una etiqueta en un servidor ajeno.
Fijar versión también es decidir cuánto pesa
Fijar la versión obliga a mirar la imagen, y ahí aparece información que con latest uno nunca ve. Los tamaños en disco de las mías:
$ docker images --format '{{.Repository}}:{{.Tag}} {{.Size}}'
n8nio/n8n:2.34.6 2.11GB
louislam/uptime-kuma:1.23.17 707MB
postgres:17-alpine 423MB
nginx:alpine 92.2MB
Dos observaciones que salieron de ahí:
Las variantes alpine no son un detalle. postgres:17-alpine pesa 423 MB; la variante normal, basada en Debian, pasa holgadamente del doble. En una máquina con disco y memoria contados, elegir la etiqueta es elegir el precio.
n8n con 2.11 GB pesa más que todas mis plataformas Laravel juntas. Mi imagen de Laravel, construida en tres etapas, pesa 282 MB. Saber eso cambia decisiones: cuando evalúo agregar un servicio nuevo, el tamaño de su imagen es parte del costo.
Cómo se fija sin quedarse atrás
Fijar versiones tiene un riesgo real, y hay que decirlo: si nadie las mueve nunca, en dos años estás corriendo software con vulnerabilidades conocidas. «Fijo» no puede significar «olvidado».
Lo que hago:
- Fijar la versión menor, no el hash.
postgres:17-alpinetoma parches dentro de la 17 pero nunca salta a la 18 sola. Es el punto medio entre reproducible y mantenible. - Revisar en bloque, con calendario. Una vez al mes miro las notas de versión de lo que corro. Actualizar es cambiar un número, reconstruir y ver.
- Uno a la vez. Si actualizo cuatro imágenes y algo se rompe, no sé cuál fue. Uno por uno tarda más y se diagnostica solo.
La regla corta
Si el archivo no dice qué versión corre, el archivo no describe tu sistema. Y un sistema que no está descrito no se puede reconstruir: se puede, con suerte, volver a armar parecido.
