yggdrasilを使ってみました。
6月末のshinagawa Redmine勉強会の際、いろいろお世話になっている楠川さん（@tkusukawa さん）が作られた、yggdrasil というツールについて、直接お話を伺う機会を持つことが出来ました。
それまでは、縁のなさそうなツールかな...という印象だったのですが（すみません....）、勉強会でのスライドを拝見しているうちに、「あ、これはいいかも！」と思うようになりました。
＃まだまだChefやらPuppetやらには手が出せていないので、そういうたぐいの感じかと、最初は戸惑っていたのです.....。
さっそく、その場で直接質問をさせていただき、変更を各サーバに反映するというアプローチではなくて、『変更が勝手にされていないか、コミット漏れがないか』をチェックすることに主眼を置いていることが分かりました。
目的が違うことが分かり、『No Ticket, No Work！』というキャッチにも、なるほどと共感するところがありました。
また、運用者にとっては、まだなじみ易いSubversionをリポジトリに使っているということもあり、yggdrasil という言葉は抜きにして、『変更はSubversionを使ってるよ』という説明なら、周囲も理解しやすいはず...。
ということで、丁度いじっていたサーバに入れてみることにしました。
また、運用者にとっては、まだなじみ易いSubversionをリポジトリに使っているということもあり、yggdrasil という言葉は抜きにして、『変更はSubversionを使ってるよ』という説明なら、周囲も理解しやすいはず...。
ということで、丁度いじっていたサーバに入れてみることにしました。
インストール後、単体での利用は、なんとなくイメージ通りだったので、このまま使ってみようと判断。ですが、サーバ／クライアント構成の場合は、しばらくどう設定すればいいのか分かりませんでした...（これもすみません....）
その後数回、楠川さんにtweet経由で質問させていただき、お忙しいところにもお返事をいただけたおかげで、「ああ、こんな感じなんだな」というのも見えてきました。
理解が間違っていないか、ちょっと心配なので、仕組みを書き出してみます。
仕組みは下記のような感じになります（勝手な理解かもしれませんが...）
1. yggdrasil スタンドアロン、もしくはclientは、Subvetsionサーバとのやりとりで、設定ファイルをコミットしたりします。svn add/commitではなく、ygg add/commit という形で、yggdrasilがsvnコマンドをラップする形で更新を重ねていきます。
2. ~/.yggdrasil ディレクトリには、Subversionサーバの情報、Subversionと通信する際のユーザの情報や、yggdrasil をclient / server構成で使う時のserverの設定情報が格納されます。
また、mirror というディレクトリが作られ、ここがシステムの / 配下をミラーしたような、Subversionのワーキングディレクトリとなります。
3. ygg check コマンドで、リポジトリに登録されている情報と、実際に扱っているファイルとの差分をチェックします。差分があればエラーと判断します。
4. client / server 構成の場合は、client側がチェック結果をserverに報告しに行きます。server側も、~/.yggdrasil/result というフォルダにclientからの報告を格納します。そうして、yggserve result というコマンドを使うと、clientたちの結果に問題が無いかどうかを一度に確認することができます。
楠川さんのおすすめは、clientからのserverへの報告はcronで行い、server上では yggserve result コマンドをJenkinsを使って処理する、というものでした。
私の環境の場合は、ygg serverに当たるサーバはJenkins masterには利用できなかったので、Jenkins slaveとして設定し、いつも使っているJenkins maseter上で他のジョブと一緒にチェックを行うようにしてみました。
実は、わたしも設定ファイルは所々Subversionに登録してはいたのですが、/etc/... とか、/usr/local/... とか、ディレクトリにばらつきがあり、どうもうまく管理できていませんでした。
yggdrasilのおかげで、そういったパスのばらつきを考慮しなくても、yggdrasilのコマンドが宜しくやってSubversionに登録／変更をチェックしてくれるので、『これは良い感じ！』と思いました:)
若干？ハードルになるのは、rubyが必要だというあたり。
インストール直後でほとんどツールが入っていないOSだとすぐには使えませんが、今回はruby入りのサーバをコピーして複数台をチェックという状況でしたので、すんなり使えています。
なお、しがないバックオフィスのスタッフの身なので、恥ずかしながらコマンドラインで使うruby gemは意識して入れるのが初めてでした。
その上で、ソースも拝見して、『こんなふうに書くんだ〜』と、とっても勉強させていただいております。
ということで、ひきつづき1ユーザとしてお世話になってみようと思います！
こんな感じ
理解が間違っていないか、ちょっと心配なので、仕組みを書き出してみます。
併せて、現状試していることを図にしてアップしてみます。
仕組みは下記のような感じになります（勝手な理解かもしれませんが...）
1. yggdrasil スタンドアロン、もしくはclientは、Subvetsionサーバとのやりとりで、設定ファイルをコミットしたりします。svn add/commitではなく、ygg add/commit という形で、yggdrasilがsvnコマンドをラップする形で更新を重ねていきます。
2. ~/.yggdrasil ディレクトリには、Subversionサーバの情報、Subversionと通信する際のユーザの情報や、yggdrasil をclient / server構成で使う時のserverの設定情報が格納されます。
また、mirror というディレクトリが作られ、ここがシステムの / 配下をミラーしたような、Subversionのワーキングディレクトリとなります。
3. ygg check コマンドで、リポジトリに登録されている情報と、実際に扱っているファイルとの差分をチェックします。差分があればエラーと判断します。
4. client / server 構成の場合は、client側がチェック結果をserverに報告しに行きます。server側も、~/.yggdrasil/result というフォルダにclientからの報告を格納します。そうして、yggserve result というコマンドを使うと、clientたちの結果に問題が無いかどうかを一度に確認することができます。
楠川さんのおすすめは、clientからのserverへの報告はcronで行い、server上では yggserve result コマンドをJenkinsを使って処理する、というものでした。
私の環境の場合は、ygg serverに当たるサーバはJenkins masterには利用できなかったので、Jenkins slaveとして設定し、いつも使っているJenkins maseter上で他のジョブと一緒にチェックを行うようにしてみました。
実は、わたしも設定ファイルは所々Subversionに登録してはいたのですが、/etc/... とか、/usr/local/... とか、ディレクトリにばらつきがあり、どうもうまく管理できていませんでした。
yggdrasilのおかげで、そういったパスのばらつきを考慮しなくても、yggdrasilのコマンドが宜しくやってSubversionに登録／変更をチェックしてくれるので、『これは良い感じ！』と思いました:)
若干？ハードルになるのは、rubyが必要だというあたり。
インストール直後でほとんどツールが入っていないOSだとすぐには使えませんが、今回はruby入りのサーバをコピーして複数台をチェックという状況でしたので、すんなり使えています。
なお、しがないバックオフィスのスタッフの身なので、恥ずかしながらコマンドラインで使うruby gemは意識して入れるのが初めてでした。
その上で、ソースも拝見して、『こんなふうに書くんだ〜』と、とっても勉強させていただいております。
ということで、ひきつづき1ユーザとしてお世話になってみようと思います！
コメント
コメントを投稿