Note
Este tipo de paquete podría no estar disponible para tu instancia, ya que los administradores del sitio pueden habilitar o inhabilitar cada tipo de paquete compatible. Para obtener más información, vea «Configurar la compatibilidad del ecosistema de paquetes para tu empresa».
Acerca de la compatibilidad de Docker
Cuando instalas o publicas una imagen de Docker, el registro de Docker no es compatible actualmente con capas ajenas, tales como imágenes de Windows.
Docker Engine v25 no es compatible con el Registro de Docker en GitHub Enterprise Server. Se recomienda usar Container registry en su lugar. Para obtener más información sobre las migraciones, consulte “Migrarse al registro del contenedor desde el registro de Docker”.
Autenticar a GitHub Packages
Note
GitHub Packages solo admite la autenticación mediante un personal access token (classic). Para obtener más información, vea «Administración de tokens de acceso personal».
Necesitas un token de acceso para publicar, instalar y eliminar paquetes privados, internos y públicos.
Puedes usar un personal access token (classic) para autenticarte en GitHub Packages o en la API de GitHub Enterprise Server. Cuando creas un personal access token (classic), puedes asignar al token diferentes ámbitos en función de tus necesidades. Para más información sobre los ámbitos relacionados con paquetes para un personal access token (classic), consulta "Acerca de los permisos para los Paquetes de GitHub".
Para autenticarte en un registro del GitHub Packages dentro de un flujo de trabajo de GitHub Actions, puedes utilizar:
GITHUB_TOKEN
para publicar los paquetes asociados con el repositorio del flujo de trabajo.- Un personal access token (classic) con, al menos, ámbito de
read:packages
para instalar los paquetes asociados con otros repositorios privados (a los cuales no puede accederGITHUB_TOKEN
).
Para más información sobre el uso de GITHUB_TOKEN
en flujos de trabajo de GitHub Actions, consulta "Autenticación automática de tokens".
Autenticación con un personal access token
Debes utilizar un personal access token (classic) con los ámbitos adecuados para publicar e instalar paquetes en GitHub Packages. Para obtener más información, vea «Introducción a los paquetes de GitHub».
Puedes autenticarte en GitHub Packages con Docker utilizando el comando de inicio de sesión docker
.
Para mantener tus credenciales seguras, te recomendamos que guardes tu personal access token en un archivo local de tu equipo y uses la marca --password-stdin
de Docker, que lee tu token desde un archivo local.
Si la instancia tiene habilitado el aislamiento de subdominio:
cat ~/TOKEN.txt | docker login docker.HOSTNAME -u USERNAME --password-stdin
Si la instancia tiene deshabilitado el aislamiento de subdominio:
cat ~/TOKEN.txt | docker login HOSTNAME -u USERNAME --password-stdin
Para usar este ejemplo de comando de inicio de sesión, reemplace USERNAME
por su nombre de usuario de GitHub Enterprise Server, HOSTNAME
por la URL de tu instancia de GitHub Enterprise Server, y ~/TOKEN.txt
por la ruta de archivo de su personal access token para GitHub Enterprise Server.
Para obtener más información, consulta "Inicio de sesión de Docker".
Publicar una imagen
Note
El registro de Docker de GitHub Packages se reemplazará en una versión futura de GitHub Enterprise Server por Container registry, que ofrece compatibilidad mejorada con contenedores.
Note
Los nombres de imagen solo deben usar letras minúsculas.
GitHub Packages admite varias imágenes Docker de primer nivel por repositorio. Un repositorio puede tener cualquier cantidad de etiquetas de imagen. Puedes experimentar un servicio de menor calidad al publicar o instalar imágenes de Docker de más de 10 GB, las capas tienen un límite de 5 GB cada una. Para obtener más información, consulta "Etiqueta de Docker" en la documentación de Docker.
Después de que publiques un paquete, puedes verlo en GitHub. Para obtener más información, vea «Visualizar paquetes».
-
Determina el nombre y la id. de la imagen Docker mediante
docker images
.$ docker images > < > > REPOSITORY TAG IMAGE ID CREATED SIZE > IMAGE_NAME VERSION IMAGE_ID 4 weeks ago 1.11MB
-
Use el identificador de la imagen de Docker para etiquetar la imagen de Docker. Reemplace PROPIETARIO por el nombre de la cuenta personal u organización a la que pertenece el repositorio, REPOSITORIO por el nombre del repositorio que contiene el proyecto, NOMBRE_DE_IMAGEN por el nombre del paquete o imagen, NOMBRE DEL HOST por el nombre de host de tu instancia de GitHub Enterprise Server, y VERSIÓN por la versión del paquete en tiempo de compilación.
Si la instancia tiene habilitado el aislamiento de subdominio:
docker tag IMAGE_ID docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
Si en la instancia se ha deshabilitado el aislamiento de subdominios:
docker tag IMAGE_ID HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
- Si aún no ha compilado una imagen de Docker para el paquete, compile la imagen. Reemplace PROPIETARIO por el nombre de la cuenta personal u organización a la que pertenece el repositorio, REPOSITORIO por el nombre del repositorio que contiene el proyecto, NOMBRE_DE_IMAGEN por el nombre del paquete o imagen, VERSIÓN por la versión de paquete en tiempo de compilación, NOMBRE DEL HOST por el nombre de host de tu instancia de GitHub Enterprise Server, y RUTA DE ACCESO a la imagen en caso de que no esté en el directorio de trabajo actual.
Si la instancia tiene habilitado el aislamiento de subdominio:
docker build -t docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION PATH
Si en la instancia se ha deshabilitado el aislamiento de subdominios:
docker build -t HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION PATH
- Publicar la imagen para GitHub Packages.
Si la instancia tiene habilitado el aislamiento de subdominio:
docker push docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
Si en la instancia se ha deshabilitado el aislamiento de subdominios:
docker push HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
Note
Debes enviar los cambios de la imagen con IMAGE_NAME:VERSION
en lugar de con IMAGE_NAME:SHA
.
Ejemplo de publicación de una imagen Docker
En estos ejemplos se da por hecho que la instancia tiene habilitado el aislamiento de subdominio.
Puedes publicar la versión 1.0 de la imagen monalisa
en el repositorio octocat/octo-app
mediante un id. de imagen.
$ docker images
> REPOSITORY TAG IMAGE ID CREATED SIZE
> monalisa 1.0 c75bebcdd211 4 weeks ago 1.11MB
# Tag the image with OWNER/REPO/IMAGE_NAME
$ docker tag c75bebcdd211 docker.HOSTNAME/octocat/octo-app/monalisa:1.0
# Push the image to GitHub Packages
$ docker push docker.HOSTNAME/octocat/octo-app/monalisa:1.0
Puedes publicar una nueva imagen de Docker por primera vez y denominarla monalisa
.
# Build the image with docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
# Assumes Dockerfile resides in the current working directory (.)
$ docker build -t docker.HOSTNAME/octocat/octo-app/monalisa:1.0 .
# Push the image to GitHub Packages
$ docker push docker.HOSTNAME/octocat/octo-app/monalisa:1.0
Descarga de una imagen
Note
El registro de Docker de GitHub Packages se reemplazará en una versión futura de GitHub Enterprise Server por Container registry, que ofrece compatibilidad mejorada con contenedores.
Puede usar el comando docker pull
para instalar una imagen de Docker desde GitHub Packages. Reemplace PROPIETARIO por el nombre de la cuenta personal u organización a la que pertenece el repositorio, REPOSITORIO por el nombre de repositorio que contiene su proyecto, NOMBRE_DE_IMAGEN por el nombre del paquete o imagen,NOMBRE DEL HOST por el nombre del host de tu instancia de GitHub Enterprise Server, y NOMBRE_DE_ETIQUETA por la etiqueta de la imagen que quiere instalar.
Si en la instancia se ha habilitado el aislamiento de subdominios:
docker pull docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:TAG_NAME
Si en la instancia se ha deshabilitado el aislamiento de subdominios:
docker pull HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:TAG_NAME
Note
Debes incorporar los cambios de la imagen con IMAGE_NAME:VERSION
en lugar de con IMAGE_NAME:SHA
.