Información general sobre los repositorios

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 algunas consideraciones que te ayudarán a planificar las ubicaciones y la organización de tus repositorios.

Cuando crees tus repositorios, ten en cuenta tanto los procesos internos para crear tus artefactos como el uso que hacen los consumidores de ellos.

Formatos de repositorio

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

Modos de repositorio

Hay varios modos de repositorio. Cada modo tiene un propósito diferente, por lo que no puedes cambiar el modo del repositorio una vez que lo hayas creado.

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 Crear 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, el índice de paquetes de Python (PyPI), Debian o CentOS.

La primera vez que solicitas una versión de un artefacto, el repositorio la descarga de la fuente upstream y almacena en caché una copia. El repositorio remoto proporciona la copia en caché cuando se vuelve a solicitar la misma versión.

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

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

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 varios 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 configurando tu política upstream para priorizar los repositorios con tus artefactos privados sobre los repositorios remotos que almacenan en caché artefactos públicos.

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

Ejemplo de uso del repositorio

En el siguiente diagrama se muestra una de las muchas formas posibles de usar repositorios en diferentes modos. El diagrama muestra un flujo de trabajo en dos proyectosGoogle Cloud . En un proyecto de desarrollo, los desarrolladores crean una aplicación Java. En otro proyecto de tiempo de ejecución, otra compilación crea una imagen de contenedor con la aplicación para desplegarla en Google Kubernetes Engine.

Repositorios estándar, virtuales y remotos usados en dos proyectos.

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

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

  2. En el proyecto de tiempo de ejecución, Cloud Build contenedoriza la aplicación Java.

    La compilación usa el repositorio virtual de Maven para descargar la aplicación. El repositorio virtual sirve 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 tiempo de ejecución, Cloud Build sube la imagen de contenedor compilada a un repositorio de Docker estándar.

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

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

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

Ubicación del repositorio

Puedes crear uno o varios repositorios en una región o multirregión admitida. Una buena ubicación del repositorio equilibra la latencia, la disponibilidad y los costes de 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é puede ser conveniente crear un repositorio en la misma región que otros servicios de Google Cloud .

Puedes reducir la latencia y los costes de salida de red creando 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 cobra por la salida de Artifact Registry a otros servicios de la misma región. Google Cloud

Aunque no se aplican cargos por el tráfico de salida de una multirregión a un servicio de la región correspondiente, estos precios solo se aplican a un conjunto limitado de regiones.Google Cloud

  • En la multirregión us, no se cobra la salida a una región de Estados Unidos, como us-central, pero sí se cobra la salida a cualquier región de Canadá o Sudamérica.
  • En 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 Dataproc Serverless si tus imágenes de contenedor están almacenadas en repositorios de Artifact Registry de la misma región que tus cargas de trabajo o en una multirregión que corresponda a la región de tus cargas de trabajo. El streaming de imágenes puede reducir significativamente el tiempo de inicialización de la carga de trabajo cuando se usan imágenes de contenedor más grandes, ya que las cargas de trabajo pueden iniciarse antes de que se descargue la imagen completa.

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

Restringir ubicaciones de repositorios

Si tienes que cumplir normativas o políticas que te exijan almacenar datos en regiones específicas, puedes incluir una restricción de ubicaciones de recursos en tu política de organización de Google Cloudpara que solo se puedan crear repositorios en las regiones que cumplan los requisitos. Artifact Registry solo aplica la restricción después de que la incluyas en tu política de la organización. Si tienes repositorios en ubicaciones no conformes, debes mover tus artefactos a un repositorio en una ubicación conforme y, a continuación, eliminar el repositorio no conforme.

Políticas de limpieza

Una política de limpieza de Artifact Registry define los criterios para eliminar automáticamente las versiones de artefactos que ya no necesites o para conservar los artefactos que quieras almacenar indefinidamente.

Las políticas de limpieza son útiles si almacenas muchas versiones de tus artefactos, pero solo necesitas conservar versiones específicas que publiques en producción. Puedes definir políticas de eliminación con criterios para eliminar artefactos y políticas de conservación con criterios para conservar artefactos.

Si una versión de un artefacto cumple los criterios de una política de eliminación y de una política de conservación, Artifact Registry aplica la política de conservación.

Eliminar políticas

Las políticas de eliminación eliminan los artefactos que cumplen los siguientes criterios obligatorios:

  • Estado de la etiqueta: indica si la política debe comprobar los artefactos etiquetados o los que no lo están. Los artefactos se etiquetan al enviar o extraer 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 la etiqueta: ignora el estado de la etiqueta y se aplica tanto a los artefactos etiquetados como a los que no lo están.
    • Etiquetado: solo se aplica a los artefactos etiquetados.
    • Sin etiquetar: solo se aplica a los artefactos sin etiquetar.

    Los formatos que no admiten etiquetas se tratan como untagged. Los artefactos etiquetados de los repositorios con etiquetas inmutables habilitadas no se pueden eliminar.

    Para obtener más información sobre el estado de las etiquetas en relación con las políticas de limpieza, consulta la referencia de TagState.

Estas son algunas formas opcionales de definir tu política de eliminación:

  • Prefijos de etiquetas: es una lista separada por comas de prefijos de etiquetas. Por ejemplo, los prefijos test y staging coincidirían con las imágenes que tengan las etiquetas testenv y staging-1.5. Para usar prefijos de etiquetas, el valor de tagState debe ser TAGGED.
    • Prefijos de versión: es una lista separada por comas de prefijos de versión de artefacto. Por ejemplo, v1 y 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 introducir varios prefijos pulsando Enter o , entre ellos. 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 el tiempo mínimo transcurrido desde que se subió una versión del artefacto al repositorio. Se especifica como un periodo. Por ejemplo, 30d es de 30 días. Puedes especificar duraciones en segundos, minutos, horas o días añadiendo s, m, h o d respectivamente.
  • Más reciente que: es el tiempo máximo transcurrido desde que se subió una versión del artefacto al repositorio, especificado como duración. Por ejemplo, 30d es de 30 días.

Mantener las políticas

Las políticas de conservación conservan los artefactos que cumplen las mismas condiciones que las políticas de eliminación o un número determinado de las versiones más recientes.

Por ejemplo, supongamos que tienes 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 la política Conservar las versiones más recientes está configurada para conservar 3 versiones de los paquetes que coincidan con los prefijos de paquete: {release-xyz}, solo se conservarán release-xyz-v1 y release-xyz-v2.

Las eliminaciones activadas por las políticas de eliminación se contabilizan en la cuota de solicitudes de eliminación por proyecto de Artifact Registry.

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

Compatibilidad con el dominio gcr.io

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

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

Para obtener más información, consulta Migrar a repositorios compatibles con el dominio gcr.io.

Estructura del proyecto

La jerarquía de recursos es la forma de organizar los recursos en los Google Cloud proyectos. La estructura que elijas dependerá de factores como los requisitos de gobernanza de datos, los límites de confianza y la estructura del equipo.

Hay dos enfoques generales para configurar tus repositorios en organizaciones con varios proyectos.

Centralizar repositorios
Crea todos los repositorios en un solo proyecto y, a continuación, concede acceso a las entidades de otros proyectos a nivel de repositorio. Este enfoque puede ser más eficaz cuando una sola persona o un equipo gestiona la administración y el acceso a los repositorios de toda la organización.
También puede simplificar la configuración de repositorios virtuales, ya que solo tienes que habilitar y gestionar una única instancia de Artifact Registry.
Repositorios específicos de proyectos
Crea repositorios en proyectos que almacenen y descarguen artefactos. Este enfoque puede ser necesario cuando tengas políticas de gobierno de datos o límites de confianza que requieran una mayor separación a nivel de proyecto y un mayor control de los recursos.

Control de acceso

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

Algunos Google Cloud servicios usan cuentas de servicio predeterminadas con permisos predeterminados para repositorios del mismo Google Cloud proyecto. Sin embargo, estos valores predeterminados pueden no ser adecuados para tu proceso de desarrollo de software o no cumplir los requisitos de seguridad o de las políticas de tu organización. El administrador del repositorio debe conceder explícitamente acceso a estos servicios a los repositorios si se da alguna de las siguientes circunstancias:

  • Artifact Registry está en un proyecto diferente al del servicio que interactúa con él.
  • Estás usando roles de gestión de identidades y accesos personalizados con las cuentas de servicio predeterminadas en lugar del rol predefinido.
  • No estás usando la cuenta de servicio predeterminada para el Google Cloud servicio.
  • Estás configurando repositorios virtuales. Debes conceder explícitamente acceso a la cuenta de servicio de Artifact Registry a los repositorios upstream.

En el caso de otras entidades que requieran acceso a los repositorios, el administrador del repositorio debe concederlo. Sigue el principio de seguridad de mínimos accesos y concede los permisos mínimos necesarios. Por ejemplo:

  • Despliega imágenes de contenedor en Artifact Registry en clústeres de GKE de varios proyectos. La cuenta de servicio de 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 han lanzado. Los desarrolladores necesitan 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 ejemplo. Tu equipo de ventas solo necesita acceso de lectura para descargar las demos.

Restringir las descargas de artefactos

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

Para obtener información sobre cómo funcionan las reglas de descarga, consulta la sección Restringir las descargas de artefactos del artículo sobre cómo controlar el acceso y proteger los artefactos.

Encriptado de datos

De forma predeterminada, Google Cloud se encriptan automáticamente los datos en reposo mediante claves de cifrado con la tecnología de Google Cloud. Si tienes requisitos de cumplimiento o normativos específicos relacionados con las claves que protegen tus datos, puedes crear repositorios cifrados con claves de cifrado gestionadas por el cliente (CMEK).

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

Etiquetas

Las etiquetas permiten organizar los recursos específicos de un Google Cloud servicio. En Artifact Registry, puede añadir etiquetas a los repositorios para agruparlos o filtrar listas de repositorios por etiqueta. Por ejemplo, puedes usar etiquetas para agrupar repositorios por fase de desarrollo o por equipo con fines de automatización o facturación. Para obtener más información sobre cómo crear y usar etiquetas de repositorio, consulta Etiquetar repositorios.

También puedes aplicar etiquetas a los repositorios. Aunque las etiquetas se usan principalmente para organizar y filtrar recursos específicos de un servicio, las etiquetas se usan para controlar las políticas de una organización de forma programática. Google Cloud Para obtener más información, consulta Etiquetar repositorios.

Siguientes pasos