2.3Versionar y publicar tus imágenes
Lo esencial en 30 segundos
- Etiquetar en el build, cuenta incluida : cuenta/imagen:versión es la dirección completa — sin namespace, no hay push.
- Inmutable por entrega : una etiqueta fijada y probada por versión (1.2.0), nunca reescrita — los alias móviles solo sirven para comodidad.
- Nunca subir un secreto : todo lo que entra en la imagen se va con el push — un push público es irreversible.
Mini-caso hilado — Idir y la prod que tiraba de latest
La imagen ligera de Idir (2.2) funciona en local, pero el equipo la comparte a mano, en latest, sin versión : la prod ya ha derivado dos veces. Idir etiqueta en el build con la cuenta (micuenta/mi-app:1.2.0 más alias 1.2), se conecta al registro, sube las dos etiquetas, y luego hace tirar de la 1.2.0 en otra máquina : build aquí, run allí, versión fijada. Verifica la visibilidad del repositorio antes de subir. En 2.4, hará configurable esta imagen ; en 2.5, verificará que no contenga ningún secreto antes de cada nuevo push.
Continuación del hilo conductor 2.2 : la imagen ligera de Idir viaja con un número de versión — y continúa en 2.4 y 2.5.
1. Etiquetar como un profesional
Se etiqueta en el build (-t micuenta/mi-app:1.2.0) y se añaden alias útiles (1.2, latest en dev). Regla : una etiqueta inmutable por entrega (1.2.0), nunca reescrita ; los alias móviles solo sirven para comodidad. La prod siempre tira de la etiqueta fijada y probada, nunca de latest. Idir fija la 1.2.0 y deja que la 1.2 siga los correctivos.
2. Publicar : login, push, pull
docker login autentica, docker push micuenta/mi-app:1.2.0 publica, cualquier máquina la recupera por pull. El nombre cuenta/imagen:tag es la dirección completa : sin cuenta (namespace), el push es rechazado. Idir sube sus dos etiquetas y luego, en otra máquina (o tras un rmi local), tira de la 1.2.0 y la lanza : la prueba de que la imagen viaja.
3. ¿Público o privado ?
Por defecto en el Hub, un repositorio es público : perfecto para open source, prohibido para código interno. Para lo interno, repositorio privado (Hub de pago, GHCR, registro de empresa). Y nunca un secreto en la imagen : un secreto COPY o ENV queda en las capas y se va con el push — un push público es irreversible. Idir controla la visibilidad antes de cada push y mantiene los secretos fuera de la imagen (2.5).
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — Publicar la 1.2.0
La imagen de Idir, de la máquina local al registro :
docker build -t moncompte/mon-app:1.2.0 -t moncompte/mon-app:1.2 .
docker login
docker push moncompte/mon-app:1.2.0
docker push moncompte/mon-app:1.2
# sur une autre machine :
docker pull moncompte/mon-app:1.2.0Lectura : la 1.2.0 está fijada y probada, la 1.2 sigue los correctivos, latest queda como comodidad de dev.
Lección : la prod tira de la 1.2.0, nunca de latest — reproducible y trazable.
Vocabulario de la sección
- Namespace
- La cuenta o la organización delante de la imagen (micuenta/mi-app) : la dirección completa exigida para subir.
Ejemplo sencillo: Idir antepone su cuenta desde el build.
Lo que no es: la etiqueta de versión sola.
Reflejo: sin namespace = sin push.
- Tag inmutable
- Una versión fijada y nunca reescrita (1.2.0) : lo que la prod tira para seguir siendo reproducible.
Ejemplo sencillo: Idir fija la 1.2.0 probada para la prod.
Lo que no es: un alias móvil como latest.
Reflejo: una entrega = una etiqueta fijada.
- Alias
- Una etiqueta móvil de comodidad (1.2, latest) que sigue los correctivos ; práctica en dev, prohibida como referencia de prod.
Ejemplo sencillo: Idir deja que 1.2 siga los parches, latest para las pruebas.
Lo que no es: la referencia desplegada en producción.
Reflejo: comodidad en dev, nunca en prod.
- push / pull
- Publicar hacia el registro (push) y recuperar desde el registro (pull) : el trío del intercambio con login.
Ejemplo sencillo: Idir sube la 1.2.0 y tira de ella en otra máquina.
Lo que no es: un build local nunca compartido.
Reflejo: login, push, pull : compartir versionado.
En la práctica — En la práctica — Publicar tu app
- Recompila tu app con dos etiquetas (1.0.0 fijada y 1.0 alias).
- Conéctate al registro (docker login).
- Sube las dos etiquetas (docker push), visibilidad verificada.
- En otra máquina (o tras rmi), tira de la 1.0.0 y lánzala.
Script listo para decir — imponer la etiqueta fijada (30 s)
« Ya no desplegamos latest : cada entrega tiene su etiqueta fijada, probada, nunca reescrita — la 1.2.0 funciona en prod, sabemos exactamente qué. Los alias como 1.2 o latest quedan para la comodidad en dev. Build aquí, pull allí, misma versión en todas partes. »
Para decir mostrando el pull de la 1.2.0 de Idir en una segunda máquina.
Modelo copiar-pegar — etiquetar y publicar
docker build -t moncompte/mon-app:1.2.0 -t moncompte/mon-app:1.2 .
docker login
docker push moncompte/mon-app:1.2.0
docker push moncompte/mon-app:1.2
docker pull moncompte/mon-app:1.2.0Push rechazado
Push « denied » : Idir verifica el login, el namespace cuenta/imagen y sus derechos sobre el repositorio.
Interno en público
Código interno subido a repositorio público : Idir pasa a privado (o registro de empresa) antes del push.
Etiqueta reescrita
Una 1.2.0 vuelta a subir distinta tras el despliegue : Idir fija 1.2.1 en lugar de reescribir la historia.
Push en cada commit
Cada prueba subida contamina el registro : Idir solo sube las versiones probadas, la CI filtrará (nivel 4).
✓ Buenas prácticas
- Una etiqueta inmutable por entrega, nunca reescrita.
- Anteponer la cuenta desde el build.
- Verificar la visibilidad (público/privado) antes del push.
✗ Errores frecuentes
- Reescribir una etiqueta ya desplegada (deriva de prod).
- Subir en público código interno.
- Incluir secretos en la imagen subida.
Puntos clave
- Se etiqueta en el build, cuenta incluida (dirección completa).
- Inmutable por entrega (1.2.0), alias (1.2, latest) para la comodidad.
- login → push → pull : el trío del intercambio versionado.
- Nunca un secreto en una imagen subida (push público irreversible).
Desafío 48h — aplica mañana
Publica tu imagen ligera (2.2) : build con dos etiquetas (1.0.0 + 1.0), login + push visibilidad verificada, y luego pull + run de la 1.0.0 en otro lugar.
- Puedo etiquetar en el build (inmutable + alias, cuenta incluida).
- Sé publicar (login, push) y recuperar (pull) en otro lugar.
- Controlo público/privado y excluyo los secretos antes de cada push.
Preguntas frecuentes
¿Por qué mi push es rechazado (denied) ?
A menudo un nombre sin namespace, o sin login, o sin derechos sobre el repositorio. Verifica docker login, el nombre cuenta/imagen:tag y tus derechos de escritura sobre el repositorio antes de reintentar.
¿Hay que subir en cada commit ?
No : se suben las versiones probadas (etiquetas fijadas), no cada prueba. La CI (nivel 4) automatizará este filtro : compila en cada commit pero solo publica las versiones validadas.
¿Qué política de etiquetas para la producción ?