Flowを自動でgit commitする仕組みを作ってみた話

Node-RED Advent Calenadarの14日目! 遅くなってすみません。
今回は、Node-REDのフローを自動でgit管理する仕組みを作ってみた話です。

そう、Node-RED LT祭でデモしたアレです。結局記事に出来ていなかったので、今回の記事ネタにしてしまおうと思ってしまった次第。

きっかけ

Node-REDはGUIでガシガシFlowを作っていけるところがウリなのですが、過去のFlowに戻す方法がなくて困ったことが何度かありました。
ブラウザを閉じるまでは、Ctrl+zでUndoできるので、数手前までは戻すことができます。が、ブラウザを閉じてしまうともう戻せなくなってしまいますし、そうでなくてもだいぶ前のFlowの状態に戻すというのは、今のNode-REDでは難しいです。
いい手を思い付いたと思ってガシガシFlowを変更してみたはいいが、実は前のヤツのほうが良かった・・・という時に、何らかの方法で戻す方法が欲しい。

もちろん、手を加える前にJSONでexportしておけばよいのですが、ものぐさな自分にとってはちょっとそれが面倒くさい。

というわけで、試しに自動で変更をgit commitする仕組みを作ってみました。

しくみ

Node-REDのFlowは、userDirの下にJSONで保存されています。Node-RED上でDeployするたびに、このJSONファイルが更新される仕組みです。
であれば、このJSONファイルが更新される度にgit commitすれば、過去の変更をgitで管理できるのではないか、と。

そこで、今回はGruntを使って自動化することにしました。

GulpではなくGruntを使った理由は、Node-REDのpackage.jsonで元々Gruntが含まれている (Node-RED本体の開発用)からです。Gulpを使っても同様のことは可能だと思われます。

次に、JSONファイルのwatchにはgrunt-contrib-watchを利用。これもNode-REDのpackage.jsonに含まれています。
Gitの操作はgrunt-gitを利用。

userDirはデフォルトだとNode-REDのインストールディレクトリになりますが、今回はconfigディレクトリを作成し、その中にJSONが作られるように設定しました。

userDir: 'config'

Gruntfile

Gruntfileは、こんな感じになりました。
リポジトリの指定やファイル名の指定はもうちょっと上手いやり方があるような気がします。

せめて相対パスで書ければもう少しスッキリするはずなんですが、相対パスで書くと何故かgrunt-gitが意図したとおりに動作してくれないため、現時点では絶対パスで指定しています。

使い方

使い方は、Node-REDを起動した後、grunt watchコマンドを実行してJSONファイルのwatchをするだけです。

Node-RED上でFlowを編集し、Deployするとgrunt側ではこのような表示になります

>> File "config/king.json" changed.
Running "gitcommit:task" (gitcommit) task

Done, without errors.
Completed in 0.943s at Tue Dec 15 2015 21:13:51 GMT+0900 (JST) - Waiting...

git logしてみると、このようにコミットが積まれていることが分かります

$ git log
commit 310db8be68829a7f47937a5d5c6cfb41ecb5b5f2
Author: Kazuto Kusama 
Date:   Tue Dec 15 21:13:51 2015 +0900

    2015-12-15T21:13:51+09:00

developからmasterへのマージ

デフォルトでは、developブランチにコミットを積むようになっています。

$ git log --graph --decorate --pretty=oneline --abbrev-commit --all
* d90cf6e (HEAD, develop) 2015-12-15T21:18:05+09:00
* 310db8b (master) 2015-12-15T21:13:51+09:00

developブランチで開発をすすめ、良い感じになってきたらmasterにマージするという、よくあるフローも今回取り入れてみました。
今回作ったGruntfileでは、versionという名前のファイルもwatchしています。

このversionファイルが更新されると

  • versionファイルの数字を読み取り
  • developブランチをmasterブランチにmerge
  • versionファイル内の数字でtag付け

という作業を行います。
versionファイルの更新は、Node-RED上でInject Nodeを押すだけで行われるようにしました。

Node-RED___10_9_8_171

ボタンを押すと、以下のようになります。masterとdevelopが同じIDになり、v2タグが降られていることが分かります

$ git log --graph --decorate --pretty=oneline --abbrev-commit --all
* 4067c47 (HEAD, tag: v2, master, develop) 2015-12-15T21:22:51+09:00

Kubernetesベースに生まれ変わるDeis v2

Open PaaS Advent Calendar 2015 の1日目の記事です。

DeisはHerokuライクな使い勝手を実現したDocker PaaSです。

現在のDeisはCoreOSの上にDockerコンテナとして各コンポーネントが稼働する形になっています。

しかしDeis v2では、Kubernetesをベースとしたものに生まれ変わるようです。
Deis v2 Design Document #4582

KubernetesベースになるDeis

PDFでDesign Document が上がっているので、興味のある方は読んでみると良いかもしれません。

Kubernetesによって提供される概念(Service, Pod, ReplicationController, Namespaceなど)はそのまま残るようです。

それに加えて

  • S3/Swift互換のObject Storage機能を提供(RiakCSやMinioを使う)
  • Docker Registryを提供(保存先はObject Storage)
  • Buildpack, docker image, dockerfileによるデプロイ(Deis v1と同じ)
  • Deisクラスタのintegration testの仕組みを提供(Portunesという機能らしい)

などが目に付きますね。

また、これまでモノリシックなアーキテクチャだったコンポーネントを、より細かい単位に分割するようです。

OpenShift v3との違い

KubernetesベースのPaaSといえば、Red HatのOpenShift v3が思い浮かびます。

それでは、このOpenShift v3とDeis v2の違いは何でしょう?

Design Documentを読む限りだと、一番大きな違いは「ユーザーの使い勝手」のように感じます。

Deis v2の使い勝手

Design Documentのp6には、buildpackを使った際のデプロイフローが記載されています。
これを読む限りだと、ユーザーは

git push deis master

するだけで、アプリがデプロイできるようです。これは、Deis v1の使い勝手と一緒です。

Dockerfileを使うときも、Dockerfileをgit pushすればデプロイされるようです。
Docker imageを使うときは、内部Docker registryにDocker pushしてからデプロイする形になるようですね。

いずれにせよ、使い方は大きく変わらないように見えます。

OpenShift v3の使い勝手

一方OpenShift v3はデプロイ方法がかなり特徴的です。Kubernetesと同じように、「どんな構成のアプリにするか」を記載したjsonやymlを作成し、それを専用CLIで指定するとデプロイされる・・・という仕組みです。

たとえば、GitHubにあるサンプルアプリだとこんな感じです

application-template-stibuild.json

・・・アプリケーションを構築する前に、このJSONファイルを作成する大きな仕事が必要になりそうですね。
一方、このJSONひとつで「どういうコンテナをどういう形でデプロイし、それらはどういう形で接続されるか」といった、アプリケーションを構築する要素すべてを定義することができます。

いつ出てくるの?

現在でも、Deis v1系の開発は進んでいます。これを執筆している時点でのバージョンは 1.12.1ですが、1.13, 1.14のリリースが予定されています。

Deis v2については、最初のalphaリリースが今年末に予定されているようです。

メタ勉強会でLTしました

先日、GREEさんところで開催されたメタ勉強会 #metabenkyokai に参加してLTしてきました。

そのときのスライドがこちら。

たまたま @iwashi86 さんが発表するというのをみかけて、じゃあ僕もなにか発表してみようということで飛び込んでみました。

iwashiさんはiwashiさんの部署で活発に社内勉強会を開いていて、僕もなんどか参加しています。
僕は僕で、あまり頻繁にはやれていないけども社内勉強会にトライしていたので、今回はiwashiさんの発表をもうちょっと膨らませる感じで、社内だけでなくグループ会社に広げるにはどうすれば?というテーマで発表しました。

スライドを見て頂いたら分かるように、結局一番大切なことは、横の繋がりを強めていくという点につきるんですよね。それが出来て初めて勉強会を広めていくことができる。横の繋がりができれば、あとは普通の社内勉強会と同じような感覚で開催出来るんじゃないかなと思っています。

今回の勉強会では、3名のセッション+4名のLTがあったわけですが、会社規模の大小を問わず同じ課題、同じ悩みを抱えていることが分かりました。

  • 勉強会開催するも続かない問題
    • 発表資料作るのに時間かかりすぎ
    • どうしても本業を優先しなければいけないので開催出来るとは限らない
    • 発表者が特定の人に偏る、もしくは発表者が居ない

などなど。

主催者はどうしても負担がかかることを覚悟しないと社内勉強会は難しい。しかしながら、負担がかかるのを放置し続けると、結局続かないという結果に陥ってしまうため

  • あまり気合いを入れすぎない
  • たとえば輪読会やもくもく会のように、主催者や発表者に負担がかからない仕組みをうまく取り入れる
  • 昼休みの時間をうまく活用する

などの解決策が提示されていました。
共通の悩みを抱えているということは、共通の解決方法を試みることで良くしていくこともできそうです。
このあたりを実践して、次に機会があったときは勉強会の改善っぷりを報告してみたいですね。

復活しました

ちょっとサーバー環境周りの見直しをしていたところ、色々手違いがあり過去のBlogを消してしまいました・・・。

以前のサーバーの構成を思い出しながら、テーマやら何やら設定をしてなんとか復活。
ただしデータは戻らず。やはりバックアップは大切ですね (:3 」∠ )

どうしても復活させておきたい記事は、Internet Archiveあたりから掘り出してこようかなと考えています。
あとは心機一転、また書きためていくしかないですね。

ということで、これからもよろしくお願いします。