---
# System prepended metadata

title: GCP Compute Engine 部署指南

---

# GCP Compute Engine 部署指南 (GCP Compute Engine Deployment)

:::info
**Author: Tai Ming Chen 　==[About me](https://mingchen.dev)==**
**Lead, Google Developer Group On Campus NCUE**
:::

**目錄**
[TOC]

> [!Important]**摘要**：
> 本文旨在提供 Google Cloud Platform (GCP) Compute Engine 的完整介紹與配置說明。內容涵蓋基礎設施層級介紹、資源階層管理、以及 VM 部署過程中的關鍵決策點（運算規格選擇、儲存效能調優、網路層級與安全性配置）。

---

## 前言：GCP 簡介 — 全球化基礎設施與核心服務

Google Cloud Platform (GCP) 並非僅是遠端伺服器的集合，它是 Google 將其支撐 Search、YouTube、Gmail 等十億級用戶產品的內部基礎建設，標準化後對外提供的服務。

![image](https://hackmd.io/_uploads/rysRzToI-x.png)

### 1. 基礎設施即服務 (Infrastructure as a Service, IaaS)
我們要探討的核心主題 **Compute Engine (GCE)**，屬於 IaaS 層級。
*   **定義**：提供虛擬化的硬體資源（CPU、記憶體、儲存、網路）。
*   **優勢**：擁有最高的 OS 層級控制權（Root Access），適合遷移傳統應用 (Lift and Shift)、執行客製化核心、或建置 Kubernetes 叢集節點。

### 2. 全球基礎設施概念 (Global Infrastructure)
GCP 的物理架構由以下層級組成，部署前須先瞭解才能選擇合適的部署策略：
*   **Region (區域)**：獨立的地理位置（如 `asia-east1` 台灣、`us-central1` 愛荷華）。每個 Region 包含多個 Zone。
*   **Zone (可用區)**：區域內的部署區域（如 `asia-east1-a`, `asia-east1-b`）。Zone 之間具有獨立的電力、冷卻與網路基礎設施，彼此透過高頻寬、低延遲的網路互連。

>[!Note] **小結**
>![image](https://hackmd.io/_uploads/BJSKgQ6UZg.png)
>
> * Google 把各個資料中心的區域，區分成了 Region 與 Zone。 Region 是由多個 Zone 組成的實體地理位置，通常在同一個 Region 中的網路傳輸延遲會低於 5 ms；而 Zone 是 Region 中可以部屬裝置的區域，每一個 Zone 可以視為一個故障域 (failure domain)，在考慮可用性的前題下，我們可以把服務部屬在同個 Region 的多個 Zone 中，以防止故障的發生。而通常選擇不同的 Region，是為了可以讓服務更接近使用者，以降低延遲。舉例來說，Google 在台灣彰濱工業區的資料中心，其 Region 為 `asia-east-1` ，它有 3 個 Zone ，分別為 `asia-east1-a`、`asia-east1-b`、`asia-east1-c`。
> 
> * GCP 的服務資源，也有分為 Zonal 、 Regional 與 Multi-regional 。Zonal 的資源就只會存在於一個 Zone 中，如果 Zone 發生了故障，則資源就完全無法存取。 Regional 的資源會在 Region 中有更高的可用性。而 Multi-regional 則同時將資源跨在多個 Region 中，有更高的可用性、性能與效率。`asia-east-1` 擁有 3 個 Zone，分別為 `asia-east1-a`, `asia-east1-b`, `asia-east1-c`。
> * 為了獲得較高的 SLA (服務層級協議)，架構師必須設計 **跨可用區 (Multi-Zone)** 甚至 **跨區域 (Multi-Region)** 的高穩定性架構。


---

## 第一章：資源管理與計費架構 (Resource Governance)

GCP 的資源管理邏輯都遵循著 **「繼承 (Inheritance)」** 與 **「隔離 (Isolation)」** 兩大原則。

### 1. 資源階層模型 (The Resource Hierarchy)

想像一個由上而下的樹狀結構，權限像水流一樣，會從最頂層一路流到底層。

#### 層級拆解與架構視角：

1.  **機構 (Organization) - 公司**
    *   **定義**：最高層級節點，通常與公司的 Domain Name (如 `@company.com`) 綁定。
    *   **架構意義**：這是實施 **「全域政策 (Organization Policy)」** 的地方。
    *   **實務範例**：資安長可以在此層級設定規則，例如：「禁止為任何 VM 分配外部 IP」。這條規則會強制繼承到公司內所有的部門與專案，無人能例外。

2.  **資料夾 (Folder) — 部門**
    *   **定義**：位於機構之下、專案之上的群組容器（可多層巢狀）。
    *   **架構意義**：用於 **「隔離」** 與 **「批量管理」**。
    *   **實務範例**：
        *   **部門隔離**：建立 `部門A` 和 `部門B` 資料夾。當賦予 職員A `部門A` 的管理員權限，他能管理該資料夾下所有專案，但完全看不到 `部門B` 的內容。
        *   **環境隔離**：常見做法是建立 `Production (正式環境)` 與 `Non-Prod (測試環境)` 資料夾，以便針對正式環境設定更嚴格的存取控管。

3.  **專案 (Project) — 專案小組**
    *   **定義**：GCP 的 **「原子管理單位」**。所有資源（VM, Storage, Network）都必須隸屬於某個專案。
    *   **架構意義**：
        *   **信任邊界 (Trust Boundary)**：此為最重要的概念。預設情況下，Project A 的網路與 Project B 是完全切斷的 (Network Isolation)。
        *   **計費主體**：GCP 的帳單是依據 Project 來計算的。每個 Project 必須連結到一個 Billing Account 才能運作。
        *   **API 開關**：如要使用 Compute Engine (或其他服務) 則必須在 Project 層級啟用 API。

4.  **資源 (Resources) — 資產設備**
    *   **定義**：最底層的實體。
    *   **範例**：一台 VM、一個靜態 IP、一顆 Persistent Disk。

> [!Tip]**權限繼承 (Inheritance) 的效果**：
> 如果你在 `Organization` 層級給予某人 `Owner` 角色，那麼他將自動擁有底下所有 Folder、Project 和 VM 的最高權限，且無法在底層被移除。因此在給予頂層權限時需十分謹慎。

---

### 2. 專案 (Project) 的技術識別碼

| 識別名稱 | 特性 | 用途與情境 | 比喻 |
| :--- | :--- | :--- | :--- |
| **專案名稱**<br>**Project Name** | **可隨時更改**<br>不具唯一性 | **給人看的 (GUI)**。<br>顯示在儀表板左上角，讓人類得以快速辨識。 | 綽號 |
| **專案 ID**<br>**Project ID** | **全域唯一**<br>**建立後不可改** | **給程式 / 指令看的 (CLI / API)**。<br>最重要的識別碼！在 gcloud 指令或 API 呼叫中，即是認這個 ID。 | 身分證字號 |
| **專案編號**<br>**Project Number** | **系統自動產生**<br>不可改 | **給 Google 內部系統看的**。<br>主要用於 IAM 綁定或 Service Account 的識別。 | 健保卡號 |

> [!Tip] **為什麼架構師要在意「Project ID」？**
> 因為 **Project ID 是全 Google Cloud 用戶共用的命名空間 (Global Namespace)**。
>
> *   **唯一性**：你想將 ID 取名為 `my-test-project` ? 但這個名字可能早已被其他人註冊走了...
> *   **最佳實踐 (Naming Convention)**： 建議企業制定一套標準的 ID 命名規範，以確保唯一性並易於識別， 例如： `<公司縮寫>-<環境>-<專案代號>-<隨機碼>`
>    *   ❌ 錯誤示範：`test-vm-1` (無法辨識歸屬)
>    *   ✅ 正確示範：`tsmc-prod-sap-hana-892` (台積電-正式區-SAP專案-隨機碼)

---

### 3. 圖解總結

```mermaid
graph TD
    Root[機構 Organization: MyCompany.com] -->|繼承: 資安政策| F1(資料夾: Engineering)
    Root --> F2(資料夾: HR)
    
    F1 -->|繼承: 部門權限| P1(專案 Project A: app-dev-001)
    F1 --> P2(專案 Project B: app-prod-001)
    
    P1 -->|計費與隔離邊界| VM1[資源: Web-Server-VM]
    P1 --> DB1[資源: Cloud-SQL-DB]

    style Root fill:#f9f,stroke:#333,stroke-width:2px
    style P1 fill:#bbf,stroke:#333,stroke-width:2px
    style VM1 fill:#bfb,stroke:#333,stroke-width:1px
```

*   **Project 是邊界**：圖中 VM 和 DB 雖然都在 Engineering 部門下，但如果他們分屬不同專案，預設是無法通訊的。
*   **ID 是關鍵**：當你在操作 `gcloud` 指令時，系統需要知道你指的是哪一個專案，這時必須輸入 `app-dev-001` (Project ID)，輸入 `Project A` (Name) 是無效的。

---

## 第二章：環境準備與 API 生命週期

GCP 採用高度模組化的 **「微服務架構」** 來提供功能。當您建立一個新專案時，它就是一個乾淨的沙盒環境。預設情況下，大多數的服務入口（API）都是關閉的。這種設計是為了 **減少攻擊面 (Attack Surface)** 並 **避免意外費用**。

### 1. 啟用 Compute Engine API

在建立第一台 VM 之前，你必須先告訴 Google:「我要在這個專案使用運算資源」。

*   **操作路徑**：
    導航至 `APIs & Services` > `Library` > 搜尋 `Compute Engine API` > 點擊 **Enable**。
> **註：** 第一次點擊 Compute Engine 選單時，GCP Console 也會自動提示並幫您執行此動作

> [!Tip]**Behind the Scenes:**
>    啟用 API 時，它在後端觸發了一系列複雜的初始化流程：
>
>1. **分配控制平面資源 (Control Plane Provisioning)**：
    Google 會為專案分配專屬的 API 端點資源，讓您可以透過 gcloud 或 Console 發送指令。
>2. **建立 Google 託管服務帳戶 (Google-managed Service Agents)**：
        系統會自動建立一個服務帳戶。這是 Google 內部系統用來幫您執行自動化任務（如：自動擴展 Autoscaling、負載平衡配置）的身分。
>3. **初始化配額 (Quota Initialization)**：
        系統會根據您的帳號等級與區域，載入預設的資源配額（例如：`us-central1` 區域預設允許 24 顆 vCPU、1 個靜態 IP 等）。
>4. **關聯依賴服務**：
        啟用 Compute Engine API 通常會連帶啟用 `OS Login API` 等相依服務，確保 VM 的登入機制運作正常。

---

### 2. 服務帳戶 (Service Account) 規劃

這是 GCP 與 AWS/Azure 最顯著的差異之一，也是資安架構的核心。

**什麼是服務帳戶 (SA)？**
服務帳戶是一種特殊的 Google 帳號，它不代表「人類使用者」，而是代表 **「應用程式」** 或 **「虛擬機 (VM)」**。當你的 VM 需要去讀取 Cloud Storage 的檔案或寫入 BigQuery 資料庫時，GCP 不會檢查「你是誰（開發者）」，而是檢查「這台 VM 綁定了哪個服務帳戶」。

#### A. 預設服務帳戶的風險 (The Default Service Account Trap)
當 Compute Engine API 啟用時，系統會自動建立一個 **Default Compute Engine Service Account**。
*   **格式**：`[PROJECT_NUMBER]-compute@developer.gserviceaccount.com`
*   **預設權限**：**Editor (編輯者)**。
   > [!Caution]**Warning:**
   > 這是極度危險的設定。`Editor` 權限意味著這台 VM 擁有對專案內**所有資源**的讀寫權限。如果這台 VM 被駭客入侵，駭客就等同於拿到了整個專案的鑰匙，可以刪除整個資料庫或進行挖礦。因此在生產環境 (Production) 中，應**停用**或**避免使用**此預設帳戶。

#### B. 使用者代管服務帳戶 (User-managed Service Account)
最佳實踐是為每一個不同的應用角色，手動建立專屬的身分。

*   **實務場景**：
    *   **Web Server VM**：只需要「讀取」存放在 Storage Bucket 裡的圖片。
        *   **建立 SA**：`web-app-sa@project-id...`
        *   **賦予權限**：`Storage Object Viewer` (僅讀取)。
    *   **Backup Server VM**：需要「寫入」備份檔到 Storage，並「讀取」資料庫。
        *   **建立 SA**：`backup-job-sa@project-id...`
        *   **賦予權限**：`Storage Object Creator` (寫入) + `Cloud SQL Viewer`。

*   **最小權限原則 (Least Privilege)**：
    透過上述拆分，即使 Web Server 被攻破，駭客也無法篡改備份檔或刪除資料庫，因為 `web-app-sa` 根本沒有那些權限。這就是 **「縱深防禦 (Defense in Depth)」** 的具體實踐。

#### C. 存取權範圍 (Access Scopes) vs IAM
在建立 VM 時，會看到 `Access scopes` 的選項。
*   **Access Scopes**：這是舊時代的遺跡，主要用於限制「預設服務帳戶」的權限範圍。
*   **IAM (Identity and Access Management)**：這是現代標準。
*   **最佳配置**：
    1.  將 VM 的 Access Scopes 設定為 **"Allow full access to all Cloud APIs"**。
    2.  然後在 **IAM 頁面** 中，精確設定該 Service Account 的權限。
    >[!Tip] **Why?**
    >讓權限控管回歸到 IAM 層級統一管理，而不是分散在網路層 (Firewall) 或 API 範圍層 (Scopes)。

---

## 第三章：VM Instance 配置 (Configuration Strategy)

本章節將深入解析 `Create Instance` 介面中各項參數的意義。

### 1. 區域與可用區策略 (Region & Zone)
*   **延遲 (Latency)**：服務台灣用戶首選 `asia-east1` (台灣，彰化)。
*   **成本 (Cost)**：非延遲敏感的批次處理建議選擇 `us-central1` 或 `us-east1`，成本通常比亞洲區低 **15%~20%**。

### 2. 機器設定 (Machine Configuration)
*   **E2 系列 (推薦)**：利用動態資源調度，在不同實體 CPU 間切換。CP 值最高，適合 Web 服務與開發環境。
*   **共享核心 (Shared-core)**：`e2-micro` 與 `e2-small` 採用時間切片 (Time-sliced) 技術，負載高時可進行爆發 (Bursting)。

### 3. 儲存子系統 (Boot Disk)
*   **pd-balanced (平衡永久磁碟)**：SSD。**推薦預設值**。在成本與 IOPS 間取得平衡。
*   **關鍵知識**：GCP 的磁碟 IOPS 是線性成長的。容量越大，讀寫速度越快。

### 4. 網路與安全性 (Networking & Security)
*   **VPC**：企業環境應自建 VPC 並劃分 Subnets。
*   **防火牆 (Firewall Rules)**：GCP 採用軟體定義防火牆。建議使用 Network Tags (網路標記) 來管理規則。

---

## 第四章：生命週期與成本管理 (Cost Management)

理解 VM 的狀態對於控制成本至關重要。

| 狀態 | CPU/RAM 費用 | 磁碟 (PD) 費用 | 靜態 IP 費用 | 說明 |
| :--- | :---: | :---: | :---: | :--- |
| **Running** | ✅ | ✅ | ✅ | 全額計費。 |
| **Stopped** | ❌ | ✅ | ✅ | 僅停止運算資源計費。資料與 IP 仍被佔用。 |
| **Deleted** | ❌ | ❌ | ❌ | 資源釋放，停止所有計費。 |

---

## 第五章：實務演練 — 雲端部署  ==[Google Skills 連結](https://www.skills.google/catalog_lab/1427)==
![image](https://hackmd.io/_uploads/r1bu8fpIZx.png)

本章節將結合 **Google Cloud Console (GUI)** 與 **gcloud CLI** 兩種方式，進行端到端的 VM 部署與 Nginx 服務架設。除了熟悉操作方法，亦可透過此實務演練理解「主控台操作」與「基礎設施即程式碼 (IaC)」的差異。

**實驗目標**
1.  **VM 1 (`gcelab`)**：透過 Console 建立，手動配置 Nginx 網頁伺服器，模擬傳統維運流程。
2.  **VM 2 (`gcelab2`)**：透過 Cloud Shell 指令自動化建立，模擬現代化 DevOps 流程。

>[!Caution] 注意事項
> 按下 **Start Lab** 後，請務必將鼠標懸浮於 **Open Google Cloud console** 上方，點擊右鍵使用 **無痕視窗 (private window)** 開啟。如此可確保正確綁定到教學帳號，避免本地環境有其他 Google 帳號導致錯誤。
>![image](https://hackmd.io/_uploads/SkjpDM6I-l.png)

---

### 第一階段：透過 Console 部署基礎設施 (`gcelab`)

於此階段，我們將先從圖形化介面開始，這有助於視覺化理解 GCP 的參數選項。

#### 1. 導航與初始化
*   **操作**：進入 GCP Console，點擊左側導覽選單 (Navigation menu) > **Compute Engine** > **VM instances**。
*   **動作**：點擊 **Create Instance**。

#### 2. 核心規格配置
在建立頁面中，請依據以下架構進行配置：

*   **Name**: `gcelab`
 
    > [!Tip]**說明:** 
    > DNS 兼容的名稱，將成為內部 DNS 解析的主機名稱 (Hostname)。
    
*   **Region/Zone**: 選擇指定的區域（如 `us-central1` / `us-central1-f`）。

    > [!Tip]**說明:** 
    > VM 與掛載的磁碟 (Persistent Disk) 必須位於同一個 Zone。
    
*   **Machine Configuration**:
    *   **Series**: `E2`
    *   **Machine Type**: `e2-medium` (2 vCPU, 4GB Memory)

    > [!Tip]**說明:** 
    > E2 系列利用動態資源排程提供高性價比，適合實驗室與 Web 伺服器負載。
    
#### 3. 儲存與作業系統 (OS & Storage)
點擊 **Boot Disk** 下方的 **Change**：
*   **OS**: `Debian`
*   **Version**: `Debian GNU/Linux 12 (bookworm)`
*   **Boot Disk Type**: `Balanced persistent disk`
*   **Size**: `10 GB`

 > [!Tip]**說明：**
 > 選擇 Debian 是因為其輕量且穩定（GCP 的原生優化最好）。`Balanced PD` 提供了 SSD 的隨機讀寫能力，但價格低於一般 SSD，是目前 GCP 的主流推薦。

#### 4. 網路安全性 (Networking)
*   **Firewall**: 勾選 **Allow HTTP traffic**。

    > [!Tip]**說明：**
    > 這個勾選動作其實是一個「巨集 (Macro)」。它做了兩件事：
    >    1.  在這個 VM 上打上了一個 `http-server` 的 **Network Tag**。
    >    2.  檢查 VPC 防火牆規則，若不存在，則自動建立一條規則：允許 `0.0.0.0/0` (全世界) 存取 TCP Port 80，目標對象為帶有 `http-server` 標籤的 VM。

#### 5. 執行部署
點擊 **Create**。等待 30~60 秒，狀態燈號轉綠即代表 Control Plane 已完成資源分配。

---

### 第二階段：應用層服務部署 (Nginx Web Server)

基礎設施就緒後，我們需要進入 OS 層級安裝應用程式。

#### 1. 建立 SSH 連線
*   **操作**：在 VM 列表中，點擊 `gcelab` 右側的 **SSH** 按鈕。
*   **背後機制**：GCP 會自動生成一組臨時的 SSH Key，將公鑰注入到 VM 的 Metadata Server，並透過瀏覽器開啟 SSH 終端機。這是最安全的連線方式之一，無需管理永久金鑰。

#### 2. 權限提升與套件管理
在 SSH視窗中執行：
```bash
sudo apt-get update
sudo apt-get install -y nginx
```
> [!Tip] **說明:**
>*   `sudo`：以 Root 權限執行，因為安裝軟體涉及寫入系統目錄。
>*   `apt-get update`：更新本地的套件索引清單，確保下載到最新、最安全的版本。
>*   `nginx`：安裝高效能的 Web 伺服器。

#### 3. 驗證服務狀態
確認 Nginx 行程是否在背景執行：
```bash
ps auwx | grep nginx
```
*   **預期結果**：應看到 `master process` 與 `worker process`。

#### 4. 驗收成果
回到 GCP Console，點擊 `gcelab` 的 **External IP** 連結。

![image](https://hackmd.io/_uploads/ryyBumT8bx.png)
*   **預期結果**：瀏覽器開啟新分頁，顯示 "Welcome to nginx!"，若無法顯示，通常是 Firewall 規則尚未生效，或瀏覽器快取問題（嘗試無痕視窗）。

---

### 第三階段：基礎設施即程式碼 (IaC) 實踐 (`gcelab2`)

視覺化界面常因 GCP 版本迭代而造成排版異動，故會有較大的不確定性，因此雲端工程師較少手動點擊 **Console**。在這個階段，我們將使用 **Cloud Shell** 與 **gcloud CLI** 來體驗自動化部署。

#### 1. 啟動 Cloud Shell
*   **操作**：點擊 Console 右上角的 `>_` 圖示 (Activate Cloud Shell)。
*   **說明**：Cloud Shell 是一台由 Google 代管的小型 VM (5GB Home 目錄)，預裝了 `gcloud`, `docker`, `kubectl` 等所有開發工具。

#### 2. 理解 gcloud 語法
在 Cloud Shell 中輸入以下指令（請將 `<ZONE>` 替換為分配到的 Zone，如 `us-central1-f`）：

```bash
gcloud compute instances create gcelab2 \
  --machine-type e2-medium \
  --zone <ZONE>
```

*   **指令說明**：
    *   `compute instances create`：宣告我們要操作的資源 (Instance) 與動作 (Create)。
    *   `--machine-type`：指定規格。若不指定，預設通常為 `e2-medium`（視專案設定而定）。
    *   `--zone`：指定部署位置。
    *   **預設值**：在此例我們沒有指定 Image 和 Network。gcloud 會自動使用預設的 Debian Image 與 Default VPC。這是 CLI 的高效之處，但也需要工程師清楚「預設值」為何。

#### 3. 透過 CLI 進行 SSH 連線
VM 建立完成後，可直接在 Cloud Shell 連線進去，無需打開新視窗：

```bash
gcloud compute ssh gcelab2 --zone <ZONE>
```

*   系統會詢問是否建立 SSH Key（輸入 Y）。
*   詢問 Passphrase（按 Enter 留空即可）。
*   此時 gcloud 正在背景生成 RSA 金鑰對，並將公鑰透過 API 寫入專案的 Metadata，幾秒鐘後即可登入。

#### 4. 清理資源 (Clean Up)
實驗結束後，務必輸入 `exit` 離開 SSH，並刪除測試用的 VM 以免產生費用
* 此為 Lab 環境，於倒數時間歸零後，GCP 會自動收回資源並關閉該學習帳號。但於綁定帳單帳戶的真實環境中，如未正確刪除則會造成額外花費）
```bash
# 危險操作：僅在確認不再需要時執行
gcloud compute instances delete gcelab2 --zone <ZONE>
```

---

>[!Tip] **Summarize**
>透過這個 Lab 的實作，體驗了兩種不同的部署模式：
> 1.  **Console 模式**：適合除錯與視覺化管理。
> 2.  **CLI 模式**：適合重複性任務、自動化腳本與大規模部署。
> 
> 在真實的企業架構中，會進一步將這些指令轉化為 **Terraform** 或 **Deployment Manager** 等 IaC 工具，實現「版本控制基礎設施」。

:::success
**🎉 Congratulations！您已成功建構雲端基礎設施**

您已經掌握了 GCP 的核心概念、資源階層配置，並學會如何部署 **VM instance**。
硬體環境就緒後，下一步是學習如何駕馭這台強大的伺服器。接下來的章節將帶您深入 **Linux 系統核心**，掌握系統管理與操作實務。

==[**下一章：Linux 系統核心與操作實務**](https://hackmd.io/@mingchen/linux)==
:::