gcp Deployment Manager - ghdrako/doc_snipets GitHub Wiki

Resource:

Deployment Manager works on the concept where a set of GCP resources forms a logical unit called a deployment, which are deployed together. The deployment unit could be any GCP resource like a GKE cluster, VM, databases, networks, IPs, and so on. Deployment Manager manages the cloud infrastructure by deploying, updating, and deleting the cloud resources with the help of templates that are set using declarative statements. Deployment Manager performs the implementation activity of deployment with the help of the following components:

  • Configuration Files
  • Resources
  • Types
  • Templates
  • Manifests
  • Deployments

Configuration Files

Configuration files are collections of GCP resources that are created and managed together. Configuration files are written as YAML templates containing the definition of resources to be deployed. A single configuration file is used by Deployment Manager to manage several resources.

# imported templates, if applicable
imports:
# path relative to the configuration file
-path: path/to/template.jinja
name: my -template
-path: path/to/another/template.py
name: another-template
resources:
-name: NAME_OF_RESOURCE
type: TYPE_OF_RESOURCE
properties:
property-a: value
property-b: value
...
property-z: value
-name: NAME_OF_RESOURCE
type: TYPE_OF_RESOURCE
properties:
property-a: value
property-b: value
...
property-z: value

Section in Configuration file:

  • Type: Represents the type of GCP resources to be provisioned as a VM, an IP address, and so on
  • Name: A name field used to identify the resources being set up using Deployment Manager. This will act as a key for any future modification or delete ctions on the set of GCP resources.
  • Properties: Defines the parameters and attributes of GCP resources that will be created, such as machine type, network interface, boot disk, and so n. These values are the same ones required at the time of creating services manually from GCP console or Cloud Shell.
  • Import: Contains a list of all the template files required for a job by the configuration, which is eventually expanded by the Deployment Manager.
  • Output: Used when data is required from one template and configuration as an output to another template for use by the end user.
  • Metadata: Used to set up explicit dependencies between resources.
resources:
-name: first-vm
type: compute.v1.instance
  properties:
    zone: us-central1-f
    machineType:
https://www.googleapis.com/compute/v1/projects/[MY_PROJECT]/zones/us
-central1-f/machineTypes/f1-micro
  disks:
  -deviceName: boot
   type: PERSISTENT
   boot: true
   autoDelete: true
   initializeParams:
   sourceImage: https://www.googleapis.com/compute/v1/projects/debian-cloud/global/images/family/debian-9
  networkInterfaces:
  -network: https://www.googleapis.com/compute/v1/projects/[MY_PROJECT]/global/networks/default
  accessConfigs:
  -name: External NAT
    type: ONE_TO_ONE_NAT

Resource Section

A Resource section in the configuration file describes a single API resource. When we write a configuration file, we can choose to use API resources provided by Google-managed base types or an API resource provided by a third-party type provider. A Compute Engine instance and a Cloud SQL instance are examples of a Google Cloud Service resource.

Types

  • Base Type When you must create a single primitive Google Cloud Resource, you can choose base type. Base types use RESTful APIs that perform CRUD (Create, Read, Update, and Delete) operations on the resource. Commonly used Google owned base types include compute.v1.instance and storage. v1.bucket. They can be accessed using the compute.v1.instance API and the storage.v1.bucket API, respectively.
gcloud deployment-manager types list # show full list of supported resource types
  • Composite Type When you must create a set of primitive Google Cloud resources, you need more than one template to work together as a unit, which can be done using Python or Jinja. A composite type is normally used to define a piece of the template and can be reused easily.
  • Google Managed Types - These types are the related to Google’s own managed base cloud resource types, like Cloud storage bucket or compute instance.
type: <api>.<api-version>.<resource-type>

type: compute.v1.instance
type: storage.v1.bucket
  • Composite or Type Provider
    • Composite
resources:
-name: my-composite-type
type: [PROJECT]/composite:[TYPE_NAME]
  • Type Provider
resources:
-name: my-base-type
type: [PROJECT_ID]/[TYPE_PROVIDER_NAME]:[TYPE_NAME]

Imported Template

imports:
-path: path/to/template/my_vm_template.jinja
 name: my-template.jinja
resources:
-name: my-first-virtual-machine
 type: my-template.jinja

Templates

Templates are part of the configuration file. These are individual files that contain the details for a set of resources. With complex deployments, we can create different templates containing information about sets of resources that provide uniformity across the different deployments. Deployment Manager scans and interprets each template in an inline fashion.

-name: vm-{{ env["deployment"] }}
 type: compute.v1.instance
 properties:
  zone: us-central1-a
  machineType: zones/{{ properties["zone"] }}/machineTypes/n1-standard-1
  disks:
  -deviceName: boot
   type: PERSISTENT
   boot: true
   autoDelete: true
   initializeParams:
    sourceImage: projects/debian-cloud/global/images/family/debian-9
  networkInterfaces:
  -network: global/networks/default

Deployment Manager also creates predefined environment variables containing information about the deployment.

For example, project_number is an environment variable that holds the project number of a deployment. When it’s used in the template, it is replaced with the actual project_number value of that deployment.

{{ env["project_number"] }}

-type: compute.v1.instance
 name: vm-{{ env["deployment"] }}
 properties:
  machineType: zones/us-central1-a/machineTypes/f1-micro
  serviceAccounts:
  -email: {{ env['project_number'] }}[email protected]
   scopes:
   -...

Manifest

Each deployment has a corresponding manifest. A manifest is a read- only property that describes all the resources in your deployment and is automatically created with each new deployment. Manifests cannot be modified after they have been created. A manifest is not the same as a configuration file, but is created based on the configuration file. You can identify a manifest by its unique ID, which has the manifest-TIMESTAMP format.

Deployment

A deployment is a collection of GCP resources deployed and managed together as a single unit. We can create a deployment using a configuration file and the create command of the GCP Cloud Shell.

gcloud deployment-manager deployments create gcp-first-deployment \
--config gcp-vm.yaml

gcloud deployment-manager deployments describe gcp-first-deployment

Feature

  • Parallel Deployment
  • Templates, schema files
  • Updates
  • Input and Output parameters
  • Type Providers
  • References - dependencies between models,templates,configurations
  • Preview Mode - review what change
  • Console UI

Fundamentals

  • Configuration
  • Resource
    • Name
    • Type
    • Properties
  • Types
  • Templates
    • Jinja2 - easier
    • Python - more flexible and efficient
  • Manifest
  • Deployment

Jinja templates

  • Env variable
{{ env["project"] }}
  • Loop
{% for n in range(nodes) %}
...
{% endfor %}
  • Conditions
{% if conditionTest %}
  ...True action
{% else %}
 ...False action
{% endif %}

CI/CD

gcloud deployment-manager deployments create DEPLOYMENT_NAME --config=CONFIG --preview
gcloud deployment-manager deployments update DEPLOYMENT_NAME --config=CONFIG --preview
gcloud deployment-manager deployments cancel-preview DEPLOYMENT_NAME
gcloud deployment-manager deployments describe DEPLOYMENT_NAME
gcloud deployment-manager deployments delete DEPLOYMENT_NAME

Configuration

resources:

  • name
  • type
  • properties
resources:
- name: the-first-vm
  type: compute.v1.instance
  properties:
    zone: us-central1-a
    machineType: https://www.googleapis.com/compute/v1/projects/myproject/zones/us-central1-a/machineTypes/f1-micro
    disks:
    - deviceName: boot
      type: PERSISTENT
      boot: true
      autoDelete: true
      initializeParams:
        sourceImage: https://www.googleapis.com/compute/v1/projects/debian-cloud/global/images/debian-7-wheezy-v20150423
    networkInterfaces:
    - network: https://www.googleapis.com/compute/v1/projects/myproject/global/networks/default
      accessConfigs:
      - name: External NAT

Templates

A template file is written in either Python or Jinja2. The Deployment Manager system will interpret each template recursively and inline the results within the configuration file. As such, the interpretation of each template eventually results in the same YAML syntax for resources as that defined above for the configuration file itself.

A template is a separate file that is imported and used as a type in a configuration. You can use as many templates as you want in a configuration.

Templates allow you to separate your configuration out into different pieces that you can use and reuse across different deployments. Templates can be as generalized or specific as you need. With templates, you can also take advantage of features like template properties, environment variables, modules, and other template functionality to create dynamic configuration and template files.

vm-template.jinja:
- name: vm-{{ env["deployment"] }}
  type: compute.v1.instance
  properties:
    zone: {{ properties["zone"] }}
    machineType: zones/{{ properties["zone"] }}/machineTypes/n1-standard-1
    disks:
    - deviceName: boot
      type: PERSISTENT
      boot: true
      autoDelete: true
      initializeParams:
        sourceImage: projects/debian-cloud/global/images/family/debian-9
    networkInterfaces:
    - network: global/networks/default

# importing tempalte
imports:
- path: vm_template.jinja

resources:
- name: my-vm
  type: vm_template.jinja
  properties:
    zone: us-central1-a


# Deploying templates directly with the command-line tool
gcloud deployment-manager deployments create a-single-vm --template vm-template.jinja
# set these properties on the command-line using the --properties flag
gcloud deployment-manager deployments create my-igm \
    --template vm-template.jinja \
    --properties zone:us-central1-a
# specify multiple properties
gcloud deployment-manager deployments create my-igm \
    --template vm-template.jinja \
    --properties zone:us-central1-a,machineType:n1-standard-1,image:debian-9

Resource

A resource represents a single API resource. This can be an API resource provided by a Google-managed base type or an API resource provided by a Type Provider.

  • Types Supported resource types and properties A base type creates a single primitive resource. For example, Google-owned base types include compute.v1.instance, storage.v1.bucket, and sqladmin.v1beta4.database, all of which are served by the respective Compute Engine V1 API, Cloud Storage V1 API, and the Cloud SQL v1beta4 Admin API.

Base types are supported by a RESTful API that supports Create, Read, Update, and Delete (CRUD) operations. You can also create additional base types by adding a type provider if the Google-owned types alone do not meet your needs. Creating a type provider exposes all resources of an API as base types that you can use. To create a type provider, you must supply an API descriptor document, which can be an OpenAPI specification or a Google Discovery, adjust any necessary input mappings for the API, and register the type with Deployment Manager. Once created, you and other users with access to your project can use the types provided by the provider.

When you add a type provider, all resources that are provided by the API and supported by a RESTful interface with Create, Read, Update, and Delete (CRUD) operations will be exposed as types that you can use in your deployment.

⚠️ **GitHub.com Fallback** ⚠️