読者です 読者をやめる 読者になる 読者になる

年中アイス

いろいろつらつら

Pull Requestを自動で作成する

rnssh, rnzooの新しいバージョンを出そうとするときに、別リポジトリになっているhomebrew-rnssh, homebrew-rnzooを編集してpushするのが、地味に面倒だと思うようになり、他の自動化でも使えるかなと考えて、Pull Requestの自動作成をやってみるようにしてみました。

こんな感じで動かします。今回はversionとsha256 hashを渡してます。

bash genpr.sh 0.0.0 ab01cd23ef45ab01cd23ef45ab01cd23ef45ab01cd23ef45

コードはgistに。rnzooのhomebrewのバージョンアップ対応。

手順としてはすごく単純で、以下を行っているだけ。

  • tmpディレクトリにcloneしてくる
  • sedで該当ファイルを編集する
  • git commitする
  • git pushする
  • hubコマンドでPull Requestを作成する

実際にできたプルリク(テストなのでクローズしてます)

sedで編集している部分は、方法は何でもよく、コードで書き換えられるなら、他の用途にも使えそうです。AWSのCodenizeに使ってるroadworker(Route53)やmiam(IAM)などの定義追加や変更は、この応用でPull Requestを生成できそうな雰囲気。

hubコマンドは、githubCLIで操作できるもので、githubのreleaseも作れるようなので、あとはそこをスクリプトにすれば、リリースが全部自動化できます。最後のhomebrewの反映だけプルリクをマージのワンクッション。*1

rnsshとrnzooのリリース自動化状況

参考

*1:今回の場合は別にPull Requestでなくてmasterにそのままpushするでもいいんですが、練習と個人的に最後の一押しは手でいいかなというところ。

golangのHTTPサーバを構成しているもの

golangのHTTPサーバは、少量のコードで動くものを作ることができます。内部的には、net/httpパッケージのServerHandlerで構成されます。

  • Serverは名前の通り、Serveするもので、HTTPをどのネットワークソースで提供するかを定義するものです。
  • Handlerは、HTTPリクエストを実際にどう処理するかを抽象化したinterfaceで、ServeHTTP(w http.ResponseWriter req *http.Request)を提供しています。

しかし、これらは簡易に使う場合、見えなくなっています。どうしてそうなっているかを理解することで、幾つかのテクニックを知ることができます。

コードが短くなる過程

よく例として出てくるHTTPサーバの実装例は以下のコードです。

通常版

package main

import (
    "net/http"
)

func main() {
    http.HandleFunc("/index", func(w http.ResponseWriter, req *http.Request) {
        w.Write([]byte("Hello world"))
    })
    http.ListenAndServe(":3000", nil)
}

GET /indexでHello worldを返します

curl http://localhost:3000/index

Hello world

ここにはServerもHandlerも登場しません。これを省略せずに書くと、おおよそ以下のコードになります。

冗長版

package main

import (
    "net/http"
)

func main() {
    m := http.NewServeMux()
    h := new(HelloHandler)
    m.Handle("/index", h)

    s := http.Server{
        Addr:    ":3000",
        Handler: m,
    }
    s.ListenAndServe()
}

type HelloHandler struct{}

func (h *HelloHandler) ServeHTTP(w http.ResponseWriter, req *http.Request) {
    w.Write([]byte("Hello world"))
}

通常版と比べると長いですね。この冗長版を以下のような3つのテクニックで短く簡単な通常版にしていきます。

その1 構造体作ってServeHTTP()作る必要をなくす

冗長版では、HelloHandler構造体を定義して、そこにHandlerinterfaceであるServeHTTP(w http.ResponseWriter req *http.Request)を実装しています。

機能を作るたびにServeHTTP()のための構造体を作るのは面倒です。そこで、ServeHTTP()と同じ関数型のaliasであるHandlerFuncが用意されています。

type HandlerFunc func(ResponseWriter, *Request)

func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
    f(w, r)
}

HandlerFunc型にServeHTTP()を作り、内部的に自身の関数を呼び出しています。

これによって、2つのメリットが生まれています。

  • わざわざ構造体を定義しなくても良くなった
  • ServeHTTPという関数名に縛られなくなった

それをコードに適用すると

package main

import (
    "net/http"
)

func main() {
    m := http.NewServeMux()

    // HandlerFunc型にキャストして渡す
    m.Handle("/index", http.HandlerFunc(index))

    s := http.Server{
        Addr:    ":3000",
        Handler: m,
    }
    s.ListenAndServe()
}

// ただの関数に
func index(w http.ResponseWriter, req *http.Request) {
    w.Write([]byte("Hello world"))
}

func(http.ResponseWriter, *http.Request)という関数を好きな名前で作り、HandlerFuncにキャストするだけで良くなります。さらに、このキャスト自体も意識しなくても良いです。詳しくは次の節で。

その2 ServeMuxは使うので予め用意する

ServeMuxは、HTTPリクエストに対しての処理をPathごとに登録することができる構造体です。ServeMuxを使わなくても、HTTPリクエストを処理することはできますが、Pathごとの振り分けは余程のことがない限り必ず使うため、省略できるようになっています。

冗長版では、http.NewServeMux()して、PathのパターンとHelloHandler構造体を渡していました。これを短くするために、net/httpは予めパッケージの変数にDefaultServeMuxという変数を持っています。DefaultServeMuxに対する登録を行うことができる関数も用意されていて、そのうちの一つがhttp.HandleFunc(pattern string, func(http.ResponseWriter, *http.Request))です。第一引数のpatternでPathを、そして第二引数はHandlerFuncにキャスト可能な関数型です。前述のHandlerFuncへのキャストを意識しなくて良い理由は、このhttp.HandleFunc()が内部でキャストしてくれるからです。

これによって2つのメリットが生まれています。

  • ServeMuxを自分でnewしなくて良くなった
  • HandlerFuncにキャストせずに、Pathと決まった引数の関数を実装して渡すだけで良くなった

再びコードに適用します。

package main

import (
    "net/http"
)

func main() {
    // ServeMuxは作らず、HandlerFuncへのキャストもしなくていい
    http.HandleFunc("/index", index)

    s := http.Server{
        Addr: ":3000",
        // packageで用意されているDefaultServeMuxを使う
        Handler: http.DefaultServeMux,
    }
    s.ListenAndServe()
}

func index(w http.ResponseWriter, req *http.Request) {
    w.Write([]byte("Hello world"))
}

また少し短くなりました。

その3 Serverも必ず使うので、1発に

Serverは、HTTPをどうServeするかを定義します。基本的にはどのネットワークソースでHTTPを提供するのかと、そのHTTPをどう処理するかのHandlerがあれば動きます。

冗長版では、Serverをnewしてport 3000番をAddrとHandlerを入れて、ListenAndServe()しています。多くの場合、これだけで済むので、その2つだけで渡せば、内部的にServerを動かしてくれるhttp.ListenAndServe(adds string, handler Handler) errorが提供されています。

func ListenAndServe(addr string, handler Handler) error {
    server := &Server{Addr: addr, Handler: handler}
    return server.ListenAndServe()
}

それを適用(+無名関数化)すると、最初に書いた通常版のコードになりました。

package main

import (
    "net/http"
)

func main() {
    // index()は無名関数に
    http.HandleFunc("/index", func(w http.ResponseWriter, req *http.Request) {
        w.Write([]byte("Hello world"))
    })
    // Serverは作らなくても、DefaultServeMuxで起動
    http.ListenAndServe(":3000", nil)
}

通常版では、http.ListenAndServe(adds string, handler Handler) errorの第一引数に、port番号を表す文字列を渡し、第二引数はnilです。nilを渡すとServerの内部で、前述のパッケージ変数のDefaultServeMuxが使われます。*1自分でHandlerを実装して、このListenAndServe()の第二引数に入れてを呼ぶことも可能です。その場合でもServerの作成は省略できます。

ちなみに、Serverの作成を省略しないケースはというと、Serverには他にも各種Timeoutや最大リクエストサイズなど、HTTPを受け付ける上での制約を課すことができます。それを使う場合はServerを自分でnewして、対象の変数に値を入れます。ここ参照*2

まとめ

以上で、冗長版が通常版に省略されていくテクニックを知ることができました。いずれも、ほとんどやることが定型化しているのであれば、できるだけ手間が少なくなるように設計されています。逆に、細かくやりたい場合は、省略せずに書くことで実現できます。

ライブラリを書いたりすると、このバランスが難しかったりしますが、net/httpパッケージで使われているやり方は参考になります。

参考

*1:その2でServerにhttp.DefaultServeMuxを渡していますが、Addrだけで動きます(Handlerは指定しなかったらnilなので)

*2:多くの場合、そういう制約は前段にnginxなどを置いて対応するかと思うので、省略形が提供されているのかなと思います。内部のAPIなどでnginxを前段に置くのは手間だけど、制限したい場合などはこれを使います。

homebrewのformulaフォーマットをチェックする

ふとQiita見てたら、homebrewで配布するという記事に、auditでフォーマットチェックするといいよってコメントがついていました。 goでcliのコマンドを作ってhomebrewで使えるようにしてみた - Qiita

rnzooもrnsshも数年前にpecoを参考に作っただけで、チェックも知らなかったので実行してみました。

homebrew-rnzooのformulaファイルに試してみました。

brew audit --strict --online rnzoo.rb

まず、チェック用に、rubocop のインストールが行われました。ログは記録忘れ。brewで入るようで、ローカルのgem listには出てこないです。結果は、以下の通り。

rnzoo:
  * A `test do` test block should be added
  * `require "formula"` is now unnecessary
  * C: 5: col 12: Prefer double-quoted strings unless you need single quotes to avoid extra backslashes for escaping.
  * C: 10: col 12: Prefer double-quoted strings unless you need single quotes to avoid extra backslashes for escaping.
  * C: 14: col 17: Prefer double-quoted strings unless you need single quotes to avoid extra backslashes for escaping.
  * W: 19: col 5: Useless assignment to variable - `msg`.
Error: 6 problems in 1 formula
  • test doはテスト用のブロックを入れるということで、特にないのでとりあえずブロックを作るだけ。
  • require "formula"はもういらないらしい(古いやつみたい)
  • Cの奴は、\使わないなら、"使うようにということで"に統一
  • Wの奴は、無駄な変数msgに割り当ててるとのことで、変数は除去

test do適当に追加したら、cavertstest doより前じゃないといけないとのこと。

* `caveats method` (line 26) should be put before `test block`

対応したコミットはこちら

セルフチェックできる仕組みいいですね。 homebrewの記事、新規に書いてアップデートしないとかなー。 reiki4040.hatenablog.com

参考

rnzoo 0.4.1をリリースしました

去年ふっとgolang 1.7に上げといたrnzooですが、先日v0.4.1をリリースしました。アップデートはhomebrewなら以下で。

brew update
brew upgrade rnzoo

内容は、rnzoo ec2listに、-t, -tsvオプションを追加しました。rnzoo ec2listは、ec2のインスタンスリストを出力しますが、区切りがタブではなく、見た目重視のスペースになっていて、シェルスクリプトとの連携具合が良くなかったので、TSVで出すようにするオプションを追加しました。

rnzoo ec2list -tsv | grep "stopped" | cut -f1とかで必要なカラムを取り出すことができます。

AWS API Gateway+LambdaでSlackにメッセージをPOSTする(後編)

前編中編にて、AWS API Gateway + Lambdaを使って、post-slack WebAPIを作り、テスト実行まで行いました。後編では、API keyの設定と実際に使えるようにデプロイをしていきます。

Slack Webhook URLは、それを知っていれば誰でも使うことができます。せっかくAPI Gatewayを使うので、API keyを使って制限をかけます。*1Usage PlanとAPI keyを使うと、アクセス自体の制限以外に、使用量の制限、スロットリングをかけることができます。

API GatewayのStageとUsagePlanとAPI key

今回の部分に関して、それぞれ用語とその関連を先に頭に入れると理解しやすいので、先にその説明をします。

Stage

API GatewayのStageは、いわゆる開発(dev)、検証(staging)、本番(prod)といった、動作環境を指します。これらを作ることで、一般的な開発フローと同じく、まず開発環境にデプロイしてーという流れと同じことができます。*2

Usage Plan

Webサービスなどでの、Free PlanやStandard Plan、Unlimited Planみたいなものです。スロットリングや使用量制限を定義します。Usage PlanはStageと紐付ける必要があり、Stageがないと作れません。

API key

対象ごとに発行する認可用のkeyです。API keyは、発行は単体でできますが、Usage Planと紐付けないと、実際にAPIで使うことはできません。

post-slackでの設定

前述の説明で、およそそれぞれの関連性がわかったかと思います。ここからは実際にそれを設定していきます。この部分がAWSコンソール上から作成しようとすると、先に作る必要があるものがあったりなどハマりがちなので、スムーズに行く順番で行っていきます。

API keyの必須設定と、API GatewayのStageの作成(=デプロイ)

まず引っかかりやすいのが、Stageを作成するには、そのWebAPIを1回はデプロイする必要があることです。左メニューから、Stageを選択して、[Create]で進むと、必須項目のDeploymentで選択できるものがなく、「どうやって環境作るんだろう・・・」と感じてしまいます。*3

デプロイするものができるまでStageは不要というのもわかるんですが、API keyで制限をかけるには、Usage Planが必要で、Usage Planの作成にはStageが必要でなので、ハマります。

今回は、API key必須の設定だけしてデプロイすることでAPI keyでの制限を有効にして進めていきます。

post-slack APIのResource -> / POSTを選択します。前回も使ったマス目の並ぶ画面です。Method Requestを選択します。

f:id:reiki4040:20170207233007p:plain:w400

API Key Requiredをtrueに変更します。これだけです。Authorizationというのもありますが、こちらは今回使いません。

f:id:reiki4040:20170207233027p:plain:w400

API key必須の設定ができたので、デプロイしてStageを作ります。[Action]-> Deploy APIを選択します。

f:id:reiki4040:20170207233254p:plain:w400

Deploy APIというダイアログが出てくるので、Deployment Stageで[New Stage]を選びます。そうするとフォームが出てくるので、devというStageにします。Deploymentの所は、デプロイ(リリース)の内容を入れます。今回は適当にfirst deployにしてます。*4 [Deploy]を押すとデプロイされます。

f:id:reiki4040:20170207233137p:plain:w400

URLが割り当てられます。これを後で使うので、コピー等で取っておいてください。 f:id:reiki4040:20170207233356p:plain

WebAPIのURLは以下のフォーマットです。

https://<ランダム>.execute-api.ap-northeast-1.amazonaws.com/<Stage名>

早速curlで試してみます。--dump-header -は、レスポンスヘッダの出力を標準出力に出すオプションです。

curl -XPOST -H 'Content-Type: application/json'  https://<あなたのURL> -d '{"message":"hi"}' --dump-header -

HTTP/1.1 403 Forbidden
Content-Type: application/json
Content-Length: 23
Connection: keep-alive
Date: Tue, 07 Feb 2017 13:39:33 GMT
...AWS独自ヘッダーかとか色々...

{"message":"Forbidden"}

はい。403の権限がないエラーになります。API keyがないからです。

Usage Planの作成とAPI keyの作成

次にUsagePlanを作ります。左メニューのUsagePlanを選択し、[Create]で作り始めます。

f:id:reiki4040:20170211150120p:plain:w300

ここではdevという名称で、Planを作ります。スロットリングは適当に10/secぐらい、burstも10にしておきます。使用制限は1,000/dayぐらいにしてみます。この辺の値は適当なので、適宜どうぞ。入れたら[Next]で次へ。

f:id:reiki4040:20170211150144p:plain:w400 f:id:reiki4040:20170211150153p:plain:w500

どのAPIのStageに適用するかを設定するので、[Add API Stage]を選択し、 f:id:reiki4040:20170211150253p:plain:w400

post-slack APIと先ほど作ったdev Stageを指定して、チェックを選択します。 f:id:reiki4040:20170211150358p:plain:w400

紐付けられたら、[Next]で進みます。 f:id:reiki4040:20170211150404p:plain:w400

次はAPI keyの設定に進みます。[Create API keyand Add to Usage Plan]を選択し、新しくAPI keyを発行します。

f:id:reiki4040:20170211150755p:plain:w400

Nameはnotification-programにします。ここは好きなもので構いません。keyは、Auto Generateでランダムに生成します。入れたら[Save]します。 f:id:reiki4040:20170211150907p:plain:w400

Usage PlanのAPI key一覧に戻るので、notification-programというkeyがあることを確認して、[Done]で完了します。 f:id:reiki4040:20170211151738p:plain:w400

作成後、API keyタブから、notification-programを選択すると、API keyの詳細を見ることができます。

f:id:reiki4040:20170211231517p:plain:w500

API keyのshowを選択すると、値を見ることができます。これをリクエストヘッダに入れて使います。 f:id:reiki4040:20170211151950p:plain

これでpost-slack APIにdev PlanとAPI keyが出来ました。

API keyを使ってcurlからslackへPOST

さていよいよ完成したので、curlを使ってリクエストしてみます。API keyはx-api-keyというリクエストヘッダで送ります。

curl -XPOST -H 'Content-Type: application/json' -H 'x-api-key: <あなたのAPI key>' https://<あなたのAPI URL> -d '{"message":"post slack message from my machine via API Gateway/Lambda!"}' --dump-header -

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 17
Connection: keep-alive
Date: Tue, 07 Feb 2017 14:05:37 GMT
...AWS独自ヘッダーかとか色々...

"posted to slack"

いやーレスポンスがひどい。でもSlackには表示されました! f:id:reiki4040:20170211152540p:plain:w500

これで、HTTPS+API keyでslackへのPOSTができるようになりました。後はスクリプトから叩いたり、他の人に渡す時は別のAPI keyを発行して渡して使うことができます。

参考

*1:もちろん、元のSlack Webhook URL自体へのアクセスを制限できるわけではありません

*2:加えて、簡単にStageを追加できるので、開発フロー上の環境だけでなく、個別用途での環境も作ることができます。

*3:触ってから説明書読むタイプにはハマるポイント

*4:本来はバージョン番号とかそういうのを入れる場所なのかなと。後で別のStageを作る時は、このDeploymentから選択することができます。

AWS API Gateway+LambdaでSlackにメッセージをPOSTする(中編)

前回、Slack Incoming Webhookの作成と、それを使うLambdaを作成したので、続いてAWS API GatewayとLambdaを繋いでいきます。書いていたら思ったより長くなったので、API Gatewayのテスト実行までを中編にして、後編で、API keyの設定とデプロイを行います。

Lambda自体は、サーバレス(正確にはインスタンス管理レス)で動きますが、呼び出しは他のAWSイベントをフックするものが多いです。それはそれでいいんですが、どうしてもAWSよりのコードが入るので、そこをWebAPIという形で、汎用的に扱えるようにします。

しかし、普通にWebAPIを用意しようとすると、サーバを準備して、nginx/apacheやプログラムを作って、Lambdaを呼び出すようにしなければならないため、API Gatewayを使って、サーバの運用なしで使えるWebAPIを作ります。

今回は1機能だけなので、直接/にJSON{"message":"hello world"}をPOSTしたら、Slackに投稿されるようにします。

AWS API GatewayとLambdaを繋ぐ

まずはAPI Gatewayで、WebAPIを作っていきます。AWS Consoleから、API Gatewayを開きます。

f:id:reiki4040:20170202221643p:plain:w400

[Create API]を選択するとフォームが出てくるので、名称を入れます。ここでは、post-slack(好きな名称で良いです)としておきます。

f:id:reiki4040:20170202221709p:plain

[Create API]で作成すると、post-slack APIのメニューが出てきます。Resourceを選び、そこで/を選択し、[Action] -> [create method]を選択し、

f:id:reiki4040:20170202221726p:plain

POSTを選択します。

f:id:reiki4040:20170202221732p:plain:w300

そうすると、Integrationを何にするか選択する画面が出てくるので、Lambdaを選択し、リージョンとLambda function名を入れます。入力を始めるとサジェストしてくれます。ap-northeast-1と前回作ったpost-slack-generalを選びます。 f:id:reiki4040:20170202221752p:plain

[Save]を押すと、API GatewayにLambdaの呼び出しを許可するかと求められるので[OK]にします。

f:id:reiki4040:20170202221933p:plain:w400

Client->Request->Integration->Responseのフローを表す、左右に縦長長方形、間に2x2 4つのマス目が表示されます。HTTPのリクエストをLambdaに渡す時の設定を行います。[Integration Request]を選択します。 f:id:reiki4040:20170202222019p:plain

下部のBody Mapping Templatesを開きます。Request body passthroughは、Neverにしておきます。これは定義したContent-Type以外は、HTTP status code 415でfailさせる扱いです。*1 f:id:reiki4040:20170202222101p:plain

今回は、JSONをPOSTしてくるので、+Add mapping templateを選択し、 f:id:reiki4040:20170202222130p:plain:w300

application/jsonを入力してチェックマークを選択します。(例として表示されてますが入力が必要です)

f:id:reiki4040:20170202222136p:plain:w300

application/jsonを選択すると、下部に入力欄が出てでくるので、以下を入力して[save]します。

{ "text": $input.json('$.message') }

f:id:reiki4040:20170202222155p:plain:w400

POSTされてきたJSONmessageというkeyの値を、textというkeyの値として置き換えるということをやっています。{"message":"hello"}{"text":"hello"}にしています。

Mappingが何に役立つかというと、Lambdaはtextで受け付けるように作ったけど、key名がいけてないなーと思っても、Lambdaには手を入れたくない(入れられない)という時に、WebAPIではmessageで受け取って、Lambdaに渡す時に変換できるということです。*2

とりあえずこれで動くので、API GatewayのTest機能を使って動かしてみます。 上部の<- Method Executionで、マス目の並ぶ画面に戻ります。

テスト実行する

左の[Test]雷マークみたいなのを選ぶと、テスト実行の画面になります。

f:id:reiki4040:20170202222349p:plain:w400

Request Bodyに{"text":"POST from API Gateway + Lambda"}を入れ、 [Test]を実行すると、横にレスポンス *3 やログが出てきます。 f:id:reiki4040:20170202222424p:plain

特に問題なければ、Slackにメッセージが出てきます。動かない時はログ見てください。 f:id:reiki4040:20170202224832p:plain

これでとりあえずWebAPIとしての動作はOKです。あとはデプロイすれば、実際に世界中から使えるようになります。

次回、API keyを使ってアクセスを制限して、デプロイして使えるようにします。

参考

*1:AWSのドキュメントみると、Request body passthroughのWhen no templateとNever何が違うんだろうという。

*2:リクエスト情報を一通り受けたい場合は、Lambda Proxy Integrationを使うと楽そうです。

*3:レスポンスが雑なメッセージですが、多分設定追加すれば{“response”:“ok”}とかぐらいにはできるはず・・・

AWS API Gateway+LambdaでSlackにメッセージをPOSTする(前編)

Slackはincoming webhooksがあり、POSTするだけで、簡単にメッセージを送ることができます。

スクリプトで直接Incoming Webhook使ってもいいんですが、これ自体は別に認証も何もないので、誰かが知ってしまうと、好き放題投稿できます。そんな時に入れ替えたりする場合、いろんなスクリプトの設定に埋め込まれていて、方々に散っているのはちょっと辛いです。また、多言語環境の場合は、一定の処理を行う場合に各言語でライブラリ作るのもしんどいかなーということで、AWSAPI Gateway + Lambdaを使って汎用化してみます。*1

Slackのteam、AWSアカウントはあるものとして、以下を行っていきます。

  • Slack Incoming Webhookの作成
  • AWS Lambdaでincoming Webhookを使う
  • AWS API GatewayとLambdaを繋ぐ(後編で)

Slack Incoming Webhookの作成

Incoming Webhookは、channelを指定するので、今回は#generalを使います。必要に応じてchannelを作成してください。

次に、incoming webhook integration(新規作成ページへのリンク)を開きます。

channelに#generalを選択して作成します。 f:id:reiki4040:20170129234607p:plain

そうすると、settingsのページに行くので、Webhook URLをコピーしておきます。 f:id:reiki4040:20170129234617p:plain

また、下の方に行くと、名称とアイコンを設定できるので、用途に合わせて変更します。 f:id:reiki4040:20170129234624p:plain

以下のcurlで試すと、メッセージが表示されます。(URL部分は置き換えてください)

curl -X POST -H 'Content-type: application/json' \
--data '{"text":"This is a line of text.\nAnd this is another one."}' \
 https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

レスポンスは、成功したらokだけです。以下のように表示されます。(画像は名称の反映が遅延しているのか、incoming webhookのままでした) f:id:reiki4040:20170129234629p:plain

AWS Lambdaでincoming Webhookを使う

次に、Lambda上に実装していきます。

AWS consoleからLambdaサービスを開き、Functionsから[create a Lambda function]を選んでスタートします。BluePrintには、pythonでのCloudWatch->APIGateway->Lambda->Slackはありますが、今回はnode.jsで行うので、Blank functionから作ります。 f:id:reiki4040:20170129234702p:plain

Triggerは、作らないまま進みます。 f:id:reiki4040:20170129234753p:plain

詳細が出てくるので、Nameにpost-slack-general(好きな名称で構いません)を入力して、RuntimeはデフォルトのNode.js 4.3にします。 f:id:reiki4040:20170129234739p:plain

Lambda function codeは[Edit in inline]で、以下を入れます。

console.log('Loading function');

const https = require('https');
const url = require('url');
const slack_url = process.env.SLACK_WEBHOOK_URL;
const slack_req_opts = url.parse(slack_url);
slack_req_opts.method = 'POST';
slack_req_opts.headers = {'Content-Type': 'application/json'};

exports.handler = function(event, context) {
  if (event.text) {
    var req = https.request(slack_req_opts, function (res) {
      if (res.statusCode === 200) {
        context.succeed('posted to slack');
      } else {
        context.fail('status code: ' + res.statusCode);
      }
    });

    req.on('error', function(e) {
      console.log('problem with request: ' + e.message);
      context.fail(e.message);
    });

    // ここで、メッセージの編集を必要に応じて行う。
    var message = event.text;

    req.write(JSON.stringify({text: message}));

    req.end();
  }
  });
};

このAWS LambdaでSlackのIncoming Webhookでメッセージを送る例は、 CloudWatchのAlertをAWS Lambda経由でSlackに飛ばすを参考にさせていただきました。

上記ページは、SNS用のpayload構造になっているので、その部分などを変更しています。{"text":"message"}というJSONが来て、そのtextのvalueをSlackに送るLambda(node.js)です。*2

また、Webhook URLは環境変数で入れるように変更しています。そのあとのEnvironment variablesで、SLACK_WEBHOOK_URLというkeyでWebhook URLを設定します。 f:id:reiki4040:20170129234730p:plain

Lambdaの実行のIAMRoleは、特に追加の権限は必要ないので、最低限Lambda実行に必要なIAMRoleを作ります。すでにある方は飛ばしてください。[Create a custom role]を選択して、IAMの画面に移動します。 f:id:reiki4040:20170129234653p:plain

デフォルトで表示されているものを[Allow]で許可すれば大丈夫です。 f:id:reiki4040:20170130000047p:plain

作成したIAMRoleが選択されます。 f:id:reiki4040:20170129234711p:plain

Advanced settingsのところは特に変更しません。最下部の[Next]で次のプレビューに進み、[Create function]で作成完了です。

Lambdaの実行確認

Lambdaは、テスト実行ができます。[Action] -> [configure test event]を選びます。 f:id:reiki4040:20170129234807p:plain

デフォルトで[Hello world]が選択されているので、その下のJSONを、以下に変更して、[Save and Test]で実行します。

{"text":"Message from AWS Lambda"}

f:id:reiki4040:20170129234817p:plain

成功したら、Slackにメッセージが表示されます。 f:id:reiki4040:20170129234800p:plain 出てこない場合は、AWS console画面下部に実行ログが出てくるので、それで確認しましょう。

次回、API Gatewayと繋いでいきます。

参考

*1:使ってみたいだけというのもある

*2:お好みで、他のkeyを追加して、送る前に組み立ててください。