AI 智能識別訂單語音撥放系統 (部署篇)，經驗筆記，踩坑篇

由於這次的專案比較小，主要在於 NLU 自然語言理解訂單，再進一步去做後續的事情。

用在咖啡店內，又是內部使用，考慮到經費與訂客數，所以我選擇這次選擇了 dialogflow 來做 NLU 的處理，在佈署到google run 上(圖1)。 

圖1 google run

沒想到 光要在google run 運行 就是個關卡的開始，由於經費的考量 一切是以免費為宗旨，就不使用 Google Artifact Registry。

1. 程式放在github 在和 google build 去做綁定，當 github 更新 cloud build 就會 自動更新程式。(圖2)

圖2. cloud build 建置

但後來在做log 監控的時候，發現每次只要更新python，並沒有更新dockerfile 或 安裝檔，cloud run 又會自動更新....

觀察了一下狀況發現：「內容變了」等於「Image 變了」，而 「Image 變了」等於「需要新的 Cloud Run Revision」，所以才會 每次cloud run 會重跑，但 每個月Cloud Build  只有120分鐘 免費額度、Artifact Registry 只有0.5 GB，所以需要謹慎使用免費。

後來的決策是:

1. 連結到github的自動更新關掉，改成手動更新，當dockerfile 有變更，在手動更新。(圖3)

圖3 手動更新 dockerfile 

2. 程式就掛載到 cloud storage。(圖4、圖5)

圖4.掛載到cloud storage

圖5.掛載到cloud storage

之後只要每次更新main.py，只要更新 cloud run 就好了。

但有些缺點，更新了 Bucket 裡的程式碼，Cloud Run 並不會知道我改了什麼檔案，需要「手動重啟」，再來就是啟動、回應速度會有點慢，但對於識別意圖來說，並無傷大雅。

其他困難點:  IAM 權限的設定、API 和服務的啟用。
IAM 要自己設定，沒有設定好 就沒有權限使用 bucket無法用。(圖6)
API 服務 沒開啟 就沒有這項功能可以用。(圖7)

圖6. IAM 權限設定

圖7. API 服務 

剛好從這個專案，一邊做一邊熟悉，熟悉後 會發現cloud build 自動化CI/CD、cloud run 會越來越熟練。

哈，但3不5時 就要計算一下免費額度的使用量，看一下LOG 監控，一天差不多就是執行這些。(圖8、圖9)

圖8. Log 監控

圖9.  監控費用