Architettura del servizio Cloud Deploy

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

Visualizzazione di alto livello

Il seguente diagramma mostra le relazioni tra Cloud Deploy e i sistemi separati da cui dipende.

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, a condizione che 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 eseguire 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 del rendering e i manifest sottoposti a rendering in un bucket Cloud Storage.

  • Google Cloud Observability e Cloud Audit Logs.

    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.

    Per saperne di più, consulta Iscrizione alle notifiche di Cloud Deploy .

  • 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 Cloud Deploy

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

Relazioni tra le risorse Cloud Deploy

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

  • La pipeline di distribuzione può generare zero o più release e può fare riferimento a uno o più target, inclusi i target multipli e i relativi target figlio 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, ovvero uno "snapshot" della pipeline di distribuzione e delle destinazioni così come erano configurate al momento della creazione della release.

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

    Ogni fase include uno o più job, che rappresentano le operazioni da eseguire durante l'implementazione, ovvero il deployment o la verifica. Ogni job può includere una o più esecuzioni di job, che sono istanze di job, ad esempio un tentativo di deployment. Un'esecuzione di job è una risorsa secondaria dell'implementazione.

    I target multipli, utilizzati per l'implementazione parallela, creano implementazioni del controller, che creano implementazioni secondarie, che corrispondono ai target secondari.

  • Ogni implementazione è associata a un target.

    Per l'implementazione parallela , ogni target secondario è associato a un rollout secondario.

  • 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) che viene implementato in un runtime di destinazione nell'ambito di un rollout.

Inoltre, un'implementazione ha una o più fasi e le fasi hanno uno o più job e una o più esecuzioni di job.

Risorse per l'implementazione

Come mostrato in questo diagramma, un lancio include quanto segue:

  • Fasi

    Una fase contiene uno o più job (ad esempio deploy o deploy e verifica). Ogni implementazione ha una o più fasi. Una fase è un sotto-messaggio in un lancio.

  • Job

    L'operazione specifica da eseguire su un'implementazione, ad esempio deploy o verify. 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 secondaria di un'implementazione.

Le automazioni contengono regole di automazione, a cui possono fare riferimento zero o più risorse AutomationRun. AutomationRuns sono istanze di regole di automazione eseguite, ad esempio una promozione automatica da un target a un altro. Le risorse Automation e AutomationRun sono risorse peer-child sotto una pipeline di distribuzione.

Risorse per l'Automation

Come si combinano per pubblicare la release

Questa sezione descrive come Cloud Deploy interagisce con i componenti elencati in questo documento per automatizzare la distribuzione dell'applicazione come release.

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

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

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

  2. Quando viene creata una nuova release, Cloud Deploy esegue le seguenti operazioni:

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

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

      Inoltre, la versione di Skaffold viene memorizzata come parte della release. Nella maggior parte dei casi, questa sarà la versione Skaffold predefinita, ma poiché puoi specificare altre versioni, queste informazioni vengono memorizzate.

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

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

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

    4. Chiama l'operazione render.

      Se utilizzi target integrati, Cloud Deploy chiama skaffold render per eseguire il rendering del manifest utilizzando le immagini o gli artefatti di build forniti. 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 di artefatti di build a cui fa riferimento il comando.

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

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

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

  3. Quando viene creato un rollout (automaticamente dopo la creazione della release o su richiesta in un secondo momento), Cloud Deploy esegue le seguenti operazioni:

    1. Chiama gli hook di pre-deployment, se specificati.

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

    2. Chiama l'operazione deploy.

      Se utilizzi target integrati, Cloud Deploy crea ed esegue automaticamente il deployment di un rollout nel primo target 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 rollout per il primo target, chiamando l'operazione deploy definita per il tipo di target personalizzato.

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

      La procedura di deployment sul primo target è la stessa delle promozioni, come descritto nel passaggio successivo.

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

    4. Chiama gli hook post-deployment, se specificati, dopo verify, se è specificato un 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 al target successivo, Cloud Build recupera il manifest specifico per il target da Cloud Storage. Poi Cloud Build richiama skaffold apply per applicare il manifest sottoposto a rendering al runtime di destinazione specificato.

    Se la destinazione richiede l'approvazione, puoi approvare o rifiutare tramite la CLI o utilizzando la console.

    Inoltre, Cloud Deploy genera un messaggio Pub/Sub, a cui puoi abbonarti 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 vale non solo per le promozioni, ma anche per i rollback e per i nuovi deployment.

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

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

  6. Puoi specificare un'automazione per eseguire automaticamente varie operazioni all'interno della pipeline di distribuzione. Questi possono essere eseguiti all'ora designata. Un automationRun rappresenta l'esecuzione di una regola di automazione.

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

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

Passaggi successivi