公式のChef MetalのGitHubのページに翻訳をつけてみました。おかしいところがあったら、pull requestを送ってみてくださいね！
Chef Metal
このライブラリは、Chefで繰り返しマシンやインフラストラクチャをつくないといけないという問題を解決します。このツールは、プラグインモデルで、ブートストラッパ(bootstrappers)をあなたのお好みのインフラストラクチャに書く事もできます。VirutualBox, EC2, LXC, bare metalや、その他多くのインフラをサポートしています。
現状では、Chef Metalは、vagrantと、ssh経由のUnixと、Windows/winrm を本物のシェフサーバーか、chef魔術的なカンタンさを持つchef-zeroのトンネリングで提供します。FogとDockerも次のバージョンでカバーする予定です。(EC2とLXCも含みます)。イメージのファクトリ(マシンリソースをイメージを創る為に使う)は今後も拡張していきたいと思っています。PXEのサポートもです。
試してみよう
まずは、chef 11.8以上をインストールしてから次のコマンドを実行してみましょう。
git clone https://github.com/opscode/cheffish.git
cd cheffish
rake install
cd ..
git clone https://github.com/opscode/chef-metal.git
cd chef-metal
rake install
cd chef-metal
chef-client -z -o myapp::vagrant,myapp::linux,myapp::small
翻訳者注：上記の手順では、4/18の時点では、そのまま動作しませんChef Metalの凄さを体験しようというフォロー記事を書いておきました。
このコマンドは、２つのvagrantのprecise64 linuxのboxを作ります。marioとluigi1という名前です。これは、~/machinetestに作られます。空白のrunlistで起動されます。Windows向けには、myapp::linuxの部分をmyapp::windowsに変えてください。windowsはライセンスが必要なので注意してください。
Chef Metalとは？
Chef Metalは、２つの主な抽象化された概念をもっています。machine resourceと、provisionerです。
The machine resource
machineリソースを使って、あなたはマシンに何をしてほしいかを定義します。(recipesとかtags等)これは、Chef Metalの基本的なユニットです。あなたはmachineリソースを、分割された、そして、OS/provisioningから独立したように記述します。これはあなたのネットワーク構成を定義して、各ノード上で、レシピを実行します。
machineリソースは、サンプルについているmyapp::smallがわかりやすいでしょう。ここに、一部を貼っておきます。
machine 'mario' do
recipe 'postgresql'
recipe 'mydb'
tag 'mydb_master'
end
num_webservers = 1
1.upto(num_webservers) do |i|
machine "luigi#{i}" do
recipe 'apache'
recipe 'mywebapp'
end
end
これを見ていると、web serverの数が、ダイナミックに設定出来るのがわかるでしょう。全てコードでできます。あなたの想像力が制約になるでしょう。 :)
Kitchen
Chef Metalは、Test Kitchenとも動作します。あなたにテストクラスタを提供します。マシンだけではなくてです。kitchen-metal gemはhttps://github.com/doubt72/kitchen-metalにあります。
Provisioners
Provisionerは、抽象的な概念を、実際の物理的な環境で動作するようにします。Provisionerは、タスクや、冪等性(idempotently: リソースを何回実行しても、マシンを１回だけ作ります。-- その過程で問題に気づいたり修正したりするかもしれませんけど。)
- クラウドからmachineを獲得します。コンテナ、VMもしくは、bare metalを作ります
- sshやvinrmやその他の方法で、machineに接続します
- chefの初期インストールを行って、レシピを適用します
ProvisionerのAPIは独立しています。ですので、新しいProvisionerを最小限の努力で作成できます(sshを上書きしたおり、トンネリングしたり、OSでサポートすることなくです) Chef Metalのユーザにとっては、一つのものとして、認識されます。machineの獲得は、賢くも他の事を自動で検出します(transportだったり、OSだったりです)
Provisionerは、Chef node自信のデータを保存します。そしてそれらのデータは、Chef Serverでノードを管理している全てのユーザからアクセスすることができるでしょう。
Provisionerは、それぞれ自分のリポジトリをもっています。今のProvionerのリストは次の通りです。
Cloud:
Virtualization:
Containers:
Bare Metal:
Vagrant
chef-zeroが、Vagrantのためのprovisionerとともに使われます。Virtual Box, VMWareや他の仮想マシンのProviderと共に使われます。実行するためには、Chef Metalリポジトリに含まれるサンプルレシピをを取得して次のようなコマンドを実行してみてください。
chef-client -z -o myapp::vagrant,myapp::linux,myapp::small
provisionerの仕様は、myapp::vagrantや、myapp::linuxのサンプルレシピその一部を掲載します。
vagrant_cluster "#{ENV['HOME']}/machinetest"
directory "#{ENV['HOME']}/machinetest/repo"
with_chef_local_server :chef_repo_path => "#{ENV['HOME']}/machinetest/repo"
vagrant_box 'precise64' do
url 'http://files.vagrantup.com/precise32.box'
end
vagrant_clusterは、どこに全てのVagrantが定義されているか、そして使われるかのディレクトリを定義します
with_provisionerは内部でChef Metalがmachineに対して、どのprovisionerを使いたいかを伝えます
vagrant_boxは、特定のvagrant boxが存在する場所を定義します。そして、``provisioner_options`の指定を要求します。例えばポートフォワーディング等です。OSの定義としては、Vagrantの流儀に則っています。より複雑なprovisioner optionsを使ったようなvagrant boxの例は、myapp::windowsで見る事ができます。
with_chef_local_serverは、一般的なディレクティブ（指示）です。これは、リポジトリの場所を示すchef-zeroサーバを作ります。あなたが指定すれば、node, client, data bagsなど全てのデータは、あなたのprovisionerのマシン上にストアされます。また、with_chef_serverは、chef-clientに対して使っているChef Serverを指定します。OSS, Hostedもしくは、Enterprise Chefさらに、何もサーバーに指定したくない時も使います。with_chef_serverを使っているとき、そして、chef-client -zをあなたのワークステーションで走らせているときには、クライアント名と、chef server用のsigning keyが必要になる事を忘れないでください。もし、あなたがknife.rbを書いているなら、それっぽいものが、クライアントに作られます。例えば、あなたがこんなknife.rbを書いているとすると:
require 'chef/config'
with_chef_server "https://chef-server.example.org", {
:client_name => Chef::Config[:node_name],
:signing_key_filename => Chef::Config[:client_key]
}
一般的にはこれは、machine リソース毎に分割して書きます。Chef Metalは、あなたが定義したprovisionerを録ってきて、あなたがリクエストしたmachineのインスタンスを作ります。実際のmachineの定義は、この場合myapp::smallの中にかかれます。そして、一般的には、同じようにEC2に対しても同じようにかけます。:
machine 'mario' do
recipe 'postgresql'
recipe 'mydb'
tag 'mydb_master'
end
num_webservers = 1
1.upto(num_webservers) do |i|
machine "luigi#{i}" do
recipe 'apache'
recipe 'mywebapp'
end
end
Fog (EC2もしくはそのファミリ)
chef-metalは、Fogのprovisionerを提供します。AmazonのEC2やその他のクラウドプロバイダのものです。(今のところEC2だけテストされています。)。使いたい時は、AWS credentialsを~/.aws/configにここで、Option1でお話したような、フォーマットでおいておく必要があります。
一旦credentialsが設置されたら、次のような感じで使います。
chef-client -z -o myapp::ec2,myapp::small
Provisionerの定義は、myapp::ec2に置きます。次のような感じです。
ec2testdir = File.expand_path('~/ec2test')
directory ec2testdir
with_fog_ec2_provisioner # :provider => 'AWS'
with_provisioner_options :image_id => 'ami-5ee70037'
fog_key_pair 'me' do
private_key_path "#{ec2testdir}/me"
public_key_path "#{ec2testdir}/me.pub"
end
with_fog_ec2_provisionerが、chef-metalに、EC2向けにFog provisionerを使うようにいいます。もし、あなたが、~/.aws/configの中にcredentialsを書いているなら、あなたは他に設定はいりません。Fogはデフォルトでそれを使います。hashのパラメータをwith_fog_ec2_provisionerに渡したいときはここを参照してください。
翻訳者注：「ここ」のリンクは現在リンク切れです。
fog_key_pairは、新しいキーペアを作ります(もし、ファイルが存在しないなら)そして、自動的に、Provisionerに、つづけて起動されるmachineの起動時にそれを使うように指示します。private/publicのキーペアは、最初にブートされるインスタンスに自動的にログオンの権限が与えられます。
オプション例えばamiみたいなものを渡したい時はこうします。
with_provisioner_options :image_id => 'ami-5ee70037'
もし、あなたが、machine毎の、起動時のオプションを渡したいとき、次のような感じにかけます
machine "Ubuntu_64bit" do
action :create
provisioner_options 'bootstrap_options' => {
'image_id' => 'ami-59a4a230',
'flavor_id' => 't1.micro'
}
end
あなたは、まだmyapp::smallを使っていることに気づくかもしれません。Machineの定義はprovisionerの定義と独立しています。これは、重要な機能で、このおかげで、あなたはクラスタを異なる場所に作る事ができます。stagingだったり、testだったり、development環境だったりといった具合です。
Bug報告と、今後の計画について
まだこのプロジェクトは始まったばかりです。bugを見つけたらhttps://github.com/opscode/chef-metal/issuesまで。また、jkeiserにコンタクトをとってください。Twitterでは、@jkeiser2, emailでは、jkeiser@opscode.comです。
もし、あなたがChef Metalの計画に興味があるなら、Trello board!をみてください。提案があれば、追加してください。そして、あなたに重要なissueに対して投票したり、コメントしたりしてみてください。そして、カードをピックアップして貢献していただいても結構です。実装に困ったら、私とチャットしてください(jkeiser@opscode.com)。そうでないと、単に制御不能になったり、PRすることになるでしょう。