Architettura del servizio Cloud Deploy

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

La visualizzazione di alto livello

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

Relazioni tra i componenti di Cloud Deploy

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

  • Il tuo sistema CI

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

  • Cloud Build

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

  • Skaffold

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

  • Cloud Storage

    Cloud Deploy archivia l'origine di rendering e i manifest sottoposti a rendering in un bucket Cloud Storage.

  • Osservabilità di Google Cloud e Audit log di Cloud.

    Google Cloud Observability raccoglie e rende disponibili i dati di logging per Cloud Deploy.

    Vedi anche Audit logging.

  • Pub/Sub

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

    Consulta Iscrizione alle notifiche di Cloud Deploy per ulteriori informazioni.

  • Runtime di destinazione

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

Risorse di Cloud Deploy

Il seguente diagramma mostra le risorse utilizzate da Cloud Deploy per distribuire le tue 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ò produrre zero o più release e può fare riferimento a uno o più target, inclusi più target e i relativi target secondari associati.

  • La pipeline di distribuzione può anche fare riferimento a una o più automazioni, che automatizzano le azioni sulle risorse Cloud Deploy.

  • Ogni release include l'istanza della pipeline, uno "snapshot" della pipeline di distribuzione e dei target così come sono stati configurati al momento della creazione della release.

  • Ogni release può comportare 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 raggruppate logicamente insieme, ad esempio un deployment o un deployment e una verifica.

    Ogni fase include uno o più job a rappresentare ciò che deve essere fatto durante l'implementazione: il deployment o la verifica. Ogni job può includere una o più esecuzioni di job, ovvero istanze di job, ad esempio un tentativo di deployment. Un'esecuzione di job è una risorsa figlio dell'implementazione.

    I target multipli, utilizzati per il deployment parallelo, creano implementazioni del controller, che creano implementazioni figlio, corrispondenti alle destinazioni figlio.

  • Ogni implementazione è associata a una destinazione.

    Per il deployment parallelo , ogni target figlio è associato a un'implementazione figlio.

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

  • Un target può essere associato 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 è costituita da una o più fasi, mentre le fasi hanno uno o più job e una o più esecuzioni di job.

Risorse di implementazione

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 è suddivisa in una o più fasi. Una fase è un messaggio secondario di un'implementazione.

  • Job

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

  • JobRuns

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

Le automazioni contengono regole di automazione alle quali possono fare riferimento zero o più risorse AutomationRun. Gli AutomationRuns sono istanze di regole di automazione eseguite, ad esempio una promozione automatica da una destinazione all'altra. Le risorse Automation e AutomationRun sono risorse peer-child al di sotto di una pipeline di distribuzione.

Risorse per l'Automation

Come interagiscono per pubblicare la nuova uscita

Questa sezione descrive in che modo Cloud Deploy interagisce con i componenti elencati in questo documento per automatizzare la distribuzione della tua applicazione come release.

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

    Il processo CI chiama Cloud Deploy utilizzando l'CLI o l'API per creare una nuova release, passando gli artefatti o i riferimenti alla build alle immagini.

    Per saperne di più sull'integrazione del sistema CI, consulta Integrazione di Cloud Deploy con altri sistemi.

  2. Quando viene creata una nuova release, Cloud Deploy procede come segue:

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

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

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

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

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

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

    4. Chiama l'operazione render.

      Se utilizzi destinazioni integrate, Cloud Deploy chiama skaffold render per eseguire il rendering del manifest utilizzando le immagini fornite o gli artefatti della build. Cloud Deploy sostituisce i nomi delle immagini in spec.templates.spec.containers.image con i percorsi completi delle immagini (inclusi digest o tag) forniti nel comando gcloud deploy releases create o in un file degli artefatti di build a cui fa riferimento il comando.

      Se utilizzi un target personalizzato, Cloud Deploy chiama l'operazione render definita per il suo tipo di target personalizzato.

      Cloud Deploy archivia il manifest visualizzato nel bucket Cloud Storage predefinito o alternativo.

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

  3. Quando viene creata un'implementazione (automaticamente dopo la creazione della release o on demand in un secondo momento), Cloud Deploy procede come segue:

    1. Chiamate agli hook pre-deployment, se specificati.

      Se utilizzi una strategia di deployment canary, gli hook pre-deployment vengono chiamati all'inizio della prima fase.

    2. Chiama l'operazione deploy.

      Se utilizzi destinazioni integrate, Cloud Deploy crea ed esegue automaticamente il deployment di un'implementazione nella prima destinazione, chiamando skaffold apply. Se utilizzi un target integrato, la prima implementazione viene creata automaticamente al momento della creazione della release.

      Se utilizzi un target personalizzato, Cloud Deploy crea automaticamente un'implementazione nel primo target, chiamando l' operazione deploy definita per il suo tipo di destinazione personalizzato.

      Per i target integrati e personalizzati, l'implementazione nel primo target è automatica solo quando la release viene creata tramite la riga di comando.

      Il processo di deployment nella prima destinazione è lo stesso utilizzato per le promozioni, come descritto nel passaggio successivo.

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

    4. Richiama gli hook post-deployment, se specificati, dopo verify, se è specificato un valore verify. In caso contrario, gli hook post-deployment vengono chiamati dopo deploy.

      Se utilizzi una strategia di deployment canary, gli hook post-deployment vengono eseguiti come ultimo job nella fase di implementazione finale.

  4. Quando è il momento di promuovere la release alla destinazione successiva, Cloud Build recupera il manifest specifico per la destinazione da Cloud Storage. A questo punto, Cloud Build richiama skaffold apply per applicare il manifest visualizzato al runtime di destinazione specificato.

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

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

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

    Questo processo è valido non solo per le promozioni, ma anche per i rollback e per i nuovi deployment.

  5. Nel corso delle operazioni di 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 ulteriormente in Integrazione di Cloud Deploy con sistemi esterni.

  6. Puoi specificare un'automazione per eseguire automaticamente varie operations all'interno della pipeline di distribuzione. che possono essere eseguiti al momento indicato. Un elemento automationRun rappresenta l'esecuzione di una regola di automazione.

  7. Durante l'operazione di Cloud Deploy, il servizio scrive i log della piattaforma e gli audit log in Google Cloud Observability e Cloud Audit Logs.

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

Passaggi successivi