Wondering how to get started with infrastructure as code (IaC) on Google Cloud Platform (GCP)? Well, if you know a bit about GCP but not so much about IaC, then have I got a story for you! Gather round, gurus, for a tale about IaC, GCP, a tool called Deployment Manager, and a man named Roy.
Once upon a time…
Once upon a time, there was a man named Roy G. Biv. He was the new intern at the Virtucon Corporation. His first task was to familiarize himself with Google Cloud Deployment Manager. He settled down at his desk where he found the following architecture diagram.
“Hmm,” Roy thought. Though he was familiar with the basics of Google Cloud Platform, Roy had never used a Deployment Manager before.
He decided to do some serious research (that is, a quick Google search) to dig up some info on Google Cloud Deployment Manager. Roy learned that Deployment Manager is a GCP tool built for defining infrastructure as code as reusable templates.
Understanding more about the diagram, Roy decided he should use Cloud Shell to submit a configuration file to the Deployment Manager APIs. Then, Deployment Manager would use the compute engine APIs to request the desired resource, a VM instance using the default VPC network.
Roy whipped up a checklist to make sure he had all his ducks in a row.
A Checklist for Google Cloud Deployment Manager
- A Google Cloud Project with Deployment Manager and Compute Engine APIs enabled
- A configuration file defining the resource or resources and your project information
- The capability to send the configuration file to the Deployment Manager APIs
Let’s see how Roy works his way through these three tasks.
Interested in infrastructure as code on Amazon Web Services?
Check out our guide to IaC on AWS.
Deployment Manager Configuration File
Roy continued to read the documentation about using Cloud Deployment Manager. Earlier in a project kickoff sync, Roy obtained a GCP project with the correct APIs enabled.
His next step was to learn more about the configuration files used to design infrastructure as code. He learned that the configuration file describes the resource to create or configure on Google Cloud Platform. Each resource has three components defined in a YAML file or Python template. The YAML file must include a resource section.
|name: the-first-vm||the resource name|
|type: compute.v1.instance||the type of resource we want to create|
|properties:||parameters for this resource type|
Roy understood in the resources section of the code file he needed to add a name, type, and properties about the resource to be created. That’s not so hard to code and pretty easy to remember.
If Roy wanted to create a different resource, say a VPC network, he would change the type to compute.v1.network and use properties relevant to network resources. Roy bookmarked the following site which provides a list of all supported resource types.
Here’s an excerpt from a configuration file. Focusing on the properties for the my-first-vm instance, can you determine what each main parameter in properties defines?
When pondering the above question, Roy noticed there are four different parameters used for the compute.v1.instance type, they are:
- zone: specifies the zone where the resource will be created in Google Cloud
- machineType: specifies the machine size — think memory and RAM of the instance
- disks: specifies the type of disk to use, if the boot disk, and the OS image to install
- networkInterfaces: specifies the VPC network and an external IP address is required
Roy also noticed the pattern of indents in the file. Roy rememberedd that the configuration files are written in YAML structure, which uses indents to separate the resources, parameters (properties), and values.
Having a good understanding of the configuration file, Roy next needed to communicate the file to the Deployment Manager APIs. Per the diagram, the tool to use is Google Cloud Shell.
*Behind the scenes, Roy updated the example configuration file with the Google Project details.
Google Cloud Shell
Roy previously worked with Cloud Shell during his preparation for the Google Certified Associate Cloud Engineer exam, so he remembered that Cloud Shell is a web-based terminal attached to a containerized instance pre-installed with tools to interact with the Google Cloud Platform.
Cloud Shell has the Google SDK pre-installed. Roy decided to submit the configuration files to Deployment Manager APIs and to use the Google Cloud Shell gcloud command-line tool.
Setting up your configuration file
Roy connected to the Google Cloud Console and launched a Cloud Shell connection in his web browser. Once in the terminal, Roy validated that he was in the correct project and set the region and zone in the active config file.
Next, Roy launched the Cloud Editor, a useful cloud-based IDE tool. In the editor, Roy created a new file in a known location called
roys.yaml. (The extension of the file needs to be in the YAML format.)
Roy then copied and pasted the example configuration file found on this webpage into the editor. Roy remembered he would need to change the section labeled “My_Project” to his project name. (This was completed earlier, but it’s an example for you to know what Roy changed.)
Perhaps you also want to change the VM name, or the network used for deployment? Download or copy roys.yaml file using this link to follow along in your instance of Cloud Shell.
Deploying the configuration file using gcloud
Once that was completed, Roy was ready to deploy the file. Roy used the command-line interface to switch to the directory where he saved the roys.yaml configuration file.
Roy used the following command to submit the resource request to the deployment manager APIs using Cloud Shell.
gcloud deployment-manager deployments create roys-test --config roys.yaml
- gcloud is the Google SDK tool
- deployment-manager is the resource
- deployments is the service we need
- to create a deployment named roys-test
- using the configuration file named <roys.yaml>
After clicking submit, Roy watched the Deployment Manager progress indicator. After 15 seconds, he was presented with a return message stating that the operation has successfully completed.
Cloud Deployment Manager does an excellent job of letting you know if there are any errors in the file — and what to do to fix them, So don’t fret: if you get an error, make the changes list and try again.
In Roy’s case, everything went as planned, and he used the gcloud compute instances list command to view the details on his new deployment. (A deployment is what resources deployed with a Deployment Manager are called.)
Deleting the resources to reduce cost
At this point in the story, Roy breaks the fourth wall and reminds us to remove the Google Cloud test resources when we finish. (We don’t want you to get a bill and blame this story.) So be like Roy. Don’t forget to delete the resources in your projects using this command — substituting your deployment name for roys-test.yaml if you changed it.
gcloud deployment-manager deployments delete roys-test
By completing the steps above, you (or rather, Roy) should have a VM created in your project on Google Cloud. And everyone lived happily ever after.
Mastering managing infrastructure as code
Like all skills, managing Infrastructure as Code takes practice. Google has a nice walkthrough on using Deployment Manager. But you can get hands-on to learn how to manage your infrastructure as code on Google Cloud Platform with the aptly titled A Cloud Guru course Infrastructure as Code on GCP with Deployment Manager.