告別 ClickOps:用 Terraform 重建 GCP 免費 VM
文章目錄

大家看過古古的這篇〈終身免費的 VM 服務!Google Cloud 免費方案分享〉嗎?
文中手把手教你設定並建立 GCP Free Tier VM。說真的,以三大雲端供應商的 VM 價格來看,這樣的免費 VM 絕對堪稱大方!
去年,我照著做過一次,大概要花個十來分鐘。
後來她更新文章說有個設定沒寫到,會扣一點錢——我有發現,就先把 VM 刪了。
刪了之後,我就再也沒有重新建立過。
一來是在 Hetzner 上已經有一台規格更高的 VM 在跑了,沒有急迫需求。二來則是……那些「click」實在太麻煩了,想想就有點懶。
但現在不同了——因為我們有了 Terraform😎
ClickOps 的代價
在雲端平台的 console 上,透過大量手動操作,點來點去建立基礎設施,在圈子裡戲稱為 ClickOps:
ClickOps is when engineers make manual changes directly in the cloud provider’s console.
那為什麼說是「戲稱」呢?
因為一般而言,xxxOps(比如 MLOps、GitOps)泛指某種流程透過程式碼自動化,但諷刺的是,ClickOps 裡沒有 code,只有 click😂
這種做法的優點是直觀、低門檻,但壞處也不少。
一次性、不可重複
ClickOps 最根本的問題是:做完就沒了,下次還得重來。
你花十分鐘建好一台 VM,刪掉之後想再建一台?再花十分鐘。想建十台一樣的?那就是一百分鐘。
沒有任何東西可以「重複使用」,每次都是從零開始。
手動操作的疲勞
回想當初手動建 VM 的過程:小心翼翼對照文章、盯著 console 怕點錯、一堆下拉選單要確認。
Region 選對了嗎?machine type 符合免費條件嗎?disk type 要選 standard 還是 balanced?network tier 要 Premium 還是 Standard?
每一個選項都要仔細核對,因為點錯就可能開始扣錢。
改動不可追溯
更麻煩的是,這些操作完全沒有紀錄——誰改了什麼、什麼時候改的、為什麼改,全都無從得知。
即使你截圖紀錄,也很難保證不會漏掉某個設定。更別說想 rollback 到之前的狀態——根本沒有「之前的狀態」可以回復。
以上就是 ClickOps 的三大代價。
所以我刪掉那台 VM 後,就沒有動力重建了。光是想到要再點一次那些設定,就覺得心累。
ClickOps 的救星:IaC
ClickOps 的反面是 IaC——Infrastructure as Code,用程式碼定義基礎設施。
簡單說,就是把你在 console 上點的那些設定,全部寫成程式碼。
這裡講的「程式碼」不一定是傳統程式語言,更常見的是設定檔格式——像 Terraform 用的就是 HCL(HashiCorp Configuration Language)。
重點是:它是文字檔——能留下紀錄。
下次要建同樣的東西?重跑一次就好。改壞了?Rollback 就好。想知道現在的設定是什麼?直接打開檔案看就好。
IaC 工具有很多,Terraform、Pulumi、AWS CloudFormation 都是。
本文使用最常見的——Terraform。
Terraform 是什麼
Terraform 是 HashiCorp 出的 IaC 工具。過去好段時間裡,它甚至是 IaC 的代名詞。
它的核心概念是宣告式:你描述「我要什麼」,Terraform 幫你算出「要怎麼做」。
換言之,就是把你在 console 點的東西寫成 .tf 檔案。
這些 .tf 檔案,如上所述,都是文字檔——可以 commit 到 Git,可以 code review,可以重複執行。
這就是 IaC 的價值。
Terraform 設定的基本元件
一個 Terraform 專案通常會有這些 .tf 檔案:
- versions.tf:指定 Terraform 版本與 provider 版本
- provider.tf:設定雲端供應商(例如 GCP、AWS)
- variables.tf:定義可調整的參數
- main.tf:主要的資源定義
- outputs.tf:定義執行完成後要輸出的資訊
請注意,這些檔名只是慣例,而不是規則。但社群普遍採用這套命名慣例來組織檔案,方便閱讀和協作。
資源清單
Terraform 會讀取目錄下所有 .tf 檔案並合併處理,檔名本身沒有特殊意義。
這是因為 .tf 檔案的本質就是一份資源清單——你宣告「我要這些資源」,Terraform 負責建立。它不是從上到下執行的腳本,而是根據資源之間的依賴關係,自動決定建立順序。
所以用一個檔案寫完,還是拆成五個檔案,對 Terraform 來說沒有區別。分檔純粹是為了人類好讀好維護。
知道這些,當你看到別人的 Terraform 專案時,就能大致理解它的結構。後面會分享我實際用的設定,到時還可以對照著看。
為什麼選 GCP Free Tier VM 當練習對象
Terraform 是 DevOps 必備技能,這點應該沒什麼爭議。
但學 Terraform 要有練習對象。而我現有的 K3s cluster 並不適合拿來練手——就算用 Terraform 建好 VM,後面還有一堆 cluster 設定要手動處理,這部分我尚未自動化。
我需要一個可以輕鬆玩、弄壞沒關係,隨時都能砍掉重練的練習環境。
而 GCP Free Tier VM 剛好符合:
- 免費:符合條件就不用錢,練習零成本
- 獨立:跟現有的 K3s cluster 完全分開
- 可重來:隨時 destroy 重建,不怕搞壞
這些特性,造就了一個得天獨厚的學習場景。
一個 apply 就搞定:Terraform 的爽快之處
現在我用 Terraform 重建這台 VM,只需要不到 30 秒。
Region、machine type、disk、network tier,全部寫在 .tf 檔裡。不用再對照文章、不用盯著 console 怕點錯或遺漏。
想建立?一個 terraform apply 指令即可:
1 | ❯ terraform apply |
填入 yes,按下 enter,完成後,你就獲得了一個完整的 VM 環境。
外部 IP、機器名稱、zone、機型等資訊都已經自動建立好,完全符合 Free Tier 條件,隨時可以連線使用。
terraform apply 結果
想刪除?使用 terraform destroy。
就這麼簡單!
這種從 ClickOps 到 IaC 的落差與舒適感,親身經歷過的人更能體會。
沒錯,瑞凡,我真的回不去了!
我的 Terraform 設定
我用來建 GCP Free Tier VM 的 Terraform 設定,已經放在 GitHub 上,可自行參考:
它主要做的事情:
- 建立一台符合 Free Tier 條件的 GCE VM
- 設定 network tier 為 STANDARD(Free Tier 必須)
- 建立 HTTP/HTTPS/SSH 的 firewall 規則
- 用 tags 讓 VM 套用這些 firewall 規則
- 把 SSH key 寫進 instance metadata
想試的人可以 clone 下來,填好 terraform.tfvars,然後 terraform apply。
如果覺得不錯,歡迎幫我按個 ⭐️!
SSH 連線
Terraform 建好 VM 之後,你還要能連進去。
最簡單的方式是用 gcloud compute ssh——它會自動透過你的 GCP 身分認證,幫你處理 SSH key,不用額外設定。
我的 Terraform 設定有另外寫 SSH key 進 instance metadata,但那需要使用者名稱、key path 完全對應,對一般人來說反而麻煩。
如果你想了解更多,可以參考 GCP 官方的 SSH 連線說明。
不能倒流的時光
由儉入奢易,由奢入儉難,我想這就是從 ClickOps 到 IaC 的心態轉變XD
Terraform 是 DevOps 必備技能,而 GCP Free Tier VM 是一個低風險、零成本的練習場。對我來說,它更是轉職路上的一塊拼圖。
如果你也想告別 ClickOps,不妨從這裡開始。