黑皮考町

前言 Google App Engine (GAE) 提供了非常方便的環境讓開發者可以輕鬆地部署服務, 除此之外還有許多有用的功能族繁不及備載... 但若如果部署在 GAE 上的服務發生異常時, 我們該如何去追蹤問題呢？ 以下簡單介紹一下幾個 GCP 上好用的服務幫助我們可以快速的縮小問題的範圍 Cloud Trace Cloud Logging Cloud Trace 這個服務可以讓我們快速的找到效能上的瓶頸是來源自哪隻 API 可以看出問題可能出在 /v1/interest/ads_pref 這隻API 上, 並且發生時間可能在  17:40 分左右 Cloud Logging 知道效能的瓶頸是源自於某隻 API 之後, 接下來可以用 Log Viewer 來看程式是否有拋出任何異常的訊息 在 Query Builder 下查詢語法來找出可能的線索 resource.type="gae_app" resource.labels.module_id="My-Service" textPayload:"exec bulk" timestamp >= "2020-05-15T17:40:00+08:00" AND timestamp <= "2020-05-15T17:43:00+08:00" 這個語法會找出 My-Service 這隻服務在 2020-05-15 這天17:40~17:43 產生含有 exec bulk 這段訊息的 log  以下是其他查詢可以用的運算子 =           # equal !=          # not equal > < >= <=   # numeric ordering :           # "has" matches any substring in the log entry field =~    ...

前言 Google App Engine (GAE) 提供了兩種部屬環境可以選擇, 對於剛接觸這個服務的新手, 一定很難搞清楚這兩者的差別到底在哪裡, 以下就做個簡單的介紹跟比較 Standard Environment 為 Serveless 的服務架構, 當服務沒有被使用時則自動釋放計算資源, 好處是當資源被釋放之後 Google 不會跟你收錢 Standard Environment 在作水平擴展時也比較快, 畢竟它不需要額外花時間重建 VM 然後再重新安裝系統 而 Standard Environment 部屬所花的時間也是遠少於 Flexible Environment, 通常不到一分鐘就可以完成部屬 如果不需要特定的 Runtime 或是也不關心底層 Infra 的配置, 基本上 Standard Environment 是最佳的選擇。 Flexible Environment Flexible Environment 的底層是跑 GCE 的 VM, 在部屬的時候必須聲明 VM 的規格, 而就算服務沒有被使用 Google 還是會收維運 VM 的相關費用, 但好處是在專用的 VM 上跑服務不會有 Cold Start 的問題 除此之外, 部屬在 Flexible Environment 上的服務, 是以容器的形式跑在 VM 裡的, 所以在部屬的時候需要額外花時間將原始碼打包成容器映像, 因此部屬的時間通常會比較長 Flexible Environment 擁有更多的彈性去客製化部屬環境, 可以將客製化的環境打包在容器裡, 再直接將容器上傳上去部屬, 或是直接 SSH 連進 VM 裝套件都是做得到的, 因此能夠隨意的客製化部屬環境, 或許是讓人選擇 Flexible Environment 最大的原因 比較表 總之, 若想要客製部屬的環境, 毫無疑問 Flexible Environment 會是最佳的選擇, 但若偏好使用 Serverless 的服務架構跟收費模式, 那可以試試 Standard Environment 參考資料 https://cloud.google.com/appengine/docs/standard/python/how-instances-are...

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

前言 話說 Google 推行 App Engine 已經有好一陣子了, 就算後來 GCP 的光芒幾乎都聚焦在其他產品上如 Kubernetes Engine, 但直至今日還是有很多死忠的開發者喜歡使用 App Engine 這項服務, 對於不想花時間搞底層環境的人來說, 將服務部屬在這兒絕對是最佳的選擇 以下簡單的介紹如何在 Google App Engine(GAE) 上部屬Go程式 首先, 設定環境 需要在開發的環境裡安裝 glcoud 的 SDK 並且初始化某些設定 gcloud init 或是, 直接打開 CloudShell 直接在上面敲 gcloud 的指令也可以 (但最後部屬時需要把程式碼 clone 到 CloudShell 的機器裡) Step 1. 建立App.yaml 在工作目錄中建立 App.yaml 來描述部署的環境, 如下所示 在 App.yaml 裡面可以定義 Runtime, Service Name, 以及程式中會用到的 Environment Variable 等等 ex: runtime: go env: flex service: my-server env_variables: RUNMODE: stage automatic_scaling: min_num_instances: 1 max_num_instances: 1 cool_down_period_sec: 120 # default value cpu_utilization: target_utilization: 0.7 resources: cpu: 1 memory_gb: 5 disk_size_gb: 10 volumes: - name: ramdisk1 volume_type: tmpfs size_gb: 0.5 App.yaml 裡有一個欄位 env 可以用來指定即將部屬的環境 env: flex 這邊要注意的是 GAE 提供兩種不同的部屬環境 Standard 以及 Flexible 可以選擇 Standard V.S Flexible Environment ...