Los repositorios virtuales de Artifact Registry te permiten acceder a artefactos del mismo formato en varios repositorios upstream a través de un solo extremo. Los repositorios virtuales pueden simplificar la configuración del cliente, habilitar una resolución de dependencias más segura y ayudar a evitar ataques de confusión de dependencias.
Para obtener instrucciones sobre cómo crear un repositorio virtual, consulta Crea repositorios virtuales. Las cuotas y los límites de Artifact Registry se aplican a los repositorios virtuales.
Cómo funcionan los repositorios virtuales
Los repositorios virtuales actúan como un único punto de acceso para descargar, instalar o implementar artefactos en el mismo formato desde uno o más repositorios upstream. Un repositorio upstream puede ser un repositorio estándar o remoto de Artifact Registry.
Casos de uso y beneficios
- Configuración de cliente más simple
Para las tareas que solo requieren acceso de lectura a los repositorios, solo necesitas configurar un único repositorio de Artifact Registry para acceder a los artefactos almacenados en varios repositorios upstream.
Por ejemplo:
- Un repositorio virtual para paquetes de Maven puede entregar paquetes privados de Java desde un repositorio estándar de Artifact Registry y paquetes públicos de Java desde un repositorio remoto que almacena en caché paquetes públicos de Maven Central.
- Un repositorio virtual puede entregar paquetes privados de Python desde varios repositorios estándar upstream que pertenecen a diferentes equipos. Cada equipo tiene acceso de escritura a su repositorio upstream, pero descarga paquetes de otros equipos con el repositorio virtual.
- Resolución de dependencias más segura
Puedes asignar una prioridad a los repositorios upstream para tener más control sobre qué repositorio elige Artifact Registry cuando un artefacto solicitado está en más de un repositorio upstream.
Algunas herramientas, como la herramienta
pipde Python, no proporcionan una forma de controlar el orden de búsqueda cuando se configura una combinación de repositorios privados y públicos en el cliente. Este tipo de configuración es vulnerable a un ataque de confusión de dependencias, en el que alguien sube una versión nueva de un paquete con código incorrecto a un repositorio público para engañar a los clientes para que elijan la versión incorrecta.Puedes usar repositorios remotos y virtuales juntos para mitigar este riesgo:
- Crea un repositorio remoto como proxy para el repositorio público.
- Crea un repositorio estándar para tus paquetes privados.
- Crea un repositorio virtual configurado para priorizar tu repositorio estándar si existe una versión del mismo paquete en ambos repositorios.
- Configura los administradores de paquetes y otras herramientas para que lean solo desde el repositorio virtual, de modo que la lógica del cliente no esté involucrada en la selección del repositorio.
Para obtener información sobre otras prácticas recomendadas de administración de dependencias, consulta Administración de dependencias.
Cómo los repositorios virtuales seleccionan un repositorio upstream
Cada repositorio upstream debe tener una prioridad configurada. La prioridad es un número entero que actúa como un peso, no como una clasificación. Esto significa que los repositorios con un valor de prioridad numérica más alto tienen prioridad sobre los repositorios con valores de prioridad más bajos.
Cuando solicitas un artefacto que está en varios repositorios upstream, Artifact Registry usa la siguiente lógica de priorización:
- Se prioriza el repositorio con el valor más alto. Por ejemplo, un valor de
10se trata como de mayor prioridad que un valor de1. - Si varios repositorios upstream tienen la misma prioridad, el artefacto se puede entregar desde cualquiera de esos repositorios.
También te recomendamos que incluyas la versión del artefacto en tu solicitud. De esta manera, el cliente muestra el repositorio upstream de mayor prioridad que contiene la versión del artefacto solicitada. Si no especificas la versión del artefacto, el cliente puede mostrar la versión más reciente del artefacto, independientemente de la prioridad del repositorio.
Cuando configuras directamente un cliente para buscar un repositorio virtual y repositorios adicionales, el cliente aún puede descargar artefactos de repositorios fuera de Artifact Registry.Por ejemplo, si configuras la herramienta pip de Python para buscar PyPI y un repositorio virtual, es posible que tu paquete se descargue directamente desde PyPI porque pip siempre elegirá la versión más reciente de un paquete, independientemente del repositorio del que provenga. Si pip está configurado para buscar solo en el repositorio virtual, puedes controlar la prioridad de todos los repositorios upstream, incluido un repositorio remoto upstream que actúa como proxy para PyPI.
Formatos de repositorio admitidos
Puedes crear repositorios virtuales para los siguientes formatos de repositorio de Artifact Registry:
Paquetes de lenguaje:
Paquetes de SO:
Si no tienes experiencia en Artifact Registry, puedes usar las guías de inicio rápido para obtener información sobre cómo configurar repositorios estándar para estos formatos.
Limitaciones
Además de las cuotas y limitaciones de Artifact Registry, los repositorios virtuales tienen las siguientes limitaciones:
- Debido a que los repositorios virtuales no almacenan datos, aparecerán vacíos cuando
se ejecute
gcloud artifacts docker images listy cuando se vea el repositorio en la Google Cloud consola. - Los repositorios upstream estándar de Artifact Registry deben estar en la misma región o multirregión que el repositorio virtual, pero pueden estar en diferentes Google Cloud proyectos.
Los repositorios virtuales de Maven no permiten configurar la política de versiones en instantánea o lanzamiento.
Los repositorios upstream de Apt y Yum deben ser repositorios estándar de Artifact Registry.
Los repositorios estándar de Apt y Yum actualizan el índice de paquetes de forma asíncrona después de que se importa, sube o borra un paquete. En el caso de los repositorios pequeños, la regeneración del índice puede tardar varios segundos. En el caso de los repositorios más grandes, la reindexación puede tardar varios minutos o más. Una vez que se completa la reindexación, el cambio en el repositorio es visible para los clientes de Apt y Yum.
Otros modos de repositorio
Los otros modos de repositorio son los siguientes:
- Estándar: Es el modo de repositorio predeterminado. Subes o publicas artefactos, como paquetes privados, directamente en repositorios estándar. Aunque puedes descargar directamente desde repositorios estándar individuales, acceder a grupos de repositorios con un repositorio virtual simplifica la configuración de la herramienta.
- Remoto: Es un repositorio que actúa como proxy para una fuente upstream mediante el almacenamiento en caché de paquetes en Artifact Registry después de que se descargan de la fuente upstream por primera vez. Cuando vuelvas a solicitar la misma versión del paquete, Artifact Registry proporcionará la copia almacenada en caché.
- Conector (vista previa): Es un repositorio que actúa como proxy para una fuente upstream, pero no almacena en caché artefactos en Artifact Registry. En cambio, todas las solicitudes se realizan a la fuente upstream. Los repositorios de conectores son útiles si necesitas una capacidad de auditoría completa de tu fuente upstream o tienes políticas que impiden el almacenamiento en caché de artefactos.
¿Qué sigue?
- Crea repositorios virtuales.
- Obtén más información sobre los repositorios de Artifact Registry leyendo la Descripción general de los repositorios.