4.1Registros: Hub, GHCR y registro privado
Lo esencial en 30 segundos
- Tres registros, tres usos : Docker Hub para compartir en público, GHCR vinculado al código para la CI, registro privado (interno de la empresa) para lo sensible — el nombre completo (registro/cuenta/imagen:tag) dice siempre de dónde viene la imagen.
- Nos autenticamos con un token de derechos limitados, nunca con la contraseña de la cuenta : pasado por --password-stdin, no queda ni en el historial del shell ni en los logs de la CI — y se revoca en un clic en caso de duda.
- Reflejo de Idir : en producción, se descarga un nombre completo + tag inmutable (nunca un atajo ambiguo), anotado en el compose de prod para saber qué imagen corre dónde.
Mini-caso hilado — Idir publica la imagen de su startup sin filtrar el token
Idir, devops junior en Argel, debe publicar la imagen de la aplicación de su startup para que el equipo la despliegue : elige GHCR (el código ya está en GitHub), crea un token limitado al push/pull, se conecta vía --password-stdin y sube un tag de versión inmutable. En producción, el equipo descarga el nombre completo y sabe exactamente qué imagen está corriendo. Primer hito del hilo : la imagen está en el lugar correcto, accesible para las personas correctas, sin secreto expuesto.
Este mismo caso vuelve en el curso, el esquema, el guion y el reto 48h — y continúa en 4.2, 4.3, 4.4 y 4.5.
1. Tres registros, tres usos
Docker Hub : la biblioteca pública por defecto, para compartir (open source, imágenes base). GHCR (GitHub Container Registry) : el registro vinculado a su código, perfecto para la CI — cada repositorio tiene ahí sus paquetes. Registro privado (interno de la empresa) : la caja fuerte de las imágenes sensibles, con acceso restringido. El nombre completo lo indica : registro/cuenta/imagen:tag — Idir lee de un vistazo de dónde viene cada imagen.
Elegir es decidir según la sensibilidad y el uso : público para el open source, GHCR para sus CI de GitHub, privado para lo interno sensible. El compose de producción fija la elección anotando los nombres completos.
2. Autenticarse sin exponer
docker login con un token de derechos limitados (push/pull), nunca la contraseña de la cuenta. El token pasa por --password-stdin (tubería, no argumento visible) : nada en el historial del shell, nada en los logs. En CI, el token vive en los secrets del repositorio, nunca en el script ni en el archivo de workflow.
Un token que se filtra se revoca en un clic : por eso nunca se comparte una cuenta — una cuenta compartida comprometida obliga a rehacer todo el acceso. Como Idir, se crea un token por uso y se revoca ante la menor duda.
3. Descargar en producción : fijen la fuente
En producción, se descarga nombre completo + tag inmutable (una versión fijada), nunca un atajo ambiguo que puede cambiar de contenido entre dos despliegues. La trazabilidad « qué imagen corre dónde » empieza con nombres completos anotados en el compose de prod.
Verificar después de la descarga : la imagen iniciada corresponde bien al tag deseado. Un tag móvil en prod es un despliegue que no se puede ni reproducir ni auditar.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — Subir hacia GHCR
El gesto de Idir : login sin rastro, imagen trazable.
echo $GHCR_TOKEN | docker login ghcr.io -u moncompte --password-stdin
docker build -t ghcr.io/monequipe/app:1.2.0 .
docker push ghcr.io/monequipe/app:1.2.0
# en prod :
docker pull ghcr.io/monequipe/app:1.2.0Lectura : el token nunca se muestra, la imagen es trazable por su nombre completo.
Lección : --password-stdin evita el secreto en el historial.
Vocabulario de la sección
- GHCR
- El registro de GitHub, vinculado a los repositorios y a la CI : cada proyecto publica ahí sus imágenes.
Ejemplo sencillo: Idir sube ahí la imagen de la aplicación cuyo código ya está en GitHub.
Lo que no es: una simple carpeta de almacenamiento de archivos.
Reflejo: código en GitHub + imagen por publicar en CI : pensar GHCR.
- Token
- Ficha de acceso de derechos LIMITADOS y revocable, que sustituye la contraseña para los usos automatizados.
Ejemplo sencillo: Idir crea un token push/pull en lugar de pegar su contraseña en un script.
Lo que no es: la contraseña de la cuenta, total y difícil de revocar limpiamente.
Reflejo: automatizar un acceso : crear un token limitado, nunca la contraseña.
- Nombre completo
- Dirección sin ambigüedad de una imagen : registro/cuenta/imagen:tag.
Ejemplo sencillo: El equipo de Idir despliega un nombre completo con versión fijada en producción.
Lo que no es: un atajo ambiguo que puede cambiar de contenido.
Reflejo: producción : descargar siempre un nombre completo + tag inmutable.
- --password-stdin
- Opción de docker login que lee el secreto desde una tubería en lugar de un argumento visible.
Ejemplo sencillo: Idir envía su token por tubería : nada queda en el historial del shell.
Lo que no es: la opción -p que expone el secreto en claro.
Reflejo: conectarse a un registro : siempre vía stdin.
En la práctica — En práctica — Publicar en el lugar correcto
- Elija el registro adaptado a su caso (Hub/GHCR/privado).
- Cree un token de derechos limitados (push/pull).
- Conéctese vía --password-stdin.
- Suba un tag inmutable y descárguelo en otro lugar para verificar.
Guion listo para decir — explicar la elección del registro a su responsable (30 s)
« Soy Idir : he publicado nuestra imagen en GHCR con un token limitado al push y al pull, conectado sin dejar rastro. La producción descarga el nombre completo con la versión fijada, así que sabemos exactamente qué imagen está corriendo. Si el token se filtra, lo revoco en un clic. »
Para decir cuando le preguntan por qué no « simplemente subir en público » : muestre la sensibilidad del código.
Modelo copiar-pegar — publicar una versión (GHCR)
echo $GHCR_TOKEN | docker login ghcr.io -u moncompte --password-stdin
docker build -t ghcr.io/monequipe/app:1.2.0 .
docker push ghcr.io/monequipe/app:1.2.0
docker pull ghcr.io/monequipe/app:1.2.0Imagen open source
Como Idir pero hacia Docker Hub en público : la comunidad puede descargar libremente, versión fijada para la confianza.
Imagen interna sensible
Registro privado de la empresa, repositorio con acceso restringido : solo los equipos habilitados descargan.
Token que se ha filtrado
Revocar inmediatamente el token, crear uno nuevo limitado, verificar los accesos — sin tocar la cuenta.
Prod que debe ser auditable
Nombre completo + tag inmutable anotados en el compose de prod : sabemos qué imagen corre dónde, en todo momento.
✓ Buenas prácticas
- Tokens limitados, nunca contraseñas.
- Nombres completos en producción.
- Revocar ante la menor duda.
✗ Errores frecuentes
- Login con -p y el secreto visible (historial).
- Imágenes internas subidas en público.
- Tags de atajos ambiguos en producción.
Puntos clave
- Hub = público, GHCR = CI, privado = interno.
- Tokens limitados vía --password-stdin.
- Nombre completo + tag inmutable en producción.
- Se revoca sin dudar.
Reto 48h — aplique mañana
Publique una imagen real : cree un token limitado, conéctese vía --password-stdin, suba un tag de versión y luego descárguelo desde otra máquina.
- Sé elegir el registro adaptado (Hub, GHCR, privado).
- Sé autenticarme por token limitado vía --password-stdin.
- Sé subir y descargar un tag inmutable trazable.
Preguntas frecuentes
¿Por qué --password-stdin en lugar de -p?
Porque -p expone el secreto en el historial del shell y los logs de CI. La tubería no deja rastro : el token transita sin aparecer nunca en claro.
¿Mantener el mismo registro en todas partes?
No : público para el open source, GHCR para sus CI de GitHub, privado para lo interno sensible. El compose de producción fija la elección con nombres completos.
En CI, ¿cómo autenticarse al registro?