黑皮考町

 使用 Terraform + Slack + Cloud Function 快速建立簡易通知系統 前言 要設計一個通知系統, 一般都會需要考慮到前端, 後端, 以及後續部署維運相關的問題, 但其實想要快速建立通知系統並不難, 只要善用雲端資源, 十分鐘也能建立一個簡易的通知系統 以下示範, 如何使用 Slack 作為訊息輸出的前端, 以及整合 Cloud PubSub 和 Cloud Function 作為訊息處理的後端, 最後再以 Terraform 將所有元件的部署流程自動化, 使日後維運更加輕鬆簡易 前端 整合 Slack 時, 需要先取得 Webhook Token  有了 token 就能透過 Slack 的 API 將訊息打到指定的 Channel 中, 使用以下方式來測試 Webhook token 有沒有作用 測試 andy@host: curl -X POST --data-urlencode "payload={\"channel\": \"#etl_job\", \"username\": \"webhookbot\", \"text\": \"This is posted to # etl_job  and comes from a bot named webhookbot.\", \"icon_emoji\": \":ghost:\"}" https://hooks.slack.com/services/T02G1HSTG/AAA4M9NN095/1VDjE3453234292ZTF4IRDEv ok 後端 後端的部分會整合 Cloud PubSub 作為觸發 Cloud Function 以習訊息輸入的來源 Source Code const { IncomingWebhook } = require('@slack/webhook'); exports.handler= async (message, context) => {  const messageData = message.data    ? Buffer.from(mes...

前言 排程一直是 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 時間是三者最長的 若是考量到安全性的問題,  建...