GCP Deployment manager: Basic templates

Photo by Arthur Osipyan on Unsplash

Google Cloud Platform lets us treat our infrastructure as a collections of resources, each resource has properties that defines its behaviour. Consider the following:

Collection.yaml (an abstraction of real values)

So with this definition in place, we can say that our job as an Cloud Engineers should be expressing what resources do we want to be created and let our Cloud provider figured out how to create them.

But the above template definition is not quite correct since we cannot express ourselves that freely but using the correct syntax for value definitions. Then replace:

virtual machine for compute.v1.instance (resource type)
my virtual machine for my-virtual-machine (custom name for our virtual machine)
close to me for us-central1-a (a physical location where it will live our resource)
F1_MICRO for https://www.googleapis.com/compute/v1/projects/deployment-manager-276220/zones/us-central1-a/machineTypes/f1-micro
(a set of virtualized hardware resources available to a virtual machine)

More over machine types.

There we go our collection of resources, from now on we are going to call them Deployments. With deployments we can manage our infrastructure at easy and more intuitively.

Before diving any further into this article consider the following:

* having installed the gcloud sdk

* having an understanding of IaaS

Each resource has properties that defined its behaviour (yeah, again), for instance, a compute engine instance (aka virtual machine) has the following:

1. Machine Type (CPU).
2. Disks (Storage), use it as a persistent data storage.
3. Network Interfaces, through is going to talk to other machine.

A compute engine instance has more properties but let us stick with this ones.

template.jinja

Do not worry about this sintax, {{ properties["F1_MICRO"] }} . They are slots for parameters we are going to provide along with the flag — properties and the properly command.

In our template we use three parameters (slots to be filled), ["F1_MICRO"] , ["DEBIAN_9"] , and ["DEFAULT"] . This parameters in order define the machineType (cpu, system memory size, persistent disk limits), the image (operating system) and the network that belongs to the compute instance (virtual machine). All our resources all going to be located in us-central1-a.

Let us define that parameters file:

.properties

Then how we run this config into the cloud?

gcloud deployment-manager deployments create qs-basic \
 — template deployment.jinja \
 — properties $(cat .properties | tr ‘\n’ ‘,’) 

In order the parameters we pass onto the script are:

name of the deployment: qs-basic
template: deployment.jinja (where our configuration lives)
properties: our file .properties

The last part of our script is maybe a little interesting at least. We are embedding a command inside another. Since we are not allowed to pass a file properties when using this command (at least when not using cloud functions command), we are transforming our properties file into a single line of key:value properties string.

$(cat .properties | tr ‘\n’ ‘,’)