1/11に開催されたJenkinsユーザ・カンファレンス2015に参加してきました。
参加したのは以下のセッション
- 基調講演 Jenkinsプロジェクトの現状とワークフロー
- はてなにおける継続的デプロイメントの現状とDockerの導入
- JenkinsとPuppet+ServerspecでインフラCI
- Jenkins導入する本当の理由を考えてみた
- LT大会
基調講演 Jenkinsプロジェクトの現状とワークフロー
- Jenkins Plugin1000突破
- 感覚的には中東の混沌としたバザール、色んなモノが雑多に置かれてる感じ
- 背景
- かつてのJenkins(CI)は１つのこと(テストならテスト、デプロイならデプロイ)だけが自動化できればよかった
- 最近はそれらを繋げて実行したくなってきている
- サポートしたい処理の特徴
- 多大な処理を含む複雑な(単純な線ではなく、条件分岐などがある)パイプライン
- 再起動をまたぐ長時間ビルドサポート
- 中断/確認/分岐などの人間との対話
- 一過性エラーなどに便利な途中からの再開
- ジョブ間・組織間の処理の再利用
- 一箇所で処理を完結に記述
- ざっくりと
- これまでも出来なくはなかったが、複雑でパズルのようになっていた。それを誰でも簡単に出来るようにしたい、という話
- 途中からの再開というのは偶発的なエラーのところから再実行できたりするようなもの
- 人間との対話は、ステリリース-(OKなら)->本番といった処理に使えそう
- つまり、期待大
所感
- 今はbuildflowプラグインを使っているが、workflowプラグインでもっと便利にできるかもしれない
- 要チェック
はてなにおける継続的デプロイメントの現状とDockerの導入
はてなのサービス開発とJenkins
- テスト実行、静的ファイル生成、デプロイなどでJenkins利用
- 昔はJenkins(Master/Slave)１組で複数のサービスを担当してたけど今は各サービスに対してJenkinsを用意してる
- サービス毎に求められる環境が異なる
- 関係者が多いとメンテが難しくなる <-僕も経験しましたｗ
なんのためのJenkinsか
- 一言で言ってしまえば 楽するため
- 開発を継続するためにはやらないといけないことが沢山あるのだけど面倒、面倒なことは続かない
- だから面倒事はJenkins、ということになる(はず)
- 特にテスト重要
- 開発担当者の環境≠本番環境な場合、本番(に近い)環境でテストを回すことは大切
- 局所的な変更だと開発者は全体のテスト回さない(かもしれない)からJenkinsで全テスト実行する
Jenkinsの管理
- 本番環境でも使うChefでJenkins環境を構築
- 本番環境と同等の環境が作れる
- 管理方針
- 複雑にしない、複雑なことはコードに落とす
- .travis.ymlのようなのをイメージ
- Jenkinsの設定で頑張ると、皆がJenkinsいじらないといけなくなるので不幸(バージョン管理とか難しいし)
スマホアプリとJenkins
- AndroidはGradleが標準になってやりやすくなった
ジャンプルーキーの開発プロセスとJenkins
- 発表者の@nobuokaさんが関わってるプロジェクト
- コード管理はGHE(GitHubEnterprise)で、ブランチモデルは大体A successful Git branching model
- ここでのJenkinsの利用
- Push毎にライブラリ更新、JSのminify、テスト実行
- Docker使って動作検証環境へデプロイ
Dockerコンテナによる確認環境とJenkins
- 開発した機能の確認が遅れると困りますよね、
- 障害とか、思ってたのと違う、とか
- 開発中に動作を確認できる環境は便利、開発中の環境を 気軽に 共有したい
- Jenkinsでやりました
- 例：https://${branchname}.dev.exmaple.com/ となるようにデプロイ
- 開発サーバ上にDockerコンテナをポート番号を変えて複数起動、ポート番号の解決はDockerAPI
- 開発サーバ上のNginx(Proxy)でサブドメインを解決
- 注意点：Dockerのイメージビルドはキャッシュ有効にしないととても時間がかかる、キャッシュが利くように工夫しないといけない
- 課題もある
- Dockerが散らかる、不要になったコンテナの破棄が面倒
小ネタ
- 複数環境起動させる場合は環境別にfavicon変えると便利
- Jenkinsでも複数用意する場合はUIいじって視覚的に区別できると間違いが少なくなってGOOD
質疑応答
- Q: テスト用のデータはどうしてるのか、スキーマ変更があった場合はどうするのか
- A: テスト用のデータセットを用意してる、(基本的には)スキーマ変更に耐えるデータにしてる
- Q: Pullreqのテストって話があったが、テストを実行する対象はマージ前/後どっち？
- A: 前
- twitterで指摘されてたけど、pullreqに対してマージ後のテストまで実行できるとGOOD [https://twitter.com/higebu/status/554146416797310976]
- Q: エンドツーエンドテストやってる？
- A: やってない。ブログチームはselenium使ってる(らしい)
所感
- 個人的にはDockerコンテナを使ってJenkinsスレーブを(動的に)作りたいなと思ってたので、そういった話ではなかったのは少し残念
- でも検証用環境をDocker使って用意するってのはそれはそれで意味があるので良い話でした、真似したい！
JenkinsとPuppet+ServerspecでインフラCI
- @tnmtさん、継続的Webサービス改善ガイド の著者の方
これまでの施策
- システム構成管理ツール(puppet)の導入
- 可読性の向上、作業品質の安定化(ヒューマンエラーからの開放)、追跡性向上
- Infrastructure as Code
Puppet
- 導入(マニフェスト作成?)は大変だが、用意ができてしますとその後の新規構築・機能追加がすごく楽になる
- 2013年当時はPuppet適用後に仕様通りにできてるかを目視で確認してた
- これをServerspecで自動化
Serverspec
-
アホ毛本 2015/01/17発売
-
インフラのTDDができるようになる
- Serverspecのテスト書いてからPuppetのマニフェスト書く
-
インフラのリグレッションテストができるようになる
- Puppetのマニフェストのリファクタリングが安心してできるようになる
-
活躍シーン：ディストリビューションのバージョンアップ、などなど
Jenkins
- Puppetのマニフェストの変更をポーリング、master(ブランチ)に変更があればPuppet適用してテスト実行
- 実行環境はVirtualBox+Vagrantで用意
- ここは多分何でもいい
- やってることは単純(Puppet実行+Serverspec実行)
コラム
- Docker使わないのか？
- 対象サービスによる。発表者の方の環境(heteml.jp)は実機に近いほうがいいので敢えて使ってない
- Dockerの方が軽量でCI向きではある(条件が合えばDockerのほうがよいと取れる)
- ハマったことは？
- vagrantの扱い
所感
- アプリ書くときにテスト書かないとか怖いので、その感覚がインフラにもやってきてるなといった印象
- PuppetとかChefで使うならServerspecは必須になるんじゃないでしょうか
Jenkins導入する本当の理由を考えてみた
どうやってJenkinsを使ってるか
デプロイ
- Jenkinsは設定に沢山書いてもりもり動かすことも出来る、けどそれはあんまり良くない
- 簡単に誰でも書き換えられちゃう(そして追跡が難しい)
- (コード管理的な意味で)Infrastracture as Code必要
テスト
- Seleniumでテスト、テスト環境が見れないと辛いときがあるのでVNC入れてる
バッチ
- Jenkinsだとログ管理しなくていいのでその点便利
- fluentdとかが流行ってて優れてるんだけど何かと大変ですよね、さくっと出来るJenkinsは便利
- モニタリング
- 新しいメンバーが追加された時などインフラの構成図などを見せるのもいいがserverspecの結果などを診てもらうのも理解が早い
サービス起動
- Capistranoを使うことで処理をまとめることができる、使わないとなると処理毎にジョブ用意するはめになりそう
なぜJenkinsを導入したのか
Operationの簡易化
- 極端な話、経験がない人でも運用できるようになるのでは
- でもジョブを用意してもそれが何をしているのかわからないと結局使ってもらえない
- =>使ってもらうための活動(手順書,README)
どうしてこんなこと(手順書とかREADMEとか)をするのだろう
- SPOF(単一障害点)をなくすため
- 自分のもってる知識・ツールを公開して皆が改修できるように
- Jenkinsが死んだ(落ちた)ときに代替手段を確保できるように
所感
- 作業の省力化(のI/F)としてJenkinsを利用するってのは共感
- ただ手順書とかREADMEなどを用意していくってのはコストかかるので、これが出来るかは組織(と人)によるのかなといった印象を受けました
- 利用頻度/必要性の高いツールに絞ってそれを皆で育てていくってが良さそう、それについては手順書とかREADME用意して
LT大会
Jenkinsを使った継続的Webセキュリティテスト
- VAddy
- 将来的にも無料でセキュリティスキャン提供予定らしい
- プラグイン提供されてるのでJenkinsとの連携は簡単
- 連携が簡単で無料で使えるとなれば試してみるしかないよね☆
Jenkinsおじさんお堅い金融系企業(メガバンク)に就職
- 最初は限られた範囲にだけ利用してたが便利なツールと認知されて広い範囲に利用されるようになった
- ただし、金融系は高い品質が求められるのでJenkinsだけではなく商用ソフトと並行して(ダブルチェックのため)利用されている
Jenkinsおじさんと楽しい連携ツールたち
- Jenkinsは単体でも便利だけど、他のツールと連携させるともっと便利ですよね！という話
- slack: プラグイン提供されてるので10分ほどで使えるようになった
- gitlab: githubでできることはだいたいできるみたい
- deploygate: これもプラグインがあるので連携は楽っぽい、(発表者の方が)proxy対応した
ゲーム業界の人がJenkinsさん3Dモデルで遊んでみた
- unity使ったデモ、カオスｗ
CIじゃないほうのJenkins
- バッジ処理などをJenkinsにやらせて、ログの集計などをさぼろうという話ｗ
- 過去のお仕事でJenkinsがメンバーのツール置き場と化して収拾つかなくなったのを思い出した、今ならうまくできるだろうか
まとめなど
- 使ってみたい
- workflow plugin
- Docker plugin
- VAddy
- Infrastracture as Codeみたいに、これまでは手順書だったりしたものをコードで管理するという考え方の広まりを感じた
- コードにすることのメリットはたくさんあると思う(可読性だったりメンテ性だったり、実際Githubなんかで管理できるってのは大きなメリットだと思う)
- コードに落とせると(Serverspecとかで)テストもできてCIの中に組み込めるのでGOODですよね！
- Jenkinsで実行するスクリプトもJenkinsに直に書くのではなく、ファイルに書いてリポジトリに置くのが流行ってるみたい
- 構成管理ツール、有名どころはChefとPuppet(ですよね？)なんだけどPuppet人気っぽい
- AWSで使うこと考えるとPuppetのほうがいいのかも http://www.slideshare.net/winebarrel/2013-0720-chefpuppet
- 皆が触るツール(ジョブ)にはちゃんと説明書こう
- 他の人(未来の自分)でも理解できるツールにしよう
- 法政大学の設備マジすごい