Deployment Manager as native IaC in GCP - Deep Dive

Overview - Deployment Manager as native IaC

What is it?

Deployment Manager is a tool from Google Cloud that helps you create and manage your cloud resources using simple text files. Instead of clicking buttons in the cloud console, you write a file describing what you want, and Deployment Manager makes it happen. This approach is called Infrastructure as Code (IaC), meaning your cloud setup is stored as code you can edit, share, and reuse. It helps keep your cloud organized and repeatable.

Why it matters

Without Deployment Manager, setting up cloud resources would be manual and error-prone, like assembling furniture without instructions. This can lead to mistakes, wasted time, and inconsistent setups. Deployment Manager solves this by automating resource creation and updates, making cloud management faster, safer, and easier to track. It also helps teams work together by sharing the same setup files.

Where it fits

Before learning Deployment Manager, you should understand basic cloud concepts like virtual machines, storage, and networking. Knowing YAML or Python basics helps since Deployment Manager uses these for configuration. After mastering Deployment Manager, you can explore more advanced IaC tools like Terraform or Cloud Build for continuous deployment.

Mental Model

Core Idea

Deployment Manager turns your cloud setup into code files that automatically build and manage your resources exactly as described.

Think of it like...

It's like writing a recipe for a cake instead of baking it by memory; anyone can follow the recipe to get the same cake every time.

┌───────────────────────────────┐
│ Deployment Manager             │
├───────────────┬───────────────┤
│ Config Files  │ Templates     │
│ (YAML/Python) │ (Reusable)    │
├───────────────┴───────────────┤
│           Cloud Resources      │
│ (VMs, Storage, Networks, etc.)│
└───────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What is Infrastructure as Code

Concept: Introduce the idea of managing cloud resources using code instead of manual steps.

Infrastructure as Code means writing down your cloud setup in files that computers can read. These files describe what resources you want, like virtual machines or storage buckets. This way, you can create or change your cloud setup by running commands that read these files, instead of clicking buttons.

Result

You understand that cloud setups can be automated and repeated exactly by using code files.

Understanding IaC is key because it changes cloud management from manual work to automated, reliable processes.

2

Foundation

Introduction to Deployment Manager

Concept: Explain Deployment Manager as Google Cloud's tool for IaC using configuration files.

Deployment Manager lets you write YAML or Python files that describe your cloud resources. When you run Deployment Manager, it reads these files and creates or updates your resources to match. It handles the order and dependencies automatically.

Result

You know Deployment Manager is the tool that turns your resource descriptions into real cloud setups.

Knowing Deployment Manager is Google's native IaC tool helps you use cloud resources more efficiently and consistently.

3

Intermediate

Writing Basic Deployment Configurations

🤔Before reading on: do you think a Deployment Manager config file can create multiple resources at once or only one? Commit to your answer.

Concept: Learn how to write simple YAML files that define multiple cloud resources together.

A Deployment Manager config file uses YAML syntax. You list resources with their type and properties. For example, you can create a VM and a storage bucket in the same file. Deployment Manager reads this and creates both resources in the right order.

Result

You can write a config file that creates several resources in one go.

Understanding that one config file can manage many resources helps you organize your cloud setup efficiently.

4

Intermediate

Using Templates for Reusable Configurations

🤔Before reading on: do you think templates are fixed files or can they accept parameters to customize resources? Commit to your answer.

Concept: Introduce templates as reusable blueprints that can be customized with parameters.

Templates are files written in Python or Jinja2 that define resource patterns. You can pass parameters to templates to create similar resources with different settings. This avoids repeating code and makes your configs cleaner.

Result

You can create flexible templates to reuse resource definitions with different values.

Knowing how to use templates saves time and reduces errors by avoiding repeated code.

5

Intermediate

Managing Resource Dependencies Automatically

Concept: Explain how Deployment Manager understands and handles resource dependencies.

Some resources depend on others, like a VM needing a network. Deployment Manager detects these links from your config and creates resources in the correct order. You don't have to manually specify the sequence.

Result

Your resources are created safely without errors from wrong order.

Understanding automatic dependency management prevents common setup failures and simplifies complex deployments.

6

Advanced

Updating and Deleting Resources Safely

🤔Before reading on: do you think Deployment Manager deletes resources immediately when removed from config or waits for confirmation? Commit to your answer.

Concept: Learn how Deployment Manager handles changes and resource removal.

When you change your config, Deployment Manager compares it to existing resources and updates only what changed. If you remove a resource from the config, Deployment Manager deletes it from the cloud. You can preview changes before applying to avoid mistakes.

Result

You can safely update or remove cloud resources using config files.

Knowing how updates and deletions work helps avoid accidental data loss or downtime.

7

Expert

Handling Complex Deployments and Limits

🤔Before reading on: do you think Deployment Manager can handle thousands of resources in one deployment smoothly? Commit to your answer.

Concept: Explore Deployment Manager's limits and strategies for large or complex setups.

Deployment Manager has quotas on deployment size and API calls. For very large setups, you split configs into smaller deployments or use modules. Also, Deployment Manager does not support all Google Cloud services natively, so sometimes you combine it with other tools. Understanding these limits helps design scalable infrastructure.

Result

You can plan and manage large cloud infrastructures effectively using Deployment Manager.

Knowing Deployment Manager's boundaries prevents surprises and guides choosing the right tool for complex needs.

Under the Hood

Deployment Manager reads your YAML or Python config files and translates them into API calls to Google Cloud services. It tracks the state of your deployment, compares desired state with actual state, and applies changes incrementally. It uses Google Cloud's REST APIs to create, update, or delete resources, handling dependencies and errors internally.

Why designed this way?

Deployment Manager was built to provide a native, integrated IaC solution for Google Cloud users, avoiding the need for third-party tools. Using declarative configs and templates allows users to describe 'what' they want, not 'how' to do it, simplifying cloud management. The design balances ease of use with flexibility, though it trades off some extensibility compared to external tools.

┌───────────────┐       ┌─────────────────────┐       ┌─────────────────────┐
│ Config Files  │──────▶│ Deployment Manager   │──────▶│ Google Cloud APIs    │
│ (YAML/Python)│       │ (State Tracking &   │       │ (Create/Update/Delete│
│               │       │ Dependency Handling)│       │  Resources)          │
└───────────────┘       └─────────────────────┘       └─────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does Deployment Manager automatically fix all errors in your config files? Commit yes or no.

Common Belief: Deployment Manager will always fix or ignore small errors in configs and complete the deployment.

Reality: Deployment Manager stops and reports errors if the config is invalid or resources fail to create, requiring you to fix issues before proceeding.

Why it matters: Assuming automatic fixes can lead to broken deployments and wasted time troubleshooting unexpected failures.

Quick: Can Deployment Manager manage any Google Cloud service out of the box? Commit yes or no.

Common Belief: Deployment Manager supports all Google Cloud services natively without exceptions.

Reality: Deployment Manager supports many but not all services; some require manual API calls or other tools.

Why it matters: Expecting full coverage can cause delays when unsupported services need alternative management methods.

Quick: Does removing a resource from the config always delete it from the cloud immediately? Commit yes or no.

Common Belief: Removing a resource from the config instantly deletes it from Google Cloud without confirmation.

Reality: Deletion happens only when you apply the updated deployment; you can preview changes and confirm before deletion.

Why it matters: Knowing this prevents accidental data loss by allowing safe review before destructive changes.

Quick: Is Deployment Manager the best choice for very large, complex infrastructures? Commit yes or no.

Common Belief: Deployment Manager scales perfectly for any size and complexity of cloud infrastructure.

Reality: Deployment Manager has limits on deployment size and complexity; large infrastructures often require splitting or other tools like Terraform.

Why it matters: Ignoring limits can cause deployment failures or slowdowns in production environments.

Expert Zone

1

Deployment Manager's state tracking is eventually consistent, so immediate successive changes may require careful timing to avoid conflicts.

2

Templates can be nested and combined, but excessive nesting can make debugging difficult and slow deployments.

3

Deployment Manager integrates with Cloud Build and CI/CD pipelines, but requires careful handling of credentials and permissions for automation.

When NOT to use

Avoid Deployment Manager when managing multi-cloud environments or when you need advanced features like drift detection and complex orchestration; tools like Terraform or Pulumi are better suited in those cases.

Production Patterns

In production, teams use Deployment Manager with modular templates for reusable components, integrate it with CI/CD pipelines for automated deployments, and combine it with monitoring tools to track resource health and changes.

Connections

Terraform

Alternative IaC tool with broader multi-cloud support

Understanding Deployment Manager helps grasp Terraform's similar declarative approach but with more extensibility and provider options.

Version Control Systems (e.g., Git)

Builds-on storing infrastructure code in repositories

Knowing how Deployment Manager configs are code clarifies why version control is essential for tracking changes and collaboration.

Software Configuration Management

Shares principles of declarative state and automated updates

Seeing Deployment Manager as a form of configuration management links cloud infrastructure to broader IT automation practices.

Common Pitfalls

#1 Writing configs with hardcoded values repeated everywhere.

Wrong approach:

resources:
- name: my-vm
type: compute.v1.instance
properties:
zone: us-central1-a
- name: my-disk
type: compute.v1.disk
properties:
zone: us-central1-a

Correct approach:

imports:
- path: zones.jinja
resources:
- name: my-vm
type: compute.v1.instance
properties:
zone: $(ref.zone)
- name: my-disk
type: compute.v1.disk
properties:
zone: $(ref.zone)

Root cause:

Not using templates or variables leads to duplicated code, harder maintenance, and more errors.

#2 Ignoring resource dependencies and forcing creation order manually.

Wrong approach:

resources:
- name: vm
type: compute.v1.instance
properties: {...}
metadata:
dependsOn: [] # empty list
- name: network
type: compute.v1.network
properties: {...}

Correct approach:

resources:
- name: network
type: compute.v1.network
properties: {...}
- name: vm
type: compute.v1.instance
properties: {...}
metadata:
dependsOn:
- network

Root cause:

Misunderstanding automatic dependency detection causes deployment failures or resource errors.

#3 Applying config changes without previewing, causing accidental deletions.

Wrong approach:

gcloud deployment-manager deployments update my-deployment --config config.yaml

Correct approach:

gcloud deployment-manager deployments update my-deployment --config config.yaml --preview
# Review changes before finalizing

gcloud deployment-manager deployments update my-deployment --config config.yaml

Root cause:

Skipping preview leads to unintended destructive changes and potential data loss.

Key Takeaways

Deployment Manager is Google Cloud's native tool to manage infrastructure using code files, making cloud setups repeatable and automated.

It uses YAML or Python templates to describe resources and handles dependencies and updates automatically.

Templates enable reusable and customizable resource definitions, reducing errors and saving time.

Understanding Deployment Manager's limits and preview features helps avoid deployment mistakes and supports safe updates.

While powerful for Google Cloud, Deployment Manager has boundaries and is best combined with other tools for complex or multi-cloud environments.