At this point, we’ve learned how to integrate containers into our development workflow, and have automated the build process for our app through each of our development environments.  This could be entirely sufficient enough for many projects, but what if our app spans across multiple GCP products? 

We might have a GKE cluster running our main application, but maybe it uses a Google Cloud SQL instance for database storage, stores files in a Google Cloud Storage bucket, and maybe we have also created some Google Cloud Functions as an API endpoint for our app.  Suddenly we have a whole mess of services to manage all over again.

Google Cloud Deployment Manager lets us combine all of these Google resources together into a single unit, which as you may have guessed is called a Deployment.  This is accomplished by creating yet another YAML file for our project to define all the GCP resources our app needs.

Let’s try an example from the deploymentmanager-samples repository from the GoogleCloudPlatform GitHub page here.  I have already pulled a copy into VS Code for us to look at.  This yaml file has a resources section with two resources named here, each representing a type of compute instance. 

When we deploy using this file, Deployment Manager will use these as instructions to deploy not one but two virtual machines for us.  We just have to replace the “MY_PROJECT” bits in the sample with our actual project name.  We can then use the gcloud deployment-manager deployments create command and point it to our YAML file to deploy both VMs.

We can take this even a step further, by creating reusable templates to use with our deployment configuration.  These templates are written in Python, which allow us to add logic based on deployment-specific environment variables, and pass custom template properties into our deployment configuration at runtime.  This way we can make the zone our app is deployed in a variable for example, allowing us to easily deploy it to a specific region as we are creating it, instead of having this information hard coded into the deployment configuration.

We can also combine multiple templates together in a modular fashion.  Let’s take a look at another slightly more complex example here.  This yaml file looks quite different from our first example.  It only imports a bunch of python scripts, and then declares one of them as a resource. 

If we look at that compute-engine-template python script, we can see it creates four more resources for us, by calling the other four python scripts.  We can take a quick look at each of these scripts, and see some more complex configuration examples for two virtual machines, and both a network and firewall resource for them to utilize.  We can then deploy our yaml file in exactly the same way as the first example, and see it create both our virtual machines, and our network and firewall resources on GCP for us.

Since we can so easily combine templates together like this, I strongly encourage using the templates found in the Cloud Foundation Toolkit as a starting point for your Deployment Manager configurations.  CFT templates are available for most GCP products and services and they already observe best practices for you, so you can start your deployment off on the right foot.

We have only scratched the surface of Cloud Deployment Manager here, but you should have a basic idea of how we can use it to combine multiple GCP products together in our own applications now.  You can see literally thousands of other examples of applications that can be deployed using Cloud Deployment Manager on the GCP Marketplace.