Panoramica dei repository

Artifact Registry ti consente di archiviare diversi tipi di elementi, creare più repository in un unico progetto e associare a ogni repository una località regionale o multi-regionale specifica. Questa pagina descrive considerazioni per aiutarti a pianificare le località e l'organizzazione dei tuoi repository.

Quando crei i repository, tieni conto sia dei processi interni per la creazione degli elementi sia del loro utilizzo da parte dei consumatori.

Formati dei repository

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

Modalità del repository

Esistono più modalità di repository. Ogni modalità ha uno scopo diverso, pertanto non puoi modificare la modalità del repository dopo averlo creato.

Repository standard

I repository standard sono normali repository Artifact Registry per i tuoi artefatti privati. Carichi e scarichi gli elementi direttamente con questi repository e utilizzi Artifact Analysis per eseguire la scansione alla ricerca di vulnerabilità e altri metadati.

Per creare repository standard, segui i passaggi descritti in Creare repository standard.

Repository remoto

I repository remoti sono repository di sola lettura che fungono da proxy per archiviare gli elementi delle seguenti origini upstream:

  • Repository Artifact Registry standard.
  • Sorgenti esterne come Docker Hub, Maven Central, l'indice dei pacchetti Python (PyPI), Debian o CentOS.

La prima volta che richiedi una versione dell'elemento, il repository la scarica dalla fonte a monte e ne memorizza una copia nella cache. Il repository remoto 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 le compilazioni e i deployment su Google Cloud. Puoi anche utilizzare Analisi degli elementi per eseguire la scansione dei pacchetti memorizzati nella cache per rilevare vulnerabilità e altri metadati.

Per scoprire di più sui repository remoti, consulta la Panoramica dei repository remoti. Per creare repository remoti, segui i passaggi descritti in Creare repository remoti.

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 un repository standard, remoto o virtuale.

I repository virtuali semplificano la configurazione del client per i consumatori dei tuoi elementi. Puoi anche mitigare gli attacchi di confusione delle dipendenze configurando il criterio di upstream in modo da dare la priorità ai repository con i tuoi elementi privati rispetto ai repository remoti che memorizzano nella cache gli elementi pubblici.

Per saperne di più sui repository virtuali, consulta Panoramica dei repository virtuali. Per creare repository virtuali, segui i passaggi descritti in Creare repository virtuali.

Esempio di utilizzo del repository

Il seguente diagramma mostra uno dei molti modi possibili per utilizzare i repository in modalità diverse. Il diagramma mostra un flusso di lavoro in due Google Cloud progetti. In un progetto di sviluppo, gli sviluppatori creano un'applicazione Java. In un progetto di runtime separato, un'altra compilazione crea un'immagine del contenitore 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 compilazione può richiedere dipendenze Java pubbliche utilizzando il repository virtuale. Il repository virtuale serve le dipendenze dal repository remoto, che è un proxy con cache per Maven Central.
    • Cloud Build carica il pacchetto nel repository Maven standard nel progetto del componente.

  2. Nel progetto di runtime, Cloud Build esegue il containerizzazione dell'applicazione Java.

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

  3. Nel progetto di runtime, Cloud Build carica l'immagine del container compilata 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 upstream fornisce le immagini richieste da GKE da Docker Hub.

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

Località repository

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

Considerazioni sulla località

Questa sezione descrive perché potresti voler creare un repository nella stessa regione di altri Google Cloud servizi.

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

Sebbene non venga addebitato alcun costo per il traffico in uscita da una regione a più regioni a un Google Cloud servizio in una regione corrispondente, questi prezzi si applicano solo a un insieme limitato di regioni.

  • Per la regione multipla us, il traffico in uscita verso una regione degli Stati Uniti come us-central non viene addebitato, mentre viene addebitato per qualsiasi regione del Canada o del Sud America.
  • Per la regione multipla asia, il traffico in uscita verso regioni asiatiche come asia-northeast1 non viene addebitato, ma viene addebitato il traffico in uscita verso regioni australiane.
Puoi utilizzare lo streaming di immagini solo in GKE e Dataproc Serverless se le immagini dei contenitori sono archiviate nei repository Artifact Registry nella stessa regione dei tuoi workload o in una regione con più regioni che corrisponde alla regione con i tuoi workload. Lo streaming di immagini può ridurre in modo significativo il tempo di inizializzazione dei carichi di lavoro quando utilizzi immagini contenitore più grandi, poiché i carichi di lavoro possono iniziare prima del download dell'intera immagine.

Prendi in considerazione la posizione dei consumatori al di fuori di Google Cloud. Ad esempio, se il team di sviluppatori in Australia deve scaricare gli elementi da Artifact Registry sulle proprie stazioni di lavoro locali, un repository in una regione australiana ridurrà la latenza e comporterà costi di uscita inferiori rispetto a un repository 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 delle località delle risorse nel criterio dell'organizzazione Google Cloudche consenta la creazione di repository solo nelle regioni conformi. Artifact Registry applica il vincolo solo dopo che lo hai incluso nei criteri della tua organizzazione. Se hai già dei repository in località non conformi, devi spostare manualmente gli elementi in un repository in una località conforme ed eliminare il repository non conforme.

Criteri di pulizia

Un criterio di pulizia di Artifact Registry definisce i criteri per eliminare automaticamente le versioni degli artefatti di cui non hai più bisogno o per conservare gli artefatti che vuoi archiviare a tempo indeterminato.

I criteri di pulizia sono utili se memorizzi molte versioni dei tuoi elementi, ma devi conservare solo versioni specifiche rilasciate in produzione. Puoi definire criteri di eliminazione con i criteri per eliminare gli elementi e criteri di conservazione con i criteri per conservarli.

Se una versione dell'elemento corrisponde ai criteri sia in una norma di eliminazione sia in una norma di conservazione, Artifact Registry applica la norma di conservazione.

Eliminare i criteri

I criteri di eliminazione eliminano gli elementi corrispondenti ai seguenti criteri obbligatori:

  • Stato tag: indica se il criterio deve verificare la presenza di artefatti con tag o di artefatti senza tag. Gli elementi vengono taggati quando viene eseguita l'estrazione o l'importazione di un'immagine da o in un repository. Per saperne di più sui tag Docker, consulta Concetti relativi ai container.

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

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

    Per ulteriori informazioni sullo stato del tag in relazione alle norme di pulizia, consulta la pagina Riferimento a TagState.

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

  • Prefisso dei tag: è un elenco separato da virgole di prefissi dei tag. Ad esempio, i prefissi test e staging corrispondono alle immagini con i tag testenv e staging-1.5. tagState deve essere impostato su TAGGED per utilizzare i prefissi dei tag.
    • Prefissi versione: è un elenco separato da virgole dei prefissi delle versioni degli elementi. Ad esempio, v1, v2 corrisponderebbe alle versioni v1.5, v2.0alpha e v10.2.
  • Prefissi pacchetto: è un elenco di prefissi dei nomi degli elementi. Puoi inserire più prefissi premendo Enter o , tra un prefisso e l'altro. Ad esempio, red, blue creerebbe due prefissi, red e blue, e corrisponderebbe ai nomi degli elementi red-team, redis e bluebird.
  • Più vecchio di: è un intervallo di tempo minimo trascorso dal caricamento di una versione dell'elemento 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: è il tempo massimo trascorso dal caricamento di una versione dell'elemento nel repository, specificato come durata. Ad esempio, 30d corrisponde a 30 giorni.

Criteri di Keep

I criteri di conservazione mantengono gli elementi corrispondenti alle stesse condizioni dei criteri di eliminazione o un numero predefinito di versioni più recenti.

Ad esempio, dato un repository contenente i seguenti elementi:

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 per conservare 3 versioni dei pacchetti corrispondenti ai Prefisso del pacchetto: {release-xyz}, vengono conservati solo release-xyz-v1 e release-xyz-v2.

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

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

Supporto per il dominio gcr.io

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

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

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

Struttura del progetto

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

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

Centralizzare i repository
Crea tutti i repository in un unico progetto e poi concedi l'accesso ai principali di altri progetti a livello di repository. Questo approccio può essere più efficace se una singola persona o un team gestisce l'amministrazione e l'accesso al repository in tutta l'organizzazione.
Può anche semplificare la configurazione dei repository virtuali, poiché devi solo attivare e gestire una singola istanza di Artifact Registry.
Repository specifici per progetto
Crea repository nei progetti che archiviano e scaricano gli artefatti. Questo approccio potrebbe essere necessario se hai criteri di governance dei dati o confini di attendibilità che richiedono una maggiore separazione e un maggiore controllo delle risorse a livello di progetto.

Controllo degli accessi

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

Alcuni Google Cloud servizi utilizzano account di servizio predefiniti con autorizzazioni predefinite per i repository nello stesso Google Cloud progetto. Tuttavia, questi valori predefiniti potrebbero non essere adatti al processo di sviluppo del software o non essere conformi ai requisiti di sicurezza o ai 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 da quello del servizio che interagisce con esso.
  • Utilizzi ruoli IAM personalizzati con gli account di servizio predefiniti anziché il ruolo predefinito.
  • Non utilizzi l'account di servizio predefinito per il Google Cloud servizio.
  • Stai configurando repository virtuali. Devi concedere esplicitamente all'account di servizio Artifact Registry l'accesso ai repository di upstream.

Per gli altri principali che richiedono l'accesso ai repository, l'amministratore del repository deve concedere l'accesso. In base al 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 di 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 un repository di produzione per le applicazioni rilasciate. Gli sviluppatori richiedono l'accesso in lettura e scrittura al repository di sviluppo e accesso di sola lettura al repository di produzione.
  • Hai un repository demo con applicazioni di esempio. Il team di vendita richiede solo accesso di sola lettura per scaricare le demo.

Limitare i download di elementi

Puoi limitare i download degli elementi con le regole di download. Le regole di download ti consentono di consentire o negare i download di artefatti dai tuoi repository e pacchetti. Puoi anche impostare condizioni in modo che la regola si applichi a tag o versioni specifici.

Per informazioni dettagliate sul funzionamento delle regole di download, consulta la sezione Limitare i download degli elementi della panoramica Controlla l'accesso e proteggi gli elementi.

Crittografia dei dati

Per impostazione predefinita, Google Cloud cripta automaticamente i dati quando sono in stato at-rest utilizzandodi proprietà di Google e gestite da Google basate su Google Cloud. Se hai requisiti specifici di conformità o normativi 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 delle policy dell'organizzazione che possono richiedere CMEK per proteggere le risorse.

Etichette e tag

Le etichette consentono di organizzare le risorse specifiche di un Google Cloud servizio. In Artifact Registry, puoi aggiungere etichette ai repository in modo da poterli raggruppare o filtrare gli elenchi dei repository in base all'etichetta. Ad esempio, puoi utilizzare le etichette per raggruppare i repository in base alla fase di sviluppo o al team per scopi di automazione o fatturazione. Per saperne di più sulla creazione e sull'utilizzo delle etichette dei repository, consulta Etichettare i repository.

Puoi anche applicare tag ai repository. Sebbene le etichette siano destinate principalmente all'organizzazione e al filtro delle risorse specifiche del servizio, i tag sono destinati al controllo programmatico delle norme in un' Google Cloud organizzazione. Per ulteriori informazioni, consulta Etichettare i repository.

Passaggi successivi