不久前，我看完了朋友古古的電子報〈終身免費的 VM 服務！Google Cloud 免費方案分享〉，介紹 GCP 的 E2 Micro（產品代號：e2-micro）免費 VM。

簡言之，我們可以在一定資源額度與條件範圍內，免費使用 Google Cloud Platform 上的 Compute Engine 虛擬機器。

我對此深感興趣，因為它的規格比之前的 F1 Micro 好上一截。

F1 時代的 RAM 大約只有 0.6 GiB（約 600MB），有開發經驗的都知道，這在某些情況下，用起來會有點捉襟見肘😂

於是，我也跟著教學開了一台！免費的午餐怎麼能不拿呢？

附帶一提，對 GCP 不熟的人——比如我，請一定要照著教學來建立 VM，以免設定時有所遺漏，一不小心就被收費。

最後一塊拼圖

不過原來的教學只寫到 VM 建立完成為止，對於我們這些後端工程師而言，顯然還有一個很重要的基礎設定沒做——SSH 連線。

因此，我想補齊這剩下的部分，包含：

  1. 建立自己的 Linux 帳號。
  2. 建立本機與 VM 的 SSH 連線金鑰，並完成連線。
  3. 建立 VM 與 GitHub 的 SSH 連線，且能正常 clone Github 專案。

剛好我在之前文章〈Linux 上的 Python 開發環境設定〉中，略過了「設定 SSH 連線」環節——老實說只是因為我懶得寫XD

但仔細想想，這個流程我自己做了很多次，不如直接寫在文章裡，方便大家回顧。

雖說是寫給 e2-micro，不過，這些內容適用於任何 Linux VM。

本文就來補完這些步驟，並講述我對於這個免費 VM 的看法。

為什麼你值得一台 E2 Micro？

因為免費囉！但不止如此。

〈從 DigitalOcean 到 Hetzner：我為何轉向這家德國 VPS 供應商〉一文中，有讀者留言問道：

想問問不選擇 Fly.io 或 render 來部署的原因，他們看起來有免費額度可以部署。

我則回應：

這類帶有免費額度的服務，主要是為了吸引不想花錢的用戶，條款常有變更的可能，比較適合短期或實驗性質（雖然 memos 備份挺容易的），長期部署我比較不會考慮

退一步來說，如果你真的需要一台免費的 VM 來部署 memos 這類的小服務，那麼與其選擇 Fly.io 或 render，還不如先開一台 E2 免費 VM！

等到不堪負荷了（但仍不想付錢XD），再考慮像 Fly.io 或 render 這些供應商也不遲。

畢竟 GCP 這樣的大廠，福利政策突然變更、收回的機率，通常比上述公司小得多。

除此之外，還有兩個關鍵理由。

一、延遲優勢

我覺得，這台免費 VM 的最大亮點，是「延遲極低」。

GCP 雖然只開放美國三個地區的資料中心供免費機器使用，但實際測試從台灣連線，延遲普遍低於 10ms，這比我在 Hetzner（德國）或 DigitalOcean（新加坡）上的機器表現好非常多。

我自己的 Cloud Ping Test 網站測試結果如下：

  • GCP（us-west1）：~10 ms
  • Hetzner（德國）：600-800 ms
  • DigitalOcean（新加坡）：120-150 ms

實在不知為何可以這麼快，而且 GCP 所有地區都很快，真是奇了！

二、免費額度堪稱大方

免費機器的內容如下：

  • 0.25 至 2 個 vCPU（1 個共用核心，動態分配資源）
  • 1 GB RAM
  • 30 GB 標準磁碟（傳統 HDD）
  • 每月 1 GB 出站流量

這些規格看似陽春，但其實已能支撐許多日常小 app。若對照 DigitalOcean，類似的 VM 要價在每個月 5 美元以上。

所以，這樣的 VM 竟然可以免費使用，我覺得已經很大方。

介紹完我認為的 E2 Micro 優點，接下來進入正題。

設定 SSH 連線

在使用雲端平台或 VPS 服務建立 VM 後，通常有兩種主要的初次登入方式：

  1. Web 界面提供內建 SSH 終端機：使用者可從平台介面直接開啟瀏覽器終端登入虛擬機器，無需事先設定金鑰。
  2. 建立 VM 時預先設定 SSH 金鑰：在建立過程中指定公鑰，平台會在 VM 建立時將其寫入authorized_keys，讓你能用該金鑰從本機連入。（通常是用 root 帳號）

這兩種方式大多數平台都支援，在原文的教學中，採用的是第一種方式，也就是透過 Web SSH 登入 VM。

登入之後，我們就可以開始設定真正屬於自己的登入方式。

建立 Linux 帳號

不管是 root 帳號還是 GCP 給你的帳號，都不是我們自己建立的帳號。

開發時，通常不會直接使用這些帳號來進行日常操作，尤其 root 帳號權限過大，存在一定的安全風險。

所以我們習慣先建立自己的 Linux 帳號，然後再設定 SSH 連線。

建立新帳號，並加入管理者群組：

1
2
sudo adduser kyo
sudo usermod -aG sudo kyo

這裡直接用kyo舉例，實際操作時，請自行替換帳號名稱。

為kyo建立.ssh目錄，設定並權限：

1
2
3
sudo mkdir /home/kyo/.ssh
sudo chown kyo:kyo /home/kyo/.ssh
sudo chmod 700 /home/kyo/.ssh

本機建立 SSH 金鑰

接下來，我們在本機電腦產出 SSH 金鑰，建議使用 Ed25519 演算法，它更加現代，而且更重要的是——公鑰很短！（方便複製）

1
ssh-keygen -t ed25519 -C "[email protected]"

採用預設選項一路按Enter的話，會產生下面兩個檔案：

1
2
3
# ~/.ssh/
id_ed25519
id_ed25519.pub

通常我會先產出，再自行改名。比如把檔名改成gcp、gcp.pub，方便辨識。

將產生的公鑰內容複製，並貼到 VM 上kyo帳戶下的authorized_keys中，此時因為是透過 Web SSH 登入的管理者帳號來操作自非身帳號，指令要加上sudo：

1
2
3
4
5
cat ~/.ssh/gcp.pub
# 複製內容後在 VM 上操作
sudo nano /home/kyo/.ssh/authorized_keys # 貼上內容後存檔
sudo chown kyo:kyo /home/kyo/.ssh/authorized_keys
sudo chmod 600 /home/kyo/.ssh/authorized_keys

在本機建立 SSH config 來簡化連線設定：

1
touch ~/.ssh/config

然後編輯~/.ssh/config，加入以下內容：

1
2
3
4
Host gcp
    HostName <VM 的實際 ip>
    User kyo
    IdentityFile ~/.ssh/gcp

本機測試使用新帳號連線 VM：

1
ssh kyo@gcp

這樣基本就完成了！

Github SSH 設定

設定完本機連線，我通常會緊接著設定 GitHub 連線。

注意，本機連線指的是「本機和 VM 之間」；而 GitHub 連線在本文的語境下，則是指「VM 和 GitHub 之間」。

所以這部分的主要操作都是在 VM 上進行。

一樣，先在 VM 上產生新的 SSH 金鑰：

1
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/github

加上-f ~/.ssh/github後，可以省去手動更名的麻煩，不過要注意，它同時也會覆蓋原有的檔案！（如果有的話）

複製公鑰內容：

1
cat ~/.ssh/github.pub

前往 Github SSH 設定頁，貼上金鑰。

新增、編輯~/.ssh/config加入 Github 設定：

1
2
3
4
Host github
    HostName github.com
    User git
    IdentityFile ~/.ssh/github

測試是否成功：

1
2
ssh -T [email protected] -i ~/.ssh/github
Hi kyomind! You've successfully authenticated, but GitHub does not provide shell access.

直接 clone 一個自己的 repo 確認沒問題：

1
2
3
4
5
6
7
8
git clone [email protected]:kyomind/WeaMind.git
Cloning into 'WeaMind'...
remote: Enumerating objects: 193, done.
remote: Counting objects: 100% (193/193), done.
remote: Compressing objects: 100% (121/121), done.
remote: Total 193 (delta 87), reused 161 (delta 58), pack-reused 0 (from 0)
Receiving objects: 100% (193/193), 63.91 KiB | 661.00 KiB/s, done.
Resolving deltas: 100% (87/87), done.

大功告成，讚！