Descripción general del repositorio

Artifact Registry te permite almacenar diferentes tipos de artefactos, crear varios repositorios en un solo proyecto y asociar una ubicación regional o multirregional específica a cada repositorio. En esta página, se describen las consideraciones que te ayudarán a planificar las ubicaciones y la organización de los repositorios.

Cuando crees tus repositorios, considera tanto procesos internos para crear los artefactos como el uso que realizan los consumidores de tus artefactos.

Formatos de repositorio

Cada repositorio está asociado con un formato de artefacto específico . Por ejemplo, un repositorio de Docker almacena imágenes de Docker. Puedes crear varios repositorios para cada formato en el mismo Google Cloud proyecto.

Modos de repositorio

Existen varios modos de repositorio. Cada modo tiene un propósito diferente, por lo que no puedes cambiar el modo de repositorio después de crear uno.

Repositorio estándar

Los repositorios estándar son repositorios normales de Artifact Registry para tus artefactos privados. Puedes subir y descargar artefactos directamente con estos repositorios y usar Artifact Analysis para buscar vulnerabilidades y otros metadatos.

Para crear repositorios estándar, sigue los pasos que se indican en Crea repositorios estándar.

Repositorio remoto

Los repositorios remotos son repositorios de solo lectura que actúan como proxies para almacenar artefactos de las siguientes fuentes upstream:

  • Repositorios estándar de Artifact Registry
  • Fuentes externas, como Docker Hub, Maven Central, Python Package Index (PyPI), Debian o CentOS

La primera vez que solicitas una versión de artefacto, el repositorio la descarga de la fuente upstream y almacena en caché una copia. El repositorio remoto entrega la copia almacenada en caché cuando se solicita la misma versión nuevamente.

Los repositorios remotos reducen la latencia y mejoran la disponibilidad para las compilaciones y las implementaciones en Google Cloud. También puedes usar Artifact Analysis para buscar vulnerabilidades y otros metadatos en los paquetes almacenados en caché.

Para obtener más información sobre los repositorios remotos, consulta Descripción general de los repositorios remotos. Para crear repositorios remotos, sigue los pasos que se indican en Crea repositorios remotos.

Repositorio de conector (vista previa)

Los repositorios de conectores actúan como proxies para las fuentes upstream y, al mismo tiempo, ayudan a garantizar que la fuente upstream controle todas las solicitudes. A diferencia de los repositorios remotos, los repositorios de conectores no almacenan artefactos en caché. Como resultado, los repositorios de conectores son útiles si necesitas una capacidad de auditoría completa de las fuentes upstream o si debes cumplir con las políticas de terceros que impiden el almacenamiento en caché de artefactos.

Para obtener más información sobre los repositorios de conectores, consulta Descripción general de los repositorios de conectores. Para crear repositorios de conectores, sigue los pasos que se indican en Crea repositorios de conectores.

Repositorio virtual

Un repositorio de solo lectura que actúa como un único punto de acceso para descargar, instalar o implementar artefactos del mismo formato desde uno o más repositorios upstream. Un repositorio upstream puede ser un repositorio estándar, remoto o virtual.

Los repositorios virtuales simplifican la configuración del cliente para los consumidores de tus artefactos. También puedes mitigar los ataques de confusión de dependencias si configuras tu política upstream para priorizar los repositorios con tus artefactos privados sobre los repositorios remotos que almacenan artefactos públicos en caché.

Para obtener más información sobre los repositorios virtuales, consulta Descripción general de los repositorios virtuales. Para crear repositorios virtuales, sigue los pasos que se indican en Crea repositorios virtuales.

Ejemplo de uso del repositorio

En el siguiente diagrama, se muestra una de las muchas formas en que puedes usar repositorios en diferentes modos juntos. El diagrama muestra un flujo de trabajo en dos Google Cloud proyectos. En un proyecto de desarrollo, los desarrolladores crean una aplicación de Java. En un proyecto de entorno de ejecución independiente, otra compilación crea una imagen de contenedor con la app para la implementación en Google Kubernetes Engine.

Repositorios estándar, virtuales y remotos que se usan en dos proyectos.

  1. En el proyecto de desarrollo, un equipo de desarrollo de Java usa Cloud Build para crear una aplicación de Java.

    • La compilación puede solicitar dependencias públicas de Java con el repositorio virtual. El repositorio virtual entrega las dependencias del repositorio remoto, que es un proxy de almacenamiento en caché para Maven Central.
    • Cloud Build sube el paquete al repositorio estándar de Maven en el proyecto de componente.

  2. En el proyecto de entorno de ejecución, Cloud Build coloca la aplicación de Java en contenedores.

    La compilación usa el repositorio virtual de Maven para descargar la aplicación. El repositorio virtual entrega el paquete del repositorio estándar en el proyecto de desarrollo. La compilación también puede descargar dependencias públicas de Java del mismo repositorio virtual.

  3. En el proyecto de entorno de ejecución, Cloud Build sube la imagen de contenedor compilada a un repositorio estándar de Docker.

  4. GKE extrae imágenes del repositorio virtual de Docker.

    • El repositorio estándar upstream proporciona imágenes privadas, como la aplicación de Java en contenedores.
    • El repositorio remoto upstream proporciona imágenes que GKE solicita a Docker Hub.

En este ejemplo, todos los repositorios, las compilaciones y los clústeres de GKE están en la misma región. Usar la misma ubicación para los Google Cloud servicios tiene beneficios que se describen en Ubicación del repositorio.

Ubicación del repositorio

Puedes crear uno o más repositorios en una región o multirregión admitida. Una buena ubicación de repositorio balancea los costos de latencia, disponibilidad y ancho de banda para los consumidores de datos. Es posible que tu organización también tenga requisitos de cumplimiento específicos.

Consideraciones de ubicación

En esta sección, se describe por qué te conviene crear un repositorio en la misma región que otros Google Cloud servicios.

Puedes reducir la latencia y los costos de salida de la red si creas repositorios en la misma región en la que ejecutas GKE, Cloud Run, Cloud Build y otros Google Cloud servicios que interactúan con el repositorio. No se aplican cargos por la salida de Artifact Registry a otros Google Cloud servicios en la misma región.

Aunque no se aplican cargos por la salida de una multirregión a un Google Cloud servicio en una región correspondiente, esta tarifa solo se aplica a un conjunto limitado de regiones.

  • Para la multirregión us, no se cobra la salida a una región de Estados Unidos, como us-central, pero sí se cobra a cualquier región de Canadá o América del Sur.
  • Para la multirregión asia, no se cobra la salida a regiones de Asia, como asia-northeast1, pero sí se cobra la salida a regiones de Australia.
Solo puedes usar la transmisión de imágenes en GKE y Managed Service para Apache Spark si tus imágenes de contenedor se almacenan en repositorios de Artifact Registry en la misma región que tus cargas de trabajo o en una multirregión que corresponda a la región con tus cargas de trabajo. La transmisión de imágenes puede reducir significativamente el tiempo de inicialización de la carga de trabajo cuando usas imágenes de contenedor más grandes, ya que las cargas de trabajo pueden comenzar antes de que se descargue toda la imagen.

Ten en cuenta la ubicación de los consumidores fuera de Google Cloud. Por ejemplo, si tu equipo de desarrolladores en Australia necesita descargar artefactos de Artifact Registry a sus estaciones de trabajo locales, un repositorio en una región australiana reducirá la latencia y generará cargos de salida más bajos que un repositorio ubicado en otro continente.

Restringe las ubicaciones de los repositorios

Si necesitas cumplir con reglamentaciones o políticas que requieren que almacenes datos en regiones específicas, puedes incluir una restricción de ubicaciones de recursos en tu Google Cloud política de la organización que solo permita la creación de repositorios en regiones compatibles. Artifact Registry solo aplica la restricción después de que la incluyes en tu política de la organización. Si tienes repositorios existentes en ubicaciones no compatibles, debes mover tus artefactos a un repositorio en una ubicación compatible y, luego, borrar el repositorio no compatible.

Políticas de limpieza

Una política de limpieza de Artifact Registry define criterios para borrar automáticamente las versiones de artefactos que ya no necesitas o conservar los artefactos que deseas almacenar de forma indefinida.

Las políticas de limpieza son útiles si almacenas muchas versiones de tus artefactos, pero solo necesitas conservar versiones específicas que lanzas a producción. Puedes definir políticas de borrado con criterios para borrar artefactos y políticas de conservación con criterios para retener artefactos.

Si una versión de artefacto coincide con los criterios de una política de borrado y una política de conservación, Artifact Registry aplica la política de conservación.

Usa políticas de borrado

Las políticas de borrado borran los artefactos que coinciden con los siguientes criterios obligatorios:

  • Estado de etiqueta: Indica si la política debe verificar los artefactos etiquetados o no etiquetados. Los artefactos se etiquetan cuando se envía o se extrae una imagen a un repositorio o desde él. Para obtener más información sobre las etiquetas de Docker, consulta Conceptos de contenedores.

    • Cualquier estado de etiqueta: Ignora el estado de la etiqueta y se aplica a los artefactos etiquetados y no etiquetados.
    • Etiquetado: Solo se aplica a los artefactos etiquetados.
    • Sin etiqueta: Solo se aplica a los artefactos no etiquetados.

    Los formatos que no admiten etiquetas se tratan como untagged. No se pueden borrar los artefactos etiquetados en repositorios con etiquetas inmutables habilitadas.

    Para obtener más información sobre el estado de la etiqueta en lo que respecta a las políticas de limpieza, consulta la referencia de TagState.

Puedes usar cualquiera de los siguientes parámetros para configurar tu política de borrado:

  • Prefijos de etiqueta: Es una lista de prefijos de etiqueta separados por comas. Por ejemplo, los prefijos test y staging coincidirían con las imágenes con las etiquetas testenv y staging-1.5. tagState debe establecerse en TAGGED para usar prefijos de etiqueta.
    • Prefijos de versión: Es una lista de prefijos de versión de artefacto separados por comas. Por ejemplo, v1, v2 coincidirían con las versiones v1.5, v2.0alpha y v10.2.
  • Prefijos de paquete: Es una lista de prefijos de nombres de artefactos. Puedes ingresar varios prefijos presionando Enter o , entre los prefijos. Por ejemplo, red, blue crearía dos prefijos, red y blue, y coincidiría con los nombres de artefactos red-team, redis, y bluebird.
  • Más antiguo que: Es un tiempo mínimo desde que se subió una versión de artefacto al repositorio, especificado como una duración. Por ejemplo, 30d son 30 días. Puedes especificar duraciones de segundos, minutos, horas o días agregando s, m, h o d, respectivamente.
  • Más reciente que: Es un tiempo máximo desde que se subió una versión de artefacto al repositorio, especificado como una duración. Por ejemplo, 30d son 30 días.

Usa políticas de conservación

Las políticas de conservación conservan los artefactos que coinciden con las mismas condiciones que las políticas de borrado o una cantidad determinada de versiones más recientes.

Por ejemplo, dado un repositorio que contiene los siguientes artefactos:

IMAGE: us-west1-docker.pkg.dev/my-project/release-xyz-v1
DIGEST: sha256:1b0a26bd07a3d17473d8d8468bea84015e27f87124b2831234581bce13f61370
TAGS:
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:10

IMAGE: us-west1-docker.pkg.dev/my-project/release-xyz-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

IMAGE: us-west1-docker.pkg.dev/my-project/release-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

Si tu política Conservar las versiones más recientes está configurada para conservar 3 versiones de paquetes que coincidan con los Prefijos de paquete: {release-xyz}, solo se conservarán release-xyz-v1 y release-xyz-v2.

Los borrados que activan las políticas de borrado se cuentan en tu cuota de solicitudes de borrado por proyecto de Artifact Registry .

Para crear y aplicar políticas de limpieza a tu repositorio, consulta Configura políticas de limpieza.

Compatibilidad con el dominio gcr.io

Artifact Registry admite el alojamiento de imágenes en el dominio gcr.io. Si estás migrando de Container Registry a Artifact Registry, puedes configurar repositorios de gcr.io Artifact Registry para minimizar los cambios en tu automatización y flujos de trabajo existentes. Estos repositorios proporcionan lo siguiente:

  • Redireccionamiento de solicitudes al dominio gcr.io
  • Creación de repositorios de gcr.io cuando se envía la primera imagen a un nombre de host de gcr.io para la compatibilidad con el comportamiento de Container Registry

Para obtener más información, consulta Transición a repositorios con compatibilidad con dominios gcr.io.

Estructura del proyecto

Tu jerarquía de recursos es la forma en que organizas tus recursos en los Google Cloud proyectos. La estructura que elijas depende de factores como los requisitos de administración de datos, los límites de confianza y la estructura del equipo.

Existen dos enfoques generales para configurar tus repositorios en organizaciones de varios proyectos.

Centralizar repositorios

Crea todos los repositorios en un solo proyecto y, luego, otorga acceso a las entidades principales de otros proyectos a nivel del repositorio. Este enfoque puede ser más eficaz cuando una sola persona o equipo administra el repositorio y el acceso al repositorio en toda tu organización.

También puede simplificar la configuración de repositorios virtuales, ya que solo necesitas habilitar y administrar una sola instancia de Artifact Registry.

Repositorios específicos del proyecto

Crea repositorios en proyectos que almacenan y descargan artefactos. Este enfoque puede ser necesario cuando tienes políticas de administración de datos o límites de confianza que requieren más separación a nivel de proyecto y control de los recursos.

Control de acceso

Solo se puede acceder a los repositorios con los permisos adecuados, a menos que los configures para el acceso público. Puedes otorgar permisos a nivel de proyecto o de repositorio.

Algunos Google Cloud servicios usan cuentas de servicio predeterminadas con permisos predeterminados para los repositorios en el mismo Google Cloud proyecto. Sin embargo, es posible que estos valores predeterminados no sean adecuados para tu proceso de desarrollo de software o que no cumplan con los requisitos de la política o de seguridad de tu organización. El administrador del repositorio debe otorgar acceso explícitamente a estos servicios a los repositorios si se cumple alguna de las siguientes condiciones:

  • Artifact Registry está en un proyecto diferente del servicio que interactúa con él.
  • Usas roles personalizados de IAM con las cuentas de servicio predeterminadas en lugar del rol predefinido.
  • No usas la cuenta de servicio predeterminada para el Google Cloud servicio.
  • Estás configurando repositorios virtuales. Debes otorgar acceso explícitamente a la cuenta de servicio de Artifact Registry a los repositorios upstream.

Para otras entidades principales que requieren acceso a los repositorios, el administrador del repositorio debe otorgar acceso. Siguiendo el principio de seguridad de menor privilegio, otorga los permisos mínimos requeridos. Por ejemplo:

  • Implementas imágenes de contenedor en Artifact Registry en clústeres de GKE en varios proyectos diferentes. La cuenta de servicio para los nodos de estos clústeres solo requiere acceso de lectura a los repositorios.
  • Tienes un repositorio de desarrollo para las aplicaciones que están en desarrollo y un repositorio de producción para las aplicaciones que se lanzan. Los desarrolladores requieren acceso de lectura y escritura al repositorio de desarrollo y acceso de solo lectura al repositorio de producción.
  • Tienes un repositorio de demostración con aplicaciones de muestra. Tu equipo de ventas solo requiere acceso de solo lectura para descargar las demostraciones.

Restringe las descargas de artefactos

Puedes restringir las descargas de artefactos con reglas de descarga. Las reglas de descarga te permiten permitir o rechazar las descargas de artefactos de tus repositorios y paquetes. También puedes establecer condiciones para que la regla se aplique a etiquetas o versiones específicas.

Para obtener detalles sobre cómo funcionan las reglas de descarga, consulta la sección Restringe las descargas de artefactos de la descripción general de Controla el acceso y protege los artefactos.

Encriptación de datos

De forma predeterminada, Google Cloud encripta los datos automáticamente cuando están en reposo con claves de encriptación administradas por Google y propiedad de Google con tecnología de . Si tienes requisitos regulatorios o de cumplimiento específicos relacionados con las claves que protegen los datos, puedes crear repositorios encriptados con claves de encriptación administradas por el cliente (CMEK).

Artifact Registry también admite restricciones de políticas de la organización que pueden requerir CMEK para proteger los recursos.

Etiquetas de recurso y de instancia

Las etiquetas proporcionan una forma de organizar los recursos específicos de un Google Cloud servicio. En Artifact Registry, puedes agregar etiquetas a los repositorios para poder agruparlos o filtrar las listas de repositorios por etiqueta. Por ejemplo, puedes usar etiquetas para agrupar repositorios por etapa de desarrollo o por equipo para fines de automatización o facturación. Para obtener más información sobre cómo crear y usar etiquetas de repositorio, consulta Etiqueta repositorios.

También puedes aplicar etiquetas a los repositorios. Si bien las etiquetas son principalmente para organizar y filtrar recursos específicos del servicio, las etiquetas son para el control programático de las políticas en una Google Cloud organización. Para obtener más información, consulta Etiqueta repositorios.

Pasos siguientes