Posted at

serverless-webpack で作る複数環境運用に耐えるserverless-node環境

More than 1 year has passed since last update.


課題

serverless で Circle CIの自動テスト・デプロイを考えていて、色々つらい経験があった。


  • Circle CI で自動テスト、自動デプロイしたい。

  • AWSのnodeは4.3。 Circle CI で4.3環境作ってもnpm i 周りで死ぬっぽい

  • APIKEYとかの管理どうするのよ問題

それまではsetting.jsとかを作ってローカルでignoreファイルに認証系入れていたけど、自動デプロイとなるとそうも行かない。

.env周りを作っても、.env依存のコードがLamdbaに上がった瞬間死ぬ

っていうかnodeのバージョン問題も辛い(手元のローカルは6.1)

ので、しっかりと理想の環境を構築することにしてみた。


理想の環境


  • バージョン問題は考えたくないのでserverless-webpackを導入

  • 開発時はsls webpack serveでテスト実行

  • デバッグ時にはローカルでmocha実行


  • mocha実行時にはwebpack じゃないコードでブレイクポイント貼ったりしたい

  • circle CIでは mocha 回してから自動でデプロイする

  • 認証情報の多元管理とかは辛い


構築

まずは serverless-webpack のexampleを参考に serverless-webpackの基本環境構築を行う。

https://github.com/elastic-coders/serverless-webpack/tree/master/examples/babel

認証情報の管理には .env を使用する。

とりあえず、setting.jsという名前で下記ファイルを設置

"use strict"

const loadenv = require("node-env-file");
loadenv("./.env")

module.exports = {
BACKLOG_APIKEY: process.env.BACKLOG_APIKEY,
....
};

ローカルには.gitignore指定で.envを作成し、認証情報系を記録していく。

BACKLOG_APIKEY=XXXXXXXXXXXX

....

handler.js などではこのsetting.jsを読み込む


handler.js

'use strict';

const {BACKLOG_APIKEY} = require("./setting")


ココでのポイントとして、必ずrequire("./setting")とすること。require("./setting.js")ではなく。

これ でひとまずmochaでは動くようになった。webpackでも多分動く?

circle CIのテストでも、env の設定を行えば動くが、このままではデプロイしても動かない。

(Lamdba上の環境変数設定が無いため)

Lamdaにデプロイしても動くように、webpack のDefinePlugin を利用して変数の埋め込みを行う。


webpack.config.js

"use strict"

const webpack = require("webpack")

module.exports = {
entry: './handler.js',
resolve:{
extensions: ["", ".webpack.js", ".js"]
},
...
plugins: [
new webpack.DefinePlugin({
env: JSON.stringify(require("./setting.js"))
})
]
};


更に下記内容でsetting.webpack.jsを追加


setting.webpack.js

module.exports = env;


resolve.extensions設定のお陰で、require("./setting")はWebpack 経由での読み込みのみ、setting.webpack.jsを参照するようになる。

setting.webpack.jsのenvはDefinePluginの効果で、setting.jsの中身をビルド時評価したものに置き換えられる。

実際にビルドされた.webpack/handler.jsをチェックしながら作業を進めると分かりやすかったりする。

従って、


  • sls webpack serve -> ビルド時評価のローカル環境環境変数参照

  • ローカルmocha実行時 -> テスト実行時評価のローカル環境変数参照

  • Circle CI mocha実行時 -> テスト実行時評価のCircleCI環境変数参照

  • Lamdba 稼働時 -> ビルド時評価のCircleCi環境変数参照

という形で環境変数を切り分けられる。

ローカルにおいて認証情報は.evnでignore運用が可能で、後はCircleCIにenv として登録してやれば良い。


あとがき

見落としてるだけかも知れないけど Lamdbaの環境変数簡単にいじれたらもっと楽なのに