黑皮考町

前言 前一篇 有跟各位介紹了三種在 GCP 上跑排程的方式, 相信大家對於 GCP 上的排程功能已經有初步的認識了吧! 這一篇會手把手帶著各位實作基於 "Cloud Scheduler & Cloud Run" 的排程方法, 詳細的步驟如下 Step 1. Deploy Service on Cloud Run Build Container Image 使用 Cloud Build 將原始碼打包成 Container Image gcloud builds submit --tag gcr.io/ <PROJECT_ID> / <CONTAINER_NAME> Example: gcloud builds submit \     --tag gcr.io/my-project/my-cronjob Deploy 將服務部屬到 Cloud Run 上跑, 並且要求每個請求都要做身分認證 gcloud run deploy <CONTAINER_NAME> \ --image gcr.io/<PROJECT_ID>/<CONTAINER_NAME> \ --platform managed \ --no-allow-unauthenticated Example: gcloud run deploy my-cronjob \     --image gcr.io/my-project/my-cronjob \     --platform managed \     --no-allow-unauthenticated 這個步驟做完後會得到服務的 Endpoint Step 2. Create Cloud Scheduler With IAM 這邊首先建立一個新的 Service Account, 並賦予執行 Cloud Run 上服務的權限 Create Service Account gcloud iam service-accounts create <SERVICE_ACCOUNT_ID> \ --displa...

前言 排程一直是 IT 自動化的流程中非常重要的一個環節, 當在設計一個系統的時候, 若能將定期發生的事件(如定期的系統檢查, 或是定期的資料備份)交由程式自己來處裡, 對於工程師來說就能省下許多的時間並把精力專注在專案開發上 要在GCP 上安全的實現排程的功能, 基本上可以歸納為以下三個方式 方法一: GAE + Firewall 第一個方法是在 GAE 上佈建一個專門跑 CronJob 的服務, 透過 GAE 內建的 Scheduler 定期去打某個指定的API 整個過程都是走 HTTP 的溝通方式, 萬一 API 的 Endpoint 被猜到就有可能被有心人士隨意使用, 所以通常都會在 API 前再多加一層 Firewall 來攔截未知來源的請求 除此之外,  程式端也可以透過辨別 Header 裡的資訊來拒絕惡意請求, 達到雙層保護的作用 方法二: Cloud Scheduler + Cloud Run 這個方法是由 Cloud Scheduler 走 HTTP 的通訊協定來定期觸發 Cloud Run 上的服務,  但是跟方法一最大的差別是, 這邊可以要求 Cloud Scheduler 帶一個特別的身分去觸發 Cloud Run, 而Cloud Run可以限制只有擁有 IAM 身分的請求才會被放行給服務層處理, 否則會出現以下的錯誤訊息 詳細的實作方法, 看這篇 方法三: Cloud Scheduler + Pub/Sub + Cloud Function 這應該是三者之中最安全的作法, 首先 Cloud Scheduler 先去觸發 Pub/Sub, 再由 Pub/Sub 以事件的方式去驅動 Cloud Function 上的服務, 這個方法看似複雜但有個非常大的好處是, 由於溝通方式不走 HTTP, 所以不需要暴露部屬在 Cloud Function 上的服務, 也因此可以更安全的在 GCP 的沙箱內執行指定任務 總結 實現排程任務可以簡單歸納成三種方法, 基本上都有各自的優缺點, 若是要跑long run的任務, 可以選擇 GAE 的方式, 因為他的 time out 時間是三者最長的 若是考量到安全性的問題,  建...