Questa pagina descrive le best practice per la creazione di deployment utilizzando Google Cloud Deployment Manager. Questa pagina è progettata per gli utenti che hanno dimestichezza con Deployment Manager. Non ti insegnerà come utilizzare Deployment Manager.
Se non hai mai utilizzato Deployment Manager, prova la guida introduttiva.
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:
|
|
❑
Se nel tuo 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 contiene 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: 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 ulteriori considerazioni durante la creazione di un cluster privato con GKE, leggi 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 la credenziale in un modello Jinja o Python per il tuo deployment, la credenziale viene oscurata dai file di configurazione e layout espansi risultanti, ma è ancora visibile nel file di importazione originale. Per questo motivo, 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 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 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, consulta il tutorial e gli esempi per utilizzare Deployment Manager su larga scala.
|
|
❑
Utilizza Python per creare i modelli.
Puoi utilizzare Python o Jinja2 per creare modelli. È più facile iniziare con Jinja, 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 la trasformazione 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. Se definisci uno schema e incoraggi gli altri a esaminare i requisiti definiti in uno schema, i tuoi 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 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 ai modelli di essere flessibili, in modo che possano essere riutilizzati senza apportare modifiche ai modelli di base.
|
|
❑
Utilizza singoli file di modello che importi nel
file di configurazione principale. In questo modo, potrai gestire più facilmente 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 alla creazione di una risorsa, ad esempio il
selfLink, l'indirizzo IP o l'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
del deployment per valutare l'impatto di un aggiornamento.
Deployment Manager non esegue l'inizializzazione di risorse effettive quando esamini un'anteprima di una configurazione, ma espande la configurazione completa e crea risorse "shell". In questo modo hai la possibilità di vedere le modifiche apportate al 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 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 deployment diversi 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 tuo deployment contiene diversi modelli, puoi potenzialmente pacchettizzare ogni modello come deployment separato.
|
|
❑
Rimuovi le risorse non necessarie dalla configurazione. Se in un secondo momento avrai bisogno di altre risorse, potrai aggiungerle al tuo deployment.
|
|
❑
Se vuoi, limita i deployment a un massimo di 1000 risorse.
|
Autorizzazioni
Per impostazione predefinita, Deployment Manager utilizza le credenziali dell'account di servizio delle API Google per autenticarsi 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 al tuo progetto Deployment Manager, devi assegnare 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à consente di modificare il criterio IAM. Pertanto,
concedi il ruolo proprietario solo se l'entità ha uno scopo legittimo per gestire
il criterio IAM, in quanto il criterio contiene dati sensibili per controllo dell'accesso#39;accesso. Avere un insieme minimo di utenti che lo gestisce semplifica eventuali controlli che potresti dover eseguire.
|
|
❑
Deployment Manager utilizza l'account di servizio delle API Google per creare e gestire le risorse. Se utilizzi Deployment Manager per gestire
risorse critiche, come
ruoli IAM personalizzati,
devi assegnare ruoli IAM aggiuntivi 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 dei ruoli all'account di servizio delle API Google.
Per una panoramica dell'account di servizio delle API di Google, consulta Account di servizio gestiti da Google. 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 delle risorse al loro interno. 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 del progetto di base.
- Avrai la certezza di eseguire il deployment di configurazioni di progetti riproducibili e coerenti.
- Incorpora la creazione del progetto all'interno di un processo di provisioning automatico.
|
❑
Automatizza la creazione dei progetti utilizzando come punto di partenza i
modelli disponibili su GitHub.
|
Integrazione continua (CI) / distribuzione continua (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 con stato del progetto e la configurazione di rete ed esegui il loro 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
nei progetti di test e QA. Al termine dei test, puoi utilizzare Deployment Manager per eliminare le risorse dai progetti di test e QA.
|
| Esegui test dei 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:
|