Jenkins ユーザ・カンファレンス 2015 東京に行ってきた
今日はJenkinsのユーザカンファレンスに行ってきました。2012のときにも行ったのですが、約2年半ぶりですね。場所は前回同様、法政大学でした。とりあえず業務でもJenkinsを使っていますが、ここまで使いこなしていないな−と思う内容が多くて勉強になりました。特に今回はInfrastructure as a Codeとして、ChefやPuppetを使ったインフラ面でもCIをやろうという内容が多かったように思います。とりあえず参加したセッションのメモ。
セッション一覧: http://build-shokunin.org/juc2015/sessions/
基調講演 Jenkinsプロジェクトの現状とワークフロー
川口さんの基調講演!のはずが会場につくとすでに始まっている!Compassの開始時間が13:00からになっていたんですが、これが間違いで本当は12:15からだったよう。。前半を聞き逃すという痛恨のミス。セッション一覧のページをちゃんと見ておくべきだった。。
とはいえ、後半のワークフロープラグインに関するところは聞けたのでよしとする。Build Pipelineをもっと簡潔に、使いやすくできるような印象だった。JP1のジョブフローのような感覚で使えるようになれば、より便利だし、いろいろ使ってみたい。
以下、メモ書き。
ワークフロープラグイン
ワークフローをより簡単に管理できるようになる。
これまではビルドとかテストとか1つだけの目的でジョブを作られていた。
現在は、自動化のニーズが高まり、ビルドやテストの自動化をつなぎたい。
具体的なニーズは以下。
- 一時サーバ活用
- 青緑デプロイメント + 自動コミット・アボート
- テストの並列実行
そのニーズに応えるために、ワークフローに求められる要件は以下。
- 制御構造・ループ
- 再起動をまたぐ長時間ビルドのサポート
- 中断、確認、分岐などの人間との対話
- 途中からの再開
- ジョブ間・組織間の処理の再利用。似たようなジョブが増えがちで、コードを共通化して再利用したい。
ワークフロープラグインのまとめ
- 複雑な活動を簡潔に記述
- 1つのジョブで全て表現
- GroovyによるDSL
- JVMのロスや再起動に耐えるデザイン
- 拡張性
githubリポジトリ
http://github.com/jenkinsci/workflow-plugin
JenkinsとSeleniumの活用事例:試験自動化のプロジェクトへの導入
NTTコミュニケーションズの方の発表ということで、エンタープライズ寄りのプロジェクトと思われる。SeleniumとJenkinsを組み合わせたWebアプリのブラウザによるテストを自動化しているとのこと。本ブログでも以前にJUnit・antと連携してSeleniumテストをJenkinsから実行する記事を書いたが、こちらはseleniumコマンドを直接たたいていたようでその方が簡単な気もする。
以下、メモ。
自動化の背景
とある開発プロジェクト。Ajail + Waterfall的なプラットフォーム開発。
DEV(単体) -> QA(結合) -> STG(受入・順本番) -> PROD(最終・本番)
WebアプリのUAT担当
試験項目はイテレーションごとに増加してしまう。最初は100項目だったものが2000項目に増える。
品質 = スコープ*時間*リソースの中でどうやって品質を上げるか。
自動化への期待:
単純作業、繰り返し作業を自動化し、効率的な試験実施、開発後も使えるテスト。リリース後も使える。
Seleniumの導入
Selenium Suiteはいろいろある。現在の主流は以下の3パターンある。
- Selenium 1 / Selenium RC : 初期のSelenium
- Selenium 2 / Selenium WebDriver : GoogleのWebDriverと統合。今はこれが多い。
=> JavaやRubyでテストコードを記述。複数ブラウザに対応
- Selenium IDE / Selenium Builder : Firefoxプラグイン。WebDriverと親和性が高いのはBuilder。IDEで作った場合はUIベースでテスト管理。
=> Firefoxプラグインで操作を記録・再生、Firefox限定
Webブラウザ操作は、要素(HTML)*コマンドの組合せでまとめる。
要素とは、 id, name, CSSセレクタ, XPathなど。Firebug + FirepathでXPathの検証もできる
コマンドは、click, wait, verify/asset(特定の文字列が存在するか検証), store(値を格納), type(文字列を記述, 検索するときなど)
IDE作成のポイント:
- 初期設定: 変数(store)、実行速度(setSpeed)
- 要素指定: id > name > CSSセレクタ > XPathの順に使うとよい
- コマンド: ページ読み込み(pause), スクリーンショット(captureEntirePageScreenshot)
- JavaScript: 入力データ生成や値の加工, storedVars[‘order’].substring(9,14)
テストケースの作成(WebDriver): フレームワークと組み合わせる。例えば、
- COCUMBER: Rubyの受け入れテストのフレームワーク
- Gherkin書式でかける
- Rubyのラッパー: capybara
実行環境:
最初はローカルPC
プロジェクトが進むにつれ、チームでの試験環境
=> VM上でテストケースを作り、gitでコード管理
VM移行時:
- Selenium用のFirefoxプロファイル作成は以下のコマンドで作成できる。
$ firefox -ProfileManager -no-remote
- Selenium実行時の画面確認
仮想ディスプレイ: Xvfb, VNC: X11VNC+ SSHトンネルでセキュアに接続(Xvfbをリアルタイムに見れる)
- Selenium Serverの利用
実行環境
Jenkinsの導入:
- 同じVMにJenkinsを入れジョブでSeleniumのテストケースを実行
- Jobの登録
Seleniumhq Pluginもしくはシェルで実行
- 実行結果
Selenium HTML Report Plugin: 結果ファイルを適切に表示
- その他便利なプラグイン
- Build Pipeline Plugin: 複数Jobの連携可視化
- Email Extension Plugin: SMTPを指定するとメールとばせる
- Text Finder Plugin: 特定のキーワードを指定し、それを検索してアクションを定義できる
- Xvfb Plugin: xvfbを起動
- Emotional Jenkins Plugin: Jenkinsの顔がかわる
画像比較:
- image magicのcompareコマンド
- 画面ショットを比較する
導入成果と課題:
- 基本機能は1日でテスト可能
- レポート作成コスト減少
- サービスレベルのモニタリングにも流用
運用フェーズにおいても継続した取り組み:
- テストケースも保守しなければすぐに陳腐化する
- 学習コストが高い?
試験以外のJenkins活用法:
- サーバのパッチ動作検証
環境構築、アプリデプロイ、テストをパッチ適用前後でテスト
- SkyWay
開発環境構築
JenkinsとPuppet+ServerspecでインフラCI
GMOペパボ(ロリポップの会社)のサーバ管理をPuppetでサーバ構築コードを書き、Serverspecでテストし、インフラCIをやるという話。
インフラ構成管理の改善
http://gihyo.jp/dev/feature/01/webservice-guide/0004
Puppet
構成管理ツール。インフラをコード化。マニフェストという。
全サーバをコード化し、機能追加の大幅に楽になった。
マニフェストのチェック
- マニフェストの構文エラー
- 仕様どおりにサービスは稼働しているか => ここだけ目視!課題! => serverspecによるマニフェストテスト
- Nagiosの監視が通るか
Serverspec
サーバの状態を簡潔なコードで記述してテストができる。RSpecで記載する。
例:
- ディストリビューションのバージョンアップする。
- Puppetで設定が収束。サーバの状態、仕様をコード化しServerspecで記述。
- 新旧、両方でテストが通ること。
Jenkins
Puppetマニフェスト、Serverspecテストコミット時にJenkinsが自動テスト
Jenkinsはポーリング
- Jenkinsジョブにて、VagrantでVM作成 -> Puppetでサーバ構築 -> Serverspecでテスト -> VM削除
- Dockerの方が軽量でCI向きだが、おり実機環境に近いVirtualBoxの完全仮想化なVMの方が都合がよい。
・CIサーバのスペック
テストに時間がかかる。1VM作ってテストするのに数分くらい。
「Infrastructure as a CodeにおけるJenkinsの役割」 〜環境構築も継続的インテグレーションを行う時代です〜
こちらはChefでインフラCIをする話。サーバ構築を4レイヤーに分けてChefコードやJenkins連携を構築するという点で、洗練されたモデルだと思った。また、JenkinsとSerfをうまく連携させるところが肝のようで、そのほかにもGlusterFSなど興味深い技術を多く連携させてインフラ群を整備していたところが印象的だった。
以下、メモ。
サーバ構築自動化
・Chef Server導入
サーバ情報 -> Wikiで管理。Wikiが更新されないという問題がある。また、複数クラウドに対応したい。
・Chefが全体制御していたことの問題
Chefのレシピが複雑化
- Cookbook同士が疎結合になっていない
Chef Serverとの接続エラー
=> 同時接続数が問題になった。
Chefの実行ログを追跡しづらい。
・対応
Chefの役割を明確にし、サーバ構築を単純化
サーバ構築の概念
Provisioning Toolchainという概念。
サーバプロビジョニングをレイヤー化し、レイヤーごとに役割を定義。レイヤーは以下4レイヤーがある。
1. Bootstrapping
- OSのプロビジョニングのレイヤー
- OSのインストールとサーバ起動のみ行う
- AWSなどクラウドの領域
2. Configuration
- システム構成のプロビジョニングのレイヤー
- ミドルウェアのセットアップ、サーバ単体で完結するような処理を行う
- Chef, Puppetの領域
3. Orchestration
- アプリケーションのプロビジョニングのレイヤー
- クラスタ追加やJenkinsからのソースコードデプロイまでを行う
- デプロイツールの領域
4. Releasalization(造語) : 発表者が独自に定義したレイヤー
- サービス提供のプロビジョニングのレイヤー
- サーバテストを実施し、問題のないサーバのみを本番環境に投入する
- Serverspecの領域
Jenkinsの役割
これまでは、ソースコードのデプロイ、UnitTestのCIのデプロイ管理のみだった。
現在はサーバ構築の自動化管理もやっている。これまでChefが全体制御をやっていたが、Jenkinsに寄せた。
Build Flow Plugin
ビルドフローを定義できる。Build Graphで構築フローを視覚化するとなおよい。
各レイヤーの実装方法
1. Bootstrapping
- Kickstartの内容を実行しイメージ化
- OSインストール、ディスクパーティション、ネットワーク、管理ユーザ作成
ポイントは物理/クラウドを意識せずやる。Chefが実行できる状態を目指し、余計なことはしない。
2. Configuration
- Jenkins + Chef
- Chef Soloでやる。
Jenkinsから対象サーバに対してknife solo実行する。
3. Orchestration
- Jenkins + Serf
- Serf: イベントを受けて、それぞれのノードでやりたいことをする
- Jenkins: サーバのSerfクラスタ参加イベントを検知して、オーケストレーション処理イベントを発火
Serfとは?
- Go言語製のオーケストレーションツール
- メンバシップ、障害検知と復旧、カスタムイベント伝播
- ゴシッププロトコル
- GlusterFSでのクラスタ管理に利用
4. Releasalization
- Orchestrationの内容をServerspecでテスト
- 全Build Flowが成功したサーバのみを本番環境に投入する
Chefの開発方法
■これまで
Cookbook作成 -> レシピ開発 -> (Chef Serverに登録) -> EC2やVagrantでインスタンス起動 -> Chef実行 -> Githubにpush
■これから
Dockerを使う。
DockerとChef Zeroをインストール。AWS EC2やローカルPCにインストール。
- > Chefのテスト駆動開発ができる。
JenkinsでChef CI
Chefは実行するロールを決める必要があり、それをJenkinsが指定する必要がある。
=> Branch名とRoleをひもづける
Jenkinsの冗長化
Jenkinsの冗長構成
- 2台用意して、アクティブ・スタンバイ
- アクティブが死んだら、serfを通じてスタンバイ側に通知、IPアドレスをスタンバイ側に振り直す。
Serfの検知・伝播力が高い。100台クラスタでも2秒程度。
データの同期はlsyncd。GlusterFSだとプラグインが一部読めなかった。
Serfがすごい
- バイナリを置くだけで使える
- やれることが柔軟で設定もシンプル
- TagsとQueryの万能感
- SSH経由でサーバにログインするのではなく、Serf経由でサーバ間のイベントを検知するように
LT
Jenkinsを使った継続的Webセキュリティテスト
■セキュリティテスト
1. 外部の診断会会社にセキュリティ診断
2. 修正 -> リリース
継続的なセキュリティテストが理想
開発 -> 単テ -> 結合テスト -> セキュリティテスト
vaddy : CIに組み込めるセキュリティ検査サービス
http://vaddy.net
無料プランでできること:
- SQLインジェクション、XSSをチェック
- Jenkinsプラグイン
JenkinsからVaddyテストをフック
Jenkinsおじさん、お堅いメガバンクに就職
SVN -> Jenkins -> Sonar -> Maven -> 開発2号機・リグレ環境・順本番にデプロイ
資源配布まで。そこから先は有償デプロイ製品。金融業界なのでミスは絶対に許されない。Jenkinsで手堅いデプロイ管理をする。
Jenkinsおじさんと楽しい連携ツールたち
Jenkinsと組み合わせることで有用なツールたち。
- Slack: チャットアプリ。Jenkinsのビルド結果の通知を行う。Jenkins Slack Pluginで連携。
- GItlab: GitHubのクローン。無料で使える。Gitlab Merge Request Builder Plugin。MergeRequestはPull Requestとほぼ同じ。
- deploygate: iOS/Androidアプリのテスト版アプリの配信ができる。gradle-deploygate-plugin。アプリに対して任意のメッセージを付与できる。
ゲーム業界の人がJenkinsさん3Dモデルで遊んでみた
ゲームエンジンUnityで3D空間にJenkinsおじさんの3Dモデルを表示。Jenkinsおじさんの3Dモデルが降ってきては爆発しては、ジョブ以上終了時に赤くなって回ってました(笑)
CI”じゃない方”のJenkins
JenkinsでできるCI以外のこと。管理画面として使う。
- バッチを実行
- ssh loginしなくていい。scpしなくていい。cronよりいい。
- スロークエリの集計や解析
- APIがあればJenkinsからコントロールできる
- 負荷テストツール
- Jmeterと連携。インストール済みamiを、インスタンス複数実行
まとめ
ということで、Jenkinsのいろいろな有効な活用法をいろいろ知ることができました。やはりインフラ系のCIは最近のはやりでもあり、機会があればやってみたいですね。
補足(セッション中にでてきた技術・ツール)
- Groovy
- Selenium
- Selenium IDE
- Selenium Builder
- Serverspec
- Puppet
- Chef
- Chef Zero
- Docker
- Kickstart
- Serf
- lsyncd
- GlusterFS
- Jenskinsプラグイン
- Workflow plugin
- Build pipeline plugin