Panoramica dei repository

Artifact Registry consente di archiviare diversi tipi di artefatti, creare più repository in un singolo progetto e associare una specifica regione o più regioni a ogni repository. In questa pagina vengono descritte alcune considerazioni utili a pianificare le località e l'organizzazione dei repository.

Considera sia i processi interni per la creazione degli artefatti sia l'utilizzo da parte dei consumatori degli artefatti quando crei i repository.

Formati repository

Ogni repository è associato a uno specifico formato artefatto. Un repository Python, ad esempio, archivia i pacchetti Python. Puoi creare più repository per ogni formato nello stesso progetto Google Cloud.

Modalità repository

Esistono diverse modalità di repository. Ogni modalità ha uno scopo diverso, perciò non puoi modificarla dopo averlo creato.

Repository standard
I repository standard sono normali repository Artifact Registry per i tuoi 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 artefatti da origini esterne predefinite come Docker Hub, Maven Central, Python Package Index (PyPI), Debian o CentOS e origini definite dall'utente per i formati supportati. La prima volta che richiedi una versione dell'artefatto, il repository la scarica dall'origine esterna e ne memorizza una copia nella cache. Il repository pubblica la copia memorizzata nella cache quando viene richiesta di nuovo la stessa versione.

I repository remoti riducono la latenza e migliorano la disponibilità per 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 per scaricare, installare o eseguire il deployment di artefatti dello stesso formato da uno o più repository upstream. Un repository upstream può essere standard, remoto o virtuale.

I repository virtuali semplificano la configurazione client per i consumatori dei tuoi artefatti. Puoi anche ridurre gli attacchi di confusione della dipendenza configurando il criterio upstream in modo da dare la priorità ai repository con artefatti privati rispetto a repository remoti che memorizzano nella cache gli artefatti pubblici.

Esempio di utilizzo del repository

Il seguente diagramma mostra uno dei tanti modi possibili di 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 Java. In un progetto di runtime separato, un'altra build crea un'immagine container con l'applicazione per il deployment su Google Kubernetes Engine.

Repository standard, virtuali e remoti utilizzati in due progetti.

  1. Un team di sviluppo Java usa Cloud Build per creare un'applicazione Java.

    • La build può richiedere dipendenze Java pubbliche utilizzando il repository virtuale. Il repository virtuale gestisce le dipendenze dal repository remoto, 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 di runtime, Cloud Build containerizza l'applicazione Java.

    La build utilizza il repository virtuale Maven per scaricare l'applicazione. Il repository virtuale gestisce il pacchetto dal repository standard nel progetto di sviluppo. La build può anche scaricare le dipendenze Java pubbliche dallo stesso repository virtuale.

  3. Nel progetto di runtime, Cloud Build carica l'immagine del container creata in un repository Docker standard.

  4. GKE estrae le immagini dal repository virtuale Docker.

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

In questo esempio, tutti i repository, le build e i cluster GKE si trovano nella stessa regione. L'utilizzo della stessa località per i servizi Google Cloud presenta i vantaggi descritti in Località del repository.

Assistenza per i domini gcr.io

Artifact Registry supporta l'hosting di immagini sul dominio gcr.io. Se stai passando da Container Registry ad Artifact Registry, puoi configurare Artifact Registry per i repository gcr.io per ridurre al minimo le modifiche all'automazione e ai flussi di lavoro esistenti. Questi repository forniscono:

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

Per maggiori informazioni, consulta Transizione ai repository con supporto per il dominio gcr.io

Località repository

Puoi creare uno o più repository in un'area geografica o multiregionale supportata. Una buona posizione del repository bilancia i costi 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à

La creazione di un repository nella stessa regione degli altri servizi Google Cloud presenta una serie di vantaggi:

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

    Sebbene non sia previsto alcun costo per il traffico in uscita da una località multiregionale a un servizio Google Cloud in una regione corrispondente, questi prezzi si applicano solo a un insieme limitato di regioni.

    • Per la località multiregionale us, non viene addebitato il traffico in uscita verso un'area geografica degli Stati Uniti, ad esempio us-central, verso qualsiasi regione del Canada o del Sud America.
    • Per il traffico multiregionale asia, non viene addebitato il traffico in uscita verso regioni dell'Asia, come asia-northeast1, mentre il traffico in uscita verso le regioni dell'Australia.
  • Puoi utilizzare il flusso di immagini in GKE e Dataproc Serverless solo se le immagini container sono archiviate in repository Artifact Registry nella stessa regione dei tuoi carichi di lavoro o in una regione multiregionale che corrisponde a quella con i tuoi carichi di lavoro. Il flusso di immagini può ridurre notevolmente i tempi di inizializzazione dei carichi di lavoro quando utilizzi immagini container più grandi, poiché i carichi di lavoro possono avviarsi prima del download dell'intera immagine.

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

Limitazione delle località dei repository

Se devi rispettare normative o criteri che richiedono di archiviare i dati in regioni specifiche, puoi includere un vincolo relativo alle località delle risorse nel criterio dell'organizzazione di Google Cloud che consente la creazione dei repository solo nelle regioni conformi. Artifact Registry applica il vincolo solo dopo che lo includi nel criterio dell'organizzazione. Se hai repository esistenti in località non conformi, devi spostare personalmente gli artefatti in un repository in una località conforme ed eliminare il repository non conforme.

Struttura del progetto

La gerarchia delle risorse è il modo in cui organizzi le risorse nei progetti Google Cloud. La struttura che scegli dipende da fattori come i requisiti di governance dei dati, i limiti di fiducia e la struttura dei team.

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

Centralizza i repository
Crea tutti i repository in un singolo progetto, quindi concedi l'accesso alle entità di altri progetti a livello di repository. Questo approccio può essere più efficace quando una singola persona o un singolo team gestisce l'amministrazione e l'accesso al repository in tutta l'organizzazione. Può anche semplificare la configurazione di repository o soluzioni virtuali come Software Delivery Shield, poiché è sufficiente abilitare e gestire una singola istanza di Artifact Registry.
Repository specifici per i progetti
Crea repository in progetti che archiviano e scaricano artefatti. Questo approccio potrebbe essere necessario quando hai criteri di governance dei dati o limiti di attendibilità che richiedono una separazione e un controllo delle risorse a livello di progetto.

Controllo dell'accesso

I repository sono accessibili solo con le autorizzazioni appropriate, a meno che non ne configuri l'accesso pubblico. Puoi concedere le autorizzazioni a livello di progetto o repository.

Alcuni servizi Google Cloud, come Cloud Build, Cloud Run e GKE, utilizzano account di servizio predefiniti con autorizzazioni predefinite per i repository nello stesso progetto Google Cloud. Tuttavia, queste impostazioni predefinite potrebbero non essere adatte per il processo di sviluppo del software o potrebbero non essere conformi ai requisiti di sicurezza o dei criteri della tua organizzazione. L'amministratore del repository deve concedere esplicitamente a questi servizi l'accesso ai repository se:

  • Artifact Registry si trova in un progetto diverso rispetto al servizio che lo interagisce.
  • Utilizzi ruoli IAM personalizzati con gli account di servizio predefiniti, anziché con il ruolo predefinito.
  • Non stai utilizzando l'account di servizio predefinito per il servizio Google Cloud.
  • Stai configurando repository virtuali. Devi concedere esplicitamente all'account di servizio Artifact Registry l'accesso ai repository upstream.

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

  • Puoi eseguire il deployment delle immagini container in Artifact Registry nei cluster GKE in vari progetti. L'account di servizio per i nodi in questi cluster richiede solo l'accesso in lettura ai repository.
  • Disponi di un repository di sviluppo per le applicazioni che si trovano nel repository di sviluppo e produzione per le applicazioni che verranno rilasciate. Gli sviluppatori richiedono l'accesso in lettura e scrittura al repository di sviluppo e l'accesso di sola lettura al repository di produzione.
  • Hai un repository dimostrativo con applicazioni di esempio. 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 at-rest utilizzando chiavi di crittografia gestite da Google. Se hai requisiti normativi o di conformità specifici relativi alle chiavi per la protezione dei dati, puoi creare repository criptati con chiavi di crittografia gestite dal cliente (CMEK).

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

Etichette e tag

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

Puoi anche applicare tag ai repository. Sebbene le etichette vengano utilizzate principalmente per organizzare e filtrare le risorse specifiche di un servizio, i tag servono per il controllo programmatico dei criteri in un'organizzazione Google Cloud. Per ulteriori informazioni, consulta la sezione Tagging dei repository.

Passaggi successivi