2014.12.22

[和訳] SysAdvent Day 14: Chef Provisioningを用いてChef Serverを構築する #opschef_ja #getchef_ja

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本稿は SysAdvent Day 14: Using Chef Provisioning to Build Chef Server (2014/12/15) の和訳です。

Or, Yo Dawg, I heard you like Chef.

(訳注: インターネットミーム。Xzibit Yo Dawg | Know Your Meme、Yo Dawg | Meme Generatorを参照のこと)

この記事はSysAdventからの転載(訳注:原文)です。

本記事をEzra Zygmuntowiczに捧げます。Erzaがいなければ、初期のChef ServerのMerb、chef-soloはなかっただろうし、そしてChef自体もなかったかもしれません。Ruby、Rails、Chefコミュニティに対する彼の貢献は多大なものでした。ありがとうErza、安らかに。

(訳注: Ezra Zygmuntowicz氏は米Engine Yardの創業者の一人で、Railsデプロイの著者の一人としても知られています。病気のため先月末に亡くなられています)

本記事では、Chef Software,Inc.のChef Provisioning (訳注: 和訳)を用いて、Amazon EC2上にChef Server 12 (訳注: 和訳)を用いた新しいホステッドChefインフラを構築するユースケースを見ていきます。これは詳細な手引きではありませんが、実例を通してChef Provisioningを設定するために何が必要かを検討するための重要な要素を明らかにしていきます。Chef ProvisioningとChef Server 12をかけ足で見ていくものだと思ってください。

背景

しばらくChefを使ってきているなら、オープンソースChef Serverを起動するために必要なすべての要素をchef-soloでインストールするCookbookを用いたインストールガイドである「Bootstrap Chef RubyGems Installation」というwikiページを思い出すかもしれません。この考え方は、Enterprise Chef (旧名 Private Chef)のomnibusパッケージにある、Chef Serverのすべてのサービスを設定して起動するようにchef-soloを実行するprivate-chef-ctl reconfigureの原点でした。

驚かないと思いますが、Chef社ではホステッドChefをChefを用いて構築しています。そう、端から端まで亀の上の亀やyo-dawgのジョークのようです。Chef社CTOであるAdamが単一のChef Serverコードベースについて記述した通り、私達が内部で用いているデプロイ方法や開発方法を私達が顧客に提供するものと同じにしたいと考えており、よりよいサポートを提供するために方法を統一したいと考えています。

Chef Server 12

先日発表した通り (訳注: 和訳)、Chef Server 12が一般公開されました。本記事で検討していく実例のために、3つのマシンをプロビジョニングします。1つはバックエンド、1つはChef ManageとChef Reportingを動作させるフロントエンド、1つはChef Analyticsを動作させます。Chef Serverはアドオンをインストールする機能を持っているので、インストールを管理するためのResourceを持つ特別なCookbookである「Chef Server Ingredients」を用意しています。これを、APIフロントエンドNodeとバックエンドNodeの両方で用いるchef-server-coreと一緒にインストールしましょう。

Chef Provisioning

Chef Provisioningは、Recipe中に「machines」というChef Resourceを定義できるようにし、そのRecipeをNode上で収束させるという、Chefの新機能です。つまり新しいマシンを、いくつか例を挙げるならばAWS、OpenStack、Dockerなどの様々なプロバイダを用いて作成し、Chef Server上に有効な他のCookbookから得たRecipeを適用します。

Chef ProvisioningはプロビジョナNode上で「実行」します。これは通常ローカルのWorkstationですが、データセンターやクラウドプロバイダ上の特に指定されたNodeであるかもしれません。単純にchef-clientまたはchef-soloでRecipeを実行するだけです。chef-clientを使うなら、ホステッド版Chefを含むあらゆるChef Serverが動作します。もちろん、ここではChef Serverはまだ用意していません。本記事での例では、OS Xラップトップをプロビジョナ、Chef ZeroをChef Serverとして用います。

部品の組み立て

Chef Provisioningを用いる作業を行うCookbookはchef-server-clusterです。このCookbookは絶賛開発中なので、この記事中で書かれているコードと実際のコードが違っているかもしれないことに注意してください。よって、Chef Provisioningの使い方を見るために適当な箇所と、動作に必要なローカル設定の助けとなるように記述するつもりです。どのように使うかの最新情報はCookbookのREADME.mdを参照してください。

Amazon Web Services EC2

まずはじめに必要なものは、EC2インスタンスのためのAWSアカウントです。アカウントを取得したら、EC2の管理権限を持つIAMユーザと、インスタンスにログインするためのSSHキーペアが必要になります。これらをどうやって行うかの詳細は本記事の範囲を越えています。これらを取得したら、次のようにしてください。

アクセスキーとシークレットアクセスキーの設定を~/.aws/configに追加してください。これはchef-provisioningのAWSプロバイダに自動的に用いられます。SSHキーは後で記述するData Bag Item (JSON)内で用いられます。そして、利用したAWSリージョンを選びたいでしょう。ここでは例のため、キーペアの名前はhc-metal-provisioner、リージョンはus-west-2とします。

Chef Provisioningは、次の3か所でSSHキーを見つけられる必要があります。

.chef/knife.rbファイルのprivate_keysとpublic_keys設定
マシンインスタンスに接続するためのAWSドライバの設定に用いられるmachine_options設定
Recipe内

これについて後で詳しく記述します。

Chefレポジトリ

ホステッドChefインフラのためのすべての材料を格納するためにChefレポジトリを用います。例のために、新規のレポジトリを利用します。ChefDKのchef generateコマンドを用いましょう。

% chef generate repo sysadvent-chef-cluster

このレポジトリはPolicyfile.rb、.chef/knife.rb設定ファイル、Data Bag群を格納します。最新の実装仕様はchef-server-cluster CookbookのREADME.mdにあります。

Chef ZeroとKnife Config

前述の通り、Chef Zeroがこの例のためのChef Serverで、特定のポート(7799)で動作します。別のターミナルで次のように開始しました。

% chef-zero -l debug -p 7799

Knife設定ファイルは2つの目的があります。1つ目はChef Zeroにすべての要素を読み込ませるため、2つ目はchef-clientを動作させる最低限の設定を提供するためです。必要な設定を見てみましょう。

これはchef、knife、chef-clientの各コマンドが先に起動したchef-zeroインスタンスを用いるようにするという設定です。

chef_server_url 'http://localhost:7799' node_name 'chef-provisioner'

次の節で、ポリシーファイル機能について詳しく述べるつもりです。これらの設定はchef-clientにポリシーファイルを用いるようにし、Chef Clientが用いるべきデプロイメントグループを指定するものです。

use_policyfile true deployment_group 'sysadvent-demo-provisioner'

前述の通り、どこにあるキーを読み込むかChef Provisioningに知らせるための設定オプションです。キーファイルはプロビジョニングNodeのどこかに存在していなければいけません。

まずKnife設定です。

private_keys 'hc-metal-provisioner' => '/tmp/ssh/id_rsa' public_keys 'hc-metal-provisioner' => '/tmp/ssh/id_rsa.pub'

そしてRecipeです。これはchef-server-cluster::setup-ssh-keysの現在のバージョンに基きます。

fog_key_pair node['chef-server-cluster']['aws']['machine_options']['bootstrap_options']['key_name'] do private_key_path '/tmp/ssh/id_rsa' public_key_path '/tmp/ssh/id_rsa.pub' end

ここでのAttributeはドライバオプションの一部で、chef-server-cluster::setup-provisionerにあるChef Provisioningのwith_machine_optionsメソッドの設定に用いられます。マシンオプションについて詳しくはChef Provisioning configuration documentationを参照してください。マシンオプションは自動的に~/.chef/keysや~/.sshに格納されたキーを用いるので、テストプロビジョニングのためのローカル開発システムでのおかしな衝突を避けるためにこのようにしています。報告されている問題も見てください。

ポリシーファイル

みなさん、気をつけて！ これは後々変更される~~かもしれない~~実験的な新機能です。それでも試してみたいというのであれば、この記事のワークフローが役に立つことでしょう。ポリシーファイルについて詳しくはChefDKのレポジトリを参照してください。特に「Motivation and FAQ」(訳注: 動機とFAQ)を読んでください。また、プロビジョニングシステムにインストールしたChef DKパッケージに含まれている、Chef (Client) 12が必要です。

ポリシーファイルについての基本的な考え方は、Nodeのrun listとして、インフラの仕事を満足するのに必要なRoleやRecipeをすべて含んだ構成要素を組み立てるということです。各Policyfile.rbは少なくとも次を含みます。

name: ポリシーの名前
run_list: ポリシーを使うNodeのrun list
default_source: Supermarketのような、Cookbookをダウンロードすべき場所
cookbook: ポリシーを満足するのに必要なCookbookを定義

この例で利用する、レポジトリの最上位に置いておくPolicyfile.rbです。

name 'sysadvent-demo' run_list 'chef-server-cluster::cluster-provision' default_source :community cookbook 'chef-server-ingredient', '>= 0.0.0', :github => 'opscode-cookbooks/chef-server-ingredient' cookbook 'chef-server-cluster', '>= 0.0.0', :github => 'opscode-cookbooks/chef-server-cluster'

Policyfile.rbを作成したら、chef installコマンドでロックファイル(Policyfile.lock.json)にコンパイルする必要があります。ポリシーのインストールは次のように行います。

ポリシーの構築
~/.chefdk/cache/cookbooksのようなCookbookの格納場所にCookbookを「インストール」
ロックファイルを生成

この手順では、CookbookやポリシーをChef Serverにアップロードしません。後述の節でchef pushを用いてアップロードします。

Data Bag

Chef社では、設定可能なデータや秘密データをData Bagに移すことを推奨しています。秘密データについて、私達は通常Chef Vaultを用いていますが、この例では取り扱いません。chef-server-cluster Cookbookは、Chef Clientを実行するより前に必要ないくつかのData Bag Itemを持っています。

data_bagsディレクトリ以下には次のようなディレクトリとファイルがあります。

secrets/hc-metal-provisioner-chef-aws-us-west-2.json: hc-metal-provisioner-chef-aws-us-west-2という名前は、chef-server-cluster::setup-ssh-keys Recipeが正しいitemを読み込むためのものです。AWSキーペアの秘密・公開SSHキーはプロビジョナNodeの/tmp/sshに書き出されます。
secrets/private-chef-secrets-_default.json: Chef Serverシステムのためのすべての秘密データで、/etc/opscode/private-chef-secrets.jsonに書き込まれます。
chef_server/topology.json: Chef Serverのトポロジと設定です。現時点ではより多くの設定オプションを持つ/etc/opscode/chef-server.rbに対して十分ではないのですが、将来拡張予定です。

必要なData Bag Itemについて最新の詳細はchef-server-cluster CookbookのREADME.mdを参照してください。注意: 現時点では秘密データにchef-vaultが用いられていませんが、将来変更予定です。

レポジトリのアップロード

それでは、プロビジョナNodeを収束するためとChef Serverクラスタを起動するために必要なすべての要素を組み立てたので、すべてをChef Serverに読み込まれるようにしましょう。

ポリシーファイルをコンパイル、インストールし、provisionerデプロイメントグループにプッシュします。グループ名は、先にknife.rbで設定したポリシー名に結び付いています。chef pushコマンドでCookbookをアップロードし、ポリシーファイルにJSON形式で格納されているData Bag Itemも作成します。

% chef install % chef push provisioner

次に、Data Bagをアップロードします。

% knife upload data_bags

必要なすべてがChef Server上にあるかどうか、knifeコマンドで確認します。

% knife data bag list chef_server policyfiles secrets % knife cookbook list apt 11131342171167261.63923027125258247.235168191861173 chef-server-cluster 2285060862094129.64629594500995644.198889591798187 chef-server-ingredient 37684361341419357.41541897591682737.246865540583454 chef-vault 11505292086701548.4466613666701158.13536425383812

なんだこのいかれたバージョン番号は？これはポリシーファイルの機能によるものです。人間が可読性のあるバージョン番号はもはや使われず、Cookbookバージョンはユニークで、自動生成されたバージョン文字列で、与えられたポリシーに正確なCookbook依存関係だとわかっているポリシーに基いています。プロビジョナNodeでChefを実行したら、このポリシーのバージョンを用います。マシンインスタンスでChefを実行したら、ポリシーファイルを用いていないので、最新のバージョンを用いてしまいます。将来、Chef Provisioningで管理している各Nodeでもポリシーを持てるようにする予定です。

確認点

ここまでのおさらいです。

ChefDKを、Chef Clientバージョン12とともに、ローカルのプロビジョニングNode (ラップトップ)にインストール
EC2インスタンスを管理するためのAWS IAMユーザクリデンシャルを~/.aws/configに配置
ローカルNodeでchef-zeroを用いてChef Serverを実行
chef-server-cluster Cookbookとその依存関係
Chef ProvisioningがEC2インスタンスにログインするためのSSHキーを含む、chef-server-clusterのRecipeを用いるために必要なData Bag Item
chef-zeroサーバにchef-clientを向けるため、ポリシーファイルを利用するためのknife.rb設定ファイル

Chef Client

ようやく、待ちに待った瞬間(というかちょっと長い時間かも...)がやってきました！プロビジョニングNodeでchef-clientを動かす時間です。

% chef-client -c .chef/knife.rb

実行している間に、ここで何をしているかを説明します。

通常、chef-clientが実行する際、/etc/chef/client.rbから設定を読み込みます。説明した通り、今は独自のrun listと設定を持っているラップトップを用いているので、これまで説明しているknife.rbを指定する必要があります。これによって、7799ポートで動いているchef-zero Chef Serverとポリシーファイルのデプロイメントグループを用いることができます。

Chefがポリシーファイルからrun listを取得している次のような出力を得られているはずです。

resolving cookbooks for run list: ["chef-server-cluster::cluster-provision@0.0.7 (081e403)"] Synchronizing Cookbooks: - chef-server-ingredient - chef-server-cluster - apt - chef-vault

出力の残りはChefユーザにとってなじみがあると思いますが、Chef Provisioningが行っていることについて説明しましょう。まず、次のResourceがchef-server-cluster::cluster-provision Recipe内にあります。

machine 'bootstrap-backend' do recipe 'chef-server-cluster::bootstrap' ohai_hints 'ec2' => '{}' action :converge converge true end

Chef Serverクラスタに構築する最初のシステムは、他のNodeに用いられるデータの格納庫を「ブートストラップ」するバックエンドNodeです。これはPostgreSQLデータベースやRabbitMQメッセージキューなどを含みます。次はChef Provisioningがこのmachine Resourceを作成する際の出力です。

Recipe: chef-server-cluster::cluster-provision * machine[bootstrap-backend] action converge - creating machine bootstrap-backend on fog:AWS:862552916454:us-west-2 - key_name: "hc-metal-provisioner" - image_id: "ami-b99ed989" - flavor_id: "m3.medium" - machine bootstrap-backend created as i-14dec01b on fog:AWS:862552916454:us-west-2 - Update tags for bootstrap-backend on fog:AWS:862552916454:us-west-2 - Add Name = "bootstrap-backend" - Add BootstrapId = "http://localhost:7799/nodes/bootstrap-backend" - Add BootstrapHost = "champagne.local" - Add BootstrapUser = "jtimberman" - create node bootstrap-backend at http://localhost:7799 - add normal.tags = nil - add normal.chef_provisioning = {"location"=>{"driver_url"=>"fog:AWS:XXXXXXXXXXXX:us-west-2", "driver_version"=>"0.11", "server_id"=>"i-14dec01b", "creator"=>"user/IAMUSERNAME, "allocated_at"=>1417385355, "key_name"=>"hc-metal-provisioner", "ssh_username"=>"ubuntu"}} - update run_list from [] to ["recipe[chef-server-cluster::bootstrap]"] - waiting for bootstrap-backend (i-14dec01b on fog:AWS:XXXXXXXXXXXX:us-west-2) to be ready ... - bootstrap-backend is now ready - waiting for bootstrap-backend (i-14dec01b on fog:AWS:XXXXXXXXXXXX:us-west-2) to be connectable (transport up and running) ... - bootstrap-backend is now connectable - generate private key (2048 bits) - create directory /etc/chef on bootstrap-backend - write file /etc/chef/client.pem on bootstrap-backend - create client bootstrap-backend at clients - add public_key = "-----BEGIN PUBLIC KEY-----\n..." - create directory /etc/chef/ohai/hints on bootstrap-backend - write file /etc/chef/ohai/hints/ec2.json on bootstrap-backend - write file /etc/chef/client.rb on bootstrap-backend - write file /tmp/chef-install.sh on bootstrap-backend - run 'bash -c ' bash /tmp/chef-install.sh'' on bootstrap-backend

ここから、Chef Provisioningはたった今作成したマシン上でchef-clientを実行します。このinstall.shスクリプトは、Chef社のomnitruckサービスの1つを用いています。これはChefの現在のリリースバージョン、執筆時点では11.16.4をインストールします。12ではないことに注意してください。このマシンでポリシーファイルを利用できない他の理由がこれです。machine Resourceで指定したrun listを用いているバックエンドインスタンスでchef-clientが動き始めます。

Starting Chef Client, version 11.16.4 resolving cookbooks for run list: ["chef-server-cluster::bootstrap"] Synchronizing Cookbooks: - chef-server-cluster - chef-server-ingredient - chef-vault - apt

この出力では、次のRecipeとResourceを見ることができます。

Recipe: chef-server-cluster::default * chef_server_ingredient[chef-server-core] action reconfigure * execute[chef-server-core-reconfigure] action run - execute chef-server-ctl reconfigure

「ingredient」はChef Serverの構成要素で、前述のコアパッケージかChef ManageやChef ReportingといったChef Serverアドオンの1つです。アドオンの通常のインストール手順では、chef_server_ingredient Resourceによってすべて扱われている、適切なctl reconfigureを実行しています。このreconfigureは実際にはChef Soloを実行しているので、chef-clientの実行中にchef-clientを実行してさらにchef-soloを実行していることになります。

bootstrap-backend Nodeは、他のNodeで必要ないくつかのファイルを生成します。Chef Provisioningからそれらが利用できるように、machine_file Resourceを用います。

%w{ actions-source.json webui_priv.pem }.each do |analytics_file| machine_file "/etc/opscode-analytics/#{analytics_file}" do local_path "/tmp/stash/#{analytics_file}" machine 'bootstrap-backend' action :download end end

machine_file '/etc/opscode/webui_pub.pem' do local_path '/tmp/stash/webui_pub.pem' machine 'bootstrap-backend' action :download end

これらはローカルNode、すなわちプロビジョナに「隠されて」います。これらはChef Manage WebUIとChef AnalyticsのNodeに用いられます。プロビジョナでこのRecipeを実行すると、次のような出力を得られます。

* machine_file[/etc/opscode-analytics/actions-source.json] action download - download file /etc/opscode-analytics/actions-source.json on bootstrap-backend to /tmp/stash/actions-source.json * machine_file[/etc/opscode-analytics/webui_priv.pem] action download - download file /etc/opscode-analytics/webui_priv.pem on bootstrap-backend to /tmp/stash/webui_priv.pem * machine_file[/etc/opscode/webui_pub.pem] action download - download file /etc/opscode/webui_pub.pem on bootstrap-backend to /tmp/stash/webui_pub.pem

これらはfiles Resource AttributeでフロントエンドとAnalyticsマシンにアップロードされます。ファイルはハッシュとして指定します。キーはマシンにアップロードする対象のファイルで、値はプロビジョニングNodeの元ファイルです。

machine 'frontend' do recipe 'chef-server-cluster::frontend' files( '/etc/opscode/webui_priv.pem' => '/tmp/stash/webui_priv.pem', '/etc/opscode/webui_pub.pem' => '/tmp/stash/webui_pub.pem' ) end

machine 'analytics' do recipe 'chef-server-cluster::analytics' files( '/etc/opscode-analytics/actions-source.json' => '/tmp/stash/actions-source.json', '/etc/opscode-analytics/webui_priv.pem' => '/tmp/stash/webui_priv.pem' ) end

注意: これらのファイルはSSHを用いて転送されるので、平文で流れることはありません。

プロビジョナは次にフロントエンドを収束し、Analytics Nodeが続きます。バックエンドで先に見たような出力が得られるまで、飛ばしていきましょう。

* machine[frontend] action converge ... SNIP - upload file /tmp/stash/webui_priv.pem to /etc/opscode/webui_priv.pem on frontend - upload file /tmp/stash/webui_pub.pem to /etc/opscode/webui_pub.pem on frontend

フロントエンドにファイルがアップロードされ、WebUIが動作するようになりました。ちなみにWebUIはknifeやchef-clientのようなAPIクライアントです。

フロントエンドでchef-clientが動作すると、ingredient Resourceを通じてchef-server-coreをインストールしてchef-server-ctl reconfigureを実行するだけでなく、ManageアドオンとReportingアドオンを取得します。

* chef_server_ingredient[opscode-manage] action install * package[opscode-manage] action install - install version 1.6.2-1 of package opscode-manage * chef_server_ingredient[opscode-reporting] action install * package[opscode-reporting] action install - install version 1.2.1-1 of package opscode-reporting Recipe: chef-server-cluster::frontend * chef_server_ingredient[opscode-manage] action reconfigure * execute[opscode-manage-reconfigure] action run - execute opscode-manage-ctl reconfigure * chef_server_ingredient[opscode-reporting] action reconfigure * execute[opscode-reporting-reconfigure] action run - execute opscode-reporting-ctl reconfigure

前述のフロントエンドのように、Analytics NodeがEC2インスタンスとして作成され、ファイルがアップロードされます。

- upload file /tmp/stash/actions-source.json to /etc/opscode-analytics/actions-source.json on analytics - upload file /tmp/stash/webui_priv.pem to /etc/opscode-analytics/webui_priv.pem on analytics

そして、Analyticsパッケージがingredientとしてインストールされ、reconfigureされます。

* chef_server_ingredient[opscode-analytics] action install * package[opscode-analytics] action install - install version 1.0.4-1 of package opscode-analytics * chef_server_ingredient[opscode-analytics] action reconfigure * execute[opscode-analytics-reconfigure] action run - execute opscode-analytics-ctl reconfigure ... Chef Client finished, 10/15 resources updated in 1108.3078 seconds

これがプロビジョナでchef-clientを実行した最後になります。この表示になるまで待ちましょう。

結果と検証

Chef Serverのバックエンド、フロントエンド、Analyticsの各システムをEC2インスタンスとして3つのNodeを動かしています。chef-zeroサーバでNode Objectを見てみましょう。

% knife node list analytics bootstrap-backend chef-provisioner frontend

searchも利用可能です。

% knife search node 'ec2:*' -r 3 items found


analytics:

  run_list: recipe[chef-server-cluster::analytics]
bootstrap-backend:

  run_list: recipe[chef-server-cluster::bootstrap]
frontend:

  run_list: recipe[chef-server-cluster::frontend]
% knife search node 'ec2:*' -a ipaddress

3 items found
analytics:

  ipaddress: 172.31.13.203
bootstrap-backend:

  ipaddress: 172.31.1.60

frontend: ipaddress: 172.31.1.120

フロントエンドのIPアドレスにアクセスすれば、Chef Serverのマネジメントコンソールを用いてサインアップして、starter kitをダウンロードし、できたてのChef Serverに対して新しいNodeをブートストラップできます。

% unzip chef-starter.zip Archive: chef-starter.zip ... inflating: chef-repo/.chef/sysadvent-demo.pem inflating: chef-repo/.chef/sysadvent-demo-validator.pem % cd chef-repo % knife client list sysadvent-demo-validator % knife node create sysadvent-node1 -d Created node[sysadvent-node1]

AnalyticsのIPアドレスにアクセスすれば、作成したユーザでサインインでき、starter kitのダウンロードしたというイベントであるvalidatorクライアントキーの再生成、Nodeの作成を見ることができます。

次の展開

これまで見てきた通り、これは完全な機能を持ったChef Serverです。25 Nodeまで無料のManage、Reporting、Analyticsといったプレミアム機能を持っています。クリーンアップするRecipeを用いてクラスタを破棄することもできます。.chef/knife.rbのポリシーファイルを無効にすることで適用できます。

% grep policyfile .chef/knife.rb # use_policyfile true % chef-client -c .chef/knife.rb -o chef-server-cluster::cluster-clean Recipe: chef-server-cluster::cluster-clean * machine[analytics] action destroy - destroy machine analytics (i-5cdac453 at fog:AWS:XXXXXXXXXXXX:us-west-2) - delete node analytics at http://localhost:7799 - delete client analytics at clients * machine[frontend] action destroy - destroy machine frontend (i-68dfc167 at fog:AWS:XXXXXXXXXXXX:us-west-2) - delete node frontend at http://localhost:7799 - delete client frontend at clients * machine[bootstrap-backend] action destroy - destroy machine bootstrap-backend (i-14dec01b at fog:AWS:XXXXXXXXXXXXX:us-west-2) - delete node bootstrap-backend at http://localhost:7799 - delete client bootstrap-backend at clients * directory[/tmp/ssh] action delete - delete existing directory /tmp/ssh * directory[/tmp/stash] action delete - delete existing directory /tmp/stash

これまで見てきた通り、Chef Provisioning機能は強力で、Chef Server 12クラスタを動作させるための柔軟性も大いにあります。そのうち、私達はこれを用いてホステッドChefを再構築し、HA機能やスケールアウト可能なフロントエンド、フロントエンドサービスを複数のNodeに分割といったより多くの機能をCookbookに追加する予定です。