Category: docker

Helper module to generate JWT for LINE OAuth2 v2.1

LINE Messaging API 最近一個比較重大的變更是 access token 新版的發放方式(v2.1),同時也配合 OAuth2 。比較不同的點是它是用 JSON Web Token (JWT) 去取 access token,這樣的好處是如果今天 Provider 本身(也就是付錢的人)請開發商開發 bot ,他並不需要把 channel secret/access token 都給開發商(這通常也暗示你要把開發人員加到 bot admin 去,當然也可以不這麼做,就是麻煩了點)。

改用 JWT 的好處在於開發商只需要知道 channel ID 以及 Provider 幫他申請的一組 Assertion Signing Key (RSA 加密的),對 Provider 來說資訊的保護層級就提高了,終止合作只要把這組 Assertion Signing Key 砍掉就好,不必重新申請 channel access token 且/或 channel secret。

但相反地,開發商沒有 long-lived channel access token,新版的 OAuth2 認證方式使用 JWT 產生的 access token 最長只有 30 天的限期,期限到了之前要再生,某種程度造成程式開發上的困難(安全與方便通常不是站在同一邊的),原本的邏輯上要多加處理 token expiry 。

對於 API 變動來說,可以分為兩部份來看。其一,是 JWT 的取得;其二,是 access token 的取得。前者並沒有直接呼叫到 LINE Messaging API server ,所以在開發 SDK 的時候,可以先著重在已有 JWT 的情況下與 server 端做申請/列出/撤銷 access token 的行為。這部份也提出了 pull request (PR) 在等待官方團隊的審核。

Web interface for generating JWT

而 JWT 的生成就比較麻煩了,在看官網的介紹時發現做 JWT 沒有想像中那麼容易。(中間省略一段心路歷程)最後就是決定自己開發工具來幫助生成 JWT 。

clsung/line-oauth2-helper 名字有 “OAuth2” ,實則沒有關係,是用來生 JWT 的,但因為這生出來的 JWT 也只能讓 LINE OAuth2 v2.1+ 使用,所以才取這個名子。

執行的方式看 README 即可,若是一般 go 開發者使用,那 go get github.com/clsung/line-oauth2-helper/cmd/line_jwt 最快,若是系統沒有 go 的,可以考慮用 docker 的版本(若是都沒有的,請按上一頁離開):docker pull clsung/line-oauth2-helper:stable

用 line_jwt 執行的話,預設生出來的 JWT 需要在 30 分鐘內去 access LINE server ,而生出來的 access token 會在 30 天後過期,要細部調整的則建議就使用 docker / web 的版本。若是要接在程式碼當 API 呼叫的,也可以參考 cmd/ 下的程式自行開發。

2019 LINE Developer Day – Hadoop Cluster Federation With 2k+ Nodes

上週以 LINE API Expert 的身份參加了今年於東京台場舉辦的 LINE Developer Day 活動。其中有一場硬底子的分享我覺得蠻值得一提的,簡單一句就是用 Hadoop 在上層做 Cluster Federation ,總共管理了超過二千個節點。

2019 DevDay 100+PB Scale Unified Hadoop Cluster Federation With 2k+ Nodes
100+PB Scale Unified Hadoop Cluster Federation With 2k+ Nodes

之所以講硬底子,因為 LINE 工程師在進行這個擴展/遷移節點的過程中,遇到的問題有送 upstream patch 回原本的專案 repo (簡單列一下投影片有提到的,照看起來應該還有不少):

各式的服務,各式的資料

幾年前還「只不過」是一個即時通訊軟體的 LINE 。時至今日,LINE 本身的服務量已經是愈來愈大了,開始嘗試提供各式各樣的服務,想當然而所有的資料格式欄位(以 SQL 的角度來看)各有不同。

2k 個資料節點,存了超過 100PB 的資料

看起來很棒,實際上對於 Data Platform 部門的工程師則不然,如果羅馬不是一天造成的,這些服務與資料並不是同時打造好提供給大家使用的,這是日積月累的使用記錄,加上服務系統迭代更新後,產生的資料。可以參考去年的演講,那時候的資料看起來還沒有這次的一半多。所以理想與現實的差距,造就了 10 座以上的 HDFS Clusters ,在系統維護與軟體更新上都拉大了難度與時間。各個 Cluster 的版本不一,能提供的 API 以及工具也無法統一。最後工程師們決定整頓一下,一統公司內的 Hadoop 江湖(想想一次可以送 job 在 2k+ node 上跑,想到就…..)

目標: 「一法度衡石丈尺,車同軌書同文字。」

當然改變不是一蹴而就,當年(應該是每年)留下來技術債也是要還的(OS: 砍掉重練就不用了…),工程師們決定邊開飛機邊改引擎 (…)。所以定了幾個 Criteria ,包括 Minimum Downtime、Incremental Migration 以及最重要的 High Security Level/Minimum Risk 。

講者簡介了幾種他們一開始規劃的想法,比如建一個新的,然後把所有的資料往裡面搬。這個當然是一個理想但不實際的方法,除非你不在意 downtime 、不在意相容性、不在意因此要多買一倍的儲存空間。另一個進階的想法則是把最大的 cluster 再擴大,然後把其他的 cluster 整合進去,這個遇到的問題是實務面的:最大的 cluster 沒有使用 Kerberos;有兩個非常大的 cluster 是有頻繁的用戶存取的;整合完, Hadoop 還是需要再更新。最後方法就採用了 HDFS Federation 架構來解決這個問題,基本上利用 HDFS Federation 可以有 multi-namespace 的特點,來支援後續的 data/service migration 。

Start small, Iterate fast.

但即使如此,在實作上還是運到了一些問題,有經驗的工程師聽到這裡大概也可以猜出來,各 cluster 原始的版本相容性會直接地影響到 merge 的成果,在這中間的過程中踩了不少雷,也因此提出 patch 增強(或修正) upstream 原有的功能。而這些的修改,都是在一邊更新 cluster 並作適度的 ETL 時,同時間也能讓原有的系統能夠持續運作,我想這點要對 Data Platform Dept. 的工程師及架構師們致敬。

最後放上一張我認為很能代表這場演講的投影片。

In short words, you do this and achieve that…. (amazing)

20190628 Chatbots Meetup 10

Evan Lin 邀請,6/28 參與演講了 Chatbots Meetup 10 的第二場,分享如何在 Google Cloud Run 上部署 LINE Bot 的經驗談。(好像拖稿很久了)

因為時間的關係,到天瓏書局時已經開場講到一半啦。就錯過了 Evan LinWrite Image Proxy Server for LINE Bot in Go。就座的時候,LINE API ExpertCaesar Chi 正在介紹 LINE@ 2.0 offline to online ,分享如何透過 LIFF + Push 機制,讓廠商能更有效率的省錢轉換,並且也跟會眾們分享在官方帳號 2.0 轉換後的衍生想法。

接著就是我上台分享 LINE Bot on Cloud Run: 使用 line/line-bot-sdk-go ,本來是想介紹 LINE Bot on GKE ,不過準備的時候發現會需要花點時間講 K8S ,就不好講 LINE Bot 開發了,所以選了一個我也沒用過的 Cloud Run 來試看看。詳情就直接看投影片吧,然後順便把 source code 整理一下放上來

最後閃電講,直接貼共筆的圖好了 :Q 我覺得 Evan Lin講解比較詳細,哈哈,偷懶一下。

Fix: Unit “containerd.service” has failed

When I upgraded yum packages, docker service had stopped. So I check the system status try to figure out the root cause….

After google ‘Subject: Unit “containerd.service” has failed’, we can find a related github issue. It seems to be a containerd problem than a docker problem, and here’s the fix: (the following shows the before and after)

[docker] Multi-stage builds

Consider the following scenario: you are going to rolling update your cluster, and it turns out your network bandwidth is limited for some reason and size of built docker image is not small enough. What’s worse, every instance of cluster will need to pull the docker image before start-up… Read More

CoreOS remove early-docker since 1284.0.0

It happens the docker daemon wasn’t alive when I login to the console.

After review the release document, it seems early-docker.target should be remove in all related target.

Ref: CoreOS Release 1284.0

2016-08-15

Developing with consul on Macbook

For development use, we need to have consul running on localhost. When using a Macbook (Air), we need to specify the “-bind=0.0.0.0” and “-client=0.0.0.0” in order to have programs (tests) access to the consul agent in the container:  Read More