Panoramica dei repository

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

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

Formati repository

Ogni repository è associato a un formato artefatto specifico. Ad esempio, un repository Docker memorizza immagini Docker. Puoi creare più repository per ogni formato nello stesso progetto Google Cloud.

Modalità repository

Esistono più modalità di repository. Ogni modalità ha uno scopo diverso, quindi non puoi cambiare la modalità

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 preimpostate, come Docker Hub, Maven Central, Python Package Index (PyPI), Debian o CentOS, nonché 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 nuovamente la stessa versione.

I repository remoti riducono la latenza e migliorano la disponibilità di build e deployment su Google Cloud. Puoi utilizzare Artifact Analysis anche 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 clienti per i consumatori dei tuoi artefatti. Puoi anche mitigare gli attacchi di confusione di dipendenze configurando il criterio upstream in modo da dare la priorità ai repository con i tuoi artefatti privati rispetto ai repository remoti che memorizzano nella cache gli artefatti pubblici.

Esempio di utilizzo del repository

Il seguente diagramma mostra uno dei molti possibili modi in cui è possibile utilizzare i repository in modalità diverse 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 runtime separato, un'altra build crea un'immagine container con l'applicazione per il deployment in 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, 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 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 dipendenze Java pubbliche dallo stesso repository virtuale.

  3. Nel progetto runtime, Cloud Build carica l'immagine container creata 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 l'applicazione Java containerizzata.
    • Il repository remoto a monte fornisce immagini che GKE richiede da 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 offre i vantaggi descritti in Località del repository.

Località repository

Puoi creare uno o più repository in una regioneo più regioni . Una buona posizione del repository bilancia 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 offre una serie di 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 con il repository. Non è previsto alcun costo per il traffico in uscita da Artifact Registry verso 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 gruppo limitato di regioni.

    • Per la località multiregionale us, il traffico in uscita verso una regione negli Stati Uniti, ad esempio us-central, non viene addebitato mentre verso qualsiasi regione del Canada o del Sud America.
    • Per la località multiregionale asia, il traffico in uscita verso le regioni in Asia, come asia-northeast1, non viene addebitato, mentre quello verso le regioni in Australia viene addebitato.

  • 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 carichi di lavoro o in una località multiregionale che corrisponde alla regione con i tuoi carichi di lavoro. L'inserimento di flussi di immagini può ridurre significativamente i tempi di inizializzazione del carico di lavoro quando si utilizzano 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 ha bisogno di scaricare artefatti da Artifact Registry alle proprie workstation locali, un repository in un'area geografica 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 per le località delle risorse nei criteri dell'organizzazione di 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 disponi di repository esistenti in località non conformi, devi spostare personalmente gli artefatti in un repository in una 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 delle versioni degli artefatti che non ti servono più o per la conservazione degli artefatti che vuoi archiviare a tempo indeterminato.

I criteri di pulizia sono utili se archivi molte versioni degli artefatti, ma devono solo conservare le versioni specifiche che rilasci in produzione. Puoi definire i criteri di eliminazione con criteri per l'eliminazione degli artefatti e i criteri di conservazione con criteri per la conservazione degli artefatti.

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

Elimina criteri

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

  • Stato del tag: indica se il criterio deve verificare la presenza di elementi con tag o senza tag. Gli artefatti vengono taggati quando si esegue il push o il pull di un'immagine da 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 agli artefatti sia con tag che 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. Gli artefatti con tag nei repository con tag immutabili abilitati non possono essere eliminati.

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

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

  • Prefissi di tag: si tratta di un elenco di prefissi di tag separati da virgole. Ad esempio, i prefissi test e staging corrispondono a immagini con tag testenv e staging-1.5. Per utilizzare i prefissi tag, tagState deve essere impostato su TAGGED.
    • Prefissi di versione: - sono un elenco separato da virgole di prefissi delle versioni dell'artefatto. 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 un prefisso. Ad esempio, red, blue crea 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 dal caricamento di una versione dell'artefatto nel repository, specificato come durata. Ad esempio, 30d corrisponde a 30 giorni. Puoi specificare durate in secondi, minuti, ore o giorni aggiungendo rispettivamente s, m, h o d.
  • Più recente di: è un tempo massimo trascorso dal caricamento di una versione dell'artefatto nel repository, specificato come durata. Ad esempio, 30d corrisponde a 30 giorni.

Conserva i criteri

I criteri di conservazione mantengono gli artefatti corrispondenti alle stesse condizioni dei criteri di eliminazione o a un numero prestabilito 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 Conserva le versioni più recenti è impostato in modo da mantenere tre versioni dei pacchetti corrispondenti ai prefissi pacchetto: {release-xyz}, solo release-xyz-v1 e release-xyz-v2 vengono conservate.

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

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

Assistenza per i domini gcr.io

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

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

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

Struttura del progetto

La gerarchia delle risorse è il modo in cui organizzare le risorse nei progetti Google Cloud. La struttura che scegli dipende da fattori quali i requisiti di governance dei dati, i confini di attendibilità 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 sola persona o un solo team gestisce l'amministrazione e l'accesso ai repository in tutta l'organizzazione.
Può anche semplificare la configurazione di soluzioni o repository virtuali come Software Delivery Shield, poiché è sufficiente abilitare e gestire una singola istanza di Artifact Registry.
Repository specifici del progetto
Crea repository in progetti che archiviano e scaricano artefatti. Questo approccio potrebbe essere necessario quando hai criteri di governance dei dati o confini di attendibilità che richiedono una maggiore separazione e controllo delle risorse a livello di progetto.

Controllo dell'accesso

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

Alcuni servizi Google Cloud usano 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 processo di sviluppo del software o non rispettare i 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 dal servizio che lo interagisce.
  • Stai utilizzando i 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 altre entità che richiedono l'accesso ai repository, l'amministratore del repository deve concedere l'accesso. Secondo il principio di sicurezza del privilegio minimo, concedi le autorizzazioni minime richieste. Ad esempio:

  • Esegui il deployment delle immagini container in Artifact Registry nei cluster GKE in diversi progetti. L'account di servizio per i nodi in questi cluster richiede solo l'accesso in lettura ai repository.
  • Hai un repository di sviluppo per le applicazioni in fase di sviluppo e produzione per le applicazioni 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 demo con applicazioni di esempio. Il team di vendita richiede solo l'accesso di sola lettura per scaricare le demo.

Crittografia dei dati

Per impostazione predefinita, Google Cloud cripta automaticamente i dati quando sono inattivi utilizzando chiavi di proprietà di Google e gestite da Google. Se hai requisiti normativi o di conformità specifici 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 CMEK per proteggere le risorse.

Etichette e tag

Le etichette consentono di organizzare le risorse specifiche di 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 per team per l'automazione o la fatturazione. Per ulteriori informazioni sulla creazione e sull'utilizzo delle etichette dei repository, consulta Etichettatura dei repository.

Puoi anche applicare tag ai repository. Mentre le etichette servono principalmente a organizzare e filtrare le risorse specifiche dei servizi, i tag servono per il controllo programmatico dei criteri in un'organizzazione Google Cloud. Per maggiori informazioni, consulta la pagina relativa al tagging dei repository.

Passaggi successivi