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

net-config.yaml

imports:
  - path: network.jinja
  - path: instance.jinja
resources:
- name: network
  type: network.jinja
  properties:
    region: us-central1
    subnets:
      - range: 10.177.0.0/17
        name: web
      - range: 10.177.128.0/17
        name: data
- name: web-instance
  type: instance.jinja
  properties:
    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

instance.jinja

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

Step 3 View the network.jinja file

$ cat network.jinja

network.jinja

resources:
- type: compute.v1.network
  name: {{ env["deployment"] }}-network
  properties:
     autoCreateSubnetworks: false
# Create subnetworks
{% for subnet in properties["subnets"] %}
  {% set name = subnet["name"] %}
  {% set range = subnet["range"] %}
- type: compute.v1.subnetwork
  name: {{ name }}
  properties:
    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:

https://cloud.google.com/deployment-manager/docs/

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