Lộ trình
Google CloudAssociateTuần 2: Đào sâu dịch vụ cốt lõiBài 8 / 30

Ngày 8: Compute Engine cơ bản

Thời lượng: 45 phút
Mục tiêu: 2 nhiệm vụ chính
Tiến độ lộ trình
gcp-acengày 8
hoàn thành8 / 30 bài
Bối cảnh bài học

Chọn cấu hình Compute Engine từ workload requirement: machine type, image, boot disk, identity, network exposure và lifecycle cost.

đọc hiểuthực hànhcheckpoint
Bài giảng hôm nay

Học hiểu, rồi mới thực hành

Chọn cấu hình Compute Engine từ workload requirement: machine type, image, boot disk, identity, network exposure và lifecycle cost.

Bắt đầu đọc bài giảng

Nhiệm vụ bài học hôm nay

  • Tìm hiểu Machine type, Image, Boot disk
  • Thực hành tạo 1 VM instance qua Console
Instructor walkthrough

Bài giảng chi tiết: từ bài toán đến bằng chứng

Scenario xuyên suốt

Một team cần chạy web service nhỏ trong project lab nhưng chọn máy theo tên quen thuộc, dùng image không rõ nguồn, mở SSH từ Internet và quên xóa disk khi dừng VM. Bài học dạy cách thiết kế VM có thể giải thích được và kiểm chứng được trước khi tạo.

01Đọc bài toán

Xác định actor, workload, constraint và trạng thái cuối cần đạt.

02Vẽ luồng / boundary

Chỉ ra request, dependency, identity và failure domain trước khi chọn công cụ.

03Chọn và thực hành

Thay đổi nhỏ nhất trong lab cô lập; command nào cũng phải nói rõ nó kiểm tra điều gì.

04Kiểm chứng / recovery

Đối chiếu trạng thái thực tế, tạo một failure variant và ghi cách hoàn tác.

Cách nối lý thuyết với thực tế
  • Machine type là trade-off giữa vCPU, memory, architecture, performance và cost; không chọn “lớn nhất” thay cho measurement.
  • Image và boot disk quyết định OS, patch baseline, persistent data boundary và license; boot disk không phải backup.
  • VM có zone scope; network interface, subnet, external IP, firewall rule và service account tạo exposure/identity khác nhau.
  • Shielded VM, OS Login, metadata hygiene và least-privilege service account giảm attack surface nhưng không thay patching.

Từ requirement đến VM design

Đừng bắt đầu bằng nút Create. Viết trước: workload cần bao nhiêu CPU/memory, latency/zone nào, OS/image nào, dữ liệu có persistent không, identity nào cần, có cần public ingress không và resource sẽ sống bao lâu. Sau đó mới chọn machine type, image, boot disk và network.

Network và identity

Một VM có thể không có external IP nhưng vẫn phục vụ qua load balancer hoặc private path. Firewall rule quyết định traffic theo target/source; service account quyết định API identity, không phải firewall. SSH nên giới hạn bằng OS Login/IAP hoặc source range kiểm soát; không mở toàn Internet chỉ để “test cho nhanh”.

Lifecycle và evidence

stop giữ VM/disk và có thể vẫn phát sinh chi phí; delete có thể giữ hoặc xóa disk tùy cờ và policy. Ghi resource ID, label/TTL và expected state. Sau cleanup phải list/describe lại, vì một static IP, disk hoặc snapshot mồ côi vẫn tạo charge.

Bài tập

Thiết kế VM cho web API lab và lập bảng quyết định gồm size/image/disk/network/identity/cost. Chạy read-only commands, rồi viết runbook create → verify → failure handling → cleanup. Nếu có sandbox, dùng size nhỏ và xác nhận account/project/billing trước khi tạo.

Terminal reference

Command list và cách dùng

Chạy từng lệnh theo đúng thứ tự. Trước các lệnh có thể tạo hoặc thay đổi tài nguyên, hãy kiểm tra profile, account và region.

Commands · read-only checkpoints
gcloud compute machine-types list --zones=ZONE --project=LAB_PROJECT_ID --format="table(name,guestCpus,memoryMb)"
gcloud compute images list --project=IMAGE_PROJECT --filter="status=READY" --format="table(name,family,status)"
gcloud compute instances describe VM_NAME --zone=ZONE --project=LAB_PROJECT_ID --format="yaml(name,status,zone,disks,networkInterfaces,tags,serviceAccounts)"
gcloud compute instances list --project=LAB_PROJECT_ID --format="table(name,zone,status,networkInterfaces[].accessConfigs[].natIP)"
Hands-on lab

Thực hành theo scenario

  1. Lập decision sheet cho một web API lab: region/zone, machine family/size, image provenance, boot disk type/size, data disk, service account, subnet, external IP và firewall.
  2. Chạy read-only preflight với `gcloud compute machine-types list`, `gcloud compute images list` và `gcloud compute regions describe REGION`; lọc output theo target zone/project.
  3. Nếu có billing-safe sandbox, tạo VM nhỏ với label/TTL, không mở SSH `0.0.0.0/0`, không đưa secret vào metadata; nếu không thì làm design-only.
  4. Verify sau khi tạo: status, zone, image, disks, network tags, service account và effective access. Cleanup theo thứ tự: workload → VM → retained disk/IP; kiểm tra lại list sau khi xóa.
Evidence checkpoint

Kiểm chứng kết quả

Không coi lệnh chạy thành công là đủ. Hãy đối chiếu output với trạng thái mong đợi:

  • Giải thích machine type/image/boot disk theo workload và cost.
  • Phân biệt zone, subnet, external IP, firewall và service account.
  • Runbook có explicit project/zone, expected state và rollback/cleanup.
  • Không dùng image không rõ provenance, secret metadata hoặc SSH mở toàn Internet.
  • Chứng minh VM và các tài nguyên phụ đã được dọn hoặc được owner phê duyệt giữ lại.
Transfer to exam / production

Bẫy thường gặp và trade-off

ACE hay dùng các từ khóa machine type, image, zone, boot disk, external IP và service account để kiểm tra scope. Đừng suy luận “VM chạy được” là thiết kế đã an toàn hoặc tiết kiệm.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: Một VM lab chỉ cần nhận traffic qua private load balancer và gọi Cloud Storage bằng IAM. Thiết kế nào giảm exposure tốt nhất?

Kết thúc bài

Checklist trước khi sang Ngày 2