What you need

To complete this lab, you need:

Internet access

Access to a supported Internet browser:

What you do

What you learn

Step 1 Create a directory for the Deployment Manager lab

$ mkdir deplab
$ cd deplab

Step 2 Download the Deployment Manager configuration files

$ gsutil cp gs://gcp-infrastructure-class-code-examples/dm-net-v01.zip .

$ gsutil cp gs://gcp-infrastructure-class-code-examples/dm-class.zip .

Step 3 unzip the archive

$ unzip dm-net-v01.zip
$ unzip dm-class.zip

Deployment manager uses a system of templates to consistently deploy GCP resources. You create files to instruct Deployment Manager.

The files are of three types:

Step 1 View the *.yaml file

$ cat net-config.yaml


  - path: network.jinja
  - path: instance.jinja
- name: network
  type: network.jinja
    region: us-central1
      - range:
        name: web
      - range:
        name: data
- name: web-instance
  type: instance.jinja
    zone: us-central1-f
    machineType: n1-standard-1
    subnetwork: web

The imports: section identifies the *.jinja templates that will be used.

The resources: section defines GCP resources to be created.

The first resource to be created is an object called 'network' that is based on the network.jinja template. It's going to pass in the properties which will create a couple of subnets named 'web' and 'data' in region us-central1.

The second resource to be created is an object called 'web-instance' that is based on the instance.jinja template. It's going to pass properties to create an n1-standard-1 VM in the us-central1-f zone on the 'web' subnetwork.

The resources Deployment Manager will create looks like this:

Step 2 View the instance.jinja file

$ cat instance.jinja


- type: compute.v1.instance
  name: {{ env["deployment"] }}-instance
     machineType: https://www.googleapis.com/compute/v1/projects/{{ env["project"] }}/zones/{{ properties["zone"] }}/machineTy
pes/{{ properties["machineType"] }}
     zone: {{ properties["zone"] }}
       - network: $(ref.{{ env["deployment"] }}-network.selfLink)
         subnetwork: $(ref.{{ properties["subnetwork"] }}.selfLink)
         accessConfigs: []
      - deviceName: boot
        type: PERSISTENT
        boot: true
        autoDelete: true
          diskName: boot
          sourceImage: https://www.googleapis.com/compute/v1/projects/debian-cloud/global/images/debian-8-jessie-v20160301
         - webnet

Step 3 View the network.jinja file

$ cat network.jinja


- type: compute.v1.network
  name: {{ env["deployment"] }}-network
     autoCreateSubnetworks: false
# Create subnetworks
{% for subnet in properties["subnets"] %}
  {% set name = subnet["name"] %}
  {% set range = subnet["range"] %}
- type: compute.v1.subnetwork
  name: {{ name }}
    network: $(ref.{{ env["deployment"] }}-network.selfLink)
    ipCidrRange: {{ range }}
    region: {{ properties["region"] }}
{% endfor %}

Step 1 Use Deployment Manager

$ gcloud deployment-manager deployments create gcpinfra --config=net-config.yaml

You should see something like this:

NAME               TYPE                   STATE      ERRORS  INTENT
data               compute.v1.subnetwork  COMPLETED  []
gcpinfra-instance  compute.v1.instance    COMPLETED  []
gcpinfra-network   compute.v1.network     COMPLETED  []
web                compute.v1.subnetwork  COMPLETED  []

Step 1 View networks

Console: Products and Services > Networking > Networks

Step 2 View instances

Console: Products and Services > Compute Engine > VM instances

Step 3 View Deployment Manager

Console: Products and Services > Deployment Manager > VM instances

Click on the gcpinfra deployment.

Step 1 Infrastructure as code

The concept behind Deployment Manager is "infrastructure as code". You can treat the templates like code, placing them under version control in a repository, and so forth.

In this lab you used commands to run Deployment Manager. However, the same functionality is also available through the API for even greater leverage.

Enter this into Cloud Shell:

$ gcloud deployment-manager types list

This lists the types of GCP resources that you can control using Deployment Manager.

Step 2 Templates for manageability

A huge configuration file can be difficult to manage. Templates are a way to break down configurations into composable units that can be separately updated and can be reused. Templates are included in the *.yaml configuration using import:.

Here are some of the benefits of Deployment Manager templates:

The Deployment Manager configuration and template files use two kinds of variables, template variables and environment variables.

Template variables are abstract properties that allow you to declare the value to be passed to the template in the *.yaml configuration file. You can change the value for each deployment in it's *.yaml file without having to make changes to the underlying templates.

Example: Passing zone as a template variable allows you to start a test deployment in a different zone from the production deployment.

Environment variables allow you to reuse templates in different projects and deployments. Rather than representing properties of resources, they represent more global properties such as a Project ID or a the name of the deployment.

Example: You want to start the same deployment in two projects, proj-east and proj-west. You could declare environment variables for the two Project IDs and then use these in the Deployment Manager configuration files.

There's a lot more to learn:


┬ęGoogle, Inc. or its affiliates. All rights reserved. Do not distribute.