昨今のサーバレス、マイクロサーバという流行りに乗っかってやってみました
システム構成
すごく単純ですが、上記のような構成です。
API GatewayでBacklog Webhook通知先URL Resource(POST)を作成、Integration TypeにAWS Lambda Functionをして、Node.jsでSlackへBacklogからのjsonデータを整形してPOSTしています。
一応、複数Backlog/複数Slackチャンネルを設定できるように、以下の様な設定ファイルをS3に持たせることで汎用的にしています。
また、どのBacklogプロジェクトの通知かはBacklog WebhookのPUSHデータ内にある project.id
を上記設定ファイルのS3オブジェクトキー(ファイル名)にすることで判定しています。
(project.id=100の例)
s3://{bucket-name}/100.conf
{
"space_name": "xxxxx",
"channel_name": "yyyyy"
}
SlackへのPOSTは(#general
など消されないであろう)特定チャンネルにIntegration(Incomming webhooks)を登録し、そのWebhook URL宛にチャンネル指定でPOSTしています。
※ただし、Slack Integration(Incomming Webhooks URL)はAWS Lambdaにハードコーディングしています。(でも書きながら今気づいたのですが、これもS3に設定情報を置けばいいですね。。)
それぞれのハマりどころなど
少しググるとたくさん情報が出てくるので細かい設定例などはそちらにお任せするとして、Tips的なことを簡単にまとめます。
Backlog Webhook
http://www.backlog.jp/help/adminsguide/webhook-setting/userguide2493.html
http://developer.nulab-inc.com/ja/docs/backlog/api/2/get-activities
上記2つを見ればおおよそ問題ないかと思います。
ただし、ハマりどころとしては以下ですね。
- 2015/09/15までBacklog Webhookの通知をAmazon API Gatewayで受けることができませんでした。
- これは他の方も記事にされてましたが、自分もBacklogチームにお問い合わせを投げたところ、すごく早いタイミングで改善いただきました!
- Backlogの各種パラメータが0始まりだったり、1始まりだったりする
- Webhook登録画面でのテスト実行は
保存
しなくてもフォームの設定値が反映される - スペース名を特定できる情報が飛んでこない
- 前述したように
project.id
をS3オブジェクトキーに含めた - ただし、この
project.id
がすべてのBacklogプロジェクトでユニークなのかは不明。
- 前述したように
- Webhook登録画面でのテスト実行した場合、
project.id=100
に固定で、設定をしているBacklogプロジェクトのそれとは異なる。- 今回S3からの設定ファイル読み込みの際にこのBacklog
project.id
を利用していたので、実質このテスト実行はデバッグに使えませんでした。。
- 今回S3からの設定ファイル読み込みの際にこのBacklog
Amazon API Gateway
これもググればたくさん情報が出てきますね。
http://dev.classmethod.jp/cloud/aws/api-gateway/
http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-tech-2015-amazon-api-gateway
とりあえず困ったらクラスメソッドさんのDevelopers.IOに頼ってます。
あと2個めのAWS Black BeltではREST APIの基本から学べてすごく勉強になりました。
ハマりどころとしては以下でした。
- Amazon API Gatewayと同一のリージョンにAWS Lambda Functionを作成しないと、Functionが発火しない
- LambdaはすでにTokyo Regionにありますが、API Gatewayはまだありません。これに2時間ほど費やしてしまいました。。。
- デバッグがしづらいのでまずはシンプルなAWS Lambda Function(eventをconsole.logするだけ、など)でうまくResource設定ができているか確認したほうがいい
- うまくいかない時はだいたいIAMを疑うといいかもしれません。
AWS Lambda
これは去年2014年のre:Inventで衝撃的な発表があって、すでに1年くらい経ってるので更に情報やサンプルがたくさんあるのであまり困りませんね。
でも未だに困るとしたらこの辺りでしょうか。
- とにかくデバッグがしづらい。。
- もうこれはこまめに
console.log
を仕込むしかないですかね。誰か教えてください。
- もうこれはこまめに
- CloudWatchにログが出ない。
- これはIAMを疑ってください。log系のパーミッションがないといけません。
- とりあえず最初は自動生成されるIAMに任せるのが無難かもしれません。
- AWS Lambdaへのデプロイがめんどくさい。
- これは他にもツールがあるみたいですが、自分はzipアーカイブして、aws cliでLambda Functionをアップデートする簡単なshellscriptを書いて使っています。