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ónoespecífica con cada repositorio. En esta página, se describen las consideraciones para ayudarte 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 repositorios

Cada repositorio está asociado a 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 proyecto de Google Cloud.

Modos de repositorio

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

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

Un repositorio de solo lectura que actúa como proxy para almacenar artefactos de fuentes externas preestablecidas, como Docker Hub, Maven Central, el índice de paquetes de Python (PyPI), Debian o CentOS, así como fuentes definidas por el usuario para los formatos compatibles. La primera vez que solicitas una versión del artefacto, el repositorio la descarga desde 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 los paquetes almacenados en caché en busca de vulnerabilidades y otros metadatos.

Repositorio virtual

Un repositorio de solo lectura que actúa como un punto de acceso único 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 tu política upstream 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 los repositorios en diferentes modos juntos. El diagrama 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 otro proyecto de entorno de ejecución, 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 desde el 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 componente.

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

    En la compilación, se usa el repositorio virtual de Maven para descargar la aplicación. El repositorio virtual entrega el paquete desde el 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 del entorno 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 de Docker 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 desde 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 servicios de Google Cloud tiene los 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 en una región . Una buena ubicación del repositorio equilibra 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 una serie de 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 cobra por la salida de una multirregión a un servicio de Google Cloud en una región correspondiente, este precio 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, a cualquier región de Canadá o Sudamérica.
    • En el caso de la multirregión asia, no se cobra la salida a regiones de Asia, como asia-northeast1, pero la salida a regiones de Australia sí se cobra.

  • Solo puedes usar la transmisión de imágenes en GKE y Dataproc sin servidores si tus imágenes de contenedor están almacenadas 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 de forma significativa 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.

  • Considera 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 en sus estaciones de trabajo locales, un repositorio en una región de Australia 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 la política de la organización de Google Cloud que solo permita la creación de repositorios en regiones compatibles. Artifact Registry solo aplica la restricción después de incluirla 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 las políticas y, luego, borrar el repositorio que no cumple con las políticas.

Políticas de limpieza

Una política de limpieza de Artifact Registry define criterios para borrar de forma automática las versiones de artefactos que ya no necesitas o conservar los artefactos que quieres 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 eliminación con criterios para borrar artefactos y mantener políticas con criterios de retención de artefactos.

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

Borrar políticas

Borrar políticas borra los artefactos que coincidan con los siguientes criterios obligatorios:

  • Estado de la etiqueta: Indica si la política debe verificar si hay artefactos etiquetados o artefactos sin etiquetar. Los artefactos se etiquetan cuando se envía o extrae una imagen hacia o desde un repositorio. 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 sin etiquetar.
    • Etiquetado: Solo se aplica a los artefactos etiquetados.
    • Sin etiquetar: Solo se aplica a artefactos sin etiquetar.

    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 las etiquetas y se aplica a las políticas de limpieza, consulta la referencia de TagState.

Las siguientes son formas opcionales de definir tu política de eliminación:

  • Prefijos de etiqueta: Es una lista separada por comas de prefijos de etiquetas. Por ejemplo, los prefijos test y staging coincidirían con las imágenes con las etiquetas testenv y staging-1.5. tagState debe configurarse como TAGGED para usar prefijos de etiqueta.
    • Prefijos de versión: Son una lista separada por comas de prefijos de versiones de artefactos. Por ejemplo, v1, v2 coincidiría con las versiones v1.5, v2.0alpha y v10.2.
  • Prefijos de paquetes: Es una lista de prefijos de nombres de artefactos. Puedes ingresar varios prefijos si presionas 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.
  • Anterior a: Es el tiempo mínimo desde que se subió una versión del artefacto al repositorio, que se especifica como una duración. Por ejemplo, 30d es de 30 días. Puedes especificar duraciones de segundos, minutos, horas o días agregando s, m, h o d, respectivamente.
  • Posterior a: Es el tiempo máximo desde que se subió la versión de un artefacto al repositorio, que se especifica como una duración. Por ejemplo, 30d es de 30 días.

Mantener las políticas

Las políticas de conservación permiten que los artefactos cumplan con las mismas condiciones que las políticas de eliminación, o bien una cantidad determinada de versiones más recientes.

Por ejemplo, en 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 mantener 3 versiones de paquetes que coincidan con los Prefijos de paquetes: {release-xyz}, solo se conservan release-xyz-v1 y release-xyz-v2.

Las eliminaciones activadas por políticas de eliminación se descuentan de tu cuota de solicitudes de eliminación 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 realizando la transición de Container Registry a Artifact Registry, puedes configurar Artifact Registry en los repositorios de gcr.io 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 se envía la primera imagen a un nombre de host de gcr.io para brindar compatibilidad con el comportamiento de Container Registry.

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

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 tus repositorios en organizaciones de varios proyectos.

Centraliza repositorios
Crea todos los repositorios en un solo proyecto y, luego, otorga acceso a principales de otros proyectos en el 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 a los repositorios en toda la 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 única instancia de Artifact Registry.
Repositorios específicos del proyecto
Crear repositorios en proyectos que almacenen y descarguen 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 un mayor 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 del proyecto o del repositorio.

Algunos servicios de Google Cloud 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 no cumplan con los requisitos de políticas o seguridad de la organización. El administrador de tu repositorio debe otorgar a estos servicios acceso a los repositorios de forma explícita en los siguientes casos:

  • Artifact Registry se encuentra en un proyecto diferente al servicio que interactúa con él.
  • Usas funciones de IAM personalizadas 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ás configurando repositorios virtuales. Debes otorgar de forma explícita a la cuenta de servicio de Artifact Registry acceso a los repositorios upstream.

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

  • Implementa imágenes de contenedor en Artifact Registry para los 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 producción para las aplicaciones que se lanzaron. 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 requiere 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 forma automática mediante claves que son propiedad de Google y que administra Google. Si tienes requisitos regulatorios 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 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 por equipo con fines de automatización o facturación. Si deseas obtener más información sobre cómo crear y usar etiquetas de repositorio, consulta Cómo etiquetar repositorios.

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

Pasos siguientes