忍者工坊
0%

發表於 更新於 分類於

前言

Serverless 架構是一個基於 FaaS(Function as a Service) 實作的一個服務，讓開發者可以更專注在開發功能，將 yml 檔設定好其餘維運的問題都交給 AWS、Google、Azure 這些服務商去處理，只要把信用卡準備好就好(?)，讓開發者在寫完程式之後不用煩惱部署得問題，減少的不少的麻煩事。
那因為現任公司的服務都是基於 AWS，如此這般我就接觸到 Serverless(以下簡稱 sls) 這個框架啦 (想更深入了解 FaaS 架構可以參考 AWS)
[2019/07/04 更新]
若已經暸解的朋友可以參考我的 python 版本:
louis70109/aws-line-echo-bot
Ruby 的範例版本:
louis70109/aws-ruby-line-echo-bot

為什麼要 Serverless

[2019/06/29 更新]
以用一個 Ruby on Rails 寫的機器人為例，在寫完個 webhook function 後，設定路由然後部署，一般主機或是虛擬機就很麻煩，要安裝佈署環境以及一安裝堆相關套件，完了之後設定 Domain 什麼的有夠花時間。但若是使用 heroku 部署就很方便，Login — Create-Deploy 馬上就結束，機器人馬上就上線了，實在是俗又大碗呀～
但我覺得像是 LINE Message 這種 stateless 的服務，且只要一個 function + route 就能實作的程式最適合 Serverless 了，讓專案可以簡潔有力，只要寫一個 function+yml 設定並打個指令就部署了，而且 domain 還附贈 SSL，將服務交給 AWS 也不需要擔心，整個就是超級方便啊！
Cold start time 問題，依照我目前使用的結果下來，在 heroku 以及 AWS Lambda 同時睡著的情況下，AWS 起床的回應速度大概 1 秒左右，而 heroku 則大概落在 10~15 秒(參考)。如下圖所示的免費方案，基本上開發階段應該是不至於到 100 萬/月 個請求吧 😆，所以這部分就別擔新大力地給他用下去～ (感謝 petertc 幫忙找這方面的問題 💪)

AWS Lambda 免費方案
接下來就讓我介紹如何使用 sls + LINE Message API 建立一個 Echo bot 吧！

環境

npm 6.9.0
python 3.7.3
serverless 1.45.1

建立 AWS 存取金鑰

首先要先有個 AWS 帳號(廢話) ，如果沒有綁定信用卡記得去綁定才能繼續，接下來就可以去就可以去建立鑰匙囉！

如上圖，按下紅色框框的部分，接著按箭頭指的按鈕，就會建立一個我們要的金鑰囉！
AWS secret & ID key

如上圖所示，可以下載 key，AWS 不會幫忙保存 Secret key，若這視窗關掉的話 key 就不見了，所以使用者可以自行下載檔案保存，以免哪天要部署的時候找不到 key。
接著就將這兩個參數加入環境變數中：

1
2
export AWS_ACCESS_KEY_ID=<your-key-here>
export AWS_SECRET_ACCESS_KEY=<your-secret-key-here>

Serverless 建立與部署

首先先透過以下指令讓 npm 幫忙安裝 sls 的指令。

1
npm install serverless -g

安裝完之後就透過 sls 指令來建立專案嚕！

1
serverless create — template aws-python — path aws-line-echo-bot

severless 指令可以縮寫成 sls
template = 想用什麼平台以及語言就在此模板了 (參考)
path = 檔案名稱


透過 severless 建立專案指令
依照不同的 template 可能會建立 N 個檔案，但主要還是以下三個檔案

1
2
3
.gitignore
handler.py = 主程式的地方
serverless.yml = 所有設定都在這裡，funtion 參數會對應到指定的路由

在部署前須至 serverless.yml 裡，把 runtime 的 python2.7 改至 3.7，否則會因版本問題導致錯誤。

1
serverless deploy # sls deploy

Serverless 部署畫面

接著到 AWS Lambda 以及 S3 就可以看到第一次部署完的程式以及檔案囉！

加入 LINE Message API

既然是寫 python，那一定是要用 line-python-sdk
照著官方用法應該是要執行以下指令安裝套件

1
pip install line-bot-sdk

不過我們是要部署到 AWS 的 Lambda 上，且因為他是無伺服器運算的服務，所以他沒辦法跑 pip 去幫我安裝套件。
此時就要出動 requirements.txt 來管理相依套件 ，但只有加入它 sls 根本不認識，因此我們需要安裝 pulgin 來讓 sls 認得(requirements.txt)。

1
sls plugin install -n serverless-python-requirements

安裝指令 & package.json
如圖，安裝過程中會自動建立 package.json，且會幫忙在 serverless.yml 裡面加入 pulgin，這樣 sls 在部署時就認得 requirements.txt 囉！
接著將 LINE SDK 加入 requirements.txt， AWS 就會幫忙安裝套件了。

1
echo "line-bot-sdk==1.12.1" > requirements.txt

然後新增一個 setup.cfg 並加入以下內容：

1
2
[install]
prefix=

由於 AWS Lambda 上都會將套件安裝在本地端(Lambda 上)，因此在執行 pip install -t . -r requirements.txt 時會需要 setup.cfg。
至於詳細原因嘛～還有請各位大大幫小弟解答 🙏
最後就處理 handler.py 以及 serverless.yml 囉！
將上述兩個 gist 分別貼到自己的 handler.py & serverless.yml，在 hanlder.py 裡的 CHANNEL KEY & TOKEN 記得換成自己的機器人 👾 哦！
佈屬完狀態
接著在執行一次 sls deploy，將程式部署上去，如上圖所示，在 endpoints 那行會有一個網址，將那網址放到 LINE Webhook URL 上並 Verify 看看有沒有成功，如下圖所示。

最後對著自己的機器人發個話，看他有沒有回應你一模一樣的文字，若成功了就能往下一步應用層繼續開發囉！若失敗了就要檢查一下是不是有哪個步驟做錯了～

結論

因為公司的緣故讓我能夠接觸到這神奇的 Serverless，經過這次的分享加深我對於 FaaS 的架構更加了熟悉，由於我也是初碰，我認為使用上可以把它當作是一個 Docker 的容器或許概念上會比較好理解，後續還有很多的設定檔都還沒詳細研究，最近讓我先研究研究一下再上來分享。

文章中有任何勘誤歡迎指正

如果覺得這篇文章有幫助的話請給我個掌聲鼓勵我一下 👋
下列是我的這次實作的專案，如果有幫助也來顆星星吧！
louis70109/aws-line-echo-bot

參考

發表於 更新於 分類於

前言

大家好，我是 NiJia，很榮幸被邀…是本來就負責 Chatbot meetup 的 Co-organizer，連續兩天參加了 meetup 真的是揮灑自己熱情兩邊跑(好 High)，希望藉由社群的分享讓大家可以吸收到不同的新知！

這次活動場地感謝 溫明輝 教授幫 chatbot 借了台北商業大學的場地，而台北商業大學最近有跟 LINE PROTOSTAR 聯合舉辦了 ”LINE Chatbot 對話機器人設計大賽”，覺得自己的機器人不錯嘛？歡迎大家踴躍報名參賽哦！

北部小聚 in 台北商業大學

LINE Platform Update 201910 - Evan Lin

長期支持 Chatbot 社群的 Evan 大大為大家帶來陣子 LINE 的更新內容，像我這種開發者最期待的就是 LIFF v2 終於上線了 🎉，當中增加了很多種應用讓嗷嗷待哺的工程師們終於可以生出更多種不一樣的應用啦，

  • 外部瀏覽器上使用 LIFF 🎉
  • 兼容 Login v2.1，取得使用者基本資訊
  • 可掃描 QR code
  • 在 LIFF 的 webview 下可獲取使用者的 OS/Language/AccessToken 等等的內容

詳細參考: https://engineering.linecorp.com/ja/blog/liff-v2/

試玩新功能：

LINE Bot 上的表單驗證、搜尋以及分頁 - 郭佳甯

簡報連結

身為卡米粉的我終於再度聽到卡米哥的議程啦，這次介紹的是從 COSCUP 之後一直更新的 kamigo，並完全使用這個套件做的寵物協尋機器人，此議程就已這隻機器人為主體介紹。

在實作網頁的過程中最長需要弄的東西不外乎就是表單驗證、搜尋以及分頁，因為 kamigo 是讓使用者經由 LIFF 幫忙將表單回傳成一份 JSON 至使用者的的對話欄上，
再轉介給 controller 去解析並儲存進資料庫，但若使用者在操作的過程中少輸入會不會一樣送出？
此時 kamigo 透過 rails 原生既有的 validates 來驗證表單欄位內容，並藉由 Turbolinks ajax + js.erb 讓表單在送出時先透過 ajax 打到後端驗證，若驗證失敗後則回傳告知 LIFF 哪個欄位有問題，這個方法也讓我使用到這個套件的肌肉仔可以透過 rails 的鬼神方法幫我驗證表單，如此一來在表單的確認上就沒問題啦！🎉

順手捐星星，救救卡米狗: https://github.com/etrex/kamigo

不懂開發也能建立屬於自己的 Chatbot - 白凱仁

接著由 Cloud Native Taiwan User Group Co-organizer - Kyle Bai 為大家帶來講題，藉由故事的敘述讓大家知道他是為甚麼啟動這個 idea 出來，並靈活運用圖片演示對話流程(筆記)，並因為打遊戲的困擾決定做一個機器人來解決朋友問題，運用 container 的技術來封裝 chatbot App，再用 k8s 透過 N 台機器來管理 container 讓它獲得不死之握能力，確保服務的可用性與延展性。

最後再透過 live demo 的方式讓會眾們一飽眼福，若是對於 Cloud Native 相關技術有興趣的朋友別忘了加入社群，或是你已經有相關主題遲遲沒地方講？趕快搭上線讓你有舞台可以發揮 😎

閃電秀

這部分就參考 Evan 大大的文章

  • Afore: 如何用 Chatbot 說 921 故事
  • 謝化挺: 921 Chatbot 開發心得
  • C.T Lin: 介紹即將發佈的 Bottender v1
  • kevin: 宣傳 DevFest 活動
  • Demo: FunWater - It’s time to rethink about the “single-use plastic” product.

中部小聚 in 夢森林

LINE Pay 串接全紀錄 - KoKo

身為通勤學的作者也是自由工作者的 KoKo 每次都熱情參加 Chatbot 的活動 👏，本次邀請來帶大家認識 LINE Pay，透過詳細的介紹 LINE Pay 帶著大家一步一步做並提醒大家當中需要注意的部分，有部分的會眾是金融相關背景也特地來了解 LINE Pay 的各種機制，透過 KoKo 解釋後讓會眾更清楚裡頭眉眉角角，此時真的是感受到滿滿的熱情，講者跟會眾踴躍的討論也讓整個活動更活絡，想了解更多議題的歡迎來許願或是來當講者體驗一下中部人真正的活力啊！

serveo 讓你用 Docker 開發 chatbot 也能過的去 - Jimmy

COSCUP 就來擔任 Chatbot Taiwan 講者的 Jimmy，本次來分享他包起來的 servo 的容器服務，主要原因是因為在開發機器人時大家都習慣用 ngrok，只是每次都要重新執行重新貼到 LINE Bot 或 LIFF 上，如此繁雜的步驟現在只要透過 container 以及自定義的 DNS 每次只要 docker 啟動後 Domain 啟動後即可開始寫機器人，根本不需要再進後台重新填寫，只能說工程師沒有極限啊！

透過 Jimmy 將 serveo 打包的 container 就不會有連線不穩定的問題(我有經歷過 🤣)，這邊需要注意的問題 serveo 有 ssh 連線數的問題，但一般來說在開發人數不會太多，這樣理論上已經很夠用了～

若對這服務有興趣的話：https://github.com/taichunmin/docker-serveo

閃電秀

感謝 Flex Simulator 拯救了我 - 陳佳新

身為中部負責人的佳新，介紹 LINE 的工具 - Flex Message Simulator，因為應用大量的 flex message 在自家產品「彰化旅行+」上，透過 LINE 的工具讓我們使用 flex message 上能夠叫得心應手。

ChatBot 製造 ChatBot - EJ Lin

近期加入 chatbot 志工的 EJ 製作了一個可以透過 chatbot 管理 chatbot 的服務，將使用者所註冊機器人的 secret 以及 token 放入後，就能訂閱 ptt 特定作者的文章，當作者只要發文就會透過 push message 通知訂閱的人，若這邊 500 則免費訊息用完的話就建議使用者在開新的 🤣

肌肉仔更新啦 - NiJia Lin

最後則是我前一陣子分享過的健身記錄機器人-肌肉仔，引入了最新更新的 flex message 站牌樣板，讓健身者在訓練的每筆紀錄變得更漂亮，讓健身者可以像是公車一樣一步一步的往下一站走！

肌肉仔還是會持續更新，有興趣的朋友別忘了幫小弟按個星星 ⭐️ 鼓勵我繼續前進 😃

結論

臺北臺中連著兩天舉辦真的是很累，但是看到大家踴躍的互動讓我覺得不虛此行，接下來還需要大家的熱情支持，讓我們繼續辦下去 🚀

Chatbot Taiwan 在台北、台中皆有一個月一次的定期聚會，致力於提供並討論聊天機器人的相關應用，每回小聚將安排講者主題分享、新知討論，環繞 Chatbot 與 AI，及大家共同關心的話題。歡迎大家踴躍分享、自由與會眾交流，同時也期望大家可以在分享中得到收獲。

歡迎各位報名、推薦講者以及閃電秀，介紹自己開發的 chatbot 並分享 chatbot 相關的議題，若有相關需要合作歡迎與我聯繫 https://m.me/linnijia。

發表於 更新於 分類於

詳細文件參考

docker 抓 mysql 最新的版本

1
docker pull mysql:tag

若只是要建立普通容器用以下指令:

1
docker run -d -p 3306:3306 -e MYSQL_USER="myname" -e MYSQL_PASSWORD="mypasswd" -e MYSQL_ROOT_PASSWORD="root_pwd" --name mysqltest1 mysql:5.7 --character-set-server=utf8 --collation-server=utf8_general_ci

由於會有備份的問題，所以要先建立資料夾們

1
2
3
4
mkdir ~/docker
mkdir ~/docker/mysql
mkdir ~/docker/mysql/conf
mkdir ~/docker/mysql/data

新增 my.cnf 配置文件

vim ~/docker/mysql/conf/my.cnf

my.cnf 加入如下内容：

1
2
3
4
5
6
7
8
[mysqld]
  user=mysql
  character-set-server=utf8
  default_authentication_plugin=mysql_native_password
[client]
  default-character-set=utf8
[mysql]
  default-character-set=utf8

將 /docker 這個資料夾映射到容器內的 /etcmysql/my.cnf

1
docker run -d -p 3306:3306 --privileged=true -v ~/docker/mysql/conf/my.cnf:/etc/mysql/my.cnf -v ~/docker/mysql/data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=123456 --name mysqltest2 mysql:5.7
  • –privileged=true：容器内的 root 永有真正 root 权限，否則容器内 root 只是外部普通用戶權限
  • -v ~/docker/mysql/conf/my.cnf:/etc/my.cnf：映射 config 資料夾
  • -v ~/docker/mysql/data:/var/lib/mysql：映射 data 資料夾 (table 都在這)

如此一來就可以儲存 /docker 這個資料夾達到備份的功能

PHPMyadmin

將 myadmin 連接 mysql 的容器指令:

1
docker run --name myadmin -d --link mysql_db_server:db -p 9100:80 phpmyadmin/phpmyadmin

mysql_db_server = mysql container id

在瀏覽器上輸入 localhost:9100 就可以看到 phpmyadmin 囉！

Docker 查詢容器 IP

1
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' container_name_or_id

發表於 更新於 分類於

Cold start

其實個家園端平台多少都會有這問題，畢竟大家都是靠流量賺錢，自然會需要個方法限制使用者，不然免費爽爽用他們也不是做慈善的 🤣，像我最常用的 Heroku，只要 30 分鐘沒有使用他就會進入睡眠時間(參考)，叫醒的時間需要 10~15 秒，不過對於我這個免費宅來說測試夠用了 🤣

AWS以我實際測試起來大概 2 秒左右，回應時間看起來不會太差，其實第一天就有提到這部分，需要的話可以參考。

若是需要它隨時都在都活著的話就要搭配 warm-up，抑或是搭配 crontab 去設定特定時間執行 warm-up。

Function as a Service

在快速成長的前、中期是很適合這個服務的， 畢竟開發者只要將 serverless.yml 基本設定完之後就可以先好好開發，等到中期之後把設定檔稍微整理一下又是一尾活龍了，且平台大多都擁有 auto-scaling 的功能，在服務快扛不住流量的時候只要錢拿出來平台就幫你解決。

只是說當流量越來越大之後相對錢也會越付越多，或許當流量 > 10K 之後代表你的服務應該也有不少人使用了，自己架主機應該不會是什麼難事(?)

幫忙推廣一下 Backend 大大的 高流量心得雜談

在 FaaS 架構下其實很適合 Chatbot 的服務，以概念來說實作時只需要一個路由**(Function)**即個完成，不需要額外太多的資源去處理 web server 的問題，像是這個系列的只要透過 serverless + WSGI 就可以馬上就可以進行本地測試，部署只要下 sls deploy，實在是超級快又輕鬆，不用像以前一樣還要去處理 Nginx 等等相關的問題 😁。

且 AWS、Google 在使用 python 跟 nodejs 上支援度很高，也不用怕找不到資源使用。

使用 Node JS 的朋友可以參考 C.T Lin 大大的文章，他們家的 bottender 超猛的！

Log

在 Log 這部分我覺得 AWS 有點不太好的地方就是他們的 Cloud Watch 應該是獨立服務，當我的 Lambda 輸出紀錄時大概要過 10 秒才會印出來，不像以前自己架主機時只要進 server 就可以馬上切到目錄看紀錄抓蟲，在使用這雲端服務可能在抓蟲有一半的時間都在等 log 出來，有時候急的時候還真的會被氣死 😭。

SNS

像是我前一陣子發的一篇文章，SNS 被觸發事件之後回來的東西是舊的，那時候看到錯誤訊息真的是心很涼，就得用一個 Lambda 排程一直去抓 DB 的 updated_at 欄位有沒有變更時間而去更新狀態，這樣情況就會多浪費一個 Function 去處理這樣的事件，不得不說專門來支援 AWS 服務的 boto3 套件(python)在某些時候做的事不是那麼完善，得使用旁門做到的方法去完成這件事，讓整個開發體驗不是那麼好，若他們可以把一些 error handle 弄更好那就完美了。

結論

其實還有好多服務沒有玩到

但其實使用 AWS 來實作 Serverless 的服務也是這一陣子加入新公司所學到的新技能，過程中總是會用舊的開發思維去想，但常常都因為這樣落坑 😓，但也因此讓我更了解像 AWS 這類的雲服務他們是如何開發每個服務並如何串接，同時也研究了 Serverless 相關的 plugins，看他們是如何支援雲平台讓開發者在開發時可以更像平常時在開發 web，也因為這樣我去貢獻了 example 到了 Serverless 的範例專案上面(參考)，慶祝完成人生第一場鐵三十，跟自己的競賽也告一段落，發現趕著寫文章品質真的會差很多，看來是時候該整理一下，謝謝您的收看 <(_ _)>

發表於 更新於 分類於

  • Imagemap

    • 這邊以微股力為範例，這隻機器人會再回應的時候輸出一張圖片讓使用者看到股票的曲線圖，然後圖片下方做三個類似按鈕的圖片在上面，再藉由設定觸發訊息在座標上，當使用者按到的時候就很像再按按鈕，更多使用方法或是 UX 上的問題可以參考 UX 三刀流。

  • Richmenu

    • Richmenu 等於把 imagemap 活生生的塞在下面，讓使用者再進聊天室時就能馬上看到圖片並按下對應的區塊而不用再輸入指令把 Imagemap 叫出來，如此就少了個步驟了，並讓開發者可以有更多的發揮空間呢！

  • 設計工具

    • Bot designer
      這個工具是桌面版，可以直接抓下來在本地端直接設計，

    • FLEX MESSAGE SIMULATOR [β]
      它有提供線上工具讓大家可以在線上直接測試樣板或是直接刻自己想要的樣板。
      • 使用心得：因為寫 Rails 基本上就是在寫全端了，難免會碰到 CSS，身為一個後端工程師排版，一定要用 flex 這個超級毒品(\吸起來/)，接著過了一段時間後接觸到 LINE bot，且 flex message 也是基於 Flexbox 的規格去實作的，所以很多排版上觀念都很像，也就不太會有障礙了 😁。
        且在排版上還有表格告知你什麼 component 要在什麼區塊內才能用，多佛心啊～

  • API 文件

    • 在最近幾個月的時候 LINE 的文件有改版，讓某些 API 可以在線上就能測了，看起來是滿讚的，若在逛文件時碰巧想測試這些功能的話可以直接把相關參數放進去，在某些時候也是滿方便的。

  • LIFF (LINE Front-end Framework)

    • 個人覺得他讓 Bot 的發揮功力又更上一層樓了，以前很多開發者都會覺得在與機器人對談中會有很多東西是不好做的，像是購物車的流程，若使用者在流程中按了上面的按鈕的話可能會發生無法預期的錯誤，且得用其他的服務去儲存操作狀態，在開發上就很麻煩，那 LIFF 就讓這個流程可以簡單許多，且能透過 SDK 在網頁上取得使用者的資訊，讓網站再被使用的同時還可以確認身份。

  • 推播 500 則

    • 在今年 OAuth 2.0 釋出當中推播則數也跟改動了，改成 500 則後其實看到不少的使用者在跳腳怎麼改成這樣，或是另類的變貴收費，只能說 LINE 也是要找方法收點費用呀，不然很多功能爽爽用他們也沒有地方去收費，這部分因為我也是少用，推播功能就都交給 LINE Notify 嚕！

  • 客服與機器人的切換

    • 參考 C.T Lin 大大的文章 Day10，簡單來說 Messager 可以在機器人處理不來的時候將訊息轉丟給設定的那位管理員，讓他來回覆訊息，但 LINE 在機器人上只能透過網頁去切換機器人狀態，抑或是自己設計流程讓機器人在無法處理才通知管理員，這樣的話管理員很容易錯過黃金的第一時間，可能也會因此造成使用者的不便。

  • 個人的 mur mur 🤣

    • 文件實在是太瀑布式了，雖然現在都懂的如何搜尋到相對應的功能，但若一般想開發的使用者在看到這個文件時瘋狂往下滑，結果發現還沒有滑到或是滑過頭，倒是找資料時氣得要死 😓，所以若是文件能夠分個頁籤什麼就更好了～

結論

當然整體來說還是很喜歡使用 LINE 這個平台(絕對不是因為熊大 🐻)，東西也不會像一開始在開發時什麼都找不太到，並且功能一直 release，讓服務可以透過不同的整合方法去達成目標，接下來 LINE 應該還會再繼續釋出不同的東西，就請大家拭目以待，或者…來參加 chatbot 小聚直接問問 LINE 的傳教士如何呢 😁

發表於 更新於 分類於

前言

在之前的文章都有將 Notify、LINE Login所需要的靜態頁面放在 S3 上面，讓其他使用者去點，雖然把前端放在程式裡面用 render template 比較好，可是在求快的情況下我把靜態頁面寫完就扔上去了(被拖走)，其實也可以透過這個方法去幫忙轉址，不過接下來我會用我的臉書做個範例提供參考～

實作

照著之前的範例來建立一個名為 facebook.nijialin.com 來做 S3 轉址的範例

建立完之後因為我們需要把網址公開給其他使用者點選，在第三個分頁中先把第一個選項的 Block all public access 更換成 off 狀態

到第二個按鈕選項選擇 Public access，暴力一點把所有選項都打開 🤣

前面都已經把權限開完，選擇Static Website hosting這個選項，這個是 S3 提供來讓他有另一種功能，不過我是覺得這功能在這邊有點奇怪 XD

接著就來到 Route 53，點選左欄的 Hosted Zone

點選上面藍色的按鈕，右邊會出現輸入的地方讓你填

這邊我會輸入跟 S3 bucket 的名字一樣，然後 Alias 選擇 Yes，下面輸入框點下去會看到自己剛剛輸入的 S3 website endpoints

建立完之後就可以在瀏覽器上輸入網址，他就會導去你預設的網站囉！向我這邊就是拿我的 facebook 來做示範。

結論

我透過這個方法幫我把 medium 的部落格網址重新導向，因為我想之後若是有獨立建立部落格的話網址會是一樣的，當有點粉絲的話至少他們認得的網址會是一樣的 😁。

參考

Route 53+靜態網址

發表於 更新於 分類於

前言

不管是建立虛擬機(EC2)，又或是像我們建立 Serverless 的服務(Lambda)，總會挑選離自己家近的節點(東京)，又或者可能因為價錢的關係選擇相對便宜的地點，但不管機器在哪，對於在台灣的我們來說都是一樣跨海啊！但好險台灣擁有 CloudFront 的節點，透過快取讓使用者可以更快的取得服務器上的資源，可能第一次都會比較慢，但只要讓 CloudFront 看過一次就會幫忙快取起來，下次使用者在用的時候就不會那麼慢囉！

建立 CDN

首先我們先進去 CloudFront 的頁面，按下左欄的Distribution後並 Create的藍色按鈕

因為我們是做 Web API 相關的，這邊當然就是選 Web 囉！

到了這邊，AWS 很有心的在這些輸入框大多都有下拉式選單，這邊就選建立完的那個專案名稱

選完之後下面三個就照著這樣點選，Comment 會幫你自動填入

CNAMEs 的部分這邊我填入我在 serverless.yml裡 create_domain 所設定的 line.nijia.lin 字串，SSL 就選擇上一篇所建立的 Certificate

建立完成之後就會看到他 In progress，CloudFront 就開始撒點告訴其他節點有建立這個名為 line.nijia.lin，有看到他的時候記得幫他做個 Cache

等個大概 15 分鐘後他就部署完成啦～

點進來可以確認自己剛剛設定的資訊對不對，若有設定錯誤在按 Edit 來修正

結論

現在每個服務都很流行 CDN，若有在寫前端的朋友常常就會用到 jQuery、Bootstrap、Vue 等等可以再標頭檔就引入的 CDN 路徑，CDN 不僅加速我們平常在抓伺服器資料的速度，也便利了我們有時候需要寫一些簡單的靜態頁面時可以透過抓取 CDN 路徑來快速取得需要的資源，但是像是 AWS 他們都是收取流量費，用得很爽時別忘了看一下自己的帳單是不是在哀嚎 🤣

發表於 更新於 分類於

簡介

繼上一篇 warm-up 機制之後來了解一下如何使用 AWS 的 CDN 服務 - cloudfont，CDN 顧名思義就是要讓使用者可以到最接近的主機上去拉到對應的資料，透過撒點的方式讓主機去挑選離自己近的服務據點，藉此加速服務。

像我之前部署在 ohio，想想光網路的時間 + Cold start 的時間就已經去了一大半，即便我們有熱開機，服務沒有 Timeout 我該慶幸了，既然如此就不得不認識一下 CDN 服務，而 AWS 的 CDN 服務就是 cloudfont 啦！

只是說原本的 domain 已經有 SSL 了，但是代理沒有這個東西，所以我們要 ban 出一個 Certificate，那在在建立 cloudfont 以前需要先到 Certificate Manager，接著會用圖片帶大家一步一步做

開始之前

我已經有先在 Route53 註冊了一個 nijialin.com 的 domain，.com大概 10 美金左右，若是有在其他地方註冊域名的話要找一下相關文章把它導進 Route53 哦！

註冊 Certificate

  • 先來到 Certificate Manager 頁面，按下左下角的這個

  • 接著就直接按右下角啦，但是要確定是不是 public

  • 這裡輸入你在 route53 註冊的 domain，這邊我是輸入 *.nijialin.com

  • 到第四部之後就會看到申請的 SSL Pending

  • 最後回首頁之後就會看到 SSL 簽證正在送簽中

最後就等他完成嚕！將將

接著我們到 API Gateway 找到左邊的 Custom Domain Name，我們要來建立屬於這個 API 的 Domain 了

按下藍色的按鈕之後，輸入Domain name以及選擇剛剛註冊的 Certificate 後按下 Save

他就會開始初始化剛剛的設定，這邊大概需要等 15 分鐘左右

在此同時我們就去新增專案裡的套件 Domain-Manager

1
npm install serverless-domain-manager --save-dev

並且在plugin下加入套件

1
2
plugins:
  - serverless-domain-manager

在custom底下加入

1
2
3
4
5
6
7
custom:
  domainName:
    default:
      domainName: line.nijialin.com
      certificateName: "*.nijialin.com"
      createRoute53Record: true
      endpointType: edge

等待前面初始化成功之後部署這個專案sls deploy之後就會看到剛剛註冊的域名啟動囉！

結論

在建立 Certificate 那邊倒沒什麼問題，畢竟需要一個 SSL，只是到了建立 domain 這邊遇到了很怪的問題，一般來說使用 serverless 框架來跑的話只要照的文件裡說的 serverless create_domain就會幫忙註冊，而且可以依照自己開發環境去自動設定，在公司的專案中這樣使用是沒問題的，在是在寫這篇文章時卻只能使用以上的方法來替代使用，雖然結果是一樣的，但是用起來實在是很不符合邏輯，google 也沒找到類似的問題，或許這個問題還要多實測幾次才夠…😭

發表於 更新於 分類於

前言

人品爆發的下半年有幸被選為 LINE API Expert，謝謝過程中給我指點、意見還有每位來參加每個 chatbot TW 活動的朋友，你們支持讓我可以更努力去辦各種活動，社團裡歡迎大家踴躍提點子討論，抑或是來參加小聚跟大家互相交流，台北台中都有小聚哦！若有不清楚的地方歡迎詢問😃
Chatbot Developers Taiwan：https://www.facebook.com/groups/chatbot.tw

迎新

在 welcome party 中身為 Rookie of LINE API Expert 一定是要被每一位大神輪流 “熱情關照” 一波🤣，想想之前在開發時還在看卡米狗 卡卡米 的 IT 30 鐵人賽、寫 golang 看著 Evan Lin 的部落格、看保哥 Will Huang 在議程中各種秀高速開發技能 … 等等的，沒有到偶像們就直接坐在旁邊，看著看著我就快不行了😝。跟大神們聊完覺得自己做的事還只是冰山一角，看著大家都那麼有影響力下還是這麼努力向前進，做為菜鳥的我當然不能就這樣滿足！繼續抱著大神們的腿前進。(喂！放開自己走啊！)

成為 LAE 後的第一場開發者日

緊接著第一場大型活動就是參加 LINE 的年度大會 — LINE Developer Day，過往都只能看著前輩們分享文章在電腦前面乾過癮，看著大家可以在國際間跟各路的開發者交流，這一直是我很羨慕的事情之一。但是！現在終於有機會以 LAE 的身分出發啦(媽我在這)！聽說去年有 60 場各種主題的座談會，而今年 LINE 主要會以推廣 人工智慧 為主軸，並且搭配其他在 LINE 中重要的技術形成了這次的 developer day，也開始漸漸露出在新聞版面了，看起來想拓展的企圖心也越來越強了🚀
以下是其他 LAE 以及社群創始人 Clement Tang 在 2018 年參加 LINE Dev Day 的文章分享

2019 的 Dev Day 資訊出來囉，
活動時間： 2019/11/20、21, 10:00~21:00 (日本時間)
活動地點：東京台場日航大酒店Grand Nikko Tokyo Daiba （2–6–1 Daiba, Minato-ku, Tokyo）
活動入場費用：免費
參加方式：繳交報名表、預先報名

活動則環繞在開發工程(Engineering)以及產品開發(Production)上

「LINE DEVELOPER DAY」開發者大會將於11/20、21東京登場 | T客邦

屆時我會分享文章出來，還請各位多多關注😀

結論

說了這麼多，還不去申請一波 LINE API Expert？讓自己的努力有個機會被 LINE 看見：
LINE developers community | Expert Request
或是你還不清楚要怎麼開始第一步，來小聚跟我們聊聊吧，社群的每位大大都很熱心跟各位分享，千萬別錯過這些機會哦！
Chatb13ts meetup 聊天機器人小聚 #13 @ 台北商業大學
▎活動型態 Chatbots meetup 社群台北、台中皆有一個月一次的定期聚會，致力於提供並討論聊天機器人的相關應用，每回小聚將安排講者主題分享、新知討論，環繞 Chatbot。