Architettura del servizio Google Cloud Deploy

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questo documento descrive le relazioni tra Google Cloud Deploy e i sistemi esterni con cui lavora per il deployment delle applicazioni. Questi sistemi sono altri servizi Google Cloud e strumenti di terze parti.

La visualizzazione generale

Il seguente diagramma mostra le relazioni tra Google Cloud Deploy e i sistemi separati su cui si basa.

Relazioni tra i componenti di Cloud Deploy

Come mostrato in questo diagramma, Google Cloud Deploy interagisce con i seguenti sistemi:

  • Il tuo sistema CI

    Google Cloud Deploy supporta la maggior parte degli strumenti CI, a condizione che un output del processo di CI possa essere una chiamata all'API o CLI di Google Cloud Deploy per creare una release.

  • Cloud Build

    Google Cloud Deploy chiama Cloud Build per il rendering dei tuoi manifest e per il deployment nel runtime di destinazione.

  • Skaffold

    Google Cloud Deploy utilizza Skaffold tramite Cloud Build per il rendering e il deployment dei manifest, eseguendo quindi il deployment dell'applicazione.

  • Cloud Storage

    Google Cloud Deploy archivia i manifest di origine e di rendering in un bucket Cloud Storage.

  • Suite operativa di Google Cloud e Cloud Audit Logs.

    La suite operativa di Google Cloud raccoglie e rende disponibili i dati di logging per Google Cloud Deploy.

    Vedi anche Log di controllo.

  • Pub/Sub

    Google Cloud Deploy pubblica messaggi in diversi argomenti Pub/Sub. Puoi utilizzare questo servizio per l'integrazione con il flusso di lavoro esterno, i test e altri sistemi correlati.

    Per ulteriori informazioni, consulta l'articolo Iscrizione alle notifiche di Google Cloud Deploy .

  • Runtime di destinazione

    Google Cloud Deploy utilizza skaffold apply, tramite Cloud Build, per eseguire il deployment delle tue applicazioni nel runtime di destinazione (GKE o Anthos).

Risorse Google Cloud Deploy

Il seguente diagramma mostra le risorse utilizzate da Google Cloud Deploy per distribuire le applicazioni e le relazioni tra queste risorse:

Relazioni tra risorse Cloud Deploy

Come mostrato in questo diagramma, le relazioni tra le risorse sono le seguenti:

  • La pipeline di distribuzione può restituire zero o più release e può fare riferimento a una o più target.

  • Ogni release include l'istanza della pipeline, ovvero una "istantanea" della pipeline di distribuzione e dei relativi target configurati al momento della creazione della release.

  • Ogni release può restituire zero o più implementazioni e può fare riferimento a zero o più artefatti.

    Ogni implementazione include almeno una fase, che rappresenta una raccolta di operazioni (job) in un'implementazione logicamente raggruppate, ad esempio un deployment o un deployment e verifica.

    Ogni fase include uno o più job, che rappresentano ciò da fare sull'implementazione: deployment o verifica. Ogni job può includere una o più esecuzioni del job, ovvero istanze di job, ad esempio un tentativo di deployment. Un'esecuzione del job è una risorsa secondaria dell'implementazione.

  • Ogni implementazione è associata a una destinazione.

  • Ogni destinazione è associata a un cluster GKE o Anthos o a un'altra destinazione di runtime per l'applicazione.

  • Una destinazione può essere associata a una o più pipeline di distribuzione.

  • Un artefatto è qualsiasi output del processo CI (ad esempio, un'immagine container) di cui viene eseguito il deployment in un runtime di destinazione nell'ambito di un'implementazione.

Inoltre, un'implementazione comprende una o più fasi e ogni fase ha uno o più job e una o più esecuzioni del job.

Implementa risorse

Come mostrato in questo diagramma, un'implementazione include quanto segue:

  • Fasi

    Una fase contiene uno o più job (ad esempio, deployment o deployment e verifica). Ogni implementazione prevede una o più fasi. Una fase è un messaggio secondario che riguarda un'implementazione.

  • Job

    L'operazione specifica da eseguire su un'implementazione, ad esempio deployment o verifica. Un job è un messaggio secondario durante un'implementazione.

  • Esecuzioni job

    Un'istanza di un job, ad esempio un tentativo di verifica. Ogni job può avere zero o più JobRuns. JobRun è una risorsa secondaria per un'implementazione.

Come interagiscono per offrire la tua uscita

Questa sezione descrive il modo in cui Google Cloud Deploy interagisce con i componenti elencati in questo documento al fine di automatizzare la distribuzione della tua applicazione come release.

  1. Il tuo sistema CI richiama una pipeline di distribuzione di Google Cloud Deploy.

    Il processo CI chiama Google Cloud Deploy tramite interfaccia a riga di comando o API per creare una nuova release, trasmettendo gli artefatti o i riferimenti di build alle immagini.

    Per ulteriori informazioni sull'integrazione del tuo sistema CI, vedi Integrazione di Google Cloud Deploy con altri sistemi.

  2. Quando viene creata una nuova release, Google Cloud Deploy esegue queste operazioni:

    1. Archivia un'istanza della pipeline di distribuzione come parte della release.

      Questa istanza di pipeline rimane invariata per questa release, anche se la configurazione della pipeline di distribuzione viene modificata. Per ulteriori informazioni, consulta la sezione Istanze pipeline per release.

      Inoltre, la versione Skaffold è archiviata come parte della release. Nella maggior parte dei casi, si tratta della versione predefinita di Skaffold, ma poiché puoi specificare altre versioni, le informazioni vengono archiviate.

    2. Richiama Cloud Build, che recupera l'origine di rendering Skaffold da Cloud Storage.

      Google Cloud Deploy archivia l'origine di rendering nel bucket Cloud Storage predefinito o alternativo.

    3. Chiamate skaffold diagnose (utilizzando la versione di Skaffold archiviata al momento della creazione della release) per generare un singolo manifest efficace.

    4. Richiama skaffold render per eseguire il rendering del manifest utilizzando le immagini fornite o crea artefatti.

      Google Cloud Deploy sostituisce i nomi delle immagini in spec.templates.spec.containers.image con i percorsi delle immagini completi (inclusi digest o tag) forniti nel comando gcloud deploy releases create o in un file degli artefatti di build a cui fa riferimento questo comando.

      Google Cloud Deploy archivia il manifest sottoposto a rendering nel bucket Cloud Storage predefinito o alternativo.

      Google Cloud Deploy esegue queste azioni utilizzando l'ambiente di esecuzione predefinito o alternativo.

    5. Crea ed esegue automaticamente il deployment di un'implementazione nel primo target, chiamando skaffold apply.

      Ciò è valido solo quando Google Cloud Deploy è richiamato dall'interfaccia a riga di comando per creare una release.

      Il processo di deployment nel primo target è lo stesso delle promozioni, come descritto nel passaggio successivo.

    6. Richiama skaffold verify, se verify è true per la destinazione nella configurazione della pipeline di distribuzione e se la verifica è specificata nella configurazione Skaffold.

  3. Quando è il momento di promuovere la release al target successivo, Cloud Build recupera il manifest specifico della destinazione da Cloud Storage. Quindi Cloud Build richiama skaffold apply per applicare il manifest sottoposto a rendering al runtime di destinazione specificato.

    Se la destinazione richiede l'approvazione, puoi approvarla o rifiutarla tramite l'interfaccia a riga di comando o utilizzando la console.

    Inoltre, Google Cloud Deploy genera un messaggio Pub/Sub, a cui puoi iscriverti per avviare automaticamente un flusso di lavoro di approvazione.

    Google Cloud Deploy utilizza la versione di Skaffold e l'istanza della pipeline associata a questa release ed esegue questo passaggio nell'ambiente di esecuzione predefinito o personalizzato.

    Questo processo vale non solo per le promozioni, ma anche per i rollback e per le nuove implementazioni.

  4. Durante le operazioni di Google Cloud Deploy, il servizio pubblica notifiche in diversi argomenti Pub/Sub (ad esempio, quando un'implementazione richiede l'approvazione).

    Questa e altre integrazioni sono descritte più avanti in Integrazione di Google Cloud Deploy con sistemi esterni.

  5. Durante l'operazione con Google Cloud Deploy, il servizio scrive i log della piattaforma e gli audit log nella suite operativa e negli audit log di Google Cloud.

Durante tutti questi passaggi, il controllo del flusso e l'accesso alle risorse sono limitati con Identity and Access Management.

Passaggi successivi