Panoramica dei repository

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

Quando crei i repository, prendi in considerazione sia i processi interni per la creazione degli artefatti sia l'utilizzo degli artefatti da parte dei consumatori.

Formati dei repository

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

Modalità del repository

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

Repository standard

I repository standard sono repository Artifact Registry regolari per i tuoi artefatti privati. Carichi e scarichi gli artefatti direttamente con questi repository e utilizzi l'Artifact Analysis per eseguire la scansione 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 artefatti dalle seguenti origini upstream:

  • Repository Artifact Registry standard.
  • Sorgenti esterne come Docker Hub, Maven Central, Python Package Index (PyPI), Debian o CentOS.

La prima volta che richiedi una versione dell'artefatto, il repository la scarica dall'origine upstream e memorizza nella cache una copia. Il repository remoto fornisce 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 build e le implementazioni su Google Cloud. Puoi anche utilizzare Artifact Analysis per eseguire la scansione dei pacchetti memorizzati nella cache alla ricerca di vulnerabilità e altri metadati.

Per saperne di più sui repository remoti, leggi 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 unico punto di accesso per scaricare, installare o implementare 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 artefatti. Puoi anche mitigare gli attacchi di confusione delle dipendenze configurando il criterio upstream in modo da dare la priorità ai repository con gli artefatti privati rispetto ai repository remoti che memorizzano nella cache gli artefatti pubblici.

Per saperne di più sui repository virtuali, leggi la 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 tanti modi possibili per utilizzare i repository in diverse modalità. Il diagramma mostra un flusso di lavoro in due progettiGoogle 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. 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 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 componente.

  2. Nel progetto di runtime, Cloud Build inserisce l'applicazione Java in un container.

    La build utilizza il repository virtuale Maven per scaricare l'applicazione. Il repository virtuale pubblica 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 container creata in un repository Docker standard.

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

    • Il repository Docker standard upstream fornisce immagini private, ad esempio l'applicazione Java containerizzata.
    • Il repository remoto upstream fornisce le immagini che GKE richiede a 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 posizione

Questa sezione descrive i motivi per cui potresti voler creare un repository nella stessa regione di altri servizi Google Cloud .

Puoi ridurre la latenza e i costi del 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 verso altri servizi Google Cloud nella stessa regione.

Sebbene non siano previsti costi per il traffico in uscita da un servizio multiregionale a un servizioGoogle Cloud in una regione corrispondente, questi prezzi si applicano solo a un insieme limitato di regioni.

  • Per la multiregione us, il traffico in uscita verso una regione degli Stati Uniti come us-central non viene addebitato, mentre il traffico in uscita verso qualsiasi regione del Canada o del Sud America viene addebitato.
  • Per la multi-regione asia, il traffico in uscita verso regioni in Asia come asia-northeast1 non viene addebitato, ma il traffico in uscita verso regioni in Australia viene addebitato.
Puoi utilizzare lo streaming 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 multipla che corrisponde alla regione con i tuoi carichi di lavoro. Lo streaming delle immagini può ridurre significativamente il tempo di inizializzazione del carico di lavoro quando utilizzi immagini di container più grandi, poiché i carichi di lavoro possono iniziare prima che l'intera immagine venga scaricata.

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

Limitazione delle località dei repository

Se devi rispettare normative o criteri che richiedono l'archiviazione dei dati in regioni specifiche, puoi includere un vincolo relativo alle località delle risorse nei criteri dell'organizzazione Google Cloud che consentono la creazione di repository solo nelle regioni conformi. Artifact Registry applica il vincolo solo dopo che lo hai incluso nella policy dell'organizzazione. Se hai repository esistenti in località non conformi, devi spostare gli artefatti 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 l'eliminazione automatica delle versioni degli artefatti che non ti servono più o per la conservazione degli artefatti che vuoi archiviare a tempo indeterminato.

Le norme di pulizia sono utili se memorizzi molte versioni dei tuoi artefatti, ma devi conservare solo le versioni specifiche che rilasci in produzione. Puoi definire criteri di eliminazione con criteri per l'eliminazione degli artefatti e criteri di conservazione con criteri per la conservazione degli artefatti.

Se una versione di un artefatto corrisponde ai criteri sia di una norma di eliminazione sia di una norma di conservazione, Artifact Registry applica la norma di conservazione.

Elimina norme

I criteri di eliminazione eliminano gli artefatti che corrispondono ai seguenti criteri obbligatori:

  • Stato tag: indica se il criterio deve verificare la presenza di artefatti taggati o senza tag. Gli artefatti vengono taggati quando viene eseguito il push o il pull di un'immagine in o da 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 artefatti taggati sia a quelli non taggati.
    • Taggati: si applica solo agli artefatti taggati.
    • Senza tag: si applica solo agli elementi senza tag.

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

    Per ulteriori informazioni sullo stato dei tag in relazione alle norme di pulizia, consulta il riferimento TagState.

Di seguito sono riportati modi facoltativi per definire le norme di eliminazione:

  • Prefissi dei tag: è un elenco separato da virgole di prefissi dei tag. Ad esempio, i prefissi test e staging corrisponderebbero a immagini con i tag testenv e staging-1.5. tagState deve essere impostato su TAGGED per utilizzare i prefissi dei tag.
    • Prefissi di versione: - è un elenco separato da virgole dei prefissi di versione 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 i prefissi. Ad esempio, red, blue creerebbe due prefissi, red e blue, e corrisponderebbe ai nomi degli artefatti red-team, redis e bluebird.
  • Precedente a: è un tempo minimo trascorso da quando una versione dell'artefatto è stata caricata nel repository, specificato come durata. Ad esempio, 30d è di 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 dall'upload di una versione dell'artefatto nel repository, specificato come durata. Ad esempio, 30d è di 30 giorni.

Mantieni i criteri

I criteri di conservazione mantengono gli artefatti che corrispondono alle stesse condizioni dei criteri di eliminazione oppure un numero prestabilito di versioni più recenti.

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

Le eliminazioni attivate dalle norme 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 tuo repository, vedi Configurare criteri di pulizia.

Supporto del dominio gcr.io

Artifact Registry supporta l'hosting di immagini sul dominio gcr.io. Se stai eseguendo la transizione da Container Registry ad Artifact Registry, puoi configurare i repository gcr.io di Artifact Registry 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 di repository gcr.io quando la prima immagine viene inviata a un nome host gcr.io per la compatibilità con il comportamento di Container Registry.

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

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 quali i requisiti di governance dei dati, i limiti di attendibilità e la struttura del team.

Esistono due approcci generali per configurare i repository nelle organizzazioni multi-progetto.

Centralizzare i repository
Crea tutti i repository in un unico progetto e poi concedi l'accesso ai principal 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 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 quando disponi di norme di governance dei dati o limiti di attendibilità che richiedono una maggiore separazione e controllo a livello di progetto delle risorse.

Controllo degli accessi

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

Alcuni servizi Google Cloud utilizzano service account predefiniti con autorizzazioni predefinite per i repository nello stesso progetto Google Cloud . Tuttavia, questi valori predefiniti potrebbero non essere adatti al tuo processo di sviluppo software o potrebbero non essere conformi ai requisiti di sicurezza o delle norme della tua organizzazione. L'amministratore del repository deve concedere esplicitamente l'accesso ai repository a questi servizi se:

  • Artifact Registry si trova in un progetto diverso dal servizio che interagisce con esso.
  • Stai utilizzando ruoli IAM personalizzati con i service account predefiniti anziché il ruolo predefinito.
  • Non stai utilizzando il 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 altri principal che richiedono l'accesso ai repository, l'amministratore del repository deve concedere l'accesso. Segui il principio di sicurezza del privilegio minimo e concedi le autorizzazioni minime richieste. Ad esempio:

  • Esegui il deployment delle immagini container in Artifact Registry nei cluster GKE in diversi progetti. Il 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 l'accesso di sola lettura al repository di produzione.
  • Hai un repository demo con applicazioni di esempio. Il tuo team di vendita richiede solo l'accesso di sola lettura per scaricare le demo.

Limitare i download degli artefatti

Puoi limitare i download di artefatti con le regole di download. Le regole di download consentono o negano i download di artefatti dai repository e dai 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 artefatti della panoramica Controllare l'accesso e proteggere gli artefatti.

Crittografia dei dati

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

Etichette e tag

Le etichette forniscono un modo per 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 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ù su come creare e utilizzare le etichette dei repository, vedi Etichettatura dei repository.

Puoi anche applicare tag ai repository. Mentre le etichette servono principalmente per organizzare e filtrare le risorse specifiche del servizio, i tag servono per il controllo programmatico delle policy in un'organizzazione. Google Cloud Per ulteriori informazioni, vedi Tagging dei repository.

Passaggi successivi