自分の勤怠状況を Kubernetes, Slack, Metabaseで可視化

システム構成はタイトル通りで、Slackから飛ばした出勤・退勤をKubernetesにデプロイしたアプリ経由でDBに登録して、 Metabaseから可視化したよって話。

タイトルだけ見ると、いや勤怠管理のアプリ使えよとなるかもしれない

やったことと

狙いとしては、Docker / Kubernetesがどれくらい使えそうか、メリットは何かをざっくり感じれればいいなと。 ついでに、勤怠報告に使えればなおよし。

全体的なフロー

1. Kubernetesクラスターを作成して、Dockerコンテナ化したアプリをデプロイ
2. SlackのSlashコマンドと(1)のアプリのHTTPエンドポイントを紐付け
3. SlackにSlashコマンドで勤怠を入れる
4. Kubernetes上のアプリ経由でMongoDBにレコードを登録
5. Embulkで MongoDB → MySQL にデータ転送
6. Metabaseから勤怠状況をグラフに落とし込む！

完成図

[Slackで勤怠をちょこちょこ入れて]

[Metabaseで結果をダッシュボードに出す]

うーん、激しい勤務実態が見えてしまいましたね。可視化した時点で休み時間入れるの忘れてたことに気がつきました。。。

大変だったとこ

フローごとに難所があったので、覚え書きとして。

Kubernetes

• Docker コンテナのイメージさえできていれば、Deploymentは問題なくいける。

• ServiceはLoad Balancerを選択しましたが、クラウドプロバイダーによってはデフォルトがHTTPになっています。HTTPSにしないといけないサービスの場合は注意が必要です。例として、SlackのMessage ButtonはHTTPSでないとボタンアクションの質問は出るものの、ボタンを押した後のRequestURLが叩かれません。

• ただ、突然Podの再生成がスケジュールできなくなる事象に遭遇。これはKubernetesクラスターを動かしていたGoogle Cloud Platformの問題っぽい。

  • 解決策は リソースの自動拡張をONにすること。でないと突発的にリソースを食い始めた時に全て落ちる。
  • 調べていたら、もう一つ解決策はあったようですね。Servicesに SessonAffinity プロパティをを加える...ことらしい。

GCE services type LoadBalancer · Issue #18347 · kubernetes/kubernetes · GitHub

• MongoDB も立てるはずだったけど、上記理由から不安があったので断念。本当は一緒のクラスター上に乗っている方がいいよ。
  • 結局DBaaSのmLab使って解決。サービス使えると楽でいいわ

mlab.com

Embulk

• 言わずとしれたデータ転送ツール

github.com

• MongoDBからデータを抽出した時に、カラムが分割されない問題がありましたがFilterで対応。
  • ここは別記事で紹介したい。。。

Metabase

• セットアップから可視化までは相当楽でした。ここは昔の記事を参照いただければと。

ponzmild.hatenablog.com

• このグラフや他の結果(週次の勤務時間合計とか)をSlackやメールで飛ばせるにはのMetabase自体にもSlackとメールでスケジュール連携する機能があるのでこっちをありがたく使う。ここは今後やってみたいですね。
• FaaSで色んなものと連携させている人は、ZapierやIFTTTでスケジュールorトリガーさせるのもいいかもしれません。

MongoDBでのmongoとmongod以外のクライアントプログラム

DBって基本のクライアントプログラム以外にも、クライアントプログラムが入ってるって最近気づきました。 NoSQLのMongoDBも同じようなクライアントプログラムがないか確認しました。MySQLも同様にたくさんあるようですね。

今回はMongoDBのクライアントプログラムの備忘録です。 MongoDBのDBaaSである、mlabの"Tools"タブに用例が書いてありました。

mlab.com

MongoDB Package Components — MongoDB Manual 3.6

使いそうなクライアントプログラムには、以下のようなものがありました。

• はじめによく使うやつら
  • mongo, mongos, mongod
• CSV, TSV, JSONを扱うとき
  • mongoimport
  • mongoexport
• バックアップ・リストア(バイナリ)をするとき
  • mongodump
  • mongorestore

単純にCSVをインポートするなら、オプションをつけて実行すればOK。

# 基本形
mongoimport -h <hostname> -d <dbname> -c <collection> \
                       -u <user> -p <password> --file <input .csv file> \
                       --type csv --headerline 

# カラムに属性を明示的に付ける場合
mongoimport -h <hostname> -d <dbname> -c <collection> \
                       -u <user> -p <password> --file <input .csv file> \
                       --type csv --columnsHaveTypes \
                       --fields "field1.string(),field2.int32()"

ES6からのトランスパイルするときのBabel 7 対応

タイトル通り、Babelの話。 JavaScript書いていると、避けて通れないのがES6からのトランスパイル。 このとき使うデファクト・スタンダードになったBabelで最近つまづいたのでメモです。

ことの発端

MochaでES6のコードを実行させるために babel-core, babel-register, babel-preset-env 入れたけど、deprecatedとか言われたのが事のはじまり。 ターミナルで言われてるバージョンをただ入れるだけでは済まないとは知らず。。。

Babel 7 ??

要はバージョンのメジャーアップデートで単にモジュールが変わっただけじゃない。そもそもの名称から変わっていたのです。 今までの要領でNPM覗いても、バージョン6系しか載ってないので注意しないといけないですね。ちなみに、新しいバージョンは7系(beta版)です。

また、v7系にする場合は、使用するbabelのモジュールのバージョンはすべてv7系にしないと動きません。

[babel-core 今まで] www.npmjs.com

[babel-core v7以降] www.npmjs.com

基本的には、以下のように名称が改定されている模様です。(2018/01/09時点)

• 〜v6 : babel-xxyyzz
• v7〜 : @babel/xxyyzz

名前がわからない場合は以下の、packageから見たいbabelのモジュールを探せばOK。

github.com

Githubのissuesを辿る限りまだまだ議論されているようですが、そろそろ新しいものになると考えた方が良さそうです。JS界隈は流れ早いので、ついていくに越したことないですしね。

設定例

名前が変わったとはいえ、基本的には設定方法は以下2つで変わらないですね。

• コマンドラインからオプションでbabelのモジュールを指定する。
• .babelrcにモジュール名を入れる

以下、設定例です。 ほぼ公式の例から分かりやすいところを取り出しました。

{
  "presets": [
    ["@babel/preset-env", {
    "targets": {
      "browsers": ["last 2 versions"]
      }
    }]
  ],
  "plugins": ["@babel/plugin-transform-runtime"]
}

あとは、package.json で以下のようにbabel-cliを叩くようにすればOK。 babel ./src/ --out-dir dist/ --ignore ./node_modules --copy-files

やることは変わらないとはいえ、やっぱり名前から変わっちゃうのは気づかないとハマって抜けない罠ですわ。。。

Mongooseの処理が非同期であるのを忘れてはいけない(戒め)

Node.jsのMongoDBのORMといえば、Mongoose。APIドキュメントをよく読んで使用されている方ならお分かりかと思いますが、よく使う.save(ドキュメント保存)や.find (ドキュメント検索)といった処理は非同期で実行されます。
これ、意識してないと処理はあってるのに値がundifinedになってハマる(実際ハマった)ので、非同期で処理されるという前提を頭に置こう(戒め)というメモです。

一応MongooseのPromiseのページにしれっと以下のように書いてあります。

Mongoose Promises v5.0.0-rc1

Built-in Promises
Mongoose async operations, like .save() and queries, return ES6 promises. This means that you can do things like MyModel.findOne({}).then() and await MyModel.findOne({}).exec() (if you're using async/await.
Queries are not promises
Mongoose queries are not promises. However, they do have a .then() function for yield and async/await. If you need a fully-fledged promise, use the .exec() function.

日本語で要約すると、以下のようになるかと。

• .save()や query(find() / findOne() / etc...) といった 非同期の処理 は、ES6のPromiseオブジェクトを返します。

  • これらのメソッドは .then()を続けられる。
  • async / await 句をつけて実行できる。

• ただし、queryは厳密にはPromiseではない。

  • .then(), async / await 句を使える。
  • 厳密にPromiseオブジェクトを使いたい場合は .exec()を使おう。

非同期であることはもちろん、返却されるのがPromiseオブジェクト(的なもの)であることもポイントです。 素直に配列が返却されると思いきや、オブジェクトが返ってくるので軽くビビります。

以下のようなコードが非同期で処理されるOK / NGパターンかな。

[NGの例]

 /**
  * findRcd(filterKeys)
  * @description 引数に渡された値・キーでレコードを検索し、検索結果を返却。
  * @param {Object} filterKeys - 更新するレコードの検索キー
  * @return {Array} resultSet - 検索結果
  */
findRcd(filterKeys) {
    knmKanr.find(filterKeys, (err, awesomeRecords) => {
 
    log.debug(`FilterKeys: ${JSON.stringify(filterKeys)}`);

    // レコード検索失敗
    if (err) {
        throw new Error("Find Docs Error");  // エラーを投げて処理を中断
    }

    // レコード検索成功
    log.debug(`AwesomeRecords: ${awesomeRecords}, Size: ${awesomeRecords.length}`);

    return awesomeRecord;    // ここで結果の配列が返却される
});

const searchResultSet = findRcd({ flg : '1' });    // 非同期で処理完了前に、変数に値が格納される
console.log(JSON.stringify(searchResultSet));    // 処理が未解決のため、undefined になる

[OKの例]

  /**
   * findRcd(filterKeys)
   * @description 引数に渡された値・キーでレコードを検索し、検索結果を返却。
   * @param {Object} filterKeys - 更新するレコードの検索キー
   * @return {Promise} resultSet - 検索結果
   */
  async findRcd(filterKeys) {
    const resultSet = await knmKanr.find(filterKeys, (err, awesomeRecords) => {
 
     console.log(`FilterKeys: ${JSON.stringify(filterKeys)}`);

        // レコード検索失敗
        if (err) {
            throw new Error("Find Docs Error");  // エラーを投げて処理を中断
        }

        // レコード検索成功
        console.log(`AwesomeRecords: ${awesomeRecords}, Size: ${awesomeRecords.length}`);

    });

    console.log(`resultSet: ${resultSet}`);    
    return resultSet;    // ここでPromiseオブジェクトが返却される
  }
}

findRcd(query)
    .then((searchResultSet) => {
        console.log(`searchResultSet: ${JSON.stringify(searchResultSet)}`);    // {...} 非同期処理が解決されてから値がセットされる
    }

こういう時こそ、async / await が効果的なんだってわかりますね。 改めて、Mongooseの処理が非同期であるのを忘れてはいけないです(戒め)。

API Blueprintで爽やかなAPI仕様書を作る

ローカルで動かそうがDockerで動かそうが、APIを持つアプリを作るとなると自然と一覧が欲しくなるもの。 できれば型や仕様書のフォーマットを... ブラウザで見れる&修正後はDiffが取れる形で欲しいですね。
(自分の関わってたプロジェクトだとExcelにペタペタ定義を書くor貼る仕様書でした。古いとこだと一太郎で作ってた。一太郎2018ってあるんだぜ)

[一太郎] ... フォントや段組機能は好きです www.justsystems.com

そこでAPI仕様書を簡単に作ろうと思った時に当たった選択肢が、Swagger or API Blueprintでした。 今回はAPI Blueprint触った感じを書きます。

[API Blueprint] API Blueprint | API Blueprint

[Swagger] ... こっちの方が The World's Most Popular らしい swagger.io

完成図

一聞は一見にしかず。下図みたいに エンドポイントごとに作成できます。 GETは青色、POSTは緑色とHTTPメソッドごとに色別になっているのはSwaggerと同じ。また、APIもグルーピングができるようです。

基本

マークダウンで書きます。SwaggerはJSON or YAMLで書くので、API Blueprintはマークダウンに慣れている人にはぴったりです。 ただ、マークダウンといっても作成するファイル形式は .apib だったり、段落にも意味があったり、特定のブロックは3tab or 12こスペース空けるといったコード規約があります。ここはクセがありますが、1時間もあれば慣れます。

流れとしては、だいたい4つに分けられます。

1. マークダウンで 仕様書を書く
2. できたファイルは .apib で保存
3. .apibファイルを 変換用のツールでHTMLにする
4. HTMLをお好きなブラウザで見る

HTML変換ツールも言語・フレームワークによって色々用意されているようですね。 例えば、Aglio: Node.js / Laravel Blueprint Docs: PHP(Laravel) / django-apiblueprint-view: Python(Django) / Snowboard: Go といった具合です。 API Blueprint Tools | API Blueprint

また、書いたマークダウンを元にAPIのモックサーバーを動かせるんですが、MacOS10.12以降では動かないみたいですね。。。
→ issuesに上がってました。

github.com

書けること

だいたい以下のようなことをかけます。

• APIのURI
• リクエスト
  • HTTPステータス
  • Header項目
  • リクエストパラメータ(型 / 必須)
• レスポンス
  • HTTPステータス
  • Header項目
  • レスポンスデータ(型 / 必須)

HTML生成時にリクエストパラメータやレスポンスデータのスキーマを必須・オプション、データ型含めてまとめて表示してくれるのは嬉しい。

面倒なポイント

私は幸いにもマークダウンは普段から書いてる & Node.jsの例は豊富にあったので書くこと自体は苦はないですが、 aglioでの面倒な点として.apib 1ファイルしか変換できないこと がネックでした。１ファイルじゃなくて、分割して書いたものを1つにまとめたいじゃないですか。

少し前の記事ですが、他の方も複数ファイルあるものを1つの.apibファイルにまとめて変換をかけているような手段をとっているようです。

dev.classmethod.jp

というわけで、シェルスクリプト書いて分割した.mdファイルを1つの.apibファイルにまとめて変換しました。 → Gistで公開してます。(マークダウンはソース貼り付けるとGist上で読みやすく変換してくれるおかげでソースコード見れなくなってますが笑)

gist.github.com

作成した仕様書はGithubPagesやローカル、社内のサーバーに置くなりすれば立派な仕様書ができそう。

MetabaseがRedashの苦労を吹き飛ばすくらい熱い

昨年末からデータ可視化ツールを諸々触る中で Redash おもろいわ〜ってなってたんですが、QiitaでMetabaseの記事を目にしてしまったので使わざるを得なかった。投稿者様ありがとうございます！！
面白さに勢いで書いてしまったので、拙い点はご容赦ください。

qiita.com

結論から言えば、MetabaseはRedashなんかより遥かに使いやすい!!(あくまで可視化系ツールを最初に触る人としてはという枕詞つき)
Docker使ってる身としては、docker composeでシコシコとセットアップしなくても、docker run 一発で起動できるのは楽で助かる。もちろん、docker compose は様々なコンテナをまとめてセットアップする点で楽なのですが、1ツール1コマンドで起動するのに比べたら手間がかかりますしね。

[今回紹介するMetabase] www.metabase.com

[苦労した方のRedash] redash.io

何がすごいの??

MetabaseとRedashで比較してみます。それぞれ数時間しか触ってないですが、雰囲気だけでも伝わればと。

セットアップが楽

公式によると、セットアップの選択肢は結構あるようです。

• Docker ... コマンド一発で起動する
• AWS ... Elastic Beastalkで動かす
• Heroku ... ボタンをポチポチするだけ
• OSの上に直接のっける (Macでやる方法が最初に紹介されてますが、まだ深くまでは見れてない)
• JARファイルをダウンロードして、java -jar metabase.jar

私はDockerの勉強がてらDockerのイメージから起動させましたが、JARファイルでやるのも簡単そう!

Dockerだと以下コマンドを叩いて、http://localhost:3000にアクセスすればOKです。

$ docker run -d -p 3000:3000 --name metabase metabase/metabase
xxxxxxyyyyyyyxxaserjaser  <- コンテナID

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                    NAMES
xxxxxxyyyyy        metabase/metabase   "/app/run_metabase.sh"   3 seconds ago       Up 2 seconds        0.0.0.0:3000->3000/tcp   metabase

ハマりポイントとしては、DockerコンテナでMetabaseのデータ取得先のDBを動かしている場合は、--link オプションで動かさないとセットアップで以下のエラーが出て先に進めなくなります。
No matching clause: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.

解決例としては、以下のようにリンクさせればOK。これはMySQLのコンテナとリンクさせた例。
docker run -d -p 3000:3000 --name metabase --link ponz-mysql:ponz-mysql metabase/metabase

アクセスして約1分待てばHome画面に遷移します。超早い！

ここから、自分で登録したDBやサンプルで最初から入ってるデータセットを調べたりできます。

データ可視化までにSQLを使わなくても良い

これがRedashとの最大の違いかなと。
例えば、東京都練馬区の各図書館の蔵書数(平成28年度時点)について調べたいとします。

※ こちらの蔵書数については、区発行のオープンデータを使用させていただきました。元はRedashいじるように使おうとしてました。。。

図書館所蔵資料数：練馬区公式ホームページ

調べたいデータを"New Question -> Custom" から選んで、自分で読み込んだDBのテーブルを選択。あとはプルダウンからサクッとデータ項目を選べば綺麗なチャートがあら簡単。円グラフが作れました。ここから、区分'0001'(図書資料)が圧倒的に多いな〜と分かりますね。
Redashは "Group by" に選んだ項目で絞ったりグラフを描画しても思った通りにならない時があるので、こちらの方が直感的かもしれないです。(個人差はあると思いますよ)

もちろん、SQLも書いても問題なくいけます。"New Question -> Native Query" でSQLエディターが出てくるので、ここでSQLを打てばOK。
若干Redashの方がグラフのオプションが多い気がします。

ダッシュボートはグリッド形式で大きさを指定して配置できます。ここも難なくできます。

雑感

まだバージョンが 0.27.2 (2018/01/04時点) なので、破壊的な変更が入る可能性がなきにしもあらずですが、非常に可能性を感じさせるプロダクトですね！非エンジニアもRedash以上にデータを扱いやすくなりそう...

ZapierでスケジュールやらRSSフィードを一括でSlackに送る

みなさま、明けましておめでとうございます！ 新年一発目は新しいことやろうとしていたので、ずっとやりたかったSlackで必要なことを１つにまとめるTipsについてです。

昨年のこちらの記事に触発されたこともあるので、ZapierでSlackにスケジュールとRSSフィードをまとめます。

[偉大な参考記事] tech.mercari.com

[Zapier公式] zapier.com

やること

• 散漫になってウォッチしづらかったものをSlackに送りつける。
  • Googleカレンダーをポストする
  • RSSフィード(購読中のはてなブログ)から更新をポストする。

Zapierって?

よく使うツールを繋ぎ合わせて、一連の作業を自動化するツール。一連の作業はZapとして作成します。 スクショの通り、めちゃくちゃいろんなツールが使えます。 例えば、Google DriveにファイルがアップロードされたらSlackに通知するとか、GithubのissuesをTrelloカードに追加したりできます。 Exploerタブからツールを選べば、10,000以上のZap例が出てくるのでみて見ると夢が膨らみます。

• Slack
• Google Calendar
• Google Drive
• Office365
• Twitter
• Evernote
• GIthub
• Instagram
• Zapier組み込みツール(RSSフィード / メール / SMS etc...)

サクッと作る

早速作ります。Exploerタブから使いたいツールを選択すると、よく作られるZapの一覧が下に出てきます。 自前で作ることもできるようですが、だいたい作るZapは定型化されているので Use this Zap から使わせてもらいましょう！

あとはガイドに沿ってプルダウンやら項目を埋めれば5分経たずに作成できます。ヽ(*´∀｀)人(´∀｀*)ﾉ

他にも、はてなブログのメール通知だと見逃す購読中のブログの更新(RSSフィード)もポストしたりできまする。 見るべきところを1つにまとめられると楽ですね。

１つのツール内でもトリガーやアクションは選べるようで、アクションの条件もフィルタリングできるようです。 例えば、Google Calenderのイベントの内容に[準備] が含まれているときだけ通知とか。

他にも使えそうなツールがたくさんあるようなので、自分の手持ちのツールのintegrationをみて見るといいかもしれないですね。