Configuration - describes all the resources you want for a single deployment. YAML. Must contain
Template - optional reusable individual building blocks of a Configuration. Python or Jinja2.
Resource - a single API resource, such as Compute Engine instance or a Cloud SQL instance. Each Resource must contain
Type - single API resource, known as a base type (list of supported base types), or a template (aka “Composite type”).
Manifest - a record that contains the original fully expanded Configuration you provided.
Deployment - collection of resources deployed based on provided Configuration
Schema - defines a set of rules that a Configuration file must meet if it wants to use a particular Template. Structure.
Outputs - key/value pairs that you can define in the Configuration or Templates that will show up in the Manifest after deployment. Example: IP address of a deployed VM.
Property - a static variable that you can use throughout Templates.
Reference - dynamic variables that are not defined until a Resource is created.
Preview - shows resources that Deployment Manager would create if you create or update the Deployment. More.
Update Policy - how your resources are updated when you update the Deployment. More.
Do not modify resources deployed with Deployment Manager using cloud console or
gcloud. Instead, update the Deployment.
While it’s possible to include secret credentials in Configurations and Templates, and Deployment Manager will attempt to redact them, it’s still better to avoid doing so.
While Jinja2 is simpler and cleaner, it’s still recommended to use Python templates due to better flexibility. It looks ugly though... 🤢
Structure your Configuration file to use only one type, and use a top-level template to call all other templates... 🤮
Use labels. Duh...
Create many small Deployments, not one huge Deployment.
For large deployments arrange configs in a hierarchical structure in multiple files rather than single config per deployment.
- Create config file. All static configs will be here.
- Create top-level template file, reference it in the config file.
- Open the Resources Types reference and map the services you need in the right order.
- Using the Resources Types reference, go to each of your deployment resources one by one and write static configuration for each of them.
gcloud deployment-manager deployments create/update my-deployment --config deployment/deployment_config.yaml --previewto validate the deployment.
gcloud deployment-manager deployments update my-deploymentto release preview.
gcloud deployment-manager deployments cancel-preview my-deploymentto cancel preview.
Production-ready sample templates
GitHub - GoogleCloudPlatform/cloud-foundation-toolkit: The Cloud Foundation toolkit provides GCP best practices as code.
The Cloud Foundation toolkit (henceforth, CFT) includes the following parts: A comprehensive set of production-ready resource templates that follow Google's best practices, which can be used with the CFT or the gcloud utility (part of the Google Cloud SDK) - see the template directory A command-line interface (henceforth, CLI) that deploys resources defined in single or multiple CFT-compliant config files - see: A growing set of sample Config Connector YAML configurations - seethe solutions directory In addition, the CFT repository includes a sample pipeline that enables running CFT deployment operations from Jenkins - see the pipeline directory.
Deployment Manager Fundamentals | Cloud Deployment Manager Documentation | Google Cloud
The following components are the fundamentals of Deployment Manager. A configuration describes all the resources you want for a single deployment. A configuration is a file written in YAML syntax that lists each of the resources you want to create and its respective resource properties.
Best practices for using Deployment Manager | Cloud Deployment Manager Documentation | Google Cloud
After you have created a resource as part of a deployment, use Deployment Manager if you need to modify the resource. If you modify a resource without using Deployment Manager, such as with the Cloud Console or gcloud you might see errors if you try to modify the resource in your original deployment.
Structuring Deployment Manager for use at scale | Cloud Deployment Manager Documentation | Google Cloud
When your "Infrastructure as code" system grows beyond the "Hello World" example without planning, code tends to become unstructured. Unplanned configurations are hardcoded. Maintainability drops drastically. Use this document, along with its accompanying code example, to structure your deployments more efficiently and at scale.
Supported resource types | Cloud Deployment Manager Documentation | Google Cloud
Deployment Manager uses the underlying APIs of each Google Cloud service to deploy your resources. For example, to create Compute Engine virtual machine instances, Deployment Manager makes a call to the Compute Engine API to create the instance, and then adds it to your deployment.