weblog of key_amb

主にIT関連の技術メモ

Ginza.rb で "grifork" について発表してきた

10/18(火)に、第40回の Ginza.rb に参加してきました。

初参加でしたが、今回は他にも初参加の方が8名ほど(?)いらしていたようです。

Ginza.rb では、毎回、別々のテーマについて会を催しているようです。
今回は「自分でつくったものを見せてみよう」というテーマでした。

約17名*1の参加者中、ほぼ全員が発表者だったため、1人あたりの発表時間が4分ほどになりました。
LT より短いレベルですね^^;

私は、前記事で紹介した "grifork" について発表してきました。
下がそのスライドです。

だいたい前の記事で紹介した内容の通りですが、v0.2 〜 v0.5 のアップデートについても触れています。
この場でも、かんたんに述べておきます:

  • v0.3 gem 化しました。 https://rubygems.org/gems/grifork
  • v0.4 Parallel, ssh, rsync のオプションを DSL でカスタマイズできるようにしました。
  • v0.5 prepare, finish という構文でジョブの最初と最後に実行するタスクを記述できるようにしました。

発表後、Twitterハッシュタグを見ていたところ、質問らしいツイートがありました。

ごもっともな質問です。
今はある意味、「何もしてない」のですが、エラーがあったらそこでジョブ全体が異常終了するようになってます。

経験上、あるノードでデプロイが止まる場合、そのノードが異常な状態であることが多いと思います。
ので、その場合、そのノードを取り除いて再デプロイする、というのがよくある運用手順になるかな、と思います。*2

grifork の仕組みとして、リトライを入れたり、異常ノードを正常ノードと入れ替えてなるべく多くのノードに対してタスクが完了するように仕向ける、といった実装も可能とは思いますが、その辺りは要望があったら考えようかなぁ、というところです。
何かご意見などありましたら、 GitHub Issue でも Twitter でもお気軽にお寄せ下さい。

自分以外の発表について

一部 Ruby じゃなかったりもあった気がしますが、発表された成果物がバリエーションに富んでいて、刺激を受けました。

特に @joker1007 さん作のものには、ふだんお世話になっているものもありそうです。
rukawa というワークフローエンジンがなぜ rukawa なのか気になりましたが、ちょっと風邪気味だったので懇親会は遠慮しました。

Ginza.rb について

自分がこれまで参加してきた技術系の勉強会は、メインパートが「発表( + LT + 質疑)」で、その後、懇親会という流れのものが多かったです。
が、Ginza.rb は前の回の振り返りや次回内容の検討があって、新鮮でした。

またの機会がありましたら、よろしくお願いします。

ありがとうございました!

*1:エントリーしていた方は、見たところほぼ全員出席していたと思います

*2:Twitter でも同じように回答しました。