Skip to content

Instantly share code, notes, and snippets.

@ohtake
Last active August 29, 2015 14:13
Show Gist options
  • Save ohtake/3662c1e12342bcee93c6 to your computer and use it in GitHub Desktop.
Save ohtake/3662c1e12342bcee93c6 to your computer and use it in GitHub Desktop.
2015 新春 JJUG 特別企画 Jenkins まつり

2015 新春 JJUG 特別企画 Jenkins まつり

Javaユーザに贈るJenkins 25のTips

Jenkins にはプラグインが多数あり、使い方にも癖があったりするので、tips を紹介することで、ユーザにとっての障害を取り除くことができる内容になっていた。

自分が使ったことがないのは 3 の Gradle プラグイン、11 の Nested View プラグイン、18 の Xvfb プラグイン、21 の Workflow プラグイン。Workflow プラグインは出たばかりではあるが、活用の幅が広そうなプラグインなので試してみたいところ。

会場にいる人で日曜の JUC 2015 に参加した人は3割くらい。1月16日にSIerを退職して別の会社に行く。TシャツのCloudBeesではない。@shawoda の別名もあり、それを公に発表するのはここが初めて。

  1. Gitプラグイン: Validated Merge プラグインも便利。Jenkins Enterprise でしか使えないが。
  2. GitHub プラグイン
  3. Gradle プラグイン: Gradle のインストールやOS差分吸収をしてくれる。
  4. CheckStyle プラグイン
  5. FindBugs プラグイン
  6. TaskScanner プラグイン
  7. JobConfigHistory プラグイン
  8. Timestamper プラグイン
  9. Emotional Jenkins プラグイン: Chuck Norris プラグインもある。
  10. Green Balls プラグイン
  11. Nested View プラグイン
  12. RSpec などでも JUnit 形式にすれば JUnit として表示できる
  13. マルチ構成プロジェクト
  14. パンくずメニューの三角形を押すとショートカットが出る
  15. ビルド中のプログレスバーをクリックするとコンソール出力に飛べる
  16. /safeRestart にアクセスすると Jenkins を再起動できる
  17. Deploy プラグイン
  18. Xvfb プラグイン
  19. Build Pipeline View プラグイン
  20. Promoted Builds プラグイン
  21. Workflow プラグイン: Groovy DSL でジョブを記述する。
  22. Slack プラグイン: 会場にいる人で Slack を使っている人は1割未満。Slack はすごい IRC みたいなもの。
  23. Email-ext プラグイン
  24. Disk Usage プラグイン: 設定もなしに可視化できるので、使っている感が出る。
  25. Monitoring プラグイン

宣伝。Jenkins 実践入門の改訂版に取りかかっている最中。

発表者から川口さんに質問。なぜ Jenkins のボールは青いのか。回答は、日本では青信号で青のイメージがあるから。日本人が緑にしろと言ったらデフォルトを緑に変える。

継続的インテグレーションから継続的デリバリーへ

Jenkins で継続的インテグレーションを行い、その先のデリバリーを UrbanCode で行うという内容。両者のツールは適用領域が異なり、考え方も異なるため、連携を行うことが可能である。なぜか TeamConcert の宣伝はなかった。

Rational の部署で開発製品を担当している。日本では Jenkins のシェアが高く、それを使ってエンタープライズアプリケーションを開発するにはどうすればよいかを紹介する。

ツールの共有は難しい。開発部門と運用部門の想いが異なるため。開発部門はスピードを重視し、運用部門は手順や検証を重視する。そのため DevOps や究極的には NoOps に向かおうとしている。

リリースとデプロイの例。開発部門が開発物とリリース手順書を作り、運用担当が手順を実行し、確認担当者がチェックリストに従って確認を行う。

見ているお客さんの中で Jenkins を使っているのは2割もいない。ビルドやテストのような継続的インテグレーションを Jenkins に行わせ、品質ゲートを通して実環境へのデプロイを IBM UrbanCode にやらせる。UrbanCode ではGUIでリリース手順の定義を行い、プッシュボタンを押すことで実行できる。プラグインによりメインフレームへのデプロイなどのニッチなものもある。特徴的なことは本番環境やステージング環境ごとにどのバージョンがデプロイされているのかを確認できる画面があり、運用的な側面もある。

デモ。古いが JPetStore を使う。UrbanCode のサンプルアプリケーションも JpetStore。統合環境には JPetStore 1.1 が入っていて、ステージング環境には 1.0 が入っている。1.1 をステージングにデプロイしようとしても、品質ゲートを通らずにエラーになる。デモ環境のVMが落ちたのでデモ中止。

Jenkin IBM UrbanCode
オープンソース 商用製品
ビルドに焦点 リソースに焦点
開発者視点 開発者と運用者視点
ビルド単位の権限 ターゲット環境単位の権限
継続的インテグレーション 継続的デリバリー

両者は適用領域が異なり、連携が可能である。UrbanCode には評価版もあるので試してほしい。

Chef/Puppet + Jenkinsによる継続的デリバリ

Jenkins のインフラにおける CD の取り組みを具体的に紹介していた。CD に使っている洗練されたコードも公開されているので、まねできるところはまねしていきたい。

会社の紹介。CloudBees で CTO をやっており、Jenkins Enterprise や Jenkins Operations Center などを開発している。主にアメリカとヨーロッパでビジネスをしていて、日本にも広めていきたい。

背景。jenkins-ci.org の運用上のニーズ。テスト環境がなく、システム管理者が地理的に分散している。

4-5年前から puppet を定期的に実行するようになった。Puppet 社の人を一週間呼んでみてもらった。Puppet 社にとってもモデルケースを作るというメリットがあった。前半ではそれを紹介する。

個々のサービスのコンテナ化。サービスごとにマシンを立てるような富豪的なことができず複雑な構成になっていた。まずはコンテナ化をすることで簡略化することから始めた。

プロファイルとマニフェストで環境を定義しておき、どのマシンでどのサービスを動かすかを簡単に動かせられる。

プルリクエストの表面上の検証は rspec-puppet。実際に動くかのテストは Vagrant で EC2 に一時サーバを作りデプロイをして serverspec を実行する。

ありきたりなことなので3行くらいでできてほしいが、実際には60行くらいも Vagrant file を書く必要があった。Puppet 社の手助けがなければすぐに60行も書けなかっただろう。

r10k という puppet のツールを使うと、Git ブランチと環境が対応付けられる。

鍵などの秘密の取り扱いが難しい。ソースコードを全世界に公開しているので、レポジトリに秘密をそのまま書くわけにはいかない。ソースを出さないエンタープライズでも似たような状況にあるだろう。現状では hiera-eyaml を使うことにしている。エディタを使うマシンに AES の鍵を置いておき、エディタで編集するときは秘密の箇所が複合された状態で編集でき、保存をするとその箇所が暗号化される。

インフラのコードは https://github.com/jenkins-infra にある。

継続的デリバリの課題としては、デプロイがいつ起こったのかがはっきりしないこと。Chef や Puppet の実行は非同期で、プルリクエストがマージされた時間とは異なる。サーバでどのビルドが動いているかもわからない。仮にわかればスタックトレースからソースコードに正確にマッピングできる。

ファイルフィンガープリントは Jenkins に昔から備わっている機能で、アーティファクトの MD5 を使っている。バイナリファイルは作られるたびにハッシュ値が異なる。ジョブの依存や設定に関係なく単純な仕組みでトレーサビリティが実現できている。

デモ。先ほどの PetStore よりも古い Maven のアプリ。Maven プロジェクトではフィンガープリントの設定をしなくても勝手にとってくれる。ビルド後には Artifactory に転送して運用者に任せるようになっている。運用者は運用マシンで artifatory から war ファイルを wget でデプロイしている。デプロイ自体は Jenkins の外の世界で行われてしまっている。Puppet を走らせると Jenkins にレポートする。レポートにはファイルのハッシュ値も入って入り、トレーサビリティを実現できる。Promoted builds プラグインを使うと、デプロイされたバージョンのビルドジョブのランに星をつけることもできる。

Chef ではカスタムレポートハンドラで実装。Puppet では MD5 を取る仕組みがもとからあったため標準レポート形式のまま Jenkins に POST するだけ。今は Chef と Puppet にしか対応していないが、二つでできればほかのツールでもできるだろう。Ansible 向けなども可能なはず。

今後の予定は、さらなるデータの可視化、ファイルではないもののフィンガープリントを取ること、jenkins-ci.org の運用でもこれを使いたい。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment