Cloud Run 是什麼？6大特色介紹與實作教學

Cloud Run 是 Google Cloud 的全代管式 Serverless 服務，使用者僅需透過簡單的指令或 Console 介面，即可直接開發及快速部署具備高擴充性的容器化應用程式及管理服務。此次的 Cloud Run 教學將從環境建立出發，依序介紹版本更新、流量導流和觸發功能的操作方法。

在了解 Cloud Run 是什麼前，我們可先來認識 Serverless 服務。Serverless 服務因為擁有讓開發人員可不需煩惱基礎設施管理、機器維運和資源是否充足等問題的特點，所以開發人員能更專注在程式開發上。除了可簡化整體開發流程、減少建置成本，也能加速開發並提升程式穩定性。

Cloud Run 是什麼？Google Cloud 的 Serverless 服務之一

Google Cloud 上主要有三種 Serverless 服務，分別為 Cloud Functions、App Engine 及 Cloud Run。每種服務又依據不同的應用情況或需求，有不同的使用方式及應用情境。舉例來說，若想快速建置小批量的工作流程或單一 Function-based 的服務，則 Cloud Functions 為理想的選擇，因為它適用於原型設計（Prototyping）。而若是使用 Web 或 API 後端建置 Serverless App，且希望可以在單一應用程式中運行多個不同的服務，則 App Engine 為最佳選擇，因為它屬於 App-based 服務。最後，若服務需要更多的靈活性，且希望能並行運作 Containers 來處理大量的服務或作業，則建議使用 Cloud Run。這次我們將焦點放在 Cloud Run，來了解其特色及簡單的實作方式。

身為全代管式 Serverless 服務的 Cloud Run，讓使用者僅需透過簡單的指令或 Console 介面即可直接在 Google Cloud 上開發及快速部署具備高擴充性的容器化應用程式及管理服務，但無需管理任何基礎架構。此外，Cloud Run 也與 Google Cloud 上的其他服務相互整合，透過相互搭配來建置功能完善的整體應用服務。

在 Cloud Run 上，使用者可透過 Services 或 Jobs 來運行程式。無論是 Services 或是 Jobs，都必須將它包裝成 Container image 來部署至 Cloud Run。

另外補充一點，雖然同樣是使用 Conatiner image 進行部署，但 Google Kubernetes Engine（GKE）需要自行管理整個 Clusters 和內部資源調度等事項，而 Cloud Run 僅需管理單一或多個 Containers，建議大家依據需求選擇適合的服務。

Cloud Run 的6大特色

支援任何語言、程式庫和二進位檔

支援多種程式語言，如：Go、Python、Java、Node.js、.Net、Java、Kotlin、Scala 和 Docker 的功能，使用者可自行選擇要使用哪種程式語言，並運用任何語言或作業系統的程式庫，甚至自備二進位檔。

容器化工作流程及整合式服務

Cloud Run 支援任何標準的 Container images，且非常適合與 Google Cloud Container ecosystem 搭配使用，像是 Cloud Build、Artifact Registry 和 Docker 等。此外，使用者不需調整任何設定，即可直接與 Cloud Monitoring、Cloud Logging、Cloud Trace 和 Error Reporting 整合，確保應用程式維持良好的健康狀態。

以量計價，即付即用

使用 Cloud Run 只需要支付程式運作期間的費用，計費單位為100毫秒。

自動擴展、並行運作及非同步事件處理

Cloud Run 會依據流量自動調整容器主機的資源配置，從零擴展至多個資源或縮小至零（Scale up or down from zero to mulitples），每個容器最多可處理1,000個並行請求，且可利用 Container image 串流功能來縮短啟動時間。此外，也能透過設定觸發條件，接收來自 Google 服務、SaaS 或使用者的應用程式事件。

備援及安全性

Cloud Run 屬於 Regional 服務，因此系統會自動將資料複製到多個 Zones，若需永久儲存空間，亦可串接 Filestore 或 Cloud Storage FUSE 等網路檔案系統（Network File Systems）。此外，Cloud Run 也可搭配 Secret Manager 掛載自己的密鑰。在部署時，使用二進位授權，使其只能接受被信任的 Container image，且於 Cloud Run 中的 Container 運作時會與其他服務隔離，具備專屬的身份及權限。

HTTPS 網址及 HTTP/2、WebSocket 和 gRPC 串接

每個 Cloud Run 服務皆具有一個立即可用的穩定 HTTPS 端點，且此端點本身已完成傳輸層安全標準（TLS）的終止作業。此外，使用者亦可透過 HTTP/1.*、HTTP/2、WebSocket 或 gRPC（Unary and Streaming）來執行及串接 Cloud Run 服務。

Cloud Run 部署教學

了解完 Cloud Run 基本功能後，接著進入實作教學。以下會介紹 Cloud Run 所提供的三種實用功能與執行方法，分別為版本更新、流量導流及搭配 Eventarc 的觸發。

環境建立

在進入第一個實作教學前，我們需先部署一個 Cloud Run 環境。首先，在 Artifact Registory 建立一個 Repository 以上傳欲部署在 Cloud Run 的 Image。Artifact Registory 為 Container Registry 的進化版，主要提供一個單一位置給使用者儲存和管理 Language packages（如 Maven 或 npm） 以及 Docker container image。它也與其他 Google Cloud CI/CD 服務或第三方 CI/CD 工具完全整合。

建置完 Repository 後，為了讓使用者能透過這個 Repository 推送及提取套件，我們需先初始化 gcloud，並設置 Docker 身份驗證，主要目的是將 gcloud 設定為憑證輔助程式，使 Docker 有權限進入任何已安裝 Google Cloud CLI 的 Artifact Registry 的 Repository 環境。

複製上述指令後即可於 Cloud shell 中執行，結果如下圖。若有顯示 Credential helper 的相關資訊，代表指令執行成功，身份驗證完成。

接下來則要上傳本次實作所需的 Image，主要以公開且預先建好的基本 Hello world image 為例。我們需先透過以下的 docker pull 指令，將特定的 Image 下載到我們自己的環境中。

docker pull 
us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

並利用 docker tag 指令，將下載的 Image 在自己的環境內訂定標籤 tag1，若沒有指定則 docker 會預設為 latest。

docker tag us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
asia-east1-docker.pkg.dev/<Project ID>/<Repository name>/<Image name>:<tag1>

最後，我們可透過 docker push 指令將 Image 推送到剛剛建立好的 Repository。

docker push asia-east1-docker.pkg.dev/<Project ID>/<Repository name>/<Image name>:<tag1>

若以上指令都執行成功，就可以在我們的 Repository 看到剛剛上傳的 Image 囉！

Image 上傳完後就可以來部署 Cloud Run 了。進入到創建 Cloud Run 的介面，在 Container image URL 欄位中選擇包含版本資訊的 Image（若剛剛上傳時未特別指定標籤名稱，此時會顯示 latest）。另外，本次實作不額外修改其餘設定，皆以預設選項進行創建。

等待 Cloud Run 部署可能會需要幾分鐘的時間，但當我們看到 Console 介面顯示 URL 後，可以在新的分頁將此 URL 貼上，可以看到網頁上顯示 Hello, world! Version: 1.0.0 的資訊，也就是剛剛部署的 Image 內容，這代表 Cloud Run 已部署成功了。

Cloud Run 教學實作一：版本更新

當開發團隊開發了新的程式版本，或是針對舊有程式進行更新，我們可透過上傳更新後或新開發的 Image，更改現有服務版本內容。上傳新版 Image 的步驟跟前面一樣，需先上傳到 Artifact Registry，但差別只在訂定了不同的標籤 tag2 以便區別新舊 Image。

接著我們要更新 Cloud Run 部署的 Image 版本，前面那個步驟僅是上傳到 Repository。一樣也是在 Container image URL 欄位選擇剛剛上傳的 Image 版本，也就是帶有 tag2 版本的 Image。

選擇完後再重新部署一次，直到 Console 上出現 URL，這邊一樣可嘗試將部署完的 URL 貼到新分頁網址內，若有看到 Hello, world! Version: 2.0.0 的資訊，就代表成功完成版本更新了。

Cloud Run 教學實作二：流量導流

若發現部署的新版本產生問題需進行程式修復，但可能連帶影響正在運作的服務時，就會需要做完全的退版，也就是將所有流量導回舊版本，以確保服務不會中斷。根據此種應用情境，我們可以在 Cloud Run Console 的版本介面（REVISIONS），透過 MANAGE TRAFFIC 修改新舊版本的流量導流機制。

現在示範需將 Cloud Run 做完全退版的模擬，我們可以在 Revision 2 欄位中選擇舊版本的服務，並在 Traffic 2 欄位中輸入100，代表希望將所有流量導回這個版本。

另外，有時候部署新版本的應用程式或服務時，可能會為了測試實際運作的效能或表現，而嘗試金絲雀部署，也就是先將少量流量導流到新版本，運作一陣子確定可正常執行時，再漸漸將大量的流量從舊版本導流至新版本，減少專案環境內可能因新版本上市而帶來的風險，確保整體的穩定性。

若要進行金絲雀部署，一樣要先將新版本部署到 Cloud Run，但與先前版本更新實作的差別是需取消勾選 Start the revision immediately，代表流量不會在部署完後，100%馬上導到新版本。接著再透過 MANAGE TRAFFIC 來調整不同服務版本間流量導流的比例差異，即可達到金絲雀部署。

Cloud Run 教學實作三：觸發功能

本文最後一個實作教學主要來介紹透過 Cloud Storage bucket 事件觸發 Eventarc，並將事件資訊傳遞至 Cloud Run 作為事件的接收端。首先，我們需要建立一個 Service account 來作為存取服務的媒介，依據本節實作所需設定賦予它以下兩個角色權限。

Service account 所需權限：
• Cloud Run 執行者：roles/run.invoker，使其能夠使用 Cloud Run 服務
• Eventarc 管理員：roles/eventarc.admin，使其能夠完整控管所有 Eventarc 資源

除了創建新的 Service account，我們也需要賦予 Cloud Storage 的 Service account Pub/Sub 發布者（roles/pubsub.publisher）的角色權限，使其能夠將 Bucket 內變動的資訊透過 Eventarc 發布至 Cloud Pub/Sub Topic，而後 Eventarc 再透過 Cloud Pub/Sub subscription 將事件傳遞到事件接收端，也就是我們的 Cloud Run。

接著，我們需要創建一個目標 GCS Bucket。這邊要注意的是，此 Bucket 必須與 Eventarc 觸發器位於相同的 Google Cloud projest 及相同區域中。

創建完 Bucket 後，需先將我們欲部署的 Image 上傳至專案內的 Container Registry（或 Artifact Registry），上傳步驟可參考前一章節。而此 Image 主要包含觸發事件所涵蓋的自訂資訊，當觸發事件結束後，可以在 Cloud Run 中查看所包含的資訊紀錄。

再來就是設置本節實作的事件接收器 Cloud Run。與先前一樣，在 Container image URL 欄位選擇剛剛上傳的 Image，並在 Authentication 欄位選擇 Require authentication，代表會強制透過 Cloud IAM 管理 Service account 在執行觸發時的權限，也就是先前授予 Service accout Cloud Run invoker 角色權限的動作，才能成功將事件傳遞至此 Cloud Run。最後按下創建，等待 Cloud Run 部署完成，就能著手設置 Eventarc 觸發器了。

進入到 Eventarc 的 Trigger 創建頁面，在 Event provider 欄位選擇 Cloud Storage，並在 Event 選擇 google.cloud.storage.object.v1.finalized，如此一來有新物件成功上傳至 Cloud Storage bucket 就會觸發此 Eventarc。接著，在 Bucket 欄位選擇先前創建好的目標 Bucket。

而在 Service account 欄位，一樣選擇我們先前創建的那個具有 Eventarc Admin 角色權限的 Service account。

最後，在 Event destination 中點選 Cloud Run，並選擇剛剛我們部署完成的 Cloud Run 服務，按下創建後我們的 Eventarc 就創建完成了。

在本節觸發功能實作教學的所有服務都創建完後，我們來測試看看是否可如預期地在 Cloud Run 收到事件觸發資訊。我們先將一個文件上傳至目標 Bucket，以觸發先前創建 Eventarc 時所選擇的 Cloud Storage object finalized 事件。

上傳完成就代表觸發事件已結束，我們可在 Cloud Logging 或事件接收端的 Cloud Run LOGS 介面中查看是否有相關觸發資訊。若有成功看到，就代表本次觸發事件執行成功。觸發事件傳遞的內容可依據個人需求，在部署的 Image 中做程式調整，而調整完後也能透過版本更新或是流量導流來進行不同 Images 間的置換。

結論

Cloud Run 作為全託管的 Serverless 服務，適用於各種規模與架構的容器化服務部署。此外，使用 Cloud Run 除了可提高部署效率，也能減少使用者在服務管理上的負擔，並透過幾近微服務的架構規劃，以即付即用的形式為使用者省下最多成本。

這次簡單介紹了 Cloud Run 這項服務和其功能與特色，並示範了三種實用功能的實作，希望能讓大家更好上手這項工具。如想更了解 Cloud Run 或 Google Cloud，歡迎與我們聯繫。

▋延伸閱讀：

・使用 Cloud Run 部署一個 API Server
・【K8s 是什麼】比較 Docker 容器、K8s 和 GKE 的架構與優勢
・【Google Cloud K8s 教學】第一次用 GKE 就上手
・GKE Autopilot 教學―輕鬆管理 K8s，加快軟體開發流程