全世界都是你的工作室:GCP 的雲端開發環境

最近看到 Heron 的 Medium 在討論使用 iPad 來開發程式,深深被 Thin Client 給感動了。如果能從硬體裝置中解放,不用開發程式前還需要花費大把時間精力來架設環境,那我們就能更快驗證,更快學習,更快迭代,把時間花在重要而有價值的事上。

Thin Client 的概念說來單純,我們可以將所有能連上網路的介面都可以當成終端,在傳統開發環境中,終端跟運算是放在同一台機器上,輸入完成後,使用機器的資源來進行運算,像是編譯程式、執行與提供服務;但自從有了雲端後,可以將這類運算都交由雲端處理,只要有個合用的終端介面能輸入與呈現資訊,就能得到運算結果。

Apply GCP free plan

既然運算資源放在雲端,首先要申請一個雲端帳戶,這邊以 GCP 的免費方案為例,首先點選 GCP 的免費試用

GCP 的免費方案提供 $300 刀的額度,還有 12 個月的使用時間,可以使用 GCP 上所有服務,如果是小型或低成本的運算,甚至不用動到 $300 的費用。

選擇國家/地區後,按[繼續]進入第二頁

第二頁要填入個人資訊,還需要一張信用卡卡號。依照 Google 的說法,信用卡是為了驗證身分。要注意 GCP 不支援 JCB,請用 Visa/Master Card 來申請。

Create Project

進入 GCP 首頁後,可以先創建一個新的 Project,來放置要測試的東西,點選 Google Cloud Platform 旁的 Project 名稱,再點選跳出視窗右上角的 New Project

填入 Project name 跟要放置的 Folder,例如 Linux VM,完成 Project 的建置。

Create VM instance

有了 Project 後,可以在裡面創建需要的雲端服務,因為主要目的是驗證 Thin Client 是否可行,選擇創建一個 VM 實例來進行登入。要創建 VM 實例可以點選 Menu 中的 Compute Engine > VM Instances,選擇 Create

Create 的選項有很多,參照 GCP 的免費方案說明,使用 Region 為 us-central1 (Iowa),Machine Type 為 f1-micro

Boot Disk 看個人習慣,我平常用的環境是 Ubuntu 18.04 LTS,這邊選同樣的,如果有習慣 Debian 或其他 Distribution 的人,也可以自行選擇

點選[Create],完成 VM 創建。

Setup SSH

在終端安裝 SSH 的 Client,例如 Windows 常用的 putty,或者 Termius 這款 App。沒有 SSH Key 的人需要使用程式產生出 SSH Key,再將 Private Key 指定給 SSH Client,同時將 Public Key 放置到雲端。產生 Key 的步驟就不多說了,Windows 下的使用者可以用 PuTTYgen 來產生,Linux 使用者可以用 ssh-keygen。

有 Public Key 後,要將它放到雲端,方便以後登入。選擇 Compute Engine 中的 Metadata,點選 SSH Keys,可以管理金鑰。點選 Add SSH keys 來加入自己的 Public Key

加入後回到 VM instances,查看對應的 External IP,使用 SSH Client 輸入 user@address,登入 VM instance,記得 user 是要 key 對應的 user,address 是要 External IP。驗證看看能否登入。

小結

自從雲端的商業模式建立起來後,許多做法都會跟著改變,這是一個思維上的轉換,以前需要的東西有可能被淘汰掉,而新的需求會被創造出來。如果可以用 GCP 處理掉伺服器,我沒必要再去購買伺服器的硬體來自行架設網站,不但比較便宜,也省掉 Maintain 的 Effort。同時,高效能對 Laptop 也不會再是議題,取而代之的,應該是穩定而快速的網路服務配上輕便的終端顯示器。

最後放張完成圖,紀念一下。

Reference

Read more

OAuth 2.0 的身份認證:OpenID Connect

OAuth 2.0 的身份認證:OpenID Connect

OAuth 2 讓網路服務可以存取第三方的受保護資源,因此,有些開發者會進一步利用 OAuth 2 來進行使用者認證。但這中間存在著一些語義落差,因為 OAuth 2 當初設計目的是「授權」而不是「認證」,兩者關注的焦點會有些不同。OpenID Connect 是基於 OAuth 2 的一套身份認證協定,讓開發者可以在 OAuth 2 授權的基礎上,再加入標準的認證流程。在這篇文章中,我會說明授權跟認證的場景有何差異,並講解 OpenID Connect 如何滿足認證需求。 因為 OpenID Connect 是建構在 OAuth 2 的基礎上,我會假設這篇文章的讀者已經知道 OAuth 2 的組件與流程,如果你不熟悉,可以先閱讀另外兩篇文章 * OAuth 2.0:

By Ken Chen
更好的選擇?用 JWT 取代 Session 的風險

更好的選擇?用 JWT 取代 Session 的風險

因為 HTTP 是無狀態協定,為了保持使用者狀態,需要後端實作 Session 管理機制。在早期方式中,使用者狀態會跟 HTTP 的 Cookie 綁定,等到有需要的時候,例如驗證身份,就能使用 Cookie 內的資訊搭配後端 Session 來進行。但自從 JWT 出現後,使用者資訊可以編碼在 JWT 內,也開始有人用它來管理使用者身份。前些日子跟公司的資安團隊討論,發現 JWT 用來管理身份認證會有些風險。在這篇文章中,我會比較原本的 Session 管理跟 JWT 的差異,並說明可能的風險所在。 Session 管理 Session 是什麼意思?為什麼需要管理?我們可以從 HTTP 無狀態的特性聊起。所謂的無狀態,翻譯成白話,就是後面請求不會受前面請求的影響。想像現在有個朋友跟你借錢,

By Ken Chen

Goroutine 的併發治理:掌握生命週期

從併發的角度來看,Goroutine 跟 Thread 的概念很類似,都是將任務交給一個執行單元來處理。然而不同的是,Goroutine 將調度放在用戶態,因此更加輕量,也能避免多餘的 Context Switch。我們可以說,Go 的併發處理是由語言原生支援,有著更好的開發者體驗,但也因此更容易忘記底層仍存在著輕量成本,當這些成本積沙成塔,就會造成 Out of Memory。這篇文章會從 Goroutine 的生命週期切入,試著說明在併發的情境中,應該如何保持 Goroutine 的正常運作。 因為這篇講的內容會比較底層,如果對應用情境不熟的人,建議先看過同系列 * Goroutine 的併發治理:由錯誤處理談起 * Goroutine 的併發治理:值是怎麼傳遞? * Goroutine 的併發治理:管理 Worker Pool 再回來看這篇,應該會更容易理解。 Goroutine 的資源使用量 讓我們看個最簡單的例子,假設現在同時開

By Ken Chen

Goroutine 的併發治理:管理 Worker Pool

併發會需要多個 Goroutine 來同時執行任務,Goroutine 雖然輕量,也還是有配置成本,如果每次新的任務進來,都需要重新建立並配置 Goroutine,一方面不容易管理 Goroutine 的記憶體,一方面也會消耗 CPU 的運算效能。這時 Worker Pool 就登場了,我們可以在執行前,先將 Goroutine 配置好放到資源池中,要用時再調用閒置資源來處理,藉此資源回收重複利用。這篇文章會從 0 開始建立 Work Pool,試著丟進不同的場景需求,看看如何實現。 基本的 Worker Pool Worker Pool 的概念可以用這張圖來解釋 Job 會放在 Queue 中送給 Pool 內配置好的 Worker,Worker 處理完後再將結果送到另一個 Queue 內。因為這是很常見的併發模式,

By Ken Chen