大家好,我是 NiJia
以下是我最近參加 IT 邦幫忙 30 天鐵人賽的文章列表,主要是紀錄從我進入新公司後學到的Serverless
,並透過結合 LINE API
實現在 AWS
上,歡迎大家參考取用 😃
大家好,我是 NiJia
以下是我最近參加 IT 邦幫忙 30 天鐵人賽的文章列表,主要是紀錄從我進入新公司後學到的Serverless
,並透過結合 LINE API
實現在 AWS
上,歡迎大家參考取用 😃
詳細文件參考
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 | mkdir ~/docker |
新增 my.cnf 配置文件
vim ~/docker/mysql/conf/my.cnf
my.cnf
加入如下内容:
1 | [mysqld] |
將 /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 |
如此一來就可以儲存 /docker 這個資料夾達到備份的功能
將 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 囉!
1 | docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' container_name_or_id |
其實個家園端平台多少都會有這問題,畢竟大家都是靠流量賺錢,自然會需要個方法限制使用者,不然免費爽爽用他們也不是做慈善的 🤣,像我最常用的 Heroku
,只要 30 分鐘沒有使用他就會進入睡眠時間(參考),叫醒的時間需要 10~15 秒,不過對於我這個免費宅來說測試夠用了 🤣
AWS
以我實際測試起來大概 2 秒左右,回應時間看起來不會太差,其實第一天就有提到這部分,需要的話可以參考。
若是需要它隨時都在都活著的話就要搭配 warm-up,抑或是搭配 crontab 去設定特定時間執行 warm-up。
在快速成長的前、中期是很適合這個服務的, 畢竟開發者只要將 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 這部分我覺得 AWS 有點不太好的地方就是他們的 Cloud Watch 應該是獨立服務,當我的 Lambda 輸出紀錄時大概要過 10 秒才會印出來,不像以前自己架主機時只要進 server 就可以馬上切到目錄看紀錄抓蟲,在使用這雲端服務可能在抓蟲有一半的時間都在等 log 出來,有時候急的時候還真的會被氣死 😭。
像是我前一陣子發的一篇文章,SNS 被觸發事件之後回來的東西是舊的,那時候看到錯誤訊息真的是心很涼,就得用一個 Lambda 排程一直去抓 DB 的 updated_at 欄位有沒有變更時間而去更新狀態,這樣情況就會多浪費一個 Function 去處理這樣的事件,不得不說專門來支援 AWS 服務的 boto3 套件(python)在某些時候做的事不是那麼完善,得使用旁門做到的方法去完成這件事,讓整個開發體驗不是那麼好,若他們可以把一些 error handle 弄更好那就完美了。
其實還有好多服務沒有玩到
但其實使用 AWS 來實作 Serverless 的服務也是這一陣子加入新公司所學到的新技能,過程中總是會用舊的開發思維去想,但常常都因為這樣落坑 😓,但也因此讓我更了解像 AWS 這類的雲服務他們是如何開發每個服務並如何串接,同時也研究了 Serverless 相關的 plugins,看他們是如何支援雲平台讓開發者在開發時可以更像平常時在開發 web,也因為這樣我去貢獻了 example 到了 Serverless 的範例專案上面(參考),慶祝完成人生第一場鐵三十,跟自己的競賽也告一段落,發現趕著寫文章品質真的會差很多,看來是時候該整理一下,謝謝您的收看 <(_ _)>
Imagemap
Richmenu
設計工具
API 文件
LIFF (LINE Front-end Framework)
推播 500 則
LINE Notify
嚕!客服與機器人的切換
個人的 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 的部落格網址重新導向,因為我想之後若是有獨立建立部落格的話網址會是一樣的,當有點粉絲的話至少他們認得的網址會是一樣的 😁。
不管是建立虛擬機(EC2),又或是像我們建立 Serverless 的服務(Lambda),總會挑選離自己家近的節點(東京),又或者可能因為價錢的關係選擇相對便宜的地點,但不管機器在哪,對於在台灣的我們來說都是一樣跨海啊!但好險台灣擁有 CloudFront 的節點,透過快取讓使用者可以更快的取得服務器上的資源,可能第一次都會比較慢,但只要讓 CloudFront 看過一次就會幫忙快取起來,下次使用者在用的時候就不會那麼慢囉!
首先我們先進去 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 哦!
最後就等他完成嚕!將將
接著我們到 API Gateway 找到左邊的 Custom Domain Name
,我們要來建立屬於這個 API 的 Domain 了
按下藍色的按鈕之後,輸入Domain name
以及選擇剛剛註冊的 Certificate 後按下 Save
他就會開始初始化剛剛的設定,這邊大概需要等 15 分鐘左右
在此同時我們就去新增專案裡的套件 Domain-Manager
1 | npm install serverless-domain-manager --save-dev |
並且在plugin
下加入套件
1 | plugins: |
在custom
底下加入
1 | custom: |
等待前面初始化成功之後部署這個專案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 在議程中各種秀高速開發技能 … 等等的,沒有到偶像們就直接坐在旁邊,看著看著我就快不行了😝。跟大神們聊完覺得自己做的事還只是冰山一角,看著大家都那麼有影響力下還是這麼努力向前進,做為菜鳥的我當然不能就這樣滿足!繼續抱著大神們的腿前進。(喂!放開自己走啊!)
緊接著第一場大型活動就是參加 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。
本篇會介紹 npm 套件庫裡的 Serverless-plugin-warmup,裡面介紹了很多參數可以使用,以下會簡介如何引入它。
透過npm
來安裝套件
1 | npm install --save-dev serverless-plugin-warmup |
在serverless.yml
的plugin
加入套件
1 | plugins: |
在custom
加入warm up
的設定參數
1 | custom: |
.gitignore
加入以下兩個_warmup/
以及.requirements.zip
,他在部署前建立一個_warp
的資料夾並放一個 Lambda 來打已建立的 api 以及 Lambda 們,部署後會建立.requirements.zip
,所以這邊就加入這兩行來防止被 git 推上去。
或許會有疑問不是
cleanFolder
設定 true 就可以,這邊我自己實測時在部署會因為 Size 過大而無法上傳,把這參數設定掉他才會乖乖的上傳成功,但這部分有待驗證。
這邊我在lib/
下新增一個decorator.py
,加入以下的 code
1 | from functools import wraps |
主要功能是透過 python decorator 的特性讓我們在 function 之前用個前綴符號就可以引用它,很像 po 文在 tag 別人一樣 🤣
warm-up 建立的 Lambda 會固定對其他的 Lambda 打serverless-plugin-warmup
的字串,這邊就寫個判斷式判斷掉後直接 return
你以為這樣就結束了?還有 IAM role 的問題呢,詳細問題已不可考,想試看看的可以把 IAM 拔掉再部署一次,問題就會出現了,以下為設定檔:
1 | iamRoleStatements: |
如果你的目錄結構跟我一樣,或是跟到今天的實作,加入以下的 code,這邊主要是告訴你的 Lambda 要在每次的 warm-up 字串來的時候呼叫這個 decorator 來幫忙處理一下
1 | from lib.decorator import lambda_warm_up |
我的 Lambda 都加了,那原本的 flask 建立的 api 我要加在哪?
看看這個網址,serverless-wsgi 在實作的時候已經有考慮到這件事了,所以 api 這邊就不用管他,他自己會去把它處理掉!
Warm-up 的機制就是透過建立一個 Lambda 來打一個 flag 到其他 Lambda 來他們別進入睡眠模式,但總是會有人考慮費用的問題,可以參考下圖,若是你建立了一個簡單的服務然後上線了,AWS 給你了一百萬個請求的量,我覺得一個月的請求可以到 100 萬應該是服務有點規模的情況,一個月能到這個量相信你也有一定的能力養它 🤣,爾後每一百萬個請求才六塊台幣,可能比 GCP 還貴,但其實以我來說這樣已經很夠用,而且還扛得住
以下就為大家帶來簡單的實作以及如何去使用它。
在views/
下新增一個liff_test.html
並加入以下內容
1 | <html> |
以上參考來自董老師的部落格
詳細的 LIFF API 文件可以參考
接下來按著之前做過的一樣把這個檔案送到S3
裡,接著它的網址複製起來
接著來去之前建立機器人的開發者頁面裡按下最右邊的LIFF
按下去之後呢,再來按下add
跑出這個頁面後,Name
好辨認為主、Size
選擇滿版(Full)、Endpoint URL
就把剛剛複製起來的 S3 網址放進去後按Confirm
大概內容會長得像這樣
建立成功後往下滑會看到 LINE 給你一個屬於他們的網址,接著可以把它貼到你的機器人上(或者任何聊天室)
點下去之後就會看到來自 LIFF 的 Webview 囉!
接下來就可以開始玩裡面的功能了 🤣
LIFF 整合的功能讓開發者在 Bot 裡不好實現的功能透過 Webview 的方式讓使用者可以到頁面上做邏輯處理,透過兩種的結合讓整體的應用就有更多的變化,這邊若要給使用者個話就把 line://xxxoxx
製作成 flex message 或者乾脆傳給使用者,引導他點選,如此就能讓使用者到自己設計的頁面上了。
這邊額外補充一點,有看到程式碼裡面可以拉到Query string
嗎?事實上可以透過Query string
讓使用者帶些參數來做更多的判斷,像是卡米哥做的Kamiliff就是讓使用者在點選後判斷這個 LIFF 的 Size,在導去對應的路由去做處理,這樣子使用者在建立 LIFF 的時候就不用一個頁面弄一個,否則這樣在 dev 轉 prod 的時候應該會弄到很生氣 🤣。