Conceptos 04 - Buenas prácticas de etiquetado y publicación
Recomendaciones para nombrar, etiquetar y publicar imágenes Docker de forma consistente, reproducible y segura. Cada práctica incluye un ejemplo concreto.
Concepto 1 de 8
Use convenciones claras de nombres y tags
Defina una convención de nomenclatura para el equipo y aplíquela de forma consistente.
Evitar
$ docker tag app nueva-version$ docker tag app fix-viernes$ docker tag app test-final-v2Preferir
$ docker tag app mi-registro/app:1.2.3$ docker tag app mi-registro/app:1.2.3-rc1$ docker tag app mi-registro/app:1.2.3-hotfixExplore las partes de una referencia completa de imagen.
Seleccione una parte de la referencia
Registro
Servidor donde se almacena la imagen. Si se omite, Docker usa Docker Hub (docker.io).
docker pull nginx equivale a docker pull docker.io/library/nginx:latest.
Concepto 2 de 8
Evite depender de latest
Utilice latest para exploración local, nunca como referencia principal en ambientes controlados.
Evitar
image: mi-app:latest# ¿Qué versión es? ¿Cuándo se construyó?Preferir
image: mi-app:2.3.1# Versión exacta, trazable al código fuenteConcepto 3 de 8
Trate los tags semánticos como inmutables
Una vez publicada la versión 1.0.0, no la sobreescriba. Si hay correcciones, publique 1.0.1.
Evitar
# Imagen 1.0.0 ya publicada, se reconstruye y sobreescribe$ docker build -t app:1.0.0 .$ docker push app:1.0.0# Ahora 1.0.0 es otra imagen distintaPreferir
$ docker build -t app:1.0.1 .$ docker push app:1.0.1# 1.0.0 permanece intactaAvance por las publicaciones y observe a qué imagen lleva cada referencia: los tags se mueven, el digest no.
Concepto 4 de 8
Mantenga coherencia entre versión de aplicación e imagen
Si la aplicación es v2.3.1, la imagen debería etiquetarse como 2.3.1. Evite numeraciones independientes.
Evitar
# App v2.3.1 pero imagen con tag independienteapp:build-47# ¿Qué versión de la app contiene?Preferir
# App v2.3.1 → imagen 2.3.1app:2.3.1# La versión de la imagen es la versión del códigoConcepto 5 de 8
Considere el digest para reproducibilidad estricta
En pipelines de producción, registre o utilice el digest como referencia definitiva.
# Obtener el digest de una imagen$ docker inspect --format='{{index .RepoDigests 0}}' app:2.3.1registry.example.com/app@sha256:a1b2c3d4e5f6...
# Referenciar por digest (inmutable por definición)image: registry.example.com/app@sha256:a1b2c3d4e5f6...En el simulador de la práctica 3, la referencia por digest es la única que no cambia cuando alguien sobrescribe un tag.
Concepto 6 de 8
Documente el origen de las imágenes
Use labels OCI para embeber información sobre el commit, la rama o el repositorio que originó la imagen.
# En el DockerfileLABEL org.opencontainers.image.version="2.3.1" \ org.opencontainers.image.revision="a1b2c3d" \ org.opencontainers.image.source="https://github.com/org/repo" \ org.opencontainers.image.created="2025-01-15T10:30:00Z"# Consultar labels de una imagen publicada$ docker inspect --format='{{json .Config.Labels}}' app:2.3.1 | jq{ "org.opencontainers.image.version": "2.3.1", "org.opencontainers.image.revision": "a1b2c3d"}Concepto 7 de 8
No publique imágenes sin revisión
Trate el push como un acto de publicación formal, no como un respaldo informal.
Evitar
# Sin verificar, sin tag apropiado$ docker push app:testPreferir
# Verificar, etiquetar y publicar$ docker build -t app:2.3.1 .$ docker tag app:2.3.1 registry.example.com/app:2.3.1$ docker push registry.example.com/app:2.3.1- Construir y verificardocker build
- Etiquetardocker tag
- Publicardocker push
Concepto 8 de 8
Use tokens de acceso en lugar de contraseñas
Para docker login en entornos automatizados o compartidos, cree tokens con permisos limitados.
Evitar
$ docker login -u usuario -p mi-contraseña-personal# Acceso completo a la cuentaPreferir
$ docker login -u usuario -p dckr_pat_a1b2c3d4...# Solo permisos de lectura/escritura en repositorios específicosAutoevaluación
Comprueba lo que aprendiste
Cinco preguntas rápidas para verificar las ideas clave de la lectura. Cada respuesta incluye una explicación.
0/5 respuestas correctas