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 è rivolta agli utenti che conoscono bene Deployment Manager questa pagina non ti insegnerà a usare con 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 vedere 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, eliminane la definizione risorsa.
  2. Aggiorna il deployment e, nel comando 'gcloud', aggiungi --delete-policy ABANDON. La risorsa non è più associata al deployment e puoi modificarla utilizzando la console Google Cloud o gcloud.
❑  
Se nel deployment sono presenti istanze Compute Engine e vuoi collegare dischi permanenti alle istanze, definire il disco separatamente dall'istanza, in modo da poterla gestire facilmente. Per nel deployment di seguito, il disco example-disk viene definiti 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 tuo 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 considerazioni aggiuntive quando crei un cluster privato con GKE, Configurazione di un cluster privato.

Inclusione delle credenziali nel deployment

❑
Deployment Manager oscura alcuni campi relativi alle credenziali delle proprietà nelle configurazioni YAML. Questa oscurazione avviene in base alla chiave della proprietà. L'esempio seguente mostra un caso di oscuramento: 
    # 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 le credenziali in un modello Jinja o Python per il tuo deployment, le credenziali vengono oscurate dai file di configurazione e layout espansi risultanti, ma rimangono visibili nel file di importazione originale. Per questo motivo, ti consigliamo vivamente di inserire tutte le credenziali intendiamo mantenere segreto 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 nell'esempio seguente. Me ti consigliamo vivamente di non fornire credenziali a Deployment Manager sotto forma di coppie chiave-valore all'interno di file YAML o elenchi di elementi per questo motivo. 
    # 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 modelli di esempio pronti per la produzione Progetto Cloud Foundation Toolkit.
❑  
Se hai requisiti di infrastruttura complessi, come la necessità di creare in più ambienti, leggi il tutorial e gli esempi usando Deployment Manager su larga scala.
❑  
Usa Python per creare i tuoi modelli. Puoi utilizzare Python o Jinja2 per creare modelli. Jinja è più facile da iniziare a utilizzare, 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 utilizza un modello di primo livello come tipo per chiamare tutti gli altri modelli. L'adozione di questa prassi semplifica modificare un insieme di modelli in un un tipo composito.
❑  
Utilizza un file di 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 il ai requisiti definiti in uno schema, gli utenti hanno un modo 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 output. L'utilizzo di proprietà e output ti consente di passare ai modelli variabili come la zona, le dimensioni delle macchine, il numero di macchine o lo stato dell'app (test, produzione, staging) e di ricevere valori di output come l'indirizzo IP e il selfLink per un'istanza VM. Le proprietà e gli output consentono i modelli siano flessibili in modo da poter essere riutilizzati senza apportare i modelli sottostanti.
❑  
Utilizza i singoli file di modello che importi nel tuo di configurazione principale. Questo ti offre un modo più gestibile gestire le configurazioni.
❑
Suddividi le configurazioni in unità logiche. Ad esempio, crea configurazioni separate per i servizi con stato, come database e bucket, e configurazioni per servizi più temporanei, come le istanze frontend.
❑
Utilizza i riferimenti. I riferimenti devono essere utilizzati per i valori che non sono definiti fino a quando una risorsa non viene creato, ad esempio selfLink, indirizzo IP o generato dal sistema. 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.
❑
Anteprima sui deployment per valutare gli effetti di un aggiornamento sul deployment. Deployment Manager non esegue l'inizializzazione di risorse effettive quando esamini la configurazione, ma espande la configurazione completa e crea risorse "shell". In questo modo avrai la possibilità di visualizzare le modifiche il deployment prima di eseguirlo.
❑  
Controlla i metodi dell'API per una risorsa specifica per comprendere le implicazioni di di eseguire un aggiornamento. Imposta norme di aggiornamento quando aggiorni un deployment per controllare in che modo Deployment Manager applica ogni aggiornamento.
❑  
Utilizza le etichette per le risorse. Se le risorse che stai definendo supportano le etichette, utilizzale per etichettarle. Le etichette possono aiutarti a classificare le risorse che appartengono a diversi deployment e sono anche un modo per distinguere lo stato in cui potrebbero trovarsi 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, rispettando i limiti di quota. Se vuoi ridurre il tempo necessario per creare, aggiornare o eliminare i deployment, puoi ridurre il numero di risorse all'interno di ogni singolo deployment.

❑
Se un gruppo di risorse non dipende da risorse esterne al gruppo, puoi spostarlo in un deployment separato. Ad esempio: se il deployment contiene diverse modelli, puoi potenzialmente pacchettizzare ogni modello come deployment separato.
❑
Rimuovi le risorse non necessarie dalla configurazione. Se hai bisogno di più risorse in un secondo momento, potrai aggiungere altre risorse al tuo deployment in quel momento.
❑
Se vuoi, limita i deployment a un massimo di 1000 risorse.

Autorizzazioni

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

Quando vuoi concedere ad altri utenti l'accesso a Deployment Manager devi concedere all'utente un Ruolo IAM con le autorizzazioni appropriate per usare 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.
❑
Concessione del ruolo di proprietario a una potrà modificare il criterio IAM. Pertanto, concedi il ruolo di proprietario solo se l'entità ha uno scopo legittimo di gestire Il criterio IAM, poiché il criterio contiene un controllo dell'accesso sensibile e i dati di Google Cloud. Avere un gruppo minimo di utenti che lo gestisce semplificherà qualsiasi controllo che che potresti dover fare.
❑  
Deployment Manager usa l'account di servizio delle API di Google per creare e per gestire le risorse. Se utilizzi Deployment Manager per gestire risorse critiche, come i ruoli IAM personalizzati, devi assegnare ruoli IAM aggiuntivi all'account di servizio predefinito delle API Google. Ad esempio, se vuoi usare Deployment Manager per devi creare e gestire ruoli IAM personalizzati, devi aggiungere il ruolo Amministratore per l'account di servizio delle API di Google.

Per una panoramica dell'account di servizio delle API di Google, consulta Google- e gestire account di servizio gestiti.

Per la procedura di assegnazione dei ruoli a un account di servizio, consulta Assegnazione dei ruoli agli account di servizio.

Automazione

Valuta la possibilità di automatizzare la creazione dei progetti e la loro creazione delle risorse contenute nei progetti. In questo modo puoi adottare un approccio di tipo 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 i progetti ai team che devono accedere alle risorse Google Cloud.
  • Fornisci una serie di ambienti di progetto predefiniti di cui è possibile eseguire il provisioning rapidamente e facilmente.
  • Utilizza il controllo della versione per gestire la configurazione di base del progetto.
  • Avrai la certezza di eseguire il deployment di configurazioni di progetti riproducibili e coerenti.
  • Incorpora la creazione di progetti come parte di un processo di provisioning automatizzato.
❑
Automatizza la creazione dei progetti utilizzando come punto di partenza i modelli disponibili su GitHub.

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 ti consigliamo di conservare 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 compilazione. 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 fino alla rimozione completa. Anche questo significa che non puoi riutilizzare il nome del progetto.
  • Con Deployment Manager puoi eliminare facilmente le risorse da un in modo da non raggiungere le quote delle risorse.
❑
Utilizza Deployment Manager per creare le parti con stato del progetto e la configurazione di rete ed eseguirne il deployment al di fuori del processo CI/CD nell'ambito della configurazione iniziale. Al termine del test, puoi eliminare i deployment che contengono solo risorse senza stato di cui è stato eseguito il deployment nell'ambito della pipeline.
❑  
Nell'ambito del processo CI/CD, utilizza una configurazione separata per eseguire il deployment delle risorse ai progetti di test e QA. Al termine dei test, puoi utilizzare Deployment Manager per eliminare le risorse dai progetti di test e QA.
Testare i 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 facilmente e riprodurre copie coerenti dell'ambiente di produzione o dell'ambiente corrente con le modifiche applicate per testare in tutta sicurezza.
❑
Utilizza il controllo della versione. L'utilizzo di un sistema di controllo della versione nell'ambito del processo di sviluppo per i tuoi deployment ti consente di:
  • Ricorri a una precedente configurazione valida.
  • Fornisci una traccia di controllo per le modifiche.
  • Utilizza la configurazione come parte di un sistema di deployment continuo.