ラベル

第5回 Jenkins勉強会に参加させていただきました

※ Blogを書いたのが時間が経ってからなことと、内容も浅くて申し訳ありませんので、末尾の「参考」のところに、皆さんのBlogやTogetterのリンクを掲載させていただきました。

より深い情報をお探しの方は、参考の部分をご参照下さい。皆さんのお探しの情報に、無事たどり着けますように…。

* * *

では、はじまり。

Jenkinsさんのお誕生月の２月。勉強会があるということで、家族の許可を得る前にダメ元で申込み…。 意外にも許可が下り、参加できる運びとなりました。
まずは家族の協力に感謝しつつ、感想程度になってしまいますが、まとめを書かせていただきます。

はじまり：

さぼてんさん（@cactumanさん)の司会でスタート。
アイスブレイクでは、Jenkinsを何年くらい使っているかとか、どんな言語で利用しているか、挙手でのアンケート。
会場に限って言うと、LL言語では、RubyよりもPythonを使っている方が多い感じでした。（compass関連のせいでしょうか）
ビルド/CIメインではないので、『シェルは…？』と心の中で呟いていたのですが、さすがにその問いは無しでした(^^;

1. 川口さん :  「DEV@cloud Jenkins-as-a-Serviceの舞台裏」

  • DEV@CloudのJenkinsホスティング / Jenkinsのマスターは1000+
  • EC2がベース。個別のJVMで起動、個別のOSユーザ権限でマスターを稼働。
  • マスターに関しては個別のJVM上で稼働させたほうが、隔離が楽になる。
    また、一台の計算機上にたくさんのインスタンスを作ることが可能。
20111221-1
  • サービスの性質上、一般のJenkins（OSSで利用できるもの）とは違う形でカスタマイズが必要。
  • マスター上ではビルドができないようにする、SMTPサーバやJENKINS_URL、ドメイン設定などは固定なので、ユーザが変更できないように独自プラグインで対応。
  • JENKINS_HOMEはEBS上に配置。
  • APサーバとしてはTomcatを利用。
  • Jenkinsの外の世界（サーバ構成管理、監視といった部分）は、Chefを利用。Rubyの構成管理システム。
  • Chefはレシピと呼ばれる設定ファイルを書いて使う。ただ、ちょっと敷居が高いかも。
  • ただ、Chefから設定を流し込んでセットアップしてスレーブを起動…というのは時間がかかりすぎるので、あらかじめセットアップしたスレーブをAMI化しておく。
  • Chefは敷居が高いので、Puppetというツールも利用。少しずつ使っていこう。
  • スレーブの割り当てはProvidoreを利用。こちらもJenkinsの外側にある。
  • EC2からのスレーブの割り当ては時間がかかる。EBSのマウントも時間がかかる。
  • Linuxコンテナ（LXC）の話 => OSレベルの仮想化を行い、単一のカーネルで動いているんだけど、仮想化の中の仮想化の中の、さらに仮想化という形でスレーブとして稼働。
  • Jenkinsのモニタリングの勘所。
    モニタすべきはヒープ。nagiosをっ使って監視。
  • トラブル切り分け、対応、データ取集に、Groovyスクリプトが有効。
  • Scriptlet2.0からダウンロードして、Groovy Pluginを使って実際の運用に活用。
    良いScriptが出来たら、みんなContributeしてね！
  • 野良Jenkins増えていませんか？
と、ここまでメモを拾いだしたのですが、理解できる頭が無かったので、苦し紛れにイラストを…。勝手ながら申し訳ありません(_ _)

* * *

※Chefの話が紹介されていたので、『CloudBeesには、執事とシェフがいます』なんて呟きがあったような気がします。

でも、川口さんも仰っていた、Chefは敷居が高い…という点。確かデブサミで、DeNAの岩永さんも、同じように仰っていました。（岩永さんの場合は、そこから自分でTouryoというPerlのツールを作られていました！）

なにやら敷居が高そうなのと、同じ構成のサーバを量産する必要が今のところないのですが、確かにJenkinsは複数立ってきそうな感じなので、酷い目に合わないうちから、すこしづつ構成管理を覚えるのもいいのかもしれません。

2. 早瀬さん@楽天 : 「楽天での"Continuous Delivery"読書会について」

20120221-3

わたしは純粋なCIは行っていませんが、Jenkinsを通して、最近、Continuous Delivery, Continuous Feedback という言葉を知りました。
自分の部署は、社内の統計情報を集計加工し、必要な部署へレポートを作成し、届けるという仕事も行っています。Deliveryという意味で、もしかしたら今の仕事に持ち込んで、展開すべき考え方なのかも…と思って、興味を持った本だったので、タイムリーなお話しでした。

以下、ぱらぱらとしたキーワードですが、書きとめたことを。
  • その年のJolt Awordとして選ばれた本をぽっくアップして読書会をしようとYammerで呼びかけ。（なんと楽天のYammerでは、書き込みは英語、というスタイルだとか！ほんとですか～、中の人？）
  • なぜかすでに Continuous Delivery をGETした社員2名より、読むことになった。
  • Forth Railway Bridge という、イギリスで有名な橋の写真を使っている。
  • 橋はずっとメンテナンスが必要になるものであり、大量生産できる部品を使い、最初からメンテンスが発生することを前提として作られている。
    『開発』も、最初からメンテナンスのことを考えて行うべき –> Continuous Deliveryの考え方に。
  • 人間は『生産的』なことをすべきであり、そのためには『自動化』が鍵。継続的改善のための、『速い』フィードバックを得ることが大事。
    ここで自動化、CIにつながり、楽天内でのJenkins勉強会も開催となる。
  • 読書会という社内に閉じたイベントではあったものの、その事を社外に発信していったことで、色々良い方向に進んで行った。
  • Jenkins入門の佐藤さんに来てもらって、社内でイベントを行った。
  • 外国人を積極的に採用している企業の例として、TVの取材申し込みがあり、英語での読書会を取り上げてもらえた。
楽天での読書会に関しては、よしおかさんの記事もありましたので、合わせてリンクを掲載させていただきます。
早瀬さんの講演中、横から、『はやくアルコール！』といった雰囲気を醸し出していた、よしおかさんでした…。

3. 加藤さん@mixi : 「mixi における Jenkins の運用について」

いきなりの英語の自己紹介からスタート！ 楽天様の英語の件は有名ですが、『mixi様も英語Onlyか～？』と、半分泣きそうになりましたが、本題は日本語で展開して下さいました(^^;

20120221-4

こちらも、ぱらぱらとしたキーワードですが、書きとめたことを。
  • ご自身は、「たんぽ」チームに所属。このチームは、『単純な、つまらない、簡単な仕事を無くす』のがミッションだ、とのこと。（ただ、これが『○○しましょう』みたいな標語、キャンペーンを展開するのではなく、本当に技術を駆使して自動化、効率化を図るお仕事です）
  • LL言語のケースでは、ビルドよりも『テストを通す』ことがメイン。
    構文チェック、単体テスト～インテグレーションテストはもちろん、テストのカバレッジ、構文チェック、メトリクス計測といった点にフォーカス。
  • mixiでのJenkinsマスターノードは3台。iOS, Android向け　-> いわゆるBuild用。
  • mixiの（純粋な昔からの）サーバサイドはPerlがメイン。ビルドの必要のないLL言語だが、Jenkinsはたくさん使っている。 今回のお話は、Perl + Jenkins がメイン。
  • 分散してビルドするのではなく、マシンパワーの強いマスタ１本でテストを通す。（1時間～30分くらいでおわっちゃうらしい）
  • それでも長いので、recent job として、コミットした部分に関係するテストだけする、といった工夫もしている。
  • それも早く通して結果を確認するのが大事なので、テストサーバはVMじゃなく実機。（24コアとか） DBもローカルに持ったりしてテスト結果が早く判るようにしている。
  • ビルド結果はIRCで。最初はプラグインを使っていたが、メッセージをカスタマイズしたいので、Ikachanという仕組みを使っている。IkachanのhttpのエンドポイントにPOSTすれば、IRCへの通知を行ってくれる。
  • JenkinsはhttpのAPIがたくさんあるので、JavaやGroovyではない言語からでも利用しやすい。ここはとても好き。
  • レガシーコードであってもCIを。
    ただし、ただテストすれば良いというものではない。意味のあるテストをしよう。
Perl＋Jenkinsという組み合わせでのお話しは、とても新鮮でした。

紹介されていたPerlモジュールなどは、加藤さんご本人のBlogに記載してあるので、そちらをご覧いただいたほうが間違いがありませんので、下記の参考情報をどうぞ。

Perlはサーバの管理やテキストのちょっとした処理のためにちょこちょこ使って覚えていきました。
でも、テストコードを書く方法知らなかったので、これは今更申し訳ないですが、自分でもっと調べたいと思える内容でした。
Perlを始め、LL言語でのCIという方向でなら、今の環境でも勉強して少しづつ取り入れることが出来そうなので、これからのテーマにしていこうと思います。 そう思えた意味で、とてもためになったお話しでした！

LT. コ 文婷さん、胡 益さん＠東大笹田研 : 「Smart Jenkins on Ruby」

Smart Jenkinsとは、昨年の電力不足 / 節電の影響でビルドできる時間が制限されてしまった、という難局から生み出された技術・プラグインです。
このLTで初めて知ったのですが、なるほど、電力事情が戻って来た今でも、応用できそうです。
上記のプラグイン自体はJavaのコードですが、さらに、こちらをRubyで書くということまで展開したとのこと。
ただ、質疑の中で、どうしてもJenkins本来のJavaのコードを呼び出す必要があるので、JRubyの方言みたいなものを使っています、とお話しされていました。

ちょうど当日の昼に、WEB+DB Pressの最新号を買っていて、ななめ読みした時に、『Rubyでプラグインが書けます』というコラムを発見。 ビルドに関しては無理そうですが、UIをカスタマイズする部分で、何かプラグイン書いてみたいな～と思っていたので、JavaではなくRubyで書けるというのは、とてもモチベーションが上るお話しでした。

なによりも、「逆境を転じて、その逆境をさえ、前進の一歩に加えて行く」という姿勢が素晴らしいと感じました。

ビアバッシュ：

自分の会社でも、内部での勉強会や技術報告会のようなものがあり、時間的に19時を超す場合は、ビアバッシュを開催していたりします。でも、わたしは時間制限で、自社のビアバッシュには参加したことがありません。

どういうわけか、外部のビアバッシュが最初になりました(^^;

ケータリング、飲み物の調達、テーブルのセッティングなどなど、楽天の皆さんが会の進行の間に、さりげなく行って下さっていました。（そしてビールは楽天様からのご提供！）

生来うまくお話しするのが苦手なのと、開発現場にいる人間ではないので、お話しできるネタもなく、なかなかお声掛けすることができず..。フォローさせていただいている方も数名いらっしゃるはずなのですが、そこまでたどり着けず。

それでも、お話しして下さった方、有難うございました！

まとめ：

まずは、スタッフの皆様、会を支えて下さった楽天の皆様、本当に有難うございました！ 久しぶりの夜のイベントで、また皆さんからのパワーを頂くことができました。
いつまでも『参加』という立場もどうかな…、いつかは何か（失敗しかないんだけど）お話ししてみたいなあ、と思うこのごろ。でも、発表者の皆さんの前に、やっぱりひるんでしまうのでした。

なかなか今後こうした会に参加できるかどうかは、先が見えてこないのですが、イラストネタ（？）とか、自分のできる方向で、自分が楽しんでいることや、とても助かっていることを、周りに伝えていけるようにしていこうと考えています。

最後に、ちょっとだけ笑わせてもらった一コマ。講演中、スライドとデモ（ブラウザ）の切り替えで、ちょっとMacの扱いに戸惑う川口さんでした。
20120221-2

参考:

ブログ / まとめ
技術 / サービス
プラグイン / スクリプト集
Jenkins Week関連
スピーカー資料
ラベル:

コメント

コメントを投稿

人気の投稿