Vagrantが普通に使われるようになってきましたが、皆さん活用してますか？ 知っている方も多いと思うんですが、Vagrantは1.1以降からAWSやRackspace等のIaaSもproviderを追加する形で接続可能となっています。
vagrant up --provider=hogeとすることでサーバの立ち上げやprovisioningの実行が行えるというものです。
海外のIaaSやOpenStack等のOSS向けにはvagrant-*が揃い始めているのですが、国内のIaaS対応のものはこれまで(恐らく)ありませんでした。 そこでproviderとしてニフティクラウドを使えるようにするためのVagrant Pluginを作成してみました。
インストールは簡単。
vagrant plugin install vagrant-niftycloudで一発です。 コードはGithubに置いてますのでバグ報告やPull Request等お待ちしております！
Case 1 Develop locally. Test Remotelly.
普通にVagrantと(VirtualBox|VMWare Fusion)を使ったローカルでのテストで十分という方も多いと思います。 ではこのプラグインやその他のIaaS向けのVagrant providerの存在意義はどこにあるのでしょう？
以下のリンク先の動画の11:36辺り、Vagrantの作者のMitchell Hashimotoさんがこう仰っています。
Multi-provider Vagrant and Chef – AWS, VMware, and More – Mitchell Hashimoto – YouTube
これがニフティクラウド上で簡単に実現できるというところです。 今までもリモートサーバ上でchef-soloコマンドを打ったり、ローカルマシン上でknife soloコマンドを実行することでリモートマシンのprovisioningは実行できましたがVagrantを使うことでより簡単に「test remotely」が実現できます。
一例を見てみます。 Vagrantは同じbox名をprovider間で使い回すことができます。 「dummy」という名前でVirtualBox、niftycloud provider向けに2つboxを作ることができるということですね。
ローカルのVirtualBox上でChef Cookbook等の開発を行いたい場合には
vagrant up
実際に本番環境として使用するリモートサーバでテストしたい場合
vagrant up –provider=niftycloud
とすることでVagrantfileを書き換えることなしに実行環境を切り替えることが可能となります。
Case 2 高速にprovisioningが実行できる開発環境として
個人的には「Develop remotely. Test Remotely」もアリではないかと思います。 ローカルのVirtualBoxにvagrant upを実行して待ち時間に苛ついた人も多いのではないかと思います。
IaaS上で実行するとvagrant upでサーバが起動するまではローカルVMより遅いのですがvagrant provisionは高速です。 ローカルでは時間ばかり食って開発が終わらない！というような場合にリモートサーバを使うことも選択肢の一つとすることができます。
Case 3 CIの実行環境として
私が在職している会社ではJenkinsサーバにVirtualBoxとVagrantを入れてChef CookbookのCIを回しているんですが、下のような問題が出ています。
- Virtual Boxが不安定(vagrant -fに失敗してディスクフル等)
- メモリを食い潰す
- サーバリソース節約のため複数のジョブの同時実行ができない
こういった問題への解決策としてvagrant upする先をIaaSにすることによって並列実行も可能となります。
使い方
必要な環境等
Vagrant1.2以降が必要です。 Vagrantは1.0からインストール方法がgem経由ではなくパッケージでの提供に変更になっています。 ・旧バージョンを使っていた方が新バージョンを使いたい場合 ・昔のブログや雑誌等の記述を参考にする場合 等は注意が必要です。
Vagrantfileについても記述方法がバージョン違いで3つ程ありますが、今のところ後方互換があるようです。
対象となるServer Configuration Framework
- Chef
- Puppet
- Ansible
- CFEngine
等です。
私Chef以外は使ったこともなく、Chef以外のテストは行なっていないのですが、 プラグインの中でやっていることは
- VagrantがSSH経由でリモートサーバにコマンド実行可能にする
- rsyncによりローカルのファイルをリモートサーバに転送する
だけなので、Vagrant×VirtualBoxな環境で通常動作するもので、元となるサーバイメージとVagrantfileの記述が問題なければ動作すると思います。
boxファイルの追加
Vagrantを使うためのいつもの儀式。
vagrant box add dummy https://github.com/sakama/vagrant-niftycloud/raw/master/dummy.boxVirtualBoxやVMWare Fusion向けのboxと違い、jsonファイルとVagrantfileをtar.gzで固めただけなのでとても軽量です。
前者はVMイメージという感じですがこのプラグイン向けのboxファイルはデフォルト設定ファイルの塊というイメージになります。 Vagrantfileにデフォルト値を記述できるので、複数人で共有する場合にはオリジナルboxファイルを作成するといいと思います。
OSイメージの作成
Vagrantを使う場合以下のような制約が発生します。
- サーバに接続するvagrantユーザがパスワードなしでsudo実行できる必要がある(rootユーザではprovisioning実行に失敗します)
- sudoがttyなしで実行できる必要がある
- サーバに接続する際のSSH秘密鍵はパスフレーズが空で設定されている必要がある(rsyncでのファイル同期に失敗します)
そのため、ニフティクラウド公式のパブリックイメージは使えません。 上記制約をクリアしたプライベートイメージ等を各自作成する必要があります。 イメージ作成方法についてはGithubのREADMEを参照してください。
chef-client/chef-soloについてはインストールするかどうかはケースバイケースだと思います。 vagrant up時にvagrant-omnibusというgemを使ってインストールする方法もあります。 ただし、私の手元ではvagrant upするとprovisioningの手前で一時停止する現象が発生し、 vagrant provisionを再実行しないと動作しませんでした。
Ansible向けにvagrant-ansibleというのもあるようです。
Vagrantfileの作成
Chefを使う場合はこんな感じで。
実行
ほぼ通常のVagrantと同じです。vagrant up時のみproviderオプションの指定が必要です。
fork元のvagrant-awsにはhalt、suspend、resumeの実装はなかったんですが、こちらは実装しています。 vagrant-awsに実装がないのはVPC(Virtual Private Cloud)周りをゴニョゴニョしてるからではないかと思います。
# サーバ立ち上げ、provisioningの実行
$ vagrant up –provider=niftycloud
# 立ち上げたサーバへのprovisioningの実行
$ vagrant provision
# サーバの一時停止
$ vagrant halt
# サーバの一時停止(haltと同じ)
$ vagrant suspend
# 停止中のサーバの起動
$ vagrant resume
# サーバの破棄
$ vagrant destroy最後に
ニフティクラウドの場合RubyのSDKがあり(Javaもある)API接続処理は比較的簡単に書けました。
このプラグインやvagrant-awsを参考に国内の他のクラウド向けのvagrant-*を書くこともできると思いますが、APIはあってもSDKはないIaaSも多いのでネットワーク接続処理とか…そこは頑張れ。
まあ折角SDKもあるので、開発者コミュニティの層が厚くなって面白いツールが出てくるといいですねー(ﾟω｀)ﾁﾗｯﾁﾗｯ
