{"meta":{"title":"Trabajar con el registro de contenedores","intro":"Puede almacenar y administrar imágenes de Docker y OCI en Container registry.","product":"GitHub Packages","breadcrumbs":[{"href":"/es/packages","title":"GitHub Packages"},{"href":"/es/packages/working-with-a-github-packages-registry","title":"Trabajar con un registro de Paquetes de GitHub"},{"href":"/es/packages/working-with-a-github-packages-registry/working-with-the-container-registry","title":"Registro de contenedor"}],"documentType":"article"},"body":"# Trabajar con el registro de contenedores\n\nPuede almacenar y administrar imágenes de Docker y OCI en Container registry.\n\n## Acerca de Container registry\n\nEl Container registry almacena imágenes de contenedor dentro de tu organización o cuenta personal y te permite asociar una imagen a un repositorio. Puedes elegir si quieres heredar permisos desde un repositorio o si quieres configurar permisos granulares independientemente de un repositorio. También puedes acceder a imágenes de contenedor públicas de forma anónima.\n\n## Acerca del Container registry soporte técnico\n\nContainer registry Actualmente admite los siguientes formatos de imagen de contenedor:\n\n* [Docker Image Manifest V2, modelo 2](https://docs.docker.com/registry/spec/manifest-v2-2/)\n* [Especificaciones de Open Container Initiative (OCI)](https://github.com/opencontainers/image-spec)\n\nAl instalar o publicar una imagen de Docker, Container registry admite capas externas, como las imágenes de Windows.\n\n## Autenticarse en Container registry\n\n> \\[!NOTE]\n> GitHub Packages solo admite la autenticación usando un personal access token (classic). Para más información, consulta [Administración de tokens de acceso personal](/es/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).\n\nNecesitas un token de acceso para publicar, instalar y eliminar paquetes privados, internos y públicos.\n\nPuedes utilizar un personal access token (classic) para autenticarte en el GitHub Packages o en la API de GitHub. 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](/es/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries).\n\nPara autenticarte en un registro del GitHub Packages dentro de un flujo de trabajo de GitHub Actions, puedes utilizar:\n\n* `GITHUB_TOKEN` para publicar los paquetes asociados con el repositorio del flujo de trabajo.\n* Un personal access token (classic) con al menos alcance `read:packages` para instalar los paquetes asociados con otros repositorios privados (`GITHUB_TOKEN` puede utilizarse si el repositorio tiene acceso de lectura al paquete. Consulta [Configurar la visibilidad y el control de accesos de un paquete](/es/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility)).\n\n### Autenticación en un GitHub Actions flujo de trabajo\n\nEste registro admite permisos granulares. En los registros que admiten permisos granulares, si tu flujo de trabajo GitHub Actions usa un personal access token para autenticarse en un registro, te recomendamos encarecidamente que actualices tu flujo de trabajo para usar `GITHUB_TOKEN`. Para obtener instrucciones sobre cómo actualizar los flujos de trabajo que se autentican en un registro con personal access token, consulte [Publicar e instalar un paquete con Acciones de GitHub](/es/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions#upgrading-a-workflow-that-accesses-a-registry-using-a-personal-access-token).\n\n> \\[!NOTE]\n> La capacidad de que los flujos de trabajo de GitHub Actions eliminen y restauren paquetes mediante la API de REST se encuentra actualmente en versión preliminar pública y está sujeta a cambios.\n\nPuede usar un `GITHUB_TOKEN` en un flujo de trabajo de GitHub Actions para eliminar o restaurar un paquete mediante la API de REST, si el token tiene permiso de `admin` para el paquete. A los repositorios que publican paquetes mediante un flujo de trabajo y a los repositorios que se han conectado explícitamente a los paquetes se les concede automáticamente el permiso `admin` para los paquetes del repositorio.\n\nPara obtener más información sobre `GITHUB_TOKEN`, consulta [Uso de GITHUB\\_TOKEN para la autenticación en flujos de trabajo](/es/actions/tutorials/authenticate-with-github_token#using-the-github_token-in-a-workflow). Para obtener más información sobre los procedimientos recomendados al usar un registro en acciones, consulta [Ejecutores en peligro](/es/actions/concepts/security/compromised-runners#cross-repository-access).\n\nTambién puede optar por conceder permisos de acceso a los paquetes de forma independiente paraGitHub Codespaces yGitHub Actions . Para más información, consulta [Configurar la visibilidad y el control de accesos de un paquete](/es/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-github-codespaces-access-to-your-package) y [Configurar la visibilidad y el control de accesos de un paquete](/es/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-workflow-access-to-your-package).\n\n### Autenticación con personal access token (classic)\n\n> \\[!NOTE]\n> GitHub Packages solo admite la autenticación usando un personal access token (classic). Para más información, consulta [Administración de tokens de acceso personal](/es/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).\n\n1. Cree un nuevo personal access token (classic) con los ámbitos adecuados para las tareas que desea realizar. Si tu organización requiere SSO, debes habilitar SSO para tu nuevo token.\n\n   > \\[!NOTE]\n   > Por defecto, cuando seleccionas el ámbito `write:packages` para tu personal access token (classic) en la interfaz de usuario, también se seleccionará el ámbito `repo`. El ámbito `repo` ofrece un acceso innecesario y demasiado amplio, por lo que te recomendamos que evites utilizarlo, especialmente para los flujos de trabajo de GitHub Actions. Para más información, consulta [Ejecutores en peligro](/es/actions/concepts/security/compromised-runners#cross-repository-access). Como solución alternativa, puedes seleccionar solo el ámbito `write:packages` para tu personal access token (classic) en la interfaz de usuario con esta URL: `https://github.com/settings/tokens/new?scopes=write:packages`.\n\n   * Selecciona el ámbito `read:packages` para descargar imágenes de contenedor y leer sus metadatos.\n   * Selecciona el ámbito `write:packages` para descargar y cargar imágenes de contenedor, así como para leer y escribir sus metadatos.\n   * Selecciona el ámbito `delete:packages` para eliminar imágenes de contenedor.\n\n   Para más información, consulta [Administración de tokens de acceso personal](/es/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).\n\n2. Guarda tu personal access token (classic). Te recomendamos guardar tu token como una variable de entorno.\n\n   ```shell\n   export CR_PAT=YOUR_TOKEN\n   ```\n\n3. Con la CLI correspondiente a su tipo de contenedor, inicie sesión en el servicio Container registry en `ghcr.io`.\n\n   ```shell\n   $ echo $CR_PAT | docker login ghcr.io -u USERNAME --password-stdin\n   > Login Succeeded\n   ```\n\n## Subir imágenes de contenedor\n\nEn este ejemplo se envía la versión más reciente de `IMAGE_NAME`.\n\n```shell\ndocker push ghcr.io/NAMESPACE/IMAGE_NAME:latest\n```\n\nReemplaza `NAMESPACE` por el nombre de la cuenta personal u organización a la que deseas designar un ámbito de imagen.\n\nEn este ejemplo se transfiere la versión `2.5` de la imagen.\n\n```shell\ndocker push ghcr.io/NAMESPACE/IMAGE_NAME:2.5\n```\n\nCuando publicas un paquete por primera vez, la visibilidad predeterminada es privada. Para cambiar la visibilidad o establecer permisos de acceso, consulta [Configurar la visibilidad y el control de accesos de un paquete](/es/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility). Puede vincular un paquete publicado a un repositorio mediante la interfaz de usuario o la línea de comandos. Para más información, consulta [Conectar un repositorio a un paquete](/es/packages/learn-github-packages/connecting-a-repository-to-a-package).\n\nAl insertar una imagen de contenedor desde la línea de comandos, la imagen no está vinculada a un repositorio de forma predeterminada. Este es el caso aunque etiquetes la imagen con un espacio de nombres que coincida con el nombre del repositorio, como `ghcr.io/octocat/my-repo:latest`.\n\nLa manera más sencilla de conectar un repositorio a un paquete de contenedor es publicar el paquete desde un flujo de trabajo mediante `${{secrets.GITHUB_TOKEN}}`, ya que el repositorio que contiene dicho flujo de trabajo se vincula automáticamente. Ten en cuenta que `GITHUB_TOKEN` no tendrá permiso para insertar el paquete si previamente has insertado un paquete en el mismo espacio de nombres, pero no has conectado dicho paquete al repositorio.\n\nPara conectar un repositorio al publicar una imagen desde la línea de comandos y para asegurarse de que `GITHUB_TOKEN` tiene los permisos adecuados al usar un flujo de trabajo de Acciones de GitHub, se recomienda agregar la etiqueta `org.opencontainers.image.source` a `Dockerfile`. Para obtener más información, consulta \"[Etiquetado de imágenes de contenedor](#labelling-container-images)\" en este artículo y \"[Publicar e instalar un paquete con Acciones de GitHub](/es/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions)\".\n\n## Extraer imágenes de contenedor\n\n### Extraer por resumen\n\nPara garantizar que siempre use la misma imagen, puede especificar la versión exacta de la imagen de contenedor que desea obtener utilizando el valor SHA de `digest`.\n\n1. Para buscar el valor de digest SHA, use `docker inspect` o `docker pull` y copie el valor de SHA después de `Digest:`.\n\n   ```shell\n   docker inspect ghcr.io/NAMESPACE/IMAGE_NAME\n   ```\n\n   Reemplaza `NAMESPACE` por el nombre de la cuenta personal u organización a la que se designa un ámbito de imagen.\n\n2. Elimina la imagen localmente de acuerdo a tus necesidades.\n\n   ```shell\n   docker rmi ghcr.io/NAMESPACE/IMAGE_NAME:latest\n   ```\n\n3. Extraiga la imagen de contenedor con `@YOUR_SHA_VALUE` después del nombre de la imagen.\n\n   ```shell\n   docker pull ghcr.io/NAMESPACE/IMAGE_NAME@sha256:82jf9a84u29hiasldj289498uhois8498hjs29hkuhs\n   ```\n\n### Extraer por nombre\n\n```shell\ndocker pull ghcr.io/NAMESPACE/IMAGE_NAME\n```\n\nReemplaza `NAMESPACE` por el nombre de la cuenta personal u organización a la que se designa un ámbito de imagen.\n\n### Extraer por nombre y versión\n\nEjemplo de CLI de Docker que muestra una imagen que se extrae por su nombre y por la etiqueta de la versión `1.14.1`:\n\n```shell\n$ docker pull ghcr.io/NAMESPACE/IMAGE_NAME:1.14.1\n> 5e35bd43cf78: Pull complete\n> 0c48c2209aab: Pull complete\n> fd45dd1aad5a: Pull complete\n> db6eb50c2d36: Pull complete\n> Digest: sha256:ae3b135f133155b3824d8b1f62959ff8a72e9cf9e884d88db7895d8544010d8e\n> Status: Downloaded newer image for ghcr.io/NAMESPACE/IMAGE_NAME/release:1.14.1\n> ghcr.io/NAMESPACE/IMAGE_NAME/release:1.14.1\n```\n\nReemplaza `NAMESPACE` por el nombre de la cuenta personal u organización a la que se designa un ámbito de imagen.\n\n### Extraer por nombre y última versión\n\n```shell\n$ docker pull ghcr.io/NAMESPACE/IMAGE_NAME:latest\n> latest: Pulling from NAMESPACE/IMAGE_NAME\n> Digest: sha256:b3d3e366b55f9a54599220198b3db5da8f53592acbbb7dc7e4e9878762fc5344\n> Status: Downloaded newer image for ghcr.io/NAMESPACE/IMAGE_NAME:latest\n> ghcr.io/NAMESPACE/IMAGE_NAME:latest\n```\n\nReemplaza `NAMESPACE` por el nombre de la cuenta personal u organización a la que se designa un ámbito de imagen.\n\n## Creación de imágenes de contenedor\n\nEn este ejemplo se compila la imagen `hello_docker`:\n\n```shell\ndocker build -t hello_docker .\n```\n\n## Etiquetado de imágenes de contenedores\n\n1. Encuentra la ID para la imagen de Docker que quieres etiquetar.\n\n   ```shell\n   $ docker images\n   > REPOSITORY                                            TAG                 IMAGE ID            CREATED             SIZE\n   > ghcr.io/my-org/hello_docker         latest            38f737a91f39        47 hours ago        91.7MB\n   > hello-world                                           latest              fce289e99eb9        16 months ago       1.84kB\n   ```\n\n2. Etiqueta tu imagen de Docker utilizando la ID ed imagen y el nombre que quieras poner a la misma, así como el destino en donde se hospedará ésta.\n\n   ```shell\n   docker tag 38f737a91f39 ghcr.io/NAMESPACE/NEW_IMAGE_NAME:latest\n   ```\n\nReemplaza `NAMESPACE` por el nombre de la cuenta personal u organización a la que deseas designar un ámbito de imagen.\n\n## Etiquetado de imágenes de contenedor\n\nPuedes usar etiquetas claves de anotación predefinidas para agregar metadatos, incluida una descripción, una licencia y un repositorio de origen a la imagen de contenedor. Los valores de las claves admitidas aparecerán en la página del paquete de la imagen.\n\nPara la mayoría de las imágenes, puedes usar etiquetas de Docker para agregar las claves de anotación a una imagen. Para obtener más información, consulta [ETIQUETA](https://docs.docker.com/engine/reference/builder/#label) en la documentación oficial de Docker y [Claves de anotación predefinidas](https://github.com/opencontainers/image-spec/blob/main/annotations.md#pre-defined-annotation-keys) en el repositorio de `opencontainers/image-spec`.\n\nPara las imágenes de varios arcos, puedes agregar una descripción a la imagen agregando la clave de anotación adecuada al campo `annotations` en el manifiesto de la imagen. Para obtener más información, consulte [Agregar una descripción a imágenes de múltiples arquitecturas](#adding-a-description-to-multi-arch-images).\n\nLas siguientes claves de anotación son compatibles con Container registry.\n\n| Clave                                  | Descripción                                                                                                                                                                                                                                                            |\n| -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `org.opencontainers.image.source`      | Dirección URL del repositorio asociado al paquete. Para más información, consulta [Conectar un repositorio a un paquete](/es/packages/learn-github-packages/connecting-a-repository-to-a-package#connecting-a-repository-to-a-container-image-using-the-command-line). |\n| `org.opencontainers.image.description` | Una descripción de solo texto limitada a 512 caracteres. Esta descripción aparecerá en la página del paquete, debajo del nombre del paquete.                                                                                                                           |\n| `org.opencontainers.image.licenses`    | Un identificador de licencia SPDX, como \"MIT\", limitado a 256 caracteres. La licencia aparecerá en la página del paquete, en la barra lateral \"Detalles\". Para más información, consulta [Lista de licencias de SPDX](https://spdx.org/licenses/).                     |\n\nPara agregar una clave como etiqueta de Docker, se recomienda usar la instrucción `LABEL` en tu `Dockerfile`. Por ejemplo, si eres el usuario `octocat` y eres el propietario de `my-repo` y la imagen se distribuye bajo los términos de la licencia MIT, agregarías las líneas siguientes a `Dockerfile`:\n\n```dockerfile\nLABEL org.opencontainers.image.source=https://github.com/octocat/my-repo\nLABEL org.opencontainers.image.description=\"My container image\"\nLABEL org.opencontainers.image.licenses=MIT\n```\n\n> \\[!NOTE]\n> Si publicas un paquete vinculado a un repositorio, el paquete hereda automáticamente los permisos de acceso del repositorio vinculado y los flujos de trabajo de GitHub Actions en el repositorio vinculado automáticamente obtienen acceso al paquete, a menos que la organización haya deshabilitado la herencia automática de los permisos de acceso. Para más información, consulta [Configurar la visibilidad y el control de accesos de un paquete](/es/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#about-inheritance-of-access-permissions).\n\nComo alternativa, puedes agregar etiquetas a una imagen en tiempo de compilación con el comando `docker build`.\n\n```shell\n$ docker build \\\n --label \"org.opencontainers.image.source=https://github.com/octocat/my-repo\" \\\n --label \"org.opencontainers.image.description=My container image\" \\\n --label \"org.opencontainers.image.licenses=MIT\"\n```\n\n### Adición de una descripción a imágenes de varios arcos\n\nUna imagen de varios arcos es una imagen que admite varias arquitecturas. Funciona haciendo referencia a una lista de imágenes, cada una de las cuales admite una arquitectura diferente, dentro de un único manifiesto.\n\nLa descripción que aparece en la página del paquete para una imagen de varios arcos se obtiene del campo `annotations` del manifiesto de la imagen. Al igual que las etiquetas de Docker, las anotaciones proporcionan una manera de asociar metadatos a una imagen y admiten claves de anotación predefinidas. Para más información, consulta [Anotaciones](https://github.com/opencontainers/image-spec/blob/main/annotations.md) en el repositorio `opencontainers/image-spec`.\n\nPara proporcionar una descripción para una imagen de varios arcos, establece un valor para la clave `org.opencontainers.image.description` en el campo del manifiesto `annotations`, como se indica a continuación.\n\n```json\n\"annotations\": {\n  \"org.opencontainers.image.description\": \"My multi-arch image\"\n}\n```\n\nPor ejemplo, el siguiente GitHub Actions paso de flujo de trabajo crea e inserta una imagen de varios arcos. El parámetro `outputs` establece la descripción de la imagen.\n\n```yaml\n# Este flujo de trabajo usa acciones que no GitHub no certifica.\n# Estas las proporcionan entidades terceras y las gobiernan\n# condiciones de servicio, políticas de privacidad y documentación de soporte\n# en línea.\n\n- name: Build and push Docker image\n  uses: docker/build-push-action@f2a1d5e99d037542a71f64918e516c093c6f3fc4\n  with:\n    context: .\n    file: ./Dockerfile\n    platforms: ${{ matrix.platforms }}\n    push: true\n    outputs: type=image,name=target,annotation-index.org.opencontainers.image.description=My multi-arch image\n```\n\n## Solución de problemas\n\n* Container registry tiene un límite de tamaño de 10 GB para cada capa.\n* Container registry tiene un límite de tiempo de espera de 10 minutos para las cargas."}