Questa pagina descrive le best practice per la creazione di deployment utilizzando Google Cloud Deployment Manager. Questa pagina è progettata per gli utenti che hanno familiarità con Deployment Manager; non ti insegnerà come utilizzare Deployment Manager.
Se è la prima volta che utilizzi Deployment Manager, prova la guida rapida.
Gestione delle risorse
|
□
Dopo aver creato una risorsa come parte 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:
|
|
□
Se nel deployment sono presenti istanze di 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 seguente, il disco
example-disk viene 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 privati di Google Kubernetes Engine (GKE) con Deployment Manager, imposta le seguenti opzioni
privateClusterConfig:
enablePrivateNodes: true
enablePrivateEndpoint: true
# Configure the IP range for the hosted master network
masterIpv4CidrBlock: IP_RANGE
ipAllocationPolicy:
useIpAliases: true
createSubnetwork: true
Per requisiti e considerazioni aggiuntive sulla creazione di un cluster privato con GKE, consulta Configurare un cluster privato. |
Inclusione delle credenziali nel deployment
|
□
Deployment Manager oscura alcuni campi relativi alle credenziali dalle
proprietà nelle configurazioni YAML. Questo oscuramento avviene in base alla chiave
della proprietà. L'esempio seguente mostra un oscuramento di questo tipo:
# 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 il deployment, la credenziale viene oscurata dai file di configurazione e layout espansi, ma sarà 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 da lì utilizzando le proprietà del modello.
|
|
□
Eventuali 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. Per questo motivo, 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 edificio
|
□
Per velocizzare la definizione dei modelli, puoi 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. Iniziare a usare Jinja è più facile, ma Python è più flessibile per deployment complessi in cui potresti avere molte risorse suddivise in più ambienti.
|
|
□
Strutturare il file di configurazione (il file YAML) in modo che utilizzi un solo tipo e utilizzare un modello di primo livello come quel tipo per chiamare tutti gli altri modelli. L'adozione di questa prassi semplifica la modifica di un insieme di modelli in 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. Con la definizione di uno schema e incoraggiando gli altri a esaminare i requisiti definiti in uno schema, gli utenti possono capire facilmente quali proprietà sono impostabili o richieste per il rispettivo modello. Ciò consente agli utenti di 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 trasferire variabili come la zona, le dimensioni della macchina, il numero di macchine o lo stato dell'app (test, produzione, gestione temporanea) nei modelli e ottenere valori di output come l'indirizzo IP e
selfLink a un'istanza VM. Le proprietà e gli output consentono ai modelli di essere flessibili, in modo da poter essere riutilizzati senza modifiche ai modelli sottostanti.
|
|
□
Utilizza i singoli file di modello che importi nel
file di configurazione principale. Questo ti offre un modo più gestibile
di lavorare con le configurazioni.
|
|
□
Suddividi le configurazioni in unità logiche. Ad esempio, crea configurazioni separate per i servizi stateful come database e bucket e configurazioni per servizi più temporanei come le istanze di frontend.
|
|
□
Utilizza i references.
I riferimenti devono essere utilizzati per i valori che non vengono definiti finché non viene creata 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'uso dei riferimenti applicherebbe l'ordine in cui vengono create le risorse.
|
|
□
Visualizza l'anteprima dei deployment per valutare in che modo un aggiornamento influirà sul deployment.
Deployment Manager non crea un'istanza di risorse effettive quando visualizzi l'anteprima di una configurazione, ma espande la configurazione completa e crea invece risorse "shell". In questo modo, hai l'opportunità di vedere le modifiche al deployment prima di impegnarti.
|
|
□
Controlla i metodi API per una risorsa specifica per comprendere le implicazioni dell'esecuzione di un aggiornamento. Imposta i criteri di aggiornamento durante l'aggiornamento di un deployment per controllare più facilmente il modo in cui Deployment Manager applica ogni aggiornamento.
|
|
□
Utilizza le etichette per le risorse. Se le risorse che definisci supportano le etichette,
utilizzale per etichettarle. Le etichette possono aiutare a classificare le risorse appartenenti a deployment diversi e sono anche un modo per distinguere la fase in cui si trovano le risorse, ad esempio se una risorsa supporta un ambiente di produzione o di test.
|
Gestione delle dimensioni dei deployment
Deployment Manager può operare su un numero elevato di risorse, soggette a 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 diversi modelli, puoi pacchettizzare ogni modello come deployment separato.
|
|
□
Rimuovi le risorse non necessarie dalla configurazione. Se in seguito avrai bisogno di altre risorse, puoi aggiungere altre risorse al deployment.
|
|
□
Facoltativamente, limita i deployment a un massimo di 1000 risorse.
|
Autorizzazioni
Per impostazione predefinita, Deployment Manager utilizza le credenziali dell'account di servizio delle API di Google per l'autenticazione con altre API. L'account di servizio delle API di Google è progettato specificamente per eseguire i processi interni di Google per tuo conto.
Quando vuoi concedere ad altri utenti l'accesso al tuo progetto Deployment Manager, devi concedergli un ruolo IAM che disponga delle autorizzazioni appropriate per l'utilizzo di 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 l'utilizzo di Deployment Manager.
|
|
□
Se vuoi che gli utenti possano accedere alle risorse create da Deployment Manager, concedi agli utenti i ruoli di cui hanno bisogno per utilizzare le risorse, ma non concedere loro le autorizzazioni per eseguire direttamente il deployment delle risorse.
|
|
□
La concessione del ruolo proprietario a un'entità consentirà di 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 dati sensibili di controllo dell'accesso#39;accesso. Avere un insieme minimo di utenti che lo gestirà semplificherà qualsiasi controllo che potresti dover eseguire.
|
|
□
Deployment Manager utilizza l'account di servizio delle API di Google per creare e gestire le risorse. Se utilizzi Deployment Manager per gestire risorse critiche, ad esempio ruoli IAM personalizzati, devi assegnare altri ruoli IAM all'account di servizio predefinito delle API di Google. Ad esempio, se vuoi utilizzare Deployment Manager per creare e gestire ruoli IAM personalizzati, devi aggiungere il ruolo Amministratore ruolo all'account di servizio API di Google.
Per una panoramica dell'account di servizio delle API di Google, consulta Account di servizio gestiti da Google. Per i passaggi per assegnare i ruoli a un account di servizio, consulta Concessione dei ruoli agli account di servizio. |
Automazione
Valuta la possibilità di automatizzare la creazione dei progetti e la creazione di risorse contenute al loro interno. In questo modo puoi adottare un approccio Infrastructure as Code per il provisioning dei progetti. Questo approccio offre numerosi vantaggi, tra cui 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 di cui è possibile eseguire il provisioning in modo rapido e semplice.
- Utilizza il controllo della versione per gestire la configurazione del progetto di base.
- Puoi avere la certezza di eseguire il deployment di configurazioni di progetto riproducibili e coerenti.
- Incorpora la creazione di progetti come parte di 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.
|
|
□
Utilizza Deployment Manager per creare le parti stateful della configurazione di progetto e rete ed eseguirne il deployment al di fuori del processo CI/CD come parte della configurazione iniziale. Al termine del test, puoi eliminare i deployment che
contengono solo le risorse stateless di cui è stato eseguito il deployment nell'ambito della pipeline.
|
|
□
Come parte del processo CI/CD, utilizza una configurazione separata per eseguire il deployment delle risorse nei progetti di test e QA. Al termine del 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 consente di trattare la configurazione del progetto come codice che puoi facilmente testare e riprodurre copie coerenti dell'ambiente di produzione attuale o dell'ambiente attuale con modifiche applicate per eseguire test in tutta sicurezza. |
|
□
Utilizza il controllo della versione. L'uso di un sistema di controllo della versione come parte del processo
di sviluppo per i deployment ti consente di:
|