Descripción general del repositorio

Artifact Registry te permite almacenar diferentes tipos de artefactos, crear varios repositorios en un solo proyecto y asociar un repositorio región o multirregión con cada repositorio. En esta página, se describen algunas consideraciones para 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 se asocia con un artefacto específico formato. 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 después de haberlo 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.
Repositorio remoto

Un repositorio de solo lectura que actúa como proxy para almacenar artefactos de la configuración fuentes externas, como Docker Hub, Maven Central, el Índice de paquetes de Python (PyPI), Debian o CentOS, así como fuentes definidas por el usuario formatos. La primera vez que solicites un versión del artefacto, el repositorio la descarga de una fuente externa y almacena en caché una copia de él. El repositorio entrega la copia almacenada en caché cuando el mismo se vuelve a solicitar la versión.

Los repositorios remotos reducen la latencia y mejoran la disponibilidad para compilaciones y de Google Cloud en Google Cloud. También puedes usar Artifact Analysis permite analizar paquetes almacenados en caché en busca de 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 un en un repositorio estándar, remoto o virtual.

Los repositorios virtuales simplifican la configuración de clientes para los consumidores de tu artefactos. También puedes mitigar ataques de confusión de dependencias para priorizar los repositorios con tus artefactos privados 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 que puedes usar los repositorios de diferentes modos. En el diagrama, se muestra un flujo de trabajo en dos proyectos de Google Cloud. En un proyecto de desarrollo, los desarrolladores compilan un archivo y mantener la integridad de su aplicación. En otro proyecto de entorno de ejecución, otra compilación crea un 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 en un repositorio de confianza. El repositorio virtual entrega las dependencias desde el 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 los datos de Java y mantener la integridad de su aplicación.

    En la compilación, se usa el repositorio virtual de Maven para descargar la aplicación. El repositorio virtual entrega el paquete del repositorio estándar en proyecto de desarrollo. La compilación también puede descargar archivos dependencias del mismo repositorio virtual.

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

  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 alojada en contenedores.
    • El repositorio remoto upstream proporciona imágenes que GKE las solicitudes desde Docker Hub.

En este ejemplo, todos los repositorios, compilaciones y clústeres de GKE en la misma región. Usa la misma ubicación para los servicios de Google Cloud 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 Una buena ubicación del repositorio la latencia, la disponibilidad y los costos de ancho de banda de los consumidores de datos. Es posible que tu organización también tenga requisitos de cumplimiento específicos.

Consideraciones de ubicación

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

  • Crea repositorios para reducir la latencia y los costos de salida de red en la misma región donde ejecutas GKE, Cloud Run, Cloud Build y otros servicios de Google Cloud con los que del repositorio. No se aplican cargos por la salida 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 una Servicio de Google Cloud en una región correspondiente, solo con este precio se aplica a un conjunto limitado de regiones.

    • Para la multirregión us, la salida a una región de Estados Unidos, como No se cobra us-central, para cualquier región de Canadá o Sudamérica es de que se hayan cargado correctamente.
    • Para la multirregión asia, la salida a regiones de Asia, como No se cobran asia-northeast1, pero sí se cobra la salida a regiones de Australia que se hayan cargado correctamente.

  • 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 Artifact Registry en la misma región que tus cargas de trabajo o en una multirregión que corresponde 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 se usan contenedores ya que las cargas de trabajo pueden iniciarse antes de que se descargue toda la imagen.

  • Considera la ubicación de los consumidores fuera de Google Cloud. Para Por ejemplo, si tu equipo de desarrolladores en Australia necesita descargar artefactos desde Artifact Registry hasta sus estaciones de trabajo locales, un repositorio en una región de Australia reducirá la latencia y disminuirá los cargos de salida que un repositorio ubicado en otro continente.

Restringe las ubicaciones de los repositorios

Si necesitas cumplir con reglamentaciones o políticas que exigen que almacenes datos de regiones específicas, puedes incluir restricción de ubicaciones de recursos en tu que solo permite la creación de repositorios en regiones que cumplen con los requisitos. Artifact Registry solo aplica la restricción después de incluirla en la política de tu organización. Si ya tienes repositorios en ubicaciones que no cumplen con las políticas, debes mover tus artefactos a un repositorio en un ubicación de cumplimiento y, luego, borra 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 automáticamente versiones de artefactos que ya no necesites o que conserven los artefactos que deseas. se almacenen de forma indefinida.

Las políticas de limpieza son útiles si almacenas muchas versiones de tus artefactos, pero solo deben conservar las versiones específicas que lanzas a producción. Tú puede definir políticas de eliminación con criterios para borrar artefactos y mantener políticas con criterios para retener artefactos

Si la versión de un artefacto coincide con los criterios de una política de eliminación y una 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 a o de 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 tanto a las etiquetas como artefactos 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. Artefactos etiquetados de los repositorios con etiquetas inmutables habilitadas.

    Para ver más para conocer el estado de la etiqueta y su aplicación 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: Una lista separada por comas de prefijos de etiquetas. Por ejemplo, los prefijos test y staging coincidirían. imágenes con las etiquetas testenv y staging-1.5. tagState se debe establecer en TAGGED para usar prefijos de etiqueta.
    • Prefijos de versión: Una lista separada por comas de las versiones del artefacto prefijos. 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 presionando 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 se subió la versión del artefacto al repositorio y se especificó como 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 un se subió la versión del artefacto al repositorio y se especificó como duración. Por ejemplo, 30d es de 30 días.

Mantener las políticas

Mantener las políticas para que los artefactos cumplan con las mismas condiciones que las políticas de eliminación, o 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á establecida para conservar 3 versiones de paquetes que coincidan con los PackagePrefixes: {release-xyz}, solo Se conservan release-xyz-v1 y release-xyz-v2.

Las eliminaciones que activan las políticas de eliminación se consideran en Artifact Registry cuota de solicitudes de eliminación por proyecto.

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 eres hacer la transición de Container Registry a Artifact Registry, puedes configurar Artifact Registry se almacena en gcr.io para minimizar los cambios en la configuración la automatización y los flujos de trabajo. 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 gcr.io nombre de host para la 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 proyectos de Google Cloud. La estructura que elijas dependerá de factores como los requisitos de administración de datos, los límites de confianza y en la nube.

Existen dos enfoques generales para configurar tus repositorios organizaciones multiproyectos.

Centraliza repositorios
Crear todos los repositorios en un solo proyecto y, luego, otorgar acceso a principales de otros proyectos a nivel del repositorio. Este enfoque puede ser más eficaz cuando una sola persona o equipo maneja el repositorio administración de identidades y accesos 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 Esta puede ser necesario un enfoque de seguridad cuando tienes políticas de administración de datos límites de confianza que requieren más separación a nivel de proyecto y control de de Google Cloud.

Control de acceso

Solo se puede acceder a los repositorios con los permisos adecuados, a menos que configurar el repositorio 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, estos valores predeterminados podrían no ser adecuados para tu software desarrollo del producto o que no cumplan con los requisitos de políticas o seguridad en tu organización. El administrador del repositorio debe otorgar explícitamente estos servicios accedan a repositorios en los siguientes casos:

  • Artifact Registry está en un proyecto diferente al servicio que está que estás interactuando con él.
  • Estás usando roles personalizados de IAM con la cuenta de servicio en lugar del rol predefinido.
  • No estás usando la cuenta de servicio predeterminada para Google Cloud servicio.
  • Estás configurando repositorios virtuales. Debes otorgar explícitamente el acceso de la cuenta de servicio de Artifact Registry para de Cloud Storage.

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

  • Implementa imágenes de contenedor en Artifact Registry en GKE. clústeres en varios proyectos diferentes. La cuenta de servicio para los nodos en estos clústeres solo requieren acceso de lectura a los repositorios.
  • Tienes un repositorio de desarrollo para las aplicaciones que están en desarrollo y de producción para las aplicaciones que se lanzan. 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. Solo para tu equipo de ventas requiere acceso de solo lectura para descargar las demostraciones.

Encriptación de datos

De forma predeterminada, Google Cloud encripta automáticamente los datos cuando están en resto con Claves de propiedad y administración de Google. Si tienes requisitos reglamentarios 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 es compatible con las restricciones de las 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 una instancia de Google Cloud servicio. En Artifact Registry, puedes agregar etiquetas a los repositorios para que puedes agruparlos o filtrar las listas de repositorios por etiqueta. Por ejemplo: puedes usar etiquetas para agrupar los repositorios por etapa de desarrollo o por equipo automatización o facturación. Para 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 principalmente organizar y filtrar recursos específicos del servicio, las etiquetas son para programática control de políticas en toda la organización de Google Cloud. Para ver más consulta Etiquetar repositorios.

Qué sigue