Panoramica dei repository

Artifact Registry consente di archiviare diversi tipi di artefatti, creare più repository in un singolo progetto e associare un progetto una o più regioni con ogni repository. In questa pagina vengono descritte le considerazioni per aiutarti a pianificare le posizioni e l'organizzazione dei tuoi repository.

Prendi in considerazione sia i processi interni per la creazione degli artefatti che l'utilizzo da parte dei consumer dei tuoi artefatti quando crei i tuoi repository.

Formati repository

Ogni repository è associato a un artefatto specifico format. Ad esempio, un repository Docker per archiviare le immagini Docker. Puoi creare più repository per ogni formato in lo stesso progetto Google Cloud.

Modalità repository

Esistono più modalità di repository. Ogni modalità ha uno scopo diverso, non puoi cambiare la modalità del repository dopo aver creato un repository.

Repository standard
I repository standard sono normali repository Artifact Registry per gli artefatti privati. Puoi caricare e scaricare gli artefatti direttamente con questi repository e utilizzare Artifact Analysis per analizzare le vulnerabilità e altri metadati.
Repository remoto

Un repository di sola lettura che funge da proxy per archiviare gli artefatti della preimpostazione origini esterne come Docker Hub, Maven Central, l'indice dei pacchetti Python (PyPI), Debian o CentOS, nonché origini definite dall'utente per formati. La prima volta che richiedi un artefatto, il repository la scarica dall'origine esterna ne memorizza una copia nella cache. Il repository pubblica la copia memorizzata nella cache quando viene richiesta nuovamente.

I repository remoti riducono la latenza e migliorano la disponibilità di build e deployment su Google Cloud. Puoi anche utilizzare Artifact Analysis per analizzare i pacchetti memorizzati nella cache alla ricerca di vulnerabilità e altri metadati.

Repository virtuale

Un repository di sola lettura che funge da singolo punto di accesso da scaricare, installare o eseguire il deployment di artefatti dello stesso formato da uno o più repository upstream. Un repository upstream può essere un un repository standard, remoto o virtuale.

I repository virtuali semplificano la configurazione del client per i consumatori dei tuoi artefatti. Puoi anche ridurre attacchi di confusione da dipendenza configurando il tuo upstream per assegnare la priorità ai repository con i tuoi artefatti privati in cui sono memorizzati gli artefatti pubblici nella cache.

Esempio di utilizzo del repository

Il seguente diagramma mostra uno dei molti possibili modi in cui puoi utilizzare i repository in diverse modalità insieme. Il diagramma mostra un flusso di lavoro tra due progetti Google Cloud. In un progetto di sviluppo, gli sviluppatori creano un'applicazione. In un progetto runtime separato, un'altra build crea un container con l'applicazione per il deployment in Google Kubernetes Engine.

Repository standard, virtuali e remoti utilizzati in due progetti.

  1. Nel progetto di sviluppo, un team di sviluppo Java utilizza Cloud Build per creare un'applicazione Java.

    • La build può richiedere dipendenze Java pubbliche utilizzando repository Git. Il repository virtuale gestisce le dipendenze dal repository di memorizzazione nella cache, che è un proxy di memorizzazione nella cache per Maven Central.
    • Cloud Build carica il pacchetto nel Repository Maven standard nel progetto del componente.

  2. Nel progetto runtime, Cloud Build containerizza le chiavi Java un'applicazione.

    La build utilizza il Repository virtuale Maven per scaricare l'applicazione. La il repository virtuale gestisce il pacchetto dal repository standard del progetto di sviluppo. La build può anche scaricare Java pubblico dallo stesso repository virtuale.

  3. Nel progetto runtime, Cloud Build carica il container creato in un repository Docker standard.

  4. GKE esegue il pull delle immagini dal repository virtuale Docker.

    • Il repository Docker standard a monte fornisce immagini private, come per l'applicazione Java containerizzata.
    • Il repository remoto upstream fornisce immagini che GKE richieste da Docker Hub.

In questo esempio, tutti i repository, le build e i cluster GKE nella stessa regione. Utilizzare la stessa località per i servizi Google Cloud presenta i vantaggi descritti in Località del repository.

Località repository

Puoi creare uno o più repository in un una o più regioni . Una buona posizione del repository bilancia di latenza, disponibilità e larghezza di banda per i consumatori dei dati. La tua organizzazione potrebbe anche avere requisiti di conformità specifici.

Considerazioni sulla località

Creazione di un repository nella stessa regione degli altri servizi Google Cloud presenta numerosi vantaggi:

  • Riduci la latenza e i costi del traffico di rete in uscita creando repository nella stessa regione in cui esegui GKE, Cloud Run Cloud Build e altri servizi Google Cloud che interagiscono nel repository. Non è previsto alcun costo per il traffico in uscita da da Artifact Registry ad altri servizi Google Cloud nello stesso regione.

    Sebbene non sia previsto alcun costo per il traffico in uscita da più regioni a una per il servizio Google Cloud in una regione corrispondente, solo questi prezzi si applica a un gruppo limitato di regioni.

    • Per l'area multiregionale us, il traffico in uscita verso una regione negli Stati Uniti, ad esempio us-central non viene addebitato alcun costo; per qualsiasi regione del Canada o del Sud America è carico.
    • Per il traffico multiregionale asia, il traffico in uscita verso le regioni in Asia, ad esempio asia-northeast1 non vengono addebitati, mentre quelli in uscita verso le regioni australiane lo carico.

  • Puoi utilizzare il flusso di immagini solo in GKE e Dataproc Serverless se le immagini container sono archiviate in Artifact Registry nella stessa regione dei carichi di lavoro o in una località multiregionale a ogni regione con i tuoi carichi di lavoro. Il flusso di immagini può ridurre di inizializzazione del carico di lavoro in modo significativo quando si utilizza un container più grande poiché i carichi di lavoro possono iniziare prima del download dell'intera immagine.

  • Considera la località dei consumatori al di fuori di Google Cloud. Per Ad esempio, se il team di sviluppatori in Australia deve scaricare gli artefatti da Artifact Registry alle rispettive workstation locali, in una regione australiana ridurrà la latenza e i costi per il traffico in uscita saranno inferiori rispetto a un repository situato in un altro continente.

Limitazione delle località dei repository

Se devi rispettare regolamenti o norme che richiedono di archiviare in regioni specifiche, puoi includere un vincolo di località delle risorse nel tuo Google Cloud che consente la creazione di repository solo in regioni conformi. Artifact Registry applica il vincolo solo dopo averlo incluso nel criterio dell'organizzazione. Se hai repository esistenti in località non conformi, devi spostare gli artefatti in un repository in la posizione conforme ed eliminare il repository non conforme.

Criteri di pulizia

Un criterio di pulizia di Artifact Registry definisce i criteri per l'eliminazione automatica versioni degli artefatti che non ti servono più o di conservare gli artefatti che vuoi per archiviarli a tempo indeterminato.

I criteri di pulizia sono utili se archivi molte versioni degli artefatti, ma e mantenere solo le versioni specifiche rilasciate in produzione. Tu può definire i criteri di eliminazione con criteri per l'eliminazione degli artefatti tieni criteri con i criteri per la conservazione degli artefatti.

Se una versione dell'artefatto corrisponde ai criteri sia in un criterio di eliminazione sia in una conservazione Artifact Registry, Artifact Registry applica il criterio di conservazione.

Elimina criteri

Elimina i criteri eliminano gli artefatti che corrispondono ai seguenti criteri obbligatori:

  • Stato dei tag: indica se il criterio deve verificare la presenza di elementi con tag o artefatti senza tag. Gli artefatti vengono taggati quando si esegue il push o il pull di un'immagine o da un repository. Per ulteriori informazioni sui tag Docker, consulta Concetti sui container.

    • Qualsiasi stato del tag: ignora lo stato del tag e si applica sia a tag che a artefatti senza tag.
    • Con tag: si applica solo agli elementi con tag.
    • Senza tag: si applica solo agli elementi senza tag.

    I formati che non supportano i tag vengono trattati come untagged. Artefatti con tag e non possono essere eliminati nei repository con tag immutabili abilitati.

    Per ulteriori informazioni informazioni sullo stato dei tag in base ai criteri di pulizia, consulta le Riferimento TagState.

Di seguito sono riportati alcuni modi facoltativi per definire il criterio di eliminazione:

  • Prefissi tag: si tratta di un elenco separato da virgole di prefissi dei tag. Ad esempio, i prefissi test e staging corrispondono immagini con tag testenv e staging-1.5. tagState deve essere impostato su TAGGED per utilizzare i prefissi tag.
    • Prefissi di versione: sono un elenco separato da virgole della versione dell'elemento prefissi. Ad esempio v1, v2 corrisponde alle versioni v1.5, v2.0alpha e v10.2.
  • Prefissi pacchetto: un elenco di prefissi dei nomi degli artefatti. Puoi inserire più prefissi premendo Enter o , tra i prefissi. Ad esempio, red, blue creerebbe due prefissi, red e blue e corrisponde ai nomi degli artefatti red-team, redis, e bluebird.
  • Precedente di: indica un periodo di tempo minimo trascorso da una versione dell'artefatto è stata caricata nel repository, specificata come durata. Ad esempio, 30d corrisponde a 30 giorni. Puoi specificare la durata in secondi, minuti, ore o giorni aggiungendo rispettivamente s, m, h o d.
  • Più recente di: è il tempo massimo trascorso da una versione dell'artefatto è stata caricata nel repository, specificata come durata. Ad esempio, 30d corrisponde a 30 giorni.

Conserva i criteri

Mantieni i criteri mantengono gli artefatti corrispondenti alle stesse condizioni dei criteri di eliminazione oppure un determinato numero di versioni più recenti.

Ad esempio, nel caso di un repository contenente i seguenti artefatti:

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

Se il criterio Mantieni versioni più recenti è impostato per conservare tre versioni di pacchetti corrispondenti ai prefissi pacchetto: solo {release-xyz} release-xyz-v1 e release-xyz-v2 vengono conservati.

Le eliminazioni attivate dai criteri di eliminazione vengono conteggiate ai fini di Artifact Registry quota di richieste di eliminazione per progetto.

Per creare e applicare criteri di pulizia al repository, consulta Configura i criteri di pulizia.

Assistenza per i domini gcr.io

Artifact Registry supporta l'hosting di immagini nel dominio gcr.io. Se di passaggio da Container Registry ad Artifact Registry, puoi configurare Artifact Registry dei repository gcr.io per ridurre al minimo le modifiche al tuo ambiente automazione e flussi di lavoro. Questi repository offrono:

  • Reindirizzamento delle richieste al dominio gcr.io.
  • Creazione di repository gcr.io quando viene eseguito il push della prima immagine su gcr.io per la compatibilità con il comportamento di Container Registry.

Per ulteriori informazioni, vedi Transizione ai repository con il supporto del dominio gcr.io

Struttura del progetto

La gerarchia delle risorse è il modo in cui organizzi le risorse tra progetti Google Cloud. La struttura scelta dipende come i requisiti di governance dei dati, i confini di attendibilità e il team alla struttura del centro di costo.

Esistono due approcci generali per configurare i repository in con più progetti.

Centralizza i repository
Crea tutti i repository in un singolo progetto e concedi l'accesso a di altri progetti a livello di repository. Questo approccio può essere più efficaci quando una singola persona o un singolo team gestisce il repository accesso amministrativo e ai repository in tutta l'organizzazione.
Può anche semplificare la configurazione di repository o soluzioni virtuali come Software Delivery Shield perché devi abilitare e gestire una sola istanza di Artifact Registry.
Repository specifici del progetto
Crea repository in progetti che archiviano e scaricano artefatti. Questo potrebbe essere necessario se esistono criteri di governance dei dati limiti di attendibilità che richiedono una maggiore separazione e controllo a livello di progetto Google Cloud.

Controllo degli accessi

I repository sono accessibili solo con le autorizzazioni appropriate, a meno che tu e configurare il repository per l'accesso pubblico. Puoi concedere autorizzazioni a livello di progetto o repository.

Alcuni servizi Google Cloud utilizzano account di servizio predefiniti con autorizzazioni predefinite per i repository nello stesso progetto Google Cloud. Tuttavia, queste impostazioni predefinite potrebbero non essere adatte al tuo software processo di sviluppo o non rispettare i requisiti delle norme o di sicurezza che fa parte della tua organizzazione. L'amministratore del repository deve concedere esplicitamente questi servizi accedono ai repository se:

  • Artifact Registry si trova in un progetto diverso dal servizio a interagire con quest'ultima.
  • Stai utilizzando ruoli IAM personalizzati con il servizio predefinito degli account sviluppatore anziché con il ruolo predefinito.
  • Non stai utilizzando l'account di servizio predefinito per Google Cloud completamente gestito di Google Cloud.
  • Stai configurando repository virtuali. Devi concedere esplicitamente l'accesso dell'account di servizio Artifact Registry all'upstream repository.

Per altre entità che richiedono l'accesso ai repository, il repository amministratore deve concedere l'accesso. Seguendo il principio di sicurezza di almeno concedi le autorizzazioni minime richieste. Ad esempio:

  • Esegui il deployment delle immagini container in Artifact Registry su GKE in diversi progetti. L'account di servizio per i nodi in questi cluster richiedono solo l'accesso in lettura ai repository.
  • Disponi di un repository per le applicazioni in fase di sviluppo nel repository di produzione per le applicazioni rilasciate. Gli sviluppatori richiedono l'accesso in lettura e scrittura al repository di sviluppo e accesso in sola lettura al repository di produzione.
  • Hai un repository demo con applicazioni di esempio. Solo il tuo team di vendita richiede l'accesso di sola lettura per scaricare le demo.

Crittografia dei dati

Per impostazione predefinita, Google Cloud cripta automaticamente i dati quando sono riposi usando Chiavi di proprietà di Google e gestite da Google. Se hai requisiti di conformità o normativi requisiti relativi alle chiavi che proteggono i tuoi dati, puoi creare repository criptati con chiavi di crittografia gestite dal cliente (CMEK).

Artifact Registry supporta anche i vincoli dei criteri dell'organizzazione che possono richiedere una CMEK per proteggere le risorse.

Etichette e tag

Le etichette consentono di organizzare le risorse specifiche di un ambiente Google Cloud completamente gestito di Google Cloud. In Artifact Registry, puoi aggiungere etichette ai repository in modo puoi raggrupparli o filtrare gli elenchi di repository per etichetta. Ad esempio: puoi utilizzare le etichette per raggruppare i repository per fase di sviluppo o per team per l'automazione o la fatturazione. Per ulteriori informazioni sulla creazione e sull'utilizzo sulle etichette dei repository, consulta Etichettatura dei repository.

Puoi anche applicare tag ai repository. Sebbene le etichette siano principalmente organizzare e filtrare le risorse specifiche dei servizi, i tag sono per la pubblicità programmatica dei criteri in tutta l'organizzazione Google Cloud. Per ulteriori informazioni consulta la sezione Tagging dei repository.

Passaggi successivi