Best practice per l'utilizzo di Deployment Manager

Questa pagina descrive le best practice per la creazione di deployment utilizzando Google Cloud Deployment Manager. Questa pagina è pensata per gli utenti che hanno familiarità con Deployment Manager; questa pagina non ti insegnerà a utilizzare Deployment Manager.

Se non hai mai utilizzato Deployment Manager, prova la guida rapida.

Gestione delle risorse

❑  
Dopo aver creato una risorsa nell'ambito di un deployment, utilizza Deployment Manager se devi modificarla. Se modifichi una risorsa senza utilizzare Deployment Manager, ad esempio con la console Google Cloud o gcloud, potresti visualizzare errori se provi a modificare la risorsa nel deployment originale.

Se vuoi rimuovere una risorsa da un deployment senza eliminarla, segui questi passaggi:

  1. Nella configurazione del deployment, elimina la definizione di questa risorsa.
  2. Aggiorna il deployment e nel comando `gcloud` aggiungi --delete-policy ABANDON. La risorsa non è più associata al deployment e puoi quindi modificarla utilizzando la console Google Cloud o gcloud.
❑  
Se nel deployment sono presenti istanze Compute Engine e vuoi collegare dischi permanenti alle istanze, definisci il disco separatamente dall'istanza, in modo da poterlo gestire facilmente. Ad esempio, nel deployment riportato di seguito, il disco example-disk è definito separatamente dall'istanza example-instance. Per collegare il disco, la configurazione ha un riferimento al disco: 
    resources:
    # instance
    - name: example-instance
      type: compute.v1.instance
      properties:
        disks:
          - type: PERSISTENT
            source:$(ref.example-disk.selfLink)
   # disk
   - name: example-disk
     type: compute.v1.disk
     properties:
       zone: us-central1-a
       sizeGb: 10
       type: ...
❑  

Se vuoi creare e gestire cluster Google Kubernetes Engine (GKE) privati con Deployment Manager, imposta le seguenti opzioni privateClusterConfig e ipAllocationPolicy nel deployment.

     privateClusterConfig:
        enablePrivateNodes: true
        enablePrivateEndpoint: true
        #  Configure the IP range for the hosted master network
        masterIpv4CidrBlock: IP_RANGE
      ipAllocationPolicy:
        useIpAliases: true
        createSubnetwork: true

Per i requisiti e le considerazioni aggiuntive durante la creazione di un cluster privato con GKE, leggi Configurazione di un cluster privato.

Inclusione delle credenziali nel deployment

❑  
Deployment Manager redige alcuni campi correlati alle credenziali dalle proprietà nelle configurazioni YAML. Questa oscuramento avviene in base alla chiave della proprietà. L'esempio seguente mostra una di queste modifiche: 
    # Config provided to Deployment Manager
    resources:
    - name: example-resource
      type: gcp-types/service-v1:sample-type-with-password
      properties:
        zone: us-central1-a
        username: test-user
        password: hunter2

   # Config as surfaced by Deployment Manager
   resources:
    - name: example-resource
      type: gcp-types/service-v1:sample-type-with-password
      properties:
        zone: us-central1-a
        username: test-user
        password: (redacted)
❑  
Se includi la credenziale in un modello Jinja o Python per la tua implementazione, la credenziale viene oscurata dai file di configurazione e layout espansi risultanti, ma è ancora visibile nel file di importazione originale. Per questo motivo, ti consigliamo vivamente di inserire tutte le credenziali che intendi mantenere segrete nella configurazione YAML di primo livello. Puoi farvi riferimento utilizzando le proprietà del modello.
❑  
Le credenziali incluse in una coppia chiave-valore all'interno di un file YAML o di un elenco di elementi non verranno oscurate, come nel seguente esempio. Per questo motivo, ti consigliamo vivamente di non fornire le credenziali a Deployment Manager come coppie chiave/valore all'interno di file YAML o elenchi di elementi. 
    # Not a valid instance configuration, used solely for demonstration
    resources:
    - name: example-resource
      type: gcp-types/compute-v1:instances
      properties:
        zone: us-central1-a
        disks:
        - autoDelete: true
          boot: true
    # Will not be redacted
          password: hunter2

Modelli di edifici

❑  
Per velocizzare la definizione dei modelli, ti consigliamo di iniziare con i modelli di esempio pronti per la produzione del progetto Cloud Foundation Toolkit.
❑  
Se hai requisiti di infrastruttura complessi, ad esempio la necessità di creare più ambienti, leggi il tutorial e gli esempi per utilizzare Deployment Manager su larga scala.
❑  
Utilizza Python per creare i tuoi modelli. Puoi utilizzare Python o Jinja2 per creare modelli. Jinja è più facile da usare per iniziare, ma Python è più flessibile per i deployment complessi in cui potresti avere molte risorse suddivise in più ambienti.
❑  
Struttura il file di configurazione (il file YAML) in modo che utilizzi un solo tipo e usa un modello di primo livello come tipo per chiamare tutti gli altri modelli. L'adozione di questa pratica semplifica la conversione di un insieme di modelli in un tipo composito.
❑  
Utilizza un file schema. Gli schemi definiscono un insieme di regole che un file di configurazione deve seguire per utilizzare un determinato modello. Definendo uno schema e incoraggiando gli altri a esaminare i requisiti definiti in uno schema, gli utenti hanno un modo semplice per capire quali proprietà sono impostabili o obbligatorie per il rispettivo modello. In questo modo gli utenti possono utilizzare la configurazione senza dover esaminare i dettagli dei modelli. Definisci almeno un file di schema per il modello di primo livello.
❑  
Utilizza le proprietà del modello e gli output. L'utilizzo di proprietà e output ti consente di passare variabili come la zona, le dimensioni della macchina, il numero di macchine o lo stato dell'app (test, produzione, staging) nei modelli e di ottenere valori di output come l'indirizzo IP e il selfLink di un'istanza VM. Le proprietà e gli output consentono ai tuoi modelli di essere flessibili, in modo da poter essere riutilizzati senza modifiche ai modelli sottostanti.
❑  
Utilizza singoli file di modelli che importi nel file di configurazione principale. In questo modo, puoi gestire le configurazioni in modo più semplice.
❑  
Dividi le configurazioni in unità logiche. Ad esempio, crea configurazioni separate per servizi stateful come database e bucket e configurazioni per servizi più temporanei come le istanze frontend.
❑  
Utilizza riferimenti. I riferimenti devono essere utilizzati per i valori che non vengono definiti fino alla creazione di una risorsa, ad esempio selfLink, indirizzo IP o ID generato dal sistema di una risorsa. Senza riferimenti, Deployment Manager crea tutte le risorse in parallelo, quindi non è garantito che le risorse dipendenti vengano create nell'ordine corretto. L'utilizzo dei riferimenti impone l'ordine in cui vengono create le risorse.
❑  
Visualizza l'anteprima dei tuoi deployment per valutare l'impatto di un aggiornamento. Deployment Manager non crea istanze di risorse effettive quando visualizzi l'anteprima di una configurazione, ma espande la configurazione completa e crea risorse "shell". In questo modo, puoi visualizzare le modifiche apportate al tuo deployment prima di applicarle.
❑  
Controlla i metodi API per una risorsa specifica per comprendere le implicazioni dell'esecuzione di un aggiornamento. Imposta norme di aggiornamento quando aggiorni un deployment per controllare il modo in cui Deployment Manager applica ogni aggiornamento.
❑  
Utilizza le etichette per le tue risorse. Se le risorse che stai definendo supportano le etichette, utilizzale per etichettarle. Le etichette possono aiutarti a classificare le risorse che appartengono a deployment diversi e sono anche un modo per distinguere in quale fase si trovano le risorse, ad esempio se una risorsa supporta un ambiente di produzione o di test.

Gestire le dimensioni dei deployment

Deployment Manager può operare su un numero elevato di risorse, soggetto a limiti di quota. Se vuoi ridurre il tempo necessario per creare, aggiornare o eliminare le tue implementazioni, puoi ridurre il numero di risorse all'interno di ogni singola implementazione.

❑  
Se un gruppo di risorse non dipende da risorse esterne al gruppo, puoi spostarlo in un deployment separato. Ad esempio, se il deployment contiene diversi modelli, puoi potenzialmente pacchettizzare ogni modello come un deployment separato.
❑  
Rimuovi le risorse non necessarie dalla configurazione. Se in un secondo momento hai bisogno di più risorse, puoi aggiungerne altre al deployment.
❑  
(Facoltativo) Limita i deployment a un massimo di 1000 risorse.

Autorizzazioni

Per impostazione predefinita, Deployment Manager utilizza le credenziali del account di servizio API di Google per l'autenticazione ad altre API. L'account di servizio API Google è progettato specificamente per eseguire processi interni di Google per tuo conto.

Quando vuoi concedere ad altri utenti l'accesso al tuo progetto Deployment Manager, devi concedere all'utente un ruolo IAM con le autorizzazioni appropriate per utilizzare Deployment Manager. Esistono diversi ruoli IAM predefiniti che puoi utilizzare per determinare il livello di accesso di un utente per chiamare Deployment Manager.

❑  
Utilizza i ruoli IAM per limitare le autorizzazioni concesse agli utenti per utilizzare Deployment Manager.
❑  
Se vuoi che gli utenti possano accedere alle risorse create da Deployment Manager, concedi loro i ruoli necessari per utilizzare le risorse, ma non concedere loro le autorizzazioni per eseguire il deployment delle risorse direttamente.
❑  
La concessione del ruolo Proprietario a un'entità le consentirà di modificare il criterio IAM. Pertanto, concedi il ruolo proprietario solo se l'entità ha uno scopo legittimo per gestire il criterio IAM, poiché il tuo criterio contiene dati sensibilcontrollo dell'accessol'accesso. Se la gestione è affidata a un numero minimo di utenti, qualsiasi controllo che potresti dover eseguire sarà più semplice.
❑  
Deployment Manager utilizza il account di servizio API di Google per creare e gestire le risorse. Se utilizzi Deployment Manager per gestire risorse critiche, come ruoli IAM personalizzati, devi assegnare ruoli IAM aggiuntivi al account di servizio API Google predefinito. Ad esempio, se vuoi utilizzare Deployment Manager per creare e gestire ruoli IAM personalizzati, devi aggiungere il ruolo Amministratore ruoli all'account di servizio delle API di Google.

Per una panoramica del account di servizio delle API di Google, consulta Service account gestiti da Google.

Per i passaggi per assegnare ruoli a un account di servizio, vedi Concessione di ruoli a service account.

Automazione

Valuta la possibilità di automatizzare la creazione dei progetti e delle risorse contenute al loro interno. Ciò consente di adottare un approccio Infrastructure as Code per il provisioning dei progetti. Questo approccio offre molti vantaggi, ad esempio la possibilità di:

  • Consenti l'applicazione dei requisiti aziendali quando fornisci progetti ai team che hanno bisogno di accedere alle risorse. Google Cloud
  • Fornisci una serie di ambienti di progetto predefiniti che possono essere sottoposti a provisioning in modo rapido e semplice.
  • Utilizza il controllo della versione per gestire la configurazione del progetto di base.
  • Avere la certezza di eseguire il deployment di configurazioni di progetto riproducibili e coerenti.
  • Incorpora la creazione di progetti in un processo di provisioning automatizzato.
❑  
Automatizza la creazione di progetti utilizzando i modelli disponibili su GitHub come punto di partenza.

Integrazione continua (CI) / Deployment continuo (CD)

Utilizza Deployment Manager come parte della tua pipeline CI/CD.

❑  
Non utilizzare una pipeline CI/CD per creare ed eliminare interi progetti di test e QA.
  • Potresti scegliere di eliminare le istanze VM o le risorse che potrebbero comportare costi aggiuntivi, ma valuta la possibilità di lasciare gli asset riutilizzabili che potrebbero richiedere un po' di tempo per essere ricreati, poiché l'eliminazione di queste risorse potrebbe influire negativamente sul tempo necessario per completare le pipeline di build. Non sono previsti costi per la configurazione di reti, subnet o regole firewall.
  • Tieni presente che, se elimini un progetto, questo rimarrà parte della quota di progetti per alcuni giorni, finché non verrà rimosso completamente. Ciò significa anche che non puoi riutilizzare il nome del progetto.
  • L'utilizzo di Deployment Manager ti consente di eliminare facilmente le risorse da un progetto in modo da non raggiungere le quote delle risorse.
❑  
Utilizza Deployment Manager per creare le parti stateful del progetto e la configurazione di rete e implementale al di fuori del processo CI/CD nell'ambito della configurazione iniziale. Al termine del test, puoi eliminare i deployment che contengono solo risorse stateless che sono state sottoposte a deployment nell'ambito della pipeline.
❑  
Nell'ambito del processo CI/CD, utilizza una configurazione separata per eseguire il deployment delle risorse nei tuoi progetti di test e controllo qualità. Al termine dei test, puoi utilizzare Deployment Manager per eliminare le risorse dai progetti di test e QA.
Verifica deployment. Grazie alla possibilità di incorporare il provisioning delle risorse come parte di una pipeline CI/CD, Deployment Manager ti consente di trattare la configurazione del progetto come codice che puoi testare e riprodurre facilmente copie coerenti dell'ambiente di produzione corrente o dell'ambiente corrente con le modifiche applicate per eseguire test in tutta sicurezza.
❑  
Utilizza il controllo della versione. L'utilizzo di un sistema di controllo della versione nell'ambito della procedura di sviluppo per i tuoi deployment ti consente di:
  • Ripristina una configurazione precedente nota.
  • Fornire un audit trail per le modifiche.
  • Utilizza la configurazione come parte di un sistema di deployment continuo.