雖然lambda本身的概念就是主打無伺服器+各自獨立運行的function,但有時又不免其然的需要共用代碼,像是api可能都需要做權限驗證。
會有這方面的研究是因為公司正好要將app跟web共用的api搬到api gateway去處理,但我馬上就想到會有code reuse的問題,怎麼樣用可維護的方式來處理,就會非常重要。
我們先來看幾種比較笨的解決方法:
缺點:當dependency更新時,難以找出到底有哪些fn需要更新版本
2. 共用的code存在s3,在lambda時讀取
缺點:讀取的時候延遲時間,而且可能需要做額外的處理,感覺髒髒的
3. 寫一隻lambda專門處理middleware
缺點:引入不必要的延遲,整個lambda變得耦合,增加危險性(網路問題),成本也會增加,打一隻api等於打了兩隻
而我選用的解法是利用lambda layer + middy套件方便將middleware邏輯跟商業邏輯做拆分。
aws會自動幫我們把layer的代碼載入到lambda中,能讓我們直接引入使用。
應用情境:共用code、共用dependency(ex: 每一隻api都需要用到middy套件)、自己寫runtime…
限制:每一個lambda最多只能有5個layer
費用:新增layer本身不計費,而要注意的是layer的代碼大小也會計入lambda的檔案大小
缺點:如果是直接用上傳code的方式,你會發現在console看不到那些載入的layer code有哪些
首先在你的IDE上開發需要給每隻lambda用到的code,這邊以nodejs為例,但語言應不受限,只不過要注意放code的檔案路徑會有所不同。
新增一個新的資料夾來放code,假設叫commonDependency,我們需要在commonDependency資料夾下新增nodejs資料夾來存放共用代碼。
aws會將nodejs資料夾的codey載入lambda,這邊我希望每一個lambda都使用lodash
npm i lodash
接著在commonDependency這一層,對所有檔案和目錄做壓縮。
zip -r /壓縮檔要存放的路徑 .
然後將這個壓縮檔上傳到AWS layer
新增layer
新增完成之後,我們只需要複製Version ARN給lambda使用就好,這邊很讚的是我們可以做版本控制,也可以很方便的知道每一個版本有在使用的lambda有哪些。
將ARN複製下來後到你想賦予的lambda function,滑到最下面就會看到可以新增layer的地方了:
選擇用ARN的方式複製貼上,點選Verify會跳出你要使用的layer資訊,按下Add就大功告成!
之後要用other version的話只要簡單點選edit就可選版號了:
對於共用的模組(以nodejs而言,為node_module),我們只需要簡單在lambda中使用:
const lodash = require('lodash');
對於我們客製化寫的function則需要指名檔案路徑:
const lodash = require('/opt/nodejs/要用的js檔');
註:他不會將lambda layer的檔案show在lambda console中,如果用cloud9似乎就沒這個問題。
很簡單的對lambda function按下test,看看你有沒有成功引入你要的東西,就可以了。