--json-attributes <json>もしくは-j <json>オプションを使えばnodes/*.jsonを作らなくても走らせることができた。
$ knife solo cook myserver.01 -j '{"hostname":"myserver.01"}'
みたいな感じ。
さすがにJSONを長々と書くのは不便なので、基本となるロールをroles/*.rbに定義して、ノードごとに異なる値をJSONで渡す形式にしてやるとよさそう。
ロールは--override-runlist 'role[<role>]'もしくは-o 'role[<role>]'で指定できる。カンマ区切りで複数指定も可。
$ knife solo cook myserver.01 -o 'role[app]' -j '{"hostname":"myserver.01"}'
みたいな感じ。
とりあえず動くようになったのでv0.0.7と中途半端だけどリリースした。rubygems.orgもしくはGitHubを参照。
次のようにノードを複数指定するとそれらに対して並列にknife soloコマンドを実行する。
$ paknife solo cook node1 node2 node3
デフォルトだと同時に2つまでに制限しているんだけど、これは--threadsもしくは-tオプションで指定できる。
$ paknife --threads 3 solo cook node1 node2 node3 node4 node5 node6
もしくは同時実行数の代わりにmaxを渡すと、指定したノード数だけ同時に実行する。
$ paknife --threads max solo cook node1 node2 node3 node4 node5
このオプションは環境変数PAKNIFE_THREADSでも指定できる。
デフォルトだと$ paknife solo ...としたときには$ bundle exec knife solo ...を実行している。
これは大体のgemはbundlerを使ってプロジェクトごとに入れてるだろうって想定からそうしているんだけど、場合によってはグローバルでknife-soloを入れているかもしれない。そういうときには--knifeもしくは-kオプションでそのknifeを実行するためのパスを記述する。
$ paknife --knife="knife" solo cook node1 node2
このオプションは環境変数PAKNIFE_KNIFEでも指定できる。
knife-soloオリジナルのオプションは末尾に付けることで、個々のknife soloコマンドに渡される。
$ paknife solo cook node1 node2 -W
最近にわかに注目を浴びているchef-zeroを使ったknife-zeroも多分動く。knife-soloとサブコマンドの渡し方が同じ限り。
まだあまり使ってないので自信はない。
naoyaさんのスライドでKAIZEN社内でparaknifeという並列に走らせるコマンドがあると知り、OSSになる雰囲気がなかったので自分で作ってみた。
大きな変更を数台のサーバに行うぐらいだと、普通にknife soloで個別にログを見ながらやるのがいいけど、10台程度に対してちょっと設定を変えるぐらいだと並列に処理できたほうが圧倒的に楽だ。
名前についてはparaknifeの語感がよかったので使いたかったけど、でもすでにどこかにあるものの名前をつけるのもなんかアレだなってことで、paknifeにした。
自分の中では「ぱない（ふ）」ぐらいの、「ふ」を弱めに発音して「パない」になりつつある。もしご利用になられる場合にはお好きな様に読んで（呼んで）いただけたらと思う。
https://github.com/a2ikm/paknife/issuesやTwitterにてお待ちしております。
時々knife solo cookを叩いても、ローカルのレシピへの変更が反映されないことがある。
そういうときはknife solo cleanを叩いて以前リモートに転送したレシピを削除し、それから再度knife solo cookを叩くと直ったりする。
$ knife solo clean HOSTNAME $ knife solo cook HOSTNAME
内容については意識高いのコメントやチャット、togetterなどを参照。
普段参加している勉強会とは違ってインフラの人が多くてちょっと新鮮だった（SIerの中の人とか多かったのかな？）。
最近Vagrant+ChefをCapistranoのデプロイのテスト環境として使おうと触っていて、そのときに必要になるGitHubへの公開鍵への登録をどうやるかもくもくと調べていた。
やり方的には2つあると思っていて、1つはホスト側で鍵を生成しておいて公開鍵を登録しておき、秘密鍵を初up時にゲスト側にコピーする。詳しく調べられていないけど、ホストとゲスト間のデータのやり取りにはdata_bagsが使えそうで、暗号化もできるらしい。
もう1つは @joker1007 さんが以前にやったという方法で、初up時にゲスト側で鍵を生成してGitHubのAPI経由で登録するというもの。鍵の生成にはこのへんが使えそうで、後者にはこのへんが使えそう。ただAPIを扱うにはOAuthのトークンやシークレットをホスト側に渡す必要があって、これもやっぱり暗号化が必要になりそう。（@joker1007 さんが時間ができたらまとめるとのことなので、ちょっと期待してます）
というあたりまで漕ぎ着けて終わってる。
懇親会では、クラウド選ぶなら今のところAWS一択とか、以前と違ってセキュリティ的な課題よりも金額的な部分でAWSにするか自前で持つかを考えることが多くなったとか、面白い話が聞けた。特に後者はデブサミ2013のサーバーワークスさんのスライドを読んでから気になってた*1。あとAWSのCloudFrontとかRoute53は圧倒的にコスパがいいらしい。
会場を提供してくれた万葉さん、企画してくれたほっかいさん、ありがとうございました。
*1:ブコメにある、法律も違う海外の会社に依存しすぎるのもどうなのよ、ってのも気になるところ
Vagrant 入門 - Mac 上に仮想マシンを簡単に用意するでVagrantを入れたら色々やってみたいよねということで、chef-soloと連携してgitを入れてみる。
まずはVagrantfileのあるディレクトリに移動して、cookbooksディレクトリを作成しておく。
cd (Vagrantfileのあるディレクトリ) mkdir cookbooks
opscodeの公開しているgitのcookbookがあるのでそれを使う。
git clone git@github.com:opscode-cookbooks/git.git cookbooks/git
Vagrantfileにcookbookを読むように指定する。
# Vagrantfile Vagrant.configure("2") do |config| config.vm.provision :chef_solo do |chef| chef.cookbooks_path = "cookbooks" # cookbooksディレクトリのパスを指定 chef.add_recipe "git" end end
適用するとき、起動していないならvagrant up、起動しているならvagrant provisionすればインストールされる。
Vagrantfileで次のように記述する。
Vagrant.configure("2") do |config| config.vm.provision :chef_solo do |chef| chef.log_level = :debug end end
