My Awesome Project

Appearance

[GCP ACE Masterclass] Toàn tập về Google Cloud Deployment Manager: Từ Zero đến Hero ​

Chào mừng các bạn, những kỹ sư cloud tương lai! Hôm nay, chúng ta sẽ cùng nhau khám phá một trong những công cụ nền tảng nhưng cực kỳ mạnh mẽ của Google Cloud: Deployment Manager (DM). Hãy quên đi việc click chuột thủ công trên Console, vốn dĩ rất dễ gây ra lỗi và không thể lặp lại. Đã đến lúc chúng ta tư duy như một chuyên gia: tự động hóa, quản lý hạ tầng bằng mã nguồn (Infrastructure as Code - IaC).

Tài liệu này là cẩm nang của bạn, được đúc kết từ nhiều năm kinh nghiệm thực chiến.

MỤC LỤC ​

Phần 1: Nhập môn Infrastructure as Code và Deployment Manager

Phần 2: Xây dựng Cấu hình Đầu tiên (Hands-on Lab)

Phần 3: Các Kỹ thuật Nâng cao và Best Practices

Phần 4: Các Usecase Thực tế và Kiến trúc Tham khảo

Phần 5: So sánh Chuyên sâu: Deployment Manager vs. Terraform

Phần 6: Lời kết của Mentor

Phần 1: Nhập môn Infrastructure as Code và Deployment Manager ​

1.1. Tại sao phải là Infrastructure as Code (IaC)? Cuộc cách mạng trong vận hành Cloud ​

Hãy tưởng tượng bạn phải thiết lập một môi trường web hoàn chỉnh trên GCP: một VPC network, vài subnet, các firewall rule, một managed instance group, một load balancer, và một Cloud SQL database.

  • Cách làm thủ công: Bạn đăng nhập vào Google Cloud Console, click qua hàng chục trang, điền vào hàng trăm ô thông tin. Quá trình này mất hàng giờ, dễ sai sót (quên một firewall rule?), và gần như không thể lặp lại chính xác 100% cho môi trường staging hay production.
  • Cách làm của chuyên gia (IaC): Bạn viết một bộ file cấu hình định nghĩa tất cả các tài nguyên trên. Sau đó, bạn chạy một lệnh duy nhất. Công cụ IaC sẽ tự động đọc cấu hình và tạo ra toàn bộ hạ tầng cho bạn. Cần một môi trường y hệt? Chạy lại lệnh đó. Cần cập nhật? Sửa file cấu hình và chạy lại lệnh.

IaC mang lại:

  • Tốc độ và Hiệu quả: Triển khai các môi trường phức tạp trong vài phút thay vì vài giờ/ngày.
  • Tính nhất quán: Loại bỏ lỗi "con người". Môi trường dev, staging, prod của bạn sẽ giống hệt nhau, giảm thiểu lỗi "it works on my machine".
  • Khả năng Phiên bản hóa và Kiểm toán (Versioning & Auditing): Hạ tầng của bạn giờ là mã nguồn. Bạn có thể lưu nó trong Git, xem lại lịch sử thay đổi, biết ai đã thay đổi cái gì, tại sao, và có thể khôi phục lại phiên bản cũ nếu cần.
  • Tự động hóa: Tích hợp việc triển khai hạ tầng vào các pipeline CI/CD một cách dễ dàng.

1.2. Giới thiệu Deployment Manager: "Nhạc trưởng" của GCP ​

Deployment Manager (DM) là công cụ IaC "chính chủ" (first-party) của Google Cloud. Nó cho phép bạn định nghĩa tất cả tài nguyên GCP mà bạn cần cho ứng dụng của mình dưới dạng file cấu hình khai báo (declarative).

  • Khai báo (Declarative): Bạn chỉ cần nói cho DM biết trạng thái cuối cùng bạn muốn (ví dụ: "Tôi muốn có một VM tên 'web-server-1' với cấu hình này"). Bạn không cần chỉ cho nó từng bước phải làm. DM sẽ tự tìm ra cách để đạt được trạng thái đó.
  • Tích hợp sâu: Là sản phẩm của Google, DM hỗ trợ các tài nguyên và tính năng mới của GCP gần như ngay lập tức khi chúng được phát hành qua API.
  • Server-side: Toàn bộ logic và trạng thái được quản lý bởi phía Google Cloud. Bạn không cần cài đặt hay quản lý một "state file" trên máy của mình.

1.3. Các Khái niệm Cốt lõi: Hiểu Ngôn ngữ của DM ​

Để làm việc với DM, bạn cần nắm vững 4 khái niệm sau:

  1. Configuration (Cấu hình): Một file YAML (.yaml) duy nhất định nghĩa toàn bộ hạ tầng bạn muốn triển khai. Nó là "bản kế hoạch" tổng thể.
  2. Resources (Tài nguyên): Các thành phần riêng lẻ của GCP mà bạn muốn tạo (ví dụ: một VM, một GCS bucket, một VPC network). Chúng được liệt kê trong file Cấu hình.
  3. Templates (Mẫu): Các file có thể tái sử dụng, giúp bạn tạo ra các cấu hình một cách linh hoạt. Thay vì định nghĩa một VM hoàn chỉnh trong file YAML chính, bạn có thể tạo một template vm_template.jinja và gọi nó nhiều lần với các tham số khác nhau. Templates có thể được viết bằng Jinja 2 hoặc Python.
  4. Deployment (Triển khai): Một tập hợp tất cả các tài nguyên đã được tạo ra từ một file Cấu hình. Mỗi lần bạn chạy gcloud deployment-manager deployments create, bạn tạo ra một Deployment. Đây là thực thể "sống" trên GCP.

1.4. Vị thế của DM trong Hệ sinh thái IaC (vs. Terraform) ​

Đây là câu hỏi quan trọng nhất mà mọi người đều hỏi.

  • Deployment Manager: Là công cụ dành riêng cho GCP. Nó đơn giản, tích hợp sâu, và được quản lý hoàn toàn bởi Google. Rất phù hợp nếu bạn cam kết 100% với hệ sinh thái GCP và muốn một giải pháp không cần quản lý state.
  • Terraform: Là công cụ đa nền tảng (multi-cloud) của HashiCorp. Nó có cộng đồng lớn hơn, hệ sinh thái module phong phú hơn, và có thể quản lý cả tài nguyên trên AWS, Azure, GCP... từ cùng một nơi. Tuy nhiên, nó yêu cầu bạn phải tự quản lý "state file".

Chúng ta sẽ có một phần so sánh chi tiết ở cuối, nhưng tạm thời hãy hiểu rằng: Học DM là cách tốt nhất để hiểu sâu về cách các API của GCP hoạt động và là một kỹ năng cực kỳ giá trị trong môi trường thuần GCP.

Phần 2: Xây dựng Cấu hình Đầu tiên (Hands-on Lab) ​

Lý thuyết đã đủ, giờ là lúc thực hành!

2.1. "Hello World" với Deployment Manager: Tạo một Google Cloud Storage Bucket ​

Đây là ví dụ đơn giản nhất. Tạo một file tên là my-first-config.yaml:

yaml
# my-first-config.yaml
resources:
- name: my-first-bucket-ace-mentor
  type: storage.v1.bucket
  properties:
    location: ASIA-SOUTHEAST1
    storageClass: STANDARD
    versioning:
      enabled: true

Giải thích:

  • resources:: Bắt đầu danh sách các tài nguyên.
  • - name: ...: Tên logic của tài nguyên này trong deployment của bạn.
  • type: storage.v1.bucket: Đây là phần quan trọng nhất. Nó cho DM biết loại tài nguyên GCP cần tạo. Bạn có thể tìm thấy tất cả các loại tài nguyên được hỗ trợ trong tài liệu của Google. storage.v1.bucket tương ứng với một GCS Bucket API.
  • properties:: Các thuộc tính của tài nguyên, tương ứng với các trường trong request API. Ở đây, chúng ta chỉ định vị trí, lớp lưu trữ, và bật versioning.

Triển khai: Mở Cloud Shell hoặc terminal đã cài gcloud và chạy:

bash
gcloud deployment-manager deployments create my-first-deployment --config my-first-config.yaml

DM sẽ hiển thị tiến trình và sau vài giây, bạn sẽ có một GCS bucket mới trong project của mình!

2.2. Sức mạnh của Templates: Tái sử dụng là Vua ​

Bây giờ, nếu bạn muốn tạo 3 bucket cho 3 môi trường: dev, staging, prod? Copy-paste file YAML 3 lần? Không! Chúng ta sẽ dùng template.

Tạo một file template tên là gcs_bucket.jinja:

jinja
{# gcs_bucket.jinja #}
resources:
- name: \{\{ env["\name"] \}\}
  type: storage.v1.bucket
  properties:
    location: {{ properties["location"] }}
    storageClass: STANDARD
    labels:
      env: {{ properties["env_label"] }}

Bây giờ, sửa lại file cấu hình chính, multi-bucket-config.yaml:

yaml
# multi-bucket-config.yaml
imports:
- path: gcs_bucket.jinja

resources:
- name: dev-data-bucket
  type: gcs_bucket.jinja
  properties:
    location: US-CENTRAL1
    env_label: dev

- name: staging-data-bucket
  type: gcs_bucket.jinja
  properties:
    location: US-CENTRAL1
    env_label: staging

- name: prod-data-bucket
  type: gcs_bucket.jinja
  properties:
    location: ASIA-SOUTHEAST1 # Prod bucket ở location khác
    env_label: prod

Giải thích:

  • imports:: Chúng ta "nhập" file template vào.
  • type: gcs_bucket.jinja: Thay vì một loại tài nguyên GCP, chúng ta chỉ định loại là file template của mình.
  • -propertiess:: Các giá trị này sẽ được truyền vào template, thay thế cho các biến `\{\{ \... \}\}`.
  • `\{\{ env\["\name"] \}\}`: Một biến đặc biệt của DM, nó lấy giá trị từ trường name của tài nguyên trong file config chính.

2.3. Nâng cấp với Jinja: Logic trong Hạ tầng ​

Jinja không chỉ là thay thế biến. Nó có cả vòng lặp for và câu lệnh if.

Hãy nâng cấp file multi-bucket-config.yaml để tận dụng điều này:

yaml
# jinja-powered-config.yaml
imports:
- path: gcs_bucket.jinja

{% set BUCKETS = [
  {"name": "dev-log-bucket", "location": "US-CENTRAL1", "env": "dev"},
  {"name": "staging-log-bucket", "location": "US-CENTRAL1", "env": "staging"},
  {"name": "prod-log-bucket", "location": "ASIA-SOUTHEAST1", "env": "prod"}
] %}

resources:
{% for bucket in BUCKETS %}
- name: {{ bucket.name }}
  type: gcs_bucket.jinja
  properties:
    location: {{ bucket.location }}
    env_label: {{ bucket.env }}
{% endfor %}

Bây giờ, file cấu hình của bạn không chỉ là dữ liệu tĩnh, nó đã có logic. Bạn định nghĩa một danh sách dữ liệu và lặp qua nó để tạo tài nguyên. Điều này cực kỳ hữu ích khi tạo nhiều tài nguyên tương tự nhau.

2.4. Khám phá Python Templates: Khi Logic trở nên Phức tạp ​

Khi logic của bạn cần phức tạp hơn (ví dụ: gọi một API bên ngoài để lấy tên, thực hiện các phép tính phức tạp), Python là lựa chọn tốt hơn.

Tạo file gcs_bucket.py:

python
# gcs_bucket.py
def generate_config(context):
  """Tạo một GCS bucket."""
  
  # Lấy thuộc tính từ file config chính
  properties = context.properties
  bucket_name = context.env['name']
  location = properties.get('location', 'US') # Mặc định là US nếu không có
  
  resources = [{
      'name': bucket_name,
      'type': 'storage.v1.bucket',
      'properties': {
          'location': location,
          'storageClass': 'STANDARD',
          'labels': {
              'env': properties['env_label'],
              'deployed-by': 'python-template'
          }
      }
  }]
  
  return {'resources': resources}

Và file python-config.yaml sẽ trông gần như y hệt, chỉ thay đổi phần imports:

yaml
imports:
- path: gcs_bucket.py

resources:
- name: my-python-bucket
  type: gcs_bucket.py
  properties:
    location: US-EAST1
    env_label: py-test

Python templates mang lại sự linh hoạt tối đa, cho phép bạn sử dụng toàn bộ sức mạnh của một ngôn ngữ lập trình để định nghĩa hạ tầng.

Phần 3: Các Kỹ thuật Nâng cao và Best Practices ​

3.1. References và Dependencies: Xây dựng Mối quan hệ giữa các Tài nguyên ​

Làm thế nào để tạo một VM bên trong một VPC network vừa mới tạo? Bạn cần tham chiếu (reference) đến network đó. DM đủ thông minh để hiểu rằng nếu tài nguyên B tham chiếu đến tài nguyên A, nó phải tạo A xong rồi mới tạo B. Đây được gọi là phụ thuộc ngầm (implicit dependency).

yaml
resources:
- name: my-vpc-network
  type: compute.v1.network
  properties:
    autoCreateSubnetworks: false

- name: my-vm-instance
  type: compute.v1.instance
  properties:
    zone: us-central1-a
    machineType: zones/us-central1-a/machineTypes/e2-micro
    # Đây là phần quan trọng!
    networkInterfaces:
    - network: $(ref.my-vpc-network.selfLink) # Tham chiếu đến selfLink của network
    disks:
      # ... cấu hình disk

Cú pháp $(ref.RESOURCE_NAME.PROPERTY) là chìa khóa. Nó nói rằng: "Lấy giá trị của thuộc tính selfLink từ tài nguyên tên là my-vpc-network sau khi nó được tạo ra".

3.2. Outputs: Lấy "Kết quả" từ Hạ tầng của bạn ​

Sau khi tạo một VM, làm thế nào để biết địa chỉ IP public của nó là gì để SSH vào? Bạn có thể định nghĩa outputs.

Thêm vào cuối file YAML của bạn:

yaml
outputs:
- name: vmExternalIp
  value: $(ref.my-vm-instance.networkInterfaces[0].accessConfigs[0].natIP)
- name: vpcNetworkName
  value: $(ref.my-vpc-network.name)

Sau khi deployment hoàn tất, bạn có thể chạy lệnh sau để xem các output:

bash
gcloud deployment-manager deployments describe my-deployment-name

3.3. Schemas và Environment Variables: Xây dựng Cấu hình Linh hoạt ​

Để làm cho template của bạn thực sự tái sử dụng được, bạn không nên hardcode các giá trị như e2-micro. Thay vào đó, bạn nên truyền chúng vào như các tham số và có một cơ chế để xác thực chúng. Đó là lúc Schemas vào cuộc.

Tạo file vm_template.jinja.schema:

yaml
# vm_template.jinja.schema
info:
  title: Basic VM Template
  author: ACE Mentor
  description: Creates a simple GCE VM.

imports:
  - path: required_properties.py

required:
  - zone
  - machineType

properties:
  zone:
    type: string
    description: The zone to create the VM in.
  machineType:
    type: string
    description: The machine type for the VM.
    default: e2-micro
  bootImage:
    type: string
    description: The image to use for the boot disk.
    default: projects/debian-cloud/global/images/family/debian-11

Bây giờ, file schema này định nghĩa các "biến môi trường" mà template vm_template.jinja có thể chấp nhận, bao gồm cả các giá trị mặc định, mô tả, và các trường bắt buộc. DM sẽ tự động xác thực các thuộc tính được truyền vào trong file config chính dựa trên schema này.

3.4. Composite Types: Tạo "Module" Hạ tầng của riêng bạn ​

Đây là một khái niệm cực kỳ mạnh mẽ. Composite Types cho phép bạn đóng gói một nhóm các template lại với nhau thành một "loại" tài nguyên cấp cao hơn. Ví dụ, bạn có thể tạo một loại tài nguyên gọi là my-company-standard-web-server. Khi ai đó sử dụng loại này, DM sẽ tự động tạo ra một VM, một firewall rule, một static IP, v.v.

Đây là một chủ đề nâng cao, nhưng hãy hiểu rằng nó cho phép bạn tạo ra các module hạ tầng trừu tượng, dễ sử dụng, giống như cách Terraform cung cấp các module.

3.5. Chế độ Preview: Nhìn trước Tương lai, Tránh Thảm họa ​

Trước khi áp dụng một thay đổi lớn, bạn muốn biết chính xác nó sẽ làm gì: tài nguyên nào sẽ được tạo, cập nhật, hay xóa? Hãy sử dụng chế độ --preview.

bash
gcloud deployment-manager deployments update my-deployment-name --config my-new-config.yaml --preview

Lệnh này sẽ không thực hiện bất kỳ thay đổi nào. Thay vào đó, nó sẽ cho bạn thấy một bản tóm tắt chi tiết về những gì sẽ xảy ra.

Lời khuyên của Mentor: LUÔN LUÔN chạy --preview trước khi cập nhật một deployment quan trọng. Đây là "lưới an toàn" của bạn.

3.6. Chính sách Cập nhật (Update Policies): Kiểm soát Vòng đời Tài nguyên ​

Điều gì xảy ra nếu bạn thay đổi một thuộc tính không thể cập nhật của một tài nguyên (ví dụ: tên của một GCS bucket)? Mặc định, DM sẽ xóa tài nguyên cũ và tạo một cái mới. Nhưng đôi khi bạn không muốn điều đó. Bạn có thể kiểm soát hành vi này thông qua update.policies.

yaml
resources:
- name: my-important-db-disk
  type: compute.v1.disk
  ...
  metadata:
    update:
      policies:
        - CREATE_OR_ACQUIRE # Nếu disk đã tồn tại, hãy "nhận nuôi" nó thay vì tạo mới
        - DELETE_BECAUSE_ABANDONED # Chỉ xóa nếu nó không còn trong config nữa

Phần 4: Các Usecase Thực tế và Kiến trúc Tham khảo ​

4.1. Usecase 1: Tự động hóa Thiết lập Project Chuẩn (Project Factory) ​

Mỗi khi một team mới bắt đầu một dự án, họ cần một project GCP với cấu hình chuẩn:

  • Kích hoạt các API cần thiết (Compute, GCS, IAM...).
  • Tạo một VPC network tùy chỉnh.
  • Thiết lập các firewall rule cơ bản (cho phép SSH, RDP từ bastion host).
  • Tạo các tài khoản dịch vụ (service accounts) với quyền hạn tối thiểu.

DM là công cụ hoàn hảo cho việc này. Bạn tạo một bộ template chuẩn cho tất cả các tài nguyên trên. Khi có yêu cầu mới, chỉ cần chạy một lệnh gcloud với project_id mới là tham số, và toàn bộ project sẽ được thiết lập đúng chuẩn trong vài phút.

4.2. Usecase 2: Triển khai một Ứng dụng Web có Khả năng Co giãn ​

Đây là kiến trúc kinh điển:

  • Một External HTTP(S) Load Balancer.
  • Một Managed Instance Group (MIG) phía sau.
  • Một Instance Template để định nghĩa các VM trong MIG.
  • Một Health Check để Load Balancer biết VM nào đang hoạt động.
  • Các Firewall rules để cho phép lưu lượng từ Load Balancer và Health Check.

Với DM, bạn có thể định nghĩa tất cả các thành phần này trong một file cấu hình duy nhất. Các references sẽ kết nối chúng lại với nhau một cách hoàn hảo: MIG tham chiếu đến Instance Template, Backend Service của Load Balancer tham chiếu đến MIG và Health Check.

4.3. Usecase 3: Tạo các Môi trường Dùng một lần (Ephemeral Environments) cho Dev/Test ​

Một developer muốn thử nghiệm một tính năng mới trên một nhánh Git. Họ cần một môi trường độc lập, đầy đủ (VM, database, cache...). Pipeline CI/CD của bạn có thể tích hợp DM:

  1. Khi một Pull Request được tạo, pipeline kích hoạt một lệnh gcloud deployment-manager deployments create feature-branch-xyz-env --config ....
  2. Một môi trường hoàn chỉnh được dựng lên.
  3. Các bài test tự động được chạy trên môi trường đó.
  4. Khi Pull Request được merge hoặc đóng, pipeline chạy lệnh gcloud deployment-manager deployments delete feature-branch-xyz-env. Toàn bộ môi trường được xóa sạch, không để lại tài nguyên rác và không tốn chi phí.

Phần 5: So sánh Chuyên sâu: Deployment Manager vs. Terraform ​

5.1. Bảng so sánh Chi tiết ​

Tiêu chíGoogle Cloud Deployment ManagerTerraform by HashiCorp
Phạm viChỉ Google Cloud (GCP-native)Đa nền tảng (Multi-cloud): GCP, AWS, Azure, on-prem...
Ngôn ngữYAML + Jinja / PythonHashiCorp Configuration Language (HCL)
Quản lý Trạng tháiPhía Server (Server-side). Google quản lý.Phía Client (Client-side). Bạn tự quản lý state file (thường dùng GCS bucket).
Hỗ trợ Tính năng mớiGần như tức thì (Day 0). Vì là sản phẩm của Google.Thường có độ trễ nhỏ để cộng đồng/HashiCorp cập nhật provider.
Cộng đồng & EcosytemNhỏ hơn, tập trung vào GCP.Rất lớn, hệ sinh thái module phong phú.
Lập kế hoạch (Planning)--preview mode.terraform plan (được cho là mạnh mẽ và chi tiết hơn).
Độ phức tạp ban đầuThấp. Dễ bắt đầu với YAML.Trung bình. Cần hiểu về state, providers, và HCL.
Tích hợp CI/CDDễ dàng, chỉ cần gcloud CLI.Dễ dàng, cần terraform CLI. Yêu cầu quản lý state an toàn.

5.2. Khi nào nên chọn Deployment Manager? ​

  • Bạn là một "GCP shop" 100%: Toàn bộ hạ tầng của bạn nằm trên GCP và bạn không có kế hoạch sử dụng cloud khác.
  • Ưu tiên sự đơn giản: Bạn muốn một giải pháp "chính chủ", không cần lo lắng về việc quản lý state file.
  • Cần hỗ trợ các tính năng GCP mới nhất ngay lập tức: Bạn làm việc với các dịch vụ cutting-edge và không thể chờ provider được cập nhật.
  • Bạn muốn sử dụng Python: Khả năng dùng Python làm template là một lợi thế độc nhất, cho phép tạo ra các logic định nghĩa hạ tầng rất phức tạp.

5.3. Khi nào Terraform là lựa chọn tốt hơn? ​

  • Chiến lược Multi-cloud hoặc Hybrid Cloud: Bạn cần quản lý tài nguyên trên cả GCP và các nền tảng khác.
  • Cần một cộng đồng lớn và hệ sinh thái module có sẵn: Bạn muốn tận dụng các module đã được cộng đồng xây dựng và kiểm thử.
  • Team của bạn đã quen với Terraform: Không có lý do gì để thay đổi nếu team đã có kỹ năng và quy trình làm việc hiệu quả với Terraform.
  • Yêu cầu tính năng plan mạnh mẽ và chi tiết: Nhiều người cho rằng terraform plan cung cấp một cái nhìn chi tiết và dễ đọc hơn so với --preview của DM.

Phần 6: Lời kết của Mentor ​

Deployment Manager có thể không hào nhoáng như các công cụ mới hơn, nhưng nó là một công cụ IaC cực kỳ vững chắc, đáng tin cậy và mạnh mẽ ngay trong lòng Google Cloud. Nó buộc bạn phải hiểu cách các API của GCP hoạt động, đây là một kiến thức vô giá.

Hành trình IaC của bạn chỉ mới bắt đầu. Hãy:

  1. Bắt đầu đơn giản: Dùng một file YAML duy nhất.
  2. Tái cấu trúc (Refactor): Chuyển logic lặp lại vào templates.
  3. Tự động hóa: Tích hợp vào các kịch bản và pipeline.
  4. Luôn Preview: Biến việc chạy --preview thành một thói quen không thể thiếu.

Nắm vững Deployment Manager, bạn không chỉ học một công cụ. Bạn đang học cách tư duy về hạ tầng một cách có hệ thống, có thể lặp lại và có thể mở rộng. Chúc các bạn thành công trên con đường trở thành những chuyên gia GCP thực thụ