Jenkinsプラグイン探訪 - Favorite Plugin
はじめに
Jenkinsにジョブを登録していくと、ジョブを何らかの目的別に分類したくなってきます。例えば、「開発案件AAAに関するジョブたち」、「開発案件BBBに関するジョブたち」、「失敗ビルドに関するジョブたち」などに分類することが考えられます。
このような場合、Jenkinsでは新たなビューを作成して、そのビューに目的別に分類したジョブを所属させます。
ジョブの数が少ない場合やマメな人が多い場合は、新しいジョブを作成する方法で十分運用できます。しかし、目的別のビューを一つ一つ作成していくのは、結構退屈で地味に手間のかかる作業です。
そこで、この記事では、このような状況を改善するための一手段としてFavoriteプラグインを紹介したいと思います。
なお、このプラグインは、簡潔に述べると、
- ジョブを「お気に入り」に追加したり、
- ジョブを「お気に入り」から削除したりして、
- ビューに表示したいジョブを
- ビューを跨って(横断的に)
一括かつ動的に設定するための機能を提供します。
インストール
Favorite Pluginの名称と関連URLは次のとおりです。
- このプラグインを使用するためには、「アクセス制御」を有効にしておく必要があります。
(Jenkinsの操作権限をユーザ/グループ/ロール別に制御する参照) - プラグインのインストール/アップデート/無効化を参照して、プラグインをインストールしてください。
- 他のプラグインとの依存関係はありません。
- プラグイン以外にインストールするものもありません。
- インストールすると、「すべて」ビューに「Fav」欄が追加され、各ジョブの「Fav」欄に星印が表示されます。
機能概要
Favoriteプラグインの機能概要は次のとおりです。
- 「すべて」ビューに「Fav」欄を追加します。
- 「すべて」ビューの各ジョブの「Fav」欄に星印を表示します。
- 「すべて」ビュー以外のビューにも「Fav」欄を追加することができます。
- 星印を選択状態にすると、選択状態にしたジョブが「お気に入り」に追加されます。
- 星印を非選択状態にすると、非選択状態にしたジョブが「お気に入り」から削除されます。
- ビューに「Favorites Filter」を適用できるようになります。
- ビューに「Favorites Filter」を適用した場合、そのビューには「お気に入り」に設定されたジョブだけが表示されます。
機能詳細と注意事項
Favoriteプラグインの機能詳細は次のとおりです
- まず、「Favorites Filter」以外の「ジョブフィルター」の条件によって、ビューに表示されるジョブの集合が決定されます。
- 次に、最新の「お気に入り」設定の情報を用いて、ジョブの集合の中から表示するジョブが決定されます。
- 「お気に入り」設定を変更すると、ビューに表示されるジョブが動的に変化します。
- 「お気に入り」設定は、ユーザごとに記録されます。
- ビューに「Favorites Filter」を適用しなかった場合、そのビューは「お気に入り」の影響を受けません。
- 「Favorites Filter」が適用されているすべてのビューが、「お気に入り」設定の影響を受けます。
- 「Fav」欄の有無は、ジョブの表示/非表示には影響しません。
- その他は「機能概要」を参照してください。
注意事項は次のとおりです。
- 繰り返しになりますが、このプラグインを使用するためには、「アクセス制御」を有効にしておく必要があります。
利用のポイント
- ジョブの最適な分類方法について悩み始めたときに使うと良いでしょう。
- 注目したいジョブを頻繁に変えたい場合に有効です。
- 比較的ざっくりとジョブを分類した共有ビューをいくつか作成しておいて、各人に「お気に入り」を使って表示したいジョブを微調整してもらうと良いでしょう。
(目的別にデフォルトビューをいくつか作成しておいて、ユーザにデフォルトビューをカスタマイズしてもらう感覚です)
下図は、共通のジョブCMN_JOB2をもつ３つのビューからCMN_JOB2を削除した場合の様子を示しています。
Jenkinsプラグイン探訪 - Disk Usage
はじめに
ほとんどディスクを消費しないジョブもあれば、一度のビルドでかなりディスクを消費するジョブもあります。
「ギリギリだけど、なんとかなると思っていたら、ディスクフルになってしまった」、「いつもと違うノードが動いて、ディスクフルになってしまった」などといったことが発生するかもしれません。
そこで、この記事では、このような状況を改善するための一手段としてDisk Usageプラグインを紹介したいと思います。
なお、このプラグインは、簡潔に述べると、
を調査するための機能を提供します。
インストール
Disk Usage Pluginの名称と関連URLは次のとおりです。
- プラグインのインストール/アップデート/無効化を参照して、プラグインをインストールしてください。
- 他のプラグインとの依存関係はありません。
- プラグイン以外にインストールするものもありません。
- インストールすると、Jenkinsの管理ページに「Disk usage」メニューが追加されます。
- ディスク使用量をグラフ表示する必要がない場合は、プラグインのデフォルト設定を変更する必要はありません。
機能概要 (デフォルト状態)
Disk Usageプラグインの機能概要は次のとおりです。
- 360分ごとに全ジョブに対して、最新ビルドが実行されたノードの「workspaceディレクトリ」のディスク使用量を計測します。
- 360分ごとに全ジョブに対して、マスターノードの「buildsディレクトリ」のディスク使用量を計測します。
- Jenkinsの管理権限をもつユーザは、「Disk usage」メニューから「Disk usageの確認画面」を表示します。
- Jenkinsの管理権限をもつユーザは、手動で全ジョブの「workspaceディレクトリ」と「buildsディレクトリ」のディスク使用量の計測を開始することもできます。
- 「Disk usageの確認画面」には、最終計測時点の「workspaceディレクトリ」と「buildsディレクトリ」のディスク使用量が表示されます。
- 「各ジョブのページ」にも、最終計測時点の「workspaceディレクトリ」と「buildsディレクトリ」のディスク使用量が表示されます。
- 「各ジョブのビルド履歴」には、「buildsディレクトリ」内の各ビルドに対応するディレクトリのディスク使用量が表示されます。
機能詳細と注意事項
Disk Usageプラグインの機能詳細は次のとおりです。
- Jenkinsのシステム設定で、[Disk usage]セクションの[Show disk usage trend graph on the project page]を有効にすると、「各ジョブのページ」にディスク使用量の推移グラフが表示されます。
- その他は「機能概要 (デフォルト状態)」を参照してください。
注意事項は次のとおりです。
- ジョブがビルドされるタイミングと、ディスク使用量が計測されるタイミングは、完全に独立しています。
例えば、ビルド#8の時点で計測された後に、しばらく計測されないままビルドが何回か行われ、次にビルド#11の時点で計測されるということもありえます。 - 「workspaceディレクトリ」のディスク使用量は異なるノードで計測される可能性があります。
例えば、最終計測時点の最新ビルド#11はノードBでビルドされ、前回計測時点の最新ビルド#8はノードAでビルドされた場合、「Disk usageの確認画面」と「各ジョブのページ右上」には、ノードBの「workspaceディレクトリ」のディスク使用量のみが表示されます。また、「各ジョブのページ」に推移グラフを表示した場合、ノードAとノードBで計測された「workspaceディレクトリ」のディスク使用量が、混在して表示されます。 - 「Disk usageの確認画面」には、全ジョブの「workspaceディレクトリ」と「buildsディレクトリ」のディスク総使用量が表示されます。
「buildsディレクトリ」の総使用量はマスターノードで消費されているディスク使用量を表すので意味がありますが、「workspaceディレクトリ」の総使用量は複数のノードでビルドが実行された場合に意味が薄れてしまいます。
利用のポイント
Jenkinsプラグイン探訪 - JobConfigHistory
はじめに
「誰かがジョブの設定を誤って変更してしまったため、昨日まで問題なく動いていた自動ビルドが失敗してしまい、問題の特定に時間がかかってしまった」なんてことになると面倒です。
このような場合、「過去の設定」と「現在の設定」が簡便に比較できるようになっていると、問題点を短時間で特定できて助かります。
そこで、この記事では、このような状況の改善策の一手段としてJobConfigHistoryプラグインを紹介したいと思います。
なお、このプラグインは簡潔に述べると、
- いつ
- 誰が
- 何の設定を
- どのように変更したのか
を調査するための機能を提供します。
インストール
JobConfigHistory Pluginの名称と関連URLは次のとおりです。
- プラグインのインストール/アップデート/無効化を参照して、プラグインをインストールしてください。
- 他のプラグインとの依存関係はありません。
- プラグイン以外にインストールするものもありません。
- ジョブ設定の変更履歴を管理するだけであれば、インストール後に「プラグインのデフォルト設定」を変更する必要はありません。
機能概要 (デフォルト状態)
JobConfigHistoryプラグインの機能概要は次のとおりです。
- ジョブの設定を保存すると、保存前の設定がジョブのconfig-historyディレクトリ内に格納されます。
- ジョブの設定を何度か保存した後に、そのジョブの[Job Config History]メニューを押すと、そのジョブのみの変更履歴が一覧されます。
- 複数のジョブの設定をそれぞれ何度か変更した後に、Jenkinsのトップ画面の[Job Config History]メニューを押すと、複数のジョブの変更履歴がまとめて一覧されます。
- 変更履歴内の[View as XML]または[RAW]を押すと、その時点の設定ファイルの内容が表示されます。
- 比較元と比較先のファイルを、それぞれ[File A]と[File B]で選択して、[Show Diffs]ボタンを押すと、Diff形式の差分情報が表示されます。
- システムの設定ファイルは、デフォルト状態のままでは保存されません。
機能詳細
JobConfigHistoryプラグインの機能詳細は次のとおりです。
- ジョブの設定ファイルを、指定した数だけ保存しておくことができます。
- システムの設定ファイルを、指定した数だけ保存しておくことができます。
- 設定が変更されると、変更者と変更時刻が変更後のファイルとともに保存されます。
- ある時点の設定ファイルの内容を確認/取得することができます。
- 同じ設定ファイルの任意の2つの時点の差分情報を見ることができます。
- ジョブの設定ファイルは、ジョブの「config-history」ディレクトリ内に保存されます。
- システムの設定ファイルは、「$JENKINS_HOME/config-history」ディレクトリ内に保存されます。
- システムの設定ファイルを保存する場合は、システム設定で「Save system configuration changes」を選択する必要があります。
- 例えば、ジョブの設定ファイルは、ジョブの設定画面を開いて[保存]ボタンを押しただけでも新たな履歴として保存されます。このような重複した履歴の保存を避ける場合は、システム設定で「Do not save duplicate history」を選択する必要があります。*1
- デフォルト状態では、設定ファイルの保存数が制限されていません。保存数を制限する場合は、システム設定で「Save system configuration changes」の値を入力する必要があります。
- 設定ファイルの格納先を変更することができます。この場合は、システム設定で「Root history folder」に相対パスまたは絶対パスで格納先のルートディレクトリを入力してください。相対パスで指定した場合は、「$JENKINS_HOME/相対パス」が格納先のディレクトリになります。絶対パスで指定した場合は、「絶対パス」そのものが格納先のディレクトリになります。これらのとき、システムの設定は「config-history」ディレクトリ、ジョブの設定は「jobs/ジョブ名」ディレクトリに格納されます。
- システムの設定ファイルのうち、保存しておく必要がないものは、システム設定の「System configuration exclude file pattern」にファイル名の正規表現パターンを記述して除外します。
利用のポイント
- 重複した変更履歴が保存されてしまうと問題追跡がしにくくなりますので、システム設定で「Do not save duplicate history」を選択しておいた方がよいでしょう。*2
- 好みによりますが、システム設定で「Save system configuration changes」を選択して、システムの設定ファイルも変更履歴の追跡対象にした方がよいでしょう。この場合、システムが関連する設定ファイルを自動的に変更する可能性があるので、「Do not save duplicate history」も選択しておくことをお奨めします。
- ユーザ管理を有効にして、設定ファイルの変更者を特定できるようにするべきです。(ユーザ管理については、「操作権限をユーザ/グループ/ロール別に制御する」を参照してください)
- デフォルト状態では、ジョブが削除されると変更履歴も削除されます。削除したジョブの設定ファイルを残しておきたい場合は、システム設定で「Root history folder」を変更してください。
おわりに
もっとキッチリ管理したい方は、構成管理ツールと連携して設定を保存した方がよいかと思います。しかし、どちらか一方の手段だけを使用するよりも、併用した方が簡便さと厳密さを兼ね備えられるので良いと思います。
また、このプラグインを使用するとJenkins単独で設定ファイルの変更履歴を管理できるので、構成管理ツールとの連携方法について悩む必要がなくなります。
第2回Jenkins勉強会でLT発表してきました。
裏歴史を紡ぎ始めるようで、躊躇するところもありますが、LT資料 - Jenkins pluginsを公開しました。少しテンパってて拙いLTになっていたかと思いますが、よい経験をさせていただきました。
さて、LT発表の中では十分にお伝えできなかったことをいくつか書き記します。
- LT資料内のランキングは2010年7月時点のものです。
- プラグイン数は473個と記述しましたが、懇親会で川口さんからプラグイン以外の数も含まれた個数であるとのご指摘を頂きました。
- FindbugsやCheckstyleの結果を集約する方法として、Violationsを使う方法の他に、Analysis Collectorを使う方法があります。両者を比べた場合、前者はツール名を区別して情報を表示するので分かりやすくて良いと思います。
- プラグインは別のプラグインに依存していることがあります。Jenkinsが提供しているインタフェース(GUIまたはCLI)を使ってプラグインをインストールする場合は依存関係が自動的に解決されます。しかし、ダウンロードしたhpiを使ってプラグインをインストールする場合は、依存関係を自分で解決しなければならないので注意してください。
- Jenkinsは、Update Centerの情報収集をブラウザに任せています。このため、Jenkinsのインストール直後に一度もブラウザでJenkinsにアクセスせずに、プラグイン名を使ってCLIを用いてプラグインをインストールしようとすると失敗します。
Jenkins本体とプラグインを一括導入する場合は、Jenkins Assemblerを使うと良いでしょう。 - CloudBee's JaaSには、LT資料内で紹介している定番プラグインのいくつかがプリインストールされています。
- Mavenを使っている方は、恐らくMaven側のプラグインを探してFindbugsなどのツールと連携した方が、より簡単に連携出来るのではないかと思います。この場合、Jenkins側はMavenプロジェクトを作るところまでを担当することになると思います。
- LT資料内で紹介しているビルドスクリプトは、もう少し整備してから公開させていただきます。しばらくお待ちください。
Hudsonの操作権限をユーザ/グループ/ロール別に制御する
はじめに
Hudsonを標準状態のままで使用した場合、Hudsonにアクセスできる全てのユーザが、Hudsonの全ての機能を制限なく利用できてしまいます。
Hudsonの機能を熟知しているチーム内でHudsonを使用するのであれば、この標準状態の方が設定に煩わされない分、簡便に運用できるので都合が良いかもしれません。
しかし一般的には、間違った操作によってHudsonが動作しなくなることを防ぐために、「Hudsonの管理者」と「Hudsonの利用者」くらいの最低限の区別をした方が良いのではないかと思います。
そこで、この記事では、Hudsonのユーザーデータベースを使用して、Hudsonの操作権限を制御する方法について説明したいと思います。
なお、説明を簡素化するために、Hudsonの公式サイトにはない用語や分類を用いて説明していますので、その点はご了承ください。
操作権限を制御する前に
config.xmlのバックアップ
間違った設定をしてしまうと、全てのユーザがHudsonにログインできなくなったり、ログインできたとしてもHudsonのシステム設定を変更できなくなったりします。
操作権限の設定は、HUDSON_HOMEディレクトリ配下の「config.xml」に保存されるので、設定を変更する前にこのファイルをバックアップしておくと良いでしょう。
なお、バックアップを取っていなかったとしても、Disable securityの手順に従って、操作権限を制限しない状態にすることができます。
操作権限の種類
操作権限の種類は次のとおりです。
| 大項目 | 中項目 | 小項目 | 操作権限 |
|---|---|---|---|
| システムレベル | 全体 | [U] Administer | Hudsonのシステム管理 |
| [R] Read | Hudsonへのアクセス | ||
| スレーブ | [U] Configure | スレーブの設定 | |
| [D] Delete | スレーブの削除 | ||
| ビュー | [C] Create | ビューの作成 | |
| [D] Delete | ビューの削除 | ||
| [U] Configure | ビューの設定 | ||
| SCM | [C] Tag | 構成管理のタグ付け | |
| プロジェクトレベル | ジョブ | [C] Create | ジョブの作成 |
| [D] Delete | ジョブの削除 | ||
| [U] Configure | ジョブの設定 | ||
| [R] Read | ジョブへのアクセス | ||
| [U] Build | ジョブのビルド | ||
| [U] Workspace | ジョブのワークスペース管理 | ||
| ビルド | [D] Delete | ビルドの削除 | |
| [U] Update | ビルドの保存 |
補足: 表内の[C]/[R]/[U]/[D]は、Hudsonの各権限がCRUD - Wikipediaのどの操作に該当するのかを私なりに分類したものです。
操作権限の構造
操作権限には次の２種類の権限が存在します。
- 「システムレベルの権限」
- 「プロジェクトレベルの権限」
「システムレベルの権限」は、「プロジェクトに依存しない操作」の権限になり、常にシステム全体に適用されます。
例えば、[全体 - Administer]の権限は、システム全体で「権限を与える」かどうかを決めることになります。
これに対して「プロジェクトレベルの権限」は、「プロジェクトに依存する操作」の権限になり、システム全体に(プロジェクトに共通して)適用されるケースとプロジェクト別に適用されるケースを使い分けることができます。
例えば、２つのプロジェクト(PRJ1とPRJ2)が登録されている状態で、[ジョブ - Configure]の権限は、システム全体で「権限を与える」に加えて、PRJ1またはPRJ2に対して「権限を与える」かどうかを決めることもできます。
次に操作権限の構造を示します。
権限設定の単位について
Hudsonは、標準ではユーザー単位の権限設定機能しか備えていません。設定画面の中にグループという言葉も現れますが、後述するauthenticatedグループを除いて、グループに見立ててアカウントを共有するという意味ですのでご注意ください。
アカウントを共有せずに、グループを形成するためには、Role Strategy Pluginを使用する必要があります。
Role Strategy Pluginの名称と関連URLは次のとおりです。
| プラグイン名 | Wiki URL | ダウンロード URL | GitHub URL |
|---|---|---|---|
| Role Strategy Plugin | http://wiki.hudson-ci.org/display/HUDSON/Role+Strategy+Plugin | http://hudson-ci.org/download/plugins/role-strategy/ | https://github.com/hudson/role-strategy-plugin |
なお、グループという用語を用いると誤解を招く恐れがあるので、アカウントを共有しないグループのことを、このプラグインの用語を用いてロールと呼ぶことにします。
匿名(anonymous)ユーザーとauthenticatedグループについて
匿名ユーザーは、Hudsonに登録されていないユーザーも含む全てのユーザーを代表するユーザーになります。
authenticatedグループは、Hudsonに登録されている全てのユーザーを代表するユーザーになります。
匿名ユーザーとauthenticatedグループの扱いを考慮した場合、例えば [全体 - Read] の権限は次のOR条件で決定されます。
- 匿名ユーザーに設定されている「システム全体の[全体 - Read]」
- authenticatedグループに設定されている「システム全体の[全体 - Read]」
- ユーザー/グループ/ロールに設定されている「プロジェクト別の[全体 - Read]」
また、例えば [ジョブ - Read] の権限は次のOR条件で決定されます。
- 匿名ユーザーに設定されている「システム全体の[ジョブ - Read]」
- 匿名ユーザーに設定されている「プロジェクト別の[ジョブ - Read]」
- authenticatedグループに設定されている「システム全体の[ジョブ - Read]」
- authenticatedグループに設定されている「プロジェクト別の[ジョブ - Read]」
- ユーザー/グループ/ロールに与えられている「システム全体の[ジョブ - Read]」
- ユーザー/グループ/ロールに設定されている「プロジェクト別の[ジョブ - Read]」
つまり、ある権限を匿名ユーザーに与えると、その権限をHudsonに登録されていないユーザーも含む全てのユーザーに与えたことになります。
また、ある権限をauthenticatedグループに与えると、その権限をHudsonに登録されている全てのユーザーに与えたことになります。
セキュリティポリシーについて
セキュリティポリシーは、次の観点で検討すると良いでしょう。
- ログインしていないユーザー(匿名ユーザー)にジョブの状態を見せるかどうか。
- ユーザー/グループ/ロールのどの単位で権限を与えるのか。
- ユーザー/グループ/ロールに、CRUDのどの操作権限を与えるのか。
- 「設定を変更した人」や「ビルドを実行した人」を特定する必要があるかどうか。
- プロジェクト別に権限を与える必要があるかどうか。
これらを適切に検討しておくことで、次の問題を防ぐことができます。
- ジョブの公開範囲が必要以上に広くなってしまう。
- Hudsonの操作に不慣れな人がHudson環境を壊してしまう。
- 権限の設定が複雑になりすぎて負担になる。
操作権限の設定手順
ここから、次の３種類の権限管理手段の設定手順を説明します。
(それぞれの権限管理手段のメリット/デメリットは後述します)
- (A) : システム全体に適用される権限のみで管理する。
- (B) : プロジェクト別に適用される権限も使用して管理する。
- (C) : ロール単位で権限を管理する。
共通事項
権限設定の基本的な流れは次の通りです。
- アクセス制御を有効にする
- ユーザー/グループ/ロールを追加する
- 操作権限を設定する
- 各ユーザーがサインアップする
２つの開発プロジェクトのどちらかに対応する次の４つのジョブ(プロジェクト)が、Hudsonに登録されているものとします。
| 開発プロジェクト | Hudsonのジョブ名 | 概要 |
|---|---|---|
| 開発プロジェクトPRJ1 | PRJ1-BUILD | PRJ1のビルド用ジョブ |
| PRJ1-DEPLOY | PRJ1のデプロイ用ジョブ | |
| 開発プロジェクトPRJ2 | PRJ2-BUILD | PRJ2のビルド用ジョブ |
| PRJ2-DEPLOY | PRJ2のデプロイ用ジョブ |
(A) : システム全体に適用される権限のみで管理する。
- 次のとおりに設定するものと仮定します。
| ユーザー名 | 操作権限 |
|---|---|
| 匿名ユーザー | 権限なし(ログイン画面以外は見えない) |
| admin | Hudsonの全ての権限をもつ |
| user1 | [全体 - Read]とプロジェクトレベルの全ての権限をもつ |
| user2 | [全体 - Read]、[ジョブ - Read]、[ジョブ - Build]の権限をもつ |
| user3 | [全体 - Read]、[ジョブ - Read]の権限をもつ |
| user4 | [ジョブ - Read]の権限のみをもつ |
補足: user4ユーザーは、[全体 - Read]の権限の必要性を説明するためだけのユーザーです。
- 次の操作で操作権限の行列を開きます。
- Hudsonのトップ画面を開きます。
- [Hudsonの管理] - [システムの設定]を選択します。
- [セキュリティを有効化]をチェックします。
- [ユーザー情報]セクションの[Hudsonのユーザーデータベース]を選択します。
- [権限管理]セクションの[行列による権限設定]を選択します。
- 「ユーザー/グループの名前」と「操作権限」の行列が表示されます。
- 次の操作でadminユーザーを追加します。
- 匿名ユーザーの[全体 - Administer]と[全体 - Read]をチェックします。
- [追加するユーザー/グループ]に、"admin"と入力します。
- [追加]ボタンを押します。
- "admin"ユーザーが行列に追加されます。
補足: ユーザーを追加する際に、誤って[Enter]キーを押してしまった場合、[追加]ボタンが押されるのではなく、画面下部の[保存]ボタンが押されたことになります。不十分な設定のままで操作権限が保存されてしまうと復旧に一手間かかるので、Hudsonのシステム管理に必要な操作権限を一時的に匿名ユーザーに与えています。
補足: 追加されたユーザー名の左側に表示される
は、ユーザーがシステムにサインアップしていないことを表すアイコンです。
- 次の操作でユーザーに操作権限を与えます。
- "admin"ユーザーの全ての権限をチェックします。
- 匿名ユーザーの[全体 - Administer]と[全体 - Read]のチェックを外します。
補足: 誤って[Enter]キーを押してしまったとしても、全ての権限をもつadminユーザーでHudsonのシステム設定を変更することができます。
- 同様の操作でuser1〜user4ユーザーに操作権限を与えて、最後に画面下部の[保存]ボタンを押します。
- この状態でHudsonのトップ画面を開くと、ログイン画面が表示されるので、[サインアップ]を選択します。
- サインアップ画面が表示されるので、次の操作をします。
- すべての空欄に値を入力します。
- [サインアップ]ボタンを押します。
補足: [テキスト:]欄には、サインアップ画面に表示される認証用文字列を入力してください。
- サインアップに成功すると、[成功]と表示されてログイン済みの状態になります。
adminユーザーの画面例:
補足: [全体 - Administer]の権限をもっているので、[Hudsonの管理]メニューが表示されています。
user1ユーザーの画面例:
補足: [全体 - Administer]の権限をもっていないので、[Hudsonの管理]メニューが表示されません。
user4ユーザーの画面例:
補足: [全体 - Read]の権限をもっていないので、Hudsonにログインすることができません。
- サインアップ後に権限管理の行列を確認すると、ユーザー名の左側のアイコンが
に変わっていることが分かります。
- 以上で(A)のケースの操作権限設定は完了です。
(B) : プロジェクト別に適用される権限も使用して管理する。
- 次のとおりに設定するものと仮定します。
| ユーザー名 | 操作権限 |
|---|---|
| 匿名ユーザー | (A)と同じ |
| admin | (A)と同じ |
| user1 | (A)と同じ |
| user2 | (A)に加えてPRJ1-BUILDジョブのConfigure権限をもつ |
| user3 | (A)に加えてPRJ1-BUILDジョブのBuild権限をもつ |
| user4 | (A)に加えてPRJ1-BUILDジョブのBuild権限をもつ |
- 次の操作で操作権限の行列を開きます。
- Hudsonのトップ画面を開きます。
- [Hudsonの管理] - [システムの設定]を選択します。
- [セキュリティを有効化]をチェックします。
- [ユーザー情報]セクションの[Hudsonのユーザーデータベース]を選択します。
- [権限管理]セクションの[行列による権限設定(プロジェクト単位)]を選択します。
- 「ユーザー/グループの名前」と「操作権限」の行列が表示されます。
- (A)と同じ手順で各ユーザーに権限を与えます。
注意: この画面で設定できるのは「システム全体に適用される権限」だけです。
- 次の操作でPRJ1-BUILD特有の操作権限を設定します。
- [PRJ1-BUILD]の設定画面を表示します。
- [権限設定(プロジェクト単位)の有効化]をチェックします。
- [追加するユーザー/グループ]に、"user2"と入力します。
- [追加]ボタンを押します。
- "user2"ユーザーが行列に追加されます。
- 匿名ユーザーの[ジョブ - Read]と[ジョブ - Build]をチェックします。
- "user2"ユーザーの[ジョブ - Configure]をチェックします。
- 画面下部の[保存]ボタンを押します。
補足: 匿名ユーザーがもつ権限は、全てのユーザーに適用されるので、user2ユーザーに[ジョブ - Read]を設定する必要はありません。(ただし、user2ユーザーは、「システム全体に適用される権限」で既に[ジョブ - Read]の権限をもっています)
- 以上で(B)のケースの操作権限設定は完了です。
(C) : ロール単位で権限を管理する。
- Role Strategy Pluginがインストール済みであると仮定します。
- 次のとおりに「システム全体に適用される権限」を設定するものと仮定します。
| ロール名 | 操作権限 |
|---|---|
| admin | (A)のadminユーザー相当 |
| all-job-build-mgr | (A)のuser1ユーザー相当の権限をもつ |
| all-job-build | (A)のuser2ユーザー相当の権限をもつ |
| all-job-read | (A)のuser3ユーザー相当の権限をもつ |
- 次のとおりに「プロジェクト別に適用される権限」を設定するものと仮定します。
| ロール名 | 操作権限 |
|---|---|
| PRJ1-job-build-mgr | 名前が「PRJ1-」から始まるジョブの全ての権限をもつ |
| PRJ2-job-build-mgr | 名前が「PRJ2-」から始まるジョブの全ての権限をもつ |
- 次のとおりにロールとユーザーを関連付けるものと仮定します。
| ロール名 | ユーザー名 |
|---|---|
| admin | admin |
| all-job-build-mgr | user1 |
| all-job-build | user2 |
| all-job-read | user3 |
| PRJ1-job-build-mgr | user2 |
- 次の操作でロール単位の権限設定を有効にします。
- Hudsonのトップ画面を開きます。
- [Hudsonの管理] - [システムの設定]を選択します。
- [セキュリティを有効化]をチェックします。
- [ユーザー情報]セクションの[Hudsonのユーザーデータベース]を選択します。
- [権限管理]セクションの[Role-Based Strategy]を選択します。
補足: この操作によって[システムの設定]画面に、[Manage Roles]メニューが追加されます。
- 次の操作でロール単位の権限設定の管理画面を表示します。
- [Hudsonの管理] - [システムの設定]を選択します。
- [Manage Roles]を選択します。
- [Manage Roles]を選択します。
- 次の操作で「システム全体に適用される権限」を設定します。
- [Role to add]に、"admin"と入力します。
- [Add]ボタンを押します。
- "admin"ロールの全ての権限をチェックします。
- 他のロールも同様の方法で追加し、権限を与えます。
- 次の操作で「プロジェクト別に適用される権限」を設定します。
- [Role to add]に、"PRJ1-job-build-mgr"と入力します。
- [Pattern]に、正規表現で"PRJ1-.*"と入力します。
- [Add]ボタンを押します。
- "PRJ1-job-build-mgr"ロールの権限をチェックします。
- 他のロールも同様の方法で追加し、権限を与えます。
- [Save]ボタンを押します。
補足: ロール名の接頭語をPatternにマッチさせるジョブの接頭語は、一致している必要はありません。
- 今度は[Assign Roles]を選択します。
- 次の操作で「システム全体に適用される権限」をもつロールにユーザーを割り当てます。
- [User/group to add]に、"admin"と入力します。
- [Add]ボタンを押します。
- "admin"ユーザーに、"admin"ロールのチェックを付けます。
- 他のユーザーも同様の方法で追加し、ロールを割り当てます。
補足: 分かりにくくなってしまいましたが、adminユーザーとadminロールは完全に独立のものです。
- 次の操作で「プロジェクト別に適用される権限」をもつロールにユーザーを割り当てます。
- [User/group to add]に、"user2"と入力します。
- [Add]ボタンを押します。
- "user2"ユーザーに、"PRJ1-job-build-mgr"ロールのチェックを付けます。
- 他のユーザーも同様の方法で追加し、ロールを割り当てます。
- 以上で(C)のケースの操作権限設定は完了です。
メリット/デメリット
(A) : システム全体に適用される権限のみで管理する。
- メリット
- ユーザー単位で管理するので分かりやすい。
- システム全体に適用される権限のみを管理するので分かりやすい。
- 設定画面は１画面だけなので分かりやすい。
- デメリット
- ユーザー数が増えた場合に煩雑になりやすい。
- プロジェクト別に管理担当者を割り当てるなどの柔軟な対応ができない。
(B) : プロジェクト別に適用される権限も使用して管理する。
- メリット
- ユーザー単位で管理するので分かりやすい。
- プロジェクト別に管理担当者を割り当てるなどの柔軟な対応ができる。
- デメリット
- ユーザー数が増えた場合に煩雑になりやすい。
- 設定画面がプロジェクトの数分存在するので煩雑になりやすい。
(C) : ロール単位で権限を管理する。
- メリット
- ロール(役割)で管理するので、どのユーザーがどの役割をもっているのかが分かりやすい。
- プロジェクト別に管理担当者を割り当てるなどの柔軟な対応ができる。
- 設定画面は３画面であるが、(B)よりも少ないので許容範囲である。
- (A)に比べて、ユーザー数が増えても煩雑になりにくい。
- デメリット
- ジョブ(プロジェクト)の名称を適切に決めておかないと、Patternが上手に設定できなくなるので煩雑になりやすい。
おわりに
最後に、操作権限を設定する場合のポイントをいくつかご紹介します。
- 特権ユーザー(記事内ではadminユーザー)を少なくとも１ユーザー登録しておく。
- 匿名ユーザーを利用して、設定数を少なくできないか検討する。
- authenticatedグループを利用して、設定数を少なくできないか検討する。
- 「システム全体に適用される権限」を利用して、設定数を少なくできないか検討する。
- ロール単位で操作権限を設定する場合は、ジョブ(プロジェクト)の命名規則を決めておき、Patternを活用できるようにする。
実際の動作を確認した上で記事を書き起こしていますが、誤りなどありましたら、早急に修正しますのでご指摘ください。
変更履歴
- 2011/1/13にauthenticatedグループに関する記述を追記しました。
Hudson環境のバックアップ
はじめに
リリースに向けて追い込みに入っている状況なのに、マーフィーの法則が予定どおりに(？)働いて、「昨日まで動いていたHudsonがハードディスク故障のせいで動作しなくなっている」なんてことになると大変です。
この記事では、そんな状況でも慌てず騒がず対処できるようにするために、Hudson環境のバックアップについて説明したいと思います。
なお、この記事におけるバックアップ方針は次のとおりです。
- (A) : お金をかけずに取得する
- (B) : 安全なタイミングで取得する
- (C) : 分かりやすい方法で取得する
- (D) : Hudson自身に(定期的に)取得してもらう
バックアップの前に
バックアップ対象
バックアップ対象は、Hudson環境が構築されているHUDSON_HOMEディレクトリの内容になります。 (HUDSON_HOMEディレクトリ内のディレクトリ構成例は以下を参照)
HUDSON_HOMEディレクトリ
+--- fingerprints
+--- jobs
+--- [JOBNAME] (各ジョブ毎のサブディレクトリ)
+--- workspace (ワークディレクトリ)
+--- builds
+--- log
+--- plugins
+--- tools
+--- updates
+--- userContent
+--- users
+--- war (Hudson本体のディレクトリ)
...
補足: Hudsonの設定状態によって多少ディレクトリ構成が変わります。
ただし、HUDSON_HOMEディレクトリのすべての内容をバックアップする必要はありません。
例えば、「war」ディレクトリの内容は、通常「hudson.war」の内容と一致しているはずなのでバックアップ対象外にしても復元できます。また、「workspace」ディレクトリの内容は、通常「構成管理ツールから得たもの」または「ビルド処理によって自動生成されたもの」のどちらかになるはずなので、バックアップ対象外にしても復元できます。
このため、バックアップ対象は、バックアップにかかる時間、バックアップファイルのサイズ、リストアのしやすさのバランスを取って決めることになります。
シャットダウンモードについて
実行中のビルドが存在している状態でバックアップを取得してしまうと、中途半端な状態でバックアップされたビルドと、そうでないビルドが切り分けられなくなってしまいます。
このため、バックアップはシャットダウンモードに移行してから実施することをお勧めします。(Hudsonのアップグレード - シャットダウンモードについて参照)
バックアップの開始時刻について
シャットダウンモードへの移行を前提にしたバックアップ計画を立案する場合、バックアップを実際に開始できる時刻(シャットダウン状態で実行中の全ビルドが終了する時刻)が問題になります。
例えば、一回のビルドに何日も要してしまうようなジョブが存在する場合は、バックアップサイクルが安定しにくくなるので「ビルドの実行時間を短縮する」、「バックアップサイクルを考慮したビルドの実行サイクルにする」などの対策が必要になります。もしくは、これらの対応が難しい場合は、シャットダウンモードへの「移行を前提にしないバックアップ」と「移行を前提にするバックアップ」を併用するなどの対策が必要になります。
バックアップ手段について
Administrating Hudson - バックアップとリストアのとおり、Hudson環境はファイルをアーカイブするだけでバックアップできますが、この記事では先に述べた方針に従って、次の点を考慮した２つのバックアップ手段を紹介します。
- HudsonとHudsonのプラグインを使ってバックアップする。(方針(A)&(D)より)
- 中途半端な状態でバックアップされないようにする。(方針(B)より)
- 除外したいファイルを分かりやすい方法で設定できるようにする。(方針(C)より)
２つのバックアップ手段は次のとおりです。
| 手段 | 概要 |
|---|---|
| Backup Pluginを使用したバックアップ | Backup専用のプラグインを使用してバックアップします。 |
| Exclusive Execution Plugin + Antタスクを使用したバックアップ | シャットダウンモードの管理をするプラグインとAntタスクを組み合わせてバックアップします。 |
使用するプラグインの名称と関連URLは次のとおりです。
バックアップを取得する
ここから、それぞれのバックアップ手段の実施手順を説明します。
(それぞれのバックアップ手段のメリット/デメリットは後述します)
Backup Pluginを使用したバックアップ
- Backup Pluginがインストール済みであると仮定します。
- バックアップファイルの格納先ディレクトリは「C:\Hudson\Backup」であるとします。
- Hudsonのトップ画面から、[Hudsonの管理] - [Backup manager]を選択します。
- [Setup]を選択します。
- 必要な設定をしてから[Save]ボタンを押します。
補足: 最低限設定する必要がある項目は、[Backup directory](バックアップファイルの格納先ディレクトリ)のみです。
補足: Windowsの場合は、(扱いやすいという意味で) [Format]を "zip" に変更した方が良いでしょう。
補足: バックアップファイル名は、[File name template]に従って決定されます。(例: backup_20110101_1200.zip)
補足: [Backup content]の設定項目でバックアップ対象を制御できます。
- 設定後に、Hudsonのトップ画面から、[Hudsonの管理] - [Backup manager] - [Backup Hudson configuration]を選択してバックアップを取得します。
- [Backup started at ...]と表示され、シャットダウンモードに移行します。
補足: 実行中のビルドがなくなってから、バックアップが開始されます。
- [Backup end at ...]と表示されれば、バックアップ終了です。
補足: [Number of errors:]の値が 0 であることを確認してください。
補足: 自動的にシャットダウンモードがキャンセルされます。
注意: 実行ログ画面は再表示できません。画面を切り替えた場合は、%HUDSON_HOME%\backup.logをテキストエディタなどで直接開く必要があります。
Exclusive Execution Plugin + Antタスクを使用したバックアップ
- Antがインストール済みであると仮定します。
- Exclusive Execution Pluginがインストール済みであると仮定します。
- バックアップファイルの格納先ディレクトリは「C:\Hudson\Backup」であるとします。
- 次の操作で新しいジョブを作成します。
- Hudsonのトップ画面で[新規ジョブ作成]を選択する。
- ジョブ名を入力する。
- [フリースタイル・プロジェクトのビルド]を選択する。
- [OK]を押す。
- 次の操作でカスタムワークスペースを設定します。
補足: 標準のワークディレクトリにバックアップファイルを作成してから、バックアップファイルの格納先にファイルを移動する方が素直ですが、ここではバックアップファイルの格納先をワークディレクトリにすることで移動処理を省いています。
- 次の操作でバックアップスケジュールを設定します。
- [ビルド・トリガ]の[定期的に実行]をチェックします。
- [スケジュール]にビルドの開始タイミングを設定します。
補足: ここでは"@daily"を設定していますが、バックアップ計画に基づいてより適切な値を設定してください。
- 次の操作でシャットダウンモードでバックアップが実施されるようにします。
- [ビルド環境]の[Set exclusive execution]をチェックします。
補足: Exclusive Execution Pluginによって追加される設定項目です。
補足: [Set exclusive execution]を設定すると、この設定をしたジョブだけが実行できる状態になってから、ジョブのビルドが実行されるようになります。
<?xml version="1.0" encoding="UTF-8"?> <project default="backup" basedir="."> <property environment="env" /> <target name="backup" > <zip basedir="${env.HUDSON_HOME}" destfile="Hudson${label}.zip" excludes="war/**, jobs/*/workspace/**"> </zip> </target> </project>
補足: Hudsonのバックアップ - azuki noteのbuild.xmlを参考にさせて頂きました。
補足: "backup"がターゲット名です。
補足: 「war」と「workspace」をバックアップ対象外にしています。
補足: プロパティ(ここでは"label")を用いて、バックアップファイル名をパラメータ化しています。
- 次の操作でビルドアクションを設定します。
- [ビルド]の[ビルド手順の追加]を押して、[Antの呼び出し]を選択します。
- 必要に応じて[使用するAnt]を選択します。
- [ターゲット]に"backup"と記述します。
- [高度な設定...]を押して、[プロパティ]を表示し、"label=$BUILD_ID"と記述します。
補足: バックアップファイル名に使用している$BUILD_IDは、Hudsonが提供する環境変数の一つです。
補足: Antのビルドファイル名が"build.xml"以外の場合は、[ビルドファイル]にファイル名を記述する必要があります。
- [保存]ボタンを押して設定を終了します。
- ビルドを実行すると、次のようにシャットダウンモードに移行してからビルドアクションが実行されます。
- [Finished SUCCESS]と表示されれば、バックアップ終了です。
メリット/デメリット
Backup Pluginを使用したバックアップ
- メリット
- シャットダウンモードに移行してからバックアップを取得できる。
- リストア機能も提供されている。
- Antなどに頼らずにプラグイン単独でバックアップを取得できる。
- バックアップ対象に関する設定項目が標準で提供されている。
- デメリット
Exclusive Execution Plugin + Antタスクを使用したバックアップ
- メリット
- デメリット
- 手動でリストアを実施する必要がある。
- プラグイン単独ではバックアップを取得できない。
- バックアップ対象に関する設定項目が標準で提供されていない。
おわりに
- 「バックアップの成功/失敗の管理をHudsonに任せられる」ので、私自身は「Exclusive Execution Plugin + Antタスクを使用したバックアップ」を採用しています。
- インストールするものが少なく、かつ、Hudsonが標準でサポートしているのでAntを採用しましたが、Ant以外でアーカイブを作成していただいても何ら問題ありません。
- Administrating Hudson - バックアップとリストアのとおり、バックアップしたファイルをHUDSON_HOMEディレクトリに展開しなおすだけでHudson環境をリストアできます。
プラグインのインストール/アップデート/無効化
はじめに
Hudsonのコミュニティは非常に活発で、2010/12/29時点で380以上のプラグインがGitHub - Hudsonに登録されています。
プラグインの洗練度には差があるものの、Hudsonをより効果的かつ効率的に利用するためには、開発業務にあったプラグインを上手に使いこなすことが不可欠ではないかと思います。
プラグインをインストールする前に
プラグインファイルの準備(自動インストールでは不要)
外部から隔絶されたネットワーク環境にあるマシンにプラグインをインストールする場合や、プラグインの公式ダウンロードサイトに登録されていないプラグインをインストールする場合は、プラグインファイル(*.hpi)をダウンロードしておくか、GitHub - Hudsonに登録されているソースなどを用いてプラグインファイルをビルドしておく必要があります。
プラグインの事前テスト
一度インストールしたプラグインは、無効にすることはできますが、基本的にはアンインストールできません。(アンインストールは、Hudson環境下の関連ファイルを手動で変更または削除しなければならないので、できれば避けたいところです。)
このため、運用中のHudson環境をできるだけクリーンな状態に保つために、「同一マシンの同一OS上に二つのHudson環境を構築する」などの方法を用いて試験用のHudson環境を構築し、そちらで動作確認することをお勧めします。
バックアップの取得について
プラグインは、HUDSON_HOMEディレクトリ配下にインストールされます。
プラグインは基本的にはアンインストールできないので、アンインストールする代わりにHUDSON_HOMEディレクトリのバックアップを取得しておき、インストール前の状態に戻せるようにしておく方がよいでしょう。(Hudsonのアップグレード - バックアップの取得について参照)
Proxyの設定について
Hudsonがアップデートサイトにアクセスできる状態になっていると、プラグインに関して次の恩恵が受けられます。
Proxy経由でないと外部にアクセスできないネットワーク環境の場合は、この恩恵を受けるために、Proxyを設定する必要があります。(Hudsonのアップグレード - Proxyの設定について参照)
シャットダウンモードについて
インストールしたプラグインを有効化するためには、Hudsonを再起動する必要があります。
このため、プラグインはシャットダウンモードに移行した状態でインストールする方が良いでしょう。(Hudsonのアップグレード - シャットダウンモードについて参照)
プラグインのインストール
プラグインは、自動インストールと手動インストールの２種類の方法でインストールすることができます。
自動インストール
- 以下の手順でHudsonを操作します。
- Hudsonをシャットダウンモードにして、実行中のビルドが無くなるのを待ちます。
- Hudsonのトップ画面で[Hudsonの管理]を選択し、続けて[プラグインの管理]を選択します。
- [利用可能]タブを選択すると、インストール可能なプラグインの一覧が表示されます。
- インストールしたいプラグインをチェックします。(複数選択可)
補足: ここでは、Backup Plugin(Hudson環境のバックアップを取得するためのプラグイン)を選択しています。
- 画面下部にスクロールして、[インストール]ボタンを押します。
- プラグインのダウンロードとインストールが開始されます。
- 「成功」と表示されれば、インストール成功です。
注意: [利用可能]タブに表示されるプラグインの名前と、[インストール済みのプラグイン]タブに表示されるプラグインの名前は、多少異なることがあります。
手動インストール
- 以下の手順でHudsonを操作します。
- Hudsonをシャットダウンモードにして、実行中のビルドが無くなるのを待ちます。
- Hudsonのトップ画面で[Hudsonの管理]を選択し、続けて[プラグインの管理]を選択します。
- [高度な管理]タブを選択し、続けて[ファイルを選択]ボタンを押します。
補足: ここでは、プラグインの公式ダウンロードサイトから取得したBackup Pluginのプラグインファイル(backup.hpi)を選択しています。
- [選択されていません] が、選択したプラグインファイルの名前になっていることを確認して、[アップロード]ボタンを押します
- 画面がリフレッシュされて、[プラグインの管理]画面の[アップデート]タブが表示されればインストール成功です。
注意: 手動インストールの場合は、インストールの進捗画面が表示されません。
- 自動インストールのときと同様に、Hudsonを再起動してプラグインを有効にしてください。
プラグインのアップデート
インストール済みのプラグインの新しいバージョンがリリースされた場合、[プラグインの管理]画面の[アップデート]タブにアップデート可能なプラグインの一覧が表示されます。
アップデートする場合は、次の手順で操作します。
- 自動インストールのときと同様に、Hudsonを再起動してプラグインを有効にしてください。
