Descripción general del repositorio

Artifact Registry te permite almacenar diferentes tipos de artefactos, crear varios repositorios en un solo proyecto y asociar una región o multirregión específica a cada repositorio. En esta página, se describen 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 Python almacena paquetes de Python. Puedes crear varios repositorios para cada formato en el mismo proyecto de Google Cloud.

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 un repositorio.

Repositorio estándar
Los repositorios estándar son repositorios normales de Artifact Registry para tus artefactos privados. Sube y descarga artefactos directamente con estos repositorios y usa Artifact Analysis para buscar vulnerabilidades y otros metadatos.
Repositorio remoto

Un repositorio de solo lectura que actúa como un proxy para una fuente externa, como Docker Hub, Maven Central o el índice de paquetes de Python (PyPI). La primera vez que solicitas una versión del artefacto, el repositorio la descarga de la fuente externa y almacena en caché una copia de esta. El repositorio entrega la copia almacenada en caché cuando se vuelve a solicitar la misma versión.

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 analizar vulnerabilidades y otros metadatos.

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 ascendentes. Un repositorio upstream puede ser 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 la política ascendente para priorizar los repositorios con tus artefactos privados sobre los repositorios remotos que almacenan en caché los artefactos públicos.

Ejemplo de uso del repositorio

En el siguiente diagrama, se muestra una de las muchas formas posibles en las que puedes usar repositorios en diferentes modos juntos. En el diagrama, se muestra un flujo de trabajo en dos proyectos de Google Cloud. En un proyecto de desarrollo, los desarrolladores compilan una aplicación de Java. En un proyecto de entorno de ejecución independiente, otra compilación crea una imagen de contenedor con la aplicación para implementarla 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 compilar una aplicación de Java.

    • La compilación puede solicitar dependencias públicas de Java mediante 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 del entorno de ejecución, Cloud Build almacena 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 desde el mismo repositorio virtual.

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

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

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

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

Compatibilidad con el dominio gcr.io

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

  • Redireccionamiento de solicitudes al dominio gcr.io.
  • Creación de repositorios de gcr.io cuando la primera imagen se envía 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 compatible con el dominio gcr.io

Ubicación del repositorio

Puedes crear uno o más repositorios en una región o multirregión compatible. 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

Crear un repositorio en la misma región que otros servicios de Google Cloud tiene varios beneficios:

  • Reduce la latencia y los costos de salida de red mediante la creación de repositorios en la misma región en la que ejecutas GKE, Cloud Run, Cloud Build y otros servicios de Google Cloud que interactúan con el repositorio. No se aplican cargos por el tráfico de salida de Artifact Registry a otros servicios de Google Cloud en la misma región.

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

    • En el caso de la multirregión us, no se cobra la salida a una región de los Estados Unidos, como us-central, a cualquier región de Canadá o Sudamérica.
    • En el caso de la multirregión asia, no se cobra la salida a regiones en Asia, como asia-northeast1, pero sí la salida a regiones en Australia.

  • Solo puedes usar la transmisión de imágenes en GKE y Dataproc Serverless 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 de tus cargas de trabajo. La transmisión de imágenes puede reducir significativamente el tiempo de inicialización de las cargas 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.

  • Considere 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 regulaciones o políticas que requieren que almacenes datos en regiones específicas, puedes incluir una restricción de ubicaciones de recursos en la política de la organización de Google Cloud que solo permita la creación de repositorios en regiones que cumplen con los requisitos. Artifact Registry solo aplica la restricción después de que la incluyes en la política de la organización. Si tienes repositorios existentes en ubicaciones que no cumplen con las políticas, debes mover tus artefactos a un repositorio en una ubicación que cumpla con los requisitos y, luego, borrar el repositorio que no cumpla con las políticas.

Estructura del proyecto

La jerarquía de recursos es la forma en que organizas los recursos en los proyectos de Google Cloud. 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 los repositorios en organizaciones de varios proyectos.

Centraliza repositorios
Crea todos los repositorios en un solo proyecto y, luego, otorga acceso a las principales de otros proyectos al nivel del repositorio. Este enfoque puede ser más eficaz cuando una sola persona o equipo controla la administración del repositorio y el acceso al repositorio en toda tu organización. También puede simplificar la configuración de repositorios virtuales o soluciones como Software Delivery Shield, ya que solo necesitas habilitar y administrar una sola instancia de Artifact Registry.
Repositorios específicos del proyecto
Crear 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 recursos.

Control de acceso

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

Algunos servicios de Google Cloud, como Cloud Build, Cloud Run y GKE, usan cuentas de servicio predeterminadas con permisos predeterminados para los repositorios en el mismo proyecto de Google Cloud. Sin embargo, es posible que estos valores predeterminados no sean adecuados para el proceso de desarrollo de software o que no cumplan con los requisitos de políticas o de seguridad de tu organización. El administrador del repositorio debe otorgar de forma explícita el acceso a los repositorios a estos servicios en los siguientes casos:

  • Artifact Registry está en un proyecto diferente que el servicio que interactúa con él.
  • Usas funciones personalizadas de IAM con las cuentas de servicio predeterminadas en lugar de la función predefinida.
  • No estás usando la cuenta de servicio predeterminada para el servicio de Google Cloud.
  • Está configurando repositorios virtuales. Debes otorgar acceso de manera explícita a la cuenta de servicio de Artifact Registry a los repositorios ascendentes.

Para otras principales que requieren acceso a los repositorios, el administrador del repositorio debe otorgar acceso. De acuerdo con el principio de seguridad de privilegio mínimo, otorga los permisos mínimos necesarios. Por ejemplo:

  • Implementas imágenes de contenedores en Artifact Registry en clústeres de GKE en varios proyectos diferentes. Las cuentas de servicio para los nodos de estos clústeres solo requieren acceso de lectura a los repositorios.
  • Tienes un repositorio de desarrollo para las aplicaciones que se encuentran en el repositorio de desarrollo y producción de 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 ejemplo. Tu equipo de ventas solo necesita acceso de solo lectura para descargar las demostraciones.

Encriptación de los datos

De forma predeterminada, Google Cloud encripta los datos cuando están en reposo de manera automática mediante claves de encriptación administradas por Google. Si tienes requisitos normativos o de cumplimiento específicos relacionados con las claves que protegen tus 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

Las etiquetas proporcionan una forma de organizar los recursos específicos de un servicio de Google Cloud. 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 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 Etiqueta repositorios.

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

Pasos siguientes