翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Chef のバージョン
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
OpsWorks スタックは複数のバージョンの Chef をサポートしています。[スタックを作成する](workingstacks-creating.md)ときにバージョンを選択します。 OpsWorks スタックは、そのバージョンと互換性のある組み込みレシピのセットとともに、スタックのすべてのインスタンスにそのバージョンの Chef をインストールします。カスタムレシピをインストールする場合、スタックの Chef バージョンと互換性がある必要があります。
OpsWorks スタックは現在、Linux スタックでは Chef バージョン 12、11.10、11.4、0.9、Windows スタックでは Chef 12.2 (現在の Chef 12.22) をサポートしています。便宜上の理由で、これらは通常、メジャーバージョン番号とマイナーバージョン番号でのみ示されます。Linux スタックの場合、使用する Chef のバージョンは、[スタックの作成](workingstacks-creating.md)時に設定マネージャを使用して指定できます。Windows スタックは Chef 12.2 を使用する必要があります。より新しい Chef のバージョンにスタックを移行するためのガイドラインなど、詳細については、「[Chef のバージョン](#workingcookbook-chef11)」を参照してください。バージョンの詳細については、「[OpsWorks スタックオペレーティングシステム](workinginstances-os.md)」を参照してください。
**Chef 12.2**
Chef 12.2 のサポートは、2015 年 5 月に導入されました。Windows スタックでのみ使用されます。Windows スタックの Chef の現行バージョンは Chef 12.22 です。Ruby 2.3.6 を使用して実行され、[chef-client をローカルモード](https://docs.chef.io/ctl_chef_client.html#run-in-local-mode)で使用します。これにより、[chef-zero](https://docs.chef.io/ctl_chef_client.html#about-chef-zero) と呼ばれるローカルインメモリ Chef サーバーが起動されます。このサーバーが存在する場合、レシピで Chef 検索およびデータバッグを使用できます。このサポートにはいくつか制限事項がありますが (「[レシピを実装する: Chef 12.2](workingcookbook-chef12.md)」を参照)、多くのコミュニティクックブックを変更せずに実行できます。
**Chef 12**
Chef 12 のサポートは、2015 年 12 月に導入されました。Linux スタックでのみ使用されます。Ruby 2.1.6 または 2.2.3 を使用して実行され、[chef-client をローカルモード](https://docs.chef.io/ctl_chef_client.html#run-in-local-mode)で使用します。これにより、レシピが Chef 検索とデータバッグを使用できるようになります。詳細については、「[OpsWorks スタックオペレーティングシステム](workinginstances-os.md)」を参照してください。
**Chef 11.10**
Chef 11.10 のサポートは、2014 年 3 月に導入されました。Linux スタックでのみ使用されます。Ruby 2.0.0 を使用して実行され、[chef-client をローカルモード](https://docs.chef.io/ctl_chef_client.html#run-in-local-mode)で使用します。これにより、レシピが Chef 検索とデータバッグを使用できるようになります。このサポートにはいくつか制限事項がありますが (「[レシピの実装: Chef 11.10](workingcookbook-chef11-10.md)」を参照)、多くのコミュニティクックブックを変更せずに実行できます。[Berkshelf](http://berkshelf.com/) を使用してクックブックの依存関係を管理することもできます。サポートされている Berkshelf バージョンは、オペレーティングシステムによって異なります。詳細については、「[OpsWorks スタックオペレーティングシステム](workinginstances-os.md)」を参照してください。Chef 11.10 を使用する CentOS スタックを作成することはできません。
**Chef 11.4**
Chef 11.4 のサポートは、2013 年 7 月に導入されました。Linux スタックでのみ使用されます。Ruby 1.8.7 を使用して実行され、[chef-solo](https://docs.chef.io/chef_solo.html) を使用します。Chef 検索やデータバッグはサポートされません。 OpsWorks スタックでは、これらの機能に依存するコミュニティクックブックを頻繁に使用できますが、「」の説明に従って変更する必要があります[新しい Chef バージョンへの移行 ](workingcookbook-chef11-migrate.md)。Chef 11.4 を使用する CentOS スタックを作成することはできません。Chef 11.4 スタックは、米国東部 (バージニア北部)リージョン以外のリージョンエンドポイントでのサポートはされていません。
**Chef 0.9**
Chef 0.9 は Linux スタックでのみ使用されますが、サポートが中止されました。注意:
+ コンソールを使用して新しい Chef 0.9 スタックを作成することはできません。
CLI または API を使用するか、別の Chef バージョンでスタックを作成し、スタック設定を編集する必要があります。
+ 新しい OpsWorks スタック機能は、Chef 0.9 スタックでは使用できません。
+ オペレーティングシステムの新しいバージョンでは、Chef 0.9 スタックに対して一部のサポートのみが提供される予定です。
特に、Amazon Linux 2014.09 およびそれ以降のバージョンでは、Ruby 1.8.7 が必要な Rails アプリケーションサーバーレイヤーを使用する Chef 0.9 スタックはサポートしていません。
+ ヨーロッパ (フランクフルト) などの新しい AWS リージョンでは、Chef 0.9 スタックはサポートされません。
新しいスタックへの Chef 0.9 の使用はお勧めしません。既存のスタックを新しいバージョンの Chef にできるだけ早く移行してください。
OpsWorks スタックでコミュニティクックブックを使用する場合は、新しい Linux スタックに [Chef 12 を指定](workingstacks-creating.md)し、既存の Linux スタックを Chef 12 に移行することをお勧めします。 OpsWorks スタックコンソール、API、または CLI を使用して、既存のスタックを新しい Chef バージョンに移行できます。詳細については、「[新しい Chef バージョンへの移行 ](workingcookbook-chef11-migrate.md)」を参照してください。
**Topics**
+ [Chef 12.2 スタック用のレシピを実装する](workingcookbook-chef12.md)
+ [Chef 12 スタック用のレシピの実装](workingcookbook-chef12-linux.md)
+ [Chef 11.10 スタック用のレシピの実装](workingcookbook-chef11-10.md)
+ [Chef 11.4 スタック用のレシピの実装](workingcookbook-chef11-4.md)
+ [新しいバージョンの Chef への既存の Linux スタックの移行](workingcookbook-chef11-migrate.md)
# Chef 12.2 スタック用のレシピを実装する
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
Chef 12.2 (現バージョン Chef 12.22) は、この Chef バージョンの実行が必須とされている Windows スタックでのみ使用可能となっています。
+ 目的によっては、レシピは Windows 固有の属性とリソースを使用する必要があります。
詳細については、「[Microsoft Windows 用の Chef](https://docs.chef.io/windows.html)」を参照してください。
+ Chef の実行に Ruby 2.3.6 が使用されるため、レシピで新しい Ruby の構文を使用できます。
+ レシピで Chef の検索およびデータバッグを使用できます。
Chef 12.2 スタックでは、多くのコミュニティクックブックを変更しないで使用できます。詳細については、「[Chef の検索の使用](workingcookbook-chef11-10.md#workingcookbook-chef11-10-search)」および「[データバッグの使用](workingcookbook-chef11-10.md#workingcookbook-chef11-10-databag)」を参照してください。
+ 「[OpsWorks スタックデータバッグリファレンス](data-bags.md)」および「[組み込みクックブックの属性](attributes-recipes.md)」で説明されているスタック設定およびデプロイ属性のほとんどは、Windows レシピに使用できます。
これらの属性値は、Chef 検索を使用して取得できます。例については、[Chef の検索での属性値の取得](cookbooks-101-opsworks-opsworks-stack-config-search.md)を参照してください。属性のリストについては、「[OpsWorks スタックデータバッグリファレンス](data-bags.md)」を参照してください。
# Chef 12 スタック用のレシピの実装
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
Chef 12 スタックは、Chef 11.10 スタックと比べて、次のような利点があります。
+ Chef の実行に Ruby 2.1.6 が使用されるため、レシピで新しい Ruby の構文を使用できます。
+ Chef 12 スタックでは、さらに多くのコミュニティクックブックを変更せずに使用できます。組み込みのクックブックがなければ、組み込みのクックブックとカスタムクックブック間の名前の競合は発生しなくなります。
+ スタックが構築済みのパッケージを提供している Berkshelf OpsWorks バージョンに制限されなくなりました。Berkshelf は Chef 12 の OpsWorks スタックインスタンスにインストールされなくなりました。代わりに、ローカルワークステーション上の任意の Berkshelf バージョンを使用できます。
+ スタックが Chef 12 (Elastic Load Balancing、Amazon RDS、Amazon ECS) OpsWorks とカスタムクックブックで提供する組み込みクックブックが明確に分離されるようになりました。これにより、エラーが発生した Chef のトラブルシューティングが容易になります。
# Chef 11.10 スタック用のレシピの実装
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
Chef 11.10 スタックは、Chef 11.4 スタックと比べて、次のような利点があります。
+ Chef の実行に Ruby 2.0.0 が使用されるため、レシピで新しい Ruby の構文を使用できます。
+ レシピで Chef の検索およびデータバッグを使用できます。
Chef 11.10 スタックでは、多くのコミュニティクックブックを変更せずに使用できます。
+ クックブックの管理に Berkshelf を使用できます。
Berkshelf は、カスタムクックブックを管理し、スタックでコミュニティクックブックを使用するための非常に柔軟な方法を提供します。
+ クックブックは、`metadata.rb` で依存関係を宣言する必要があります。
クックブックが別のクックブックに依存する場合、その依存関係をカスタムクックブックの `metadata.rb` ファイルに含める必要があります。たとえば、クックブックに `include_recipe anothercookbook::somerecipe` のようなステートメントを持つレシピが含まれている場合は、クックブックの `metadata.rb` ファイルに `depends "anothercookbook"` という行が含まれている必要があります。
+ OpsWorks スタックは、スタックに MySQL レイヤーが含まれている場合にのみ、スタックのインスタンスに MySQL クライアントをインストールします。
+ OpsWorks スタックは、スタックに Ganglia レイヤーが含まれている場合にのみ、スタックのインスタンスに Ganglia クライアントをインストールします。
+ デプロイで `bundle install` を実行し、インストールが失敗した場合、デプロイも失敗します。
**重要**
カスタムクックブックまたはコミュニティクックブックに組み込みクックブックの名前を再使用しないでください。組込クックブックと同じ名前のカスタムクックブックは失敗する可能性があります。Chef 11.10、11.4、0.9 のスタックで使用可能な組み込みクックブックの完全なリストについては、「[GitHub の opsworks-cookbooks リポジトリ](https://github.com/aws/opsworks-cookbooks)」を参照してください。
非 ASCII 文字が含まれているクックブックは、Chef 0.9 および 11.4 のスタックで正常に実行される場合でも、Chef 11.10 スタックでは失敗する可能性があります。これは Chef 11.10 スタックが、Ruby 1.8.7 よりもエンコードが厳密である Ruby 2.0.0 を使用して Chef を実行するためです。このようなクックブックが Chef 11.10 スタックで正常に実行されるためには、非 ASCII 文字を使用する各ファイルの先頭に、エンコードに関するヒントを提供するコメントを追加する必要があります。たとえば、UTF-8 エンコードの場合、コメントは `# encoding: UTF-8` のようになります。Ruby 2.0.0 のエンコードの詳細については、「[エンコード](http://www.ruby-doc.org/core-2.0.0/Encoding.html)」を参照してください。
**Topics**
+ [クックブックのインストールと優先順位](#workingcookbook-chef11-10-override)
+ [Chef の検索の使用](#workingcookbook-chef11-10-search)
+ [データバッグの使用](#workingcookbook-chef11-10-databag)
+ [Berkshelf の使用](#workingcookbook-chef11-10-berkshelf)
## クックブックのインストールと優先順位
OpsWorks スタッククックブックをインストールする手順は、Chef 11.10 スタックでは以前の Chef バージョンと若干異なります。Chef 11.10 スタックの場合、 OpsWorks スタックが組み込みクックブック、カスタムクックブック、および Berkshelf クックブックをインストールすると、次の順序で共通のディレクトリにマージされます。
1. 組み込みクックブック。
1. Berkshelf クックブック (ある場合)。
1. カスタムクックブック (ある場合)。
OpsWorks スタックはこのマージを実行すると、レシピを含むディレクトリのコンテンツ全体をコピーします。重複がある場合、次のルールが適用されます。
+ Berkshelf クックブックの内容は組み込みクックブックより優先されます。
+ カスタムクックブックの内容は Berkshelf クックブックより優先されます。
このプロセスがどのように機能するかを示すために、3 つのすべてのクックブックのディレクトリに `mycookbook` という名前のクックブックが含まれている、次のようなシナリオを考えてみます。
+ 組み込みクックブック — `mycookbook` は、`someattributes.rb` という名前の属性ファイル、`sometemplate.erb` という名前のテンプレートファイル、`somerecipe.rb` という名前のレシピを含みます。
+ Berkshelf クックブック — `mycookbook` は、`sometemplate.erb` および `somerecipe.rb` を含みます。
+ カスタムクックブック — `mycookbook` は、`somerecipe.rb` を含みます。
マージされたクックブックには次のものが含まれます。
+ 組み込みクックブックの `someattributes.rb`。
+ Berkshelf クックブックの `sometemplate.erb`。
+ カスタムクックブックの `somerecipe.rb`。
**重要**
組み込みクックブック全体をリポジトリにコピーし、クックブックの一部を変更することによって、Chef 11.10 スタックをカスタマイズしないでください。そうすることで、レシピを含む組み込みクックブック全体が上書きされます。 OpsWorks スタックがそのクックブックを更新する場合、プライベートコピーを手動で更新しない限り、スタックはこれらの更新のメリットを享受できません。スタックをカスタマイズする方法の詳細については、「[OpsWorks スタックのカスタマイズ](customizing.md)」を参照してください。
## Chef の検索の使用
レシピで Chef の [`search` メソッド](http://docs.chef.io/dsl_recipe.html#search)を使用して、スタックデータのクエリを実行できます。Chef サーバーと同じ構文を使用しますが、 スタックは Chef OpsWorks サーバーをクエリするのではなく、ローカルノードオブジェクトからデータを取得します。これには、以下のデータが含まれます。
+ インスタンスの[スタック設定およびデプロイ属性](workingstacks-json.md)。
+ インスタンスの組み込みクックブックとカスタムクックブックの属性ファイルにある属性。
+ Ohai によって収集されるシステムデータ。
スタック設定属性とデプロイ属性には、スタック内の各オンラインインスタンスのホスト名や IP アドレスなどのデータなど、レシピが検索を通じて通常取得するほとんどの情報が含まれます。 OpsWorks スタックは[ライフサイクルイベント](workingcookbook-events.md)ごとにこれらの属性を更新し、現在のスタック状態を正確に反映します。つまり、スタック内で検索に依存するコミュニティレシピを、変更せずに、頻繁に使用できます。search メソッドでは適切なデータが返されますが、データはサーバーではなく、スタック設定およびデプロイ属性から取得されます。
OpsWorks スタック検索の主な制限は、ローカルノードオブジェクトのデータ、特にスタック設定とデプロイ属性のみを処理することです。そのため、次のような種類のデータは検索で使用できない可能性があります。
+ 他のインスタンスにあるローカルに定義された属性。
レシピが属性をローカルで定義している場合、その情報は OpsWorks スタックサービスに報告されないため、検索を使用して他のインスタンスからそのデータにアクセスすることはできません。
+ カスタム `deploy` 属性。
[アプリケーションをデプロイ](workingapps-deploying.md)し、対応する属性がそのデプロイのスタックのインスタンスにインストールされるとき、カスタム JSON を指定できます。ただし、選択したインスタンスにのみデプロイする場合、属性はそのインスタンスにのみインストールされます。それらのカスタム JSON の属性に対するクエリは、他のすべてのインスタンスで失敗します。さらに、カスタム属性は、その特定のデプロイについてのみ、スタック設定およびデプロイ JSON に含められます。カスタム属性にアクセスできるのは、次回のライフサイクルイベントで、新しい一連のスタック設定およびデプロイ属性がインストールされるまでの間だけです。[スタックのカスタム JSON を指定する](workingstacks-json.md)場合、属性は、すべてのライフサイクルイベントについて、すべてのインスタンスにインストールされ、常に検索でアクセスすることができます。
+ 他のインスタンスの Ohai データ。
Chef の [Ohai ツール](http://docs.chef.io/resource_ohai.html)は、インスタンスでさまざまなシステムデータを取得し、ノードオブジェクトに追加します。このデータはローカルに保存され、 OpsWorks スタックサービスに報告されないため、検索で他のインスタンスから Ohai データにアクセスすることはできません。ただし、このデータの一部はスタック設定およびデプロイ属性に含まれる場合があります。
+ オフラインインスタンス。
スタック設定およびデプロイ属性には、オンラインインスタンスのデータのみが含まれます。
次のレシピの例では、検索を使用して、PHP レイヤーのインスタンスのプライベート IP アドレスを取得する方法を示します。
```
appserver = search(:node, "role:php-app").first
Chef::Log.info("The private IP is '#{appserver[:private_ip]}'")
```
**注記**
OpsWorks スタックがスタック設定属性とデプロイ属性をノードオブジェクトに追加すると、実際には 2 つのレイヤー属性のセットが作成され、それぞれが同じデータを持ちます。1 つのセットは `layers`名前空間にあります。これは、 OpsWorks スタックがデータを保存する方法です。もう 1 つのセットは `role` 名前空間にあります。Chef サーバーでは同等のデータはこのように保存されます。`role` 名前空間の目的は、Chef サーバーが OpsWorks スタックインスタンスで実行するために実装された検索コードを許可することです。 OpsWorks スタック専用のコードを記述する場合は、前の例`role:php-app`で `layers:php-app`または のいずれかを使用すると`search`、同じ結果が返されます。
## データバッグの使用
レシピ内で Chef の [`data_bag_item` メソッド](http://docs.chef.io/dsl_recipe.html#data-bag-item)を使用して、データバッグ内の情報に対するクエリを実行できます。Chef サーバーを対象とする場合と同じ構文を使用しますが、 OpsWorks スタックではインスタンスのスタック設定およびデプロイ属性からデータを取得します。ただし、 OpsWorks スタックは現在 Chef 環境をサポートしていないため、 `node.chef_environment` は常に を返します`_default`。
カスタム JSON を使用して `[:opsworks][:data_bags]` 属性に 1 つ以上の属性を追加することによって、データバッグを作成します。次の例では、カスタム JSON にデータバッグを作成するための一般的な形式を示します。
**注記**
クックブックリポジトリに追加することで、データバッグを作成することはできません。カスタム JSON を使用する必要があります。
```
{
"opsworks": {
"data_bags": {
"bag_name1": {
"item_name1: {
"key1" : “value1”,
"key2" : “value2”,
...
}
},
"bag_name2": {
"item_name1": {
"key1" : “value1”,
"key2" : “value2”,
...
}
},
...
}
}
}
```
通常、[スタックにカスタム JSON を指定](workingstacks-json.md)して、それ以降のすべてのライフサイクルイベントについて、すべてのインスタンスにカスタム属性をインストールします。アプリケーションをデプロイするときにカスタム JSON を指定することもできますが、それらの属性はそのデプロイについてのみインストールされるため、選択した一連のインスタンスにのみインストールされている可能性があります。詳細については、「[アプリケーションのデプロイ](workingapps-deploying.md)」を参照してください。
次のカスタム JSON の例は、`myapp` という名前のデータバッグを作成します。`mysql` という項目が 1 個と、キーと値のペアが 2 個含まれます。
```
{ "opsworks": {
"data_bags": {
"myapp": {
"mysql": {
"username": "default-user",
"password": "default-pass"
}
}
}
}
}
```
レシピでこのデータを使用するために、次の例に示すように、`data_bag_item` を呼び出して、データバッグと値の名前を渡すことができます。
```
mything = data_bag_item("myapp", "mysql")
Chef::Log.info("The username is '#{mything['username']}' ")
```
データバッグ内のデータを変更するには、単にカスタム JSON を変更するだけで、次のライフサイクルイベントについて、スタックのインスタンスにインストールされます。
## Berkshelf の使用
Chef 0.9 および 11.4 スタックでは、カスタムクックブックリポジトリを 1 つだけインストールできます。Chef 11.10 スタックでは、[Berkshelf](http://berkshelf.com/) を使用してクックブックとその依存関係を管理でき、これにより複数のリポジトリからクックブックをインストールできます。(詳細については「[ローカルでのクックブックの依存関係のパッケージ化](best-practices-packaging-cookbooks-locally.md)」 を参照してください)。特に、Berkshelf では、カスタムクックブックリポジトリにコピーする代わりに、 OpsWorks スタック互換のコミュニティクックブックをリポジトリから直接インストールできます。サポートされている Berkshelf バージョンは、オペレーティングシステムによって異なります。詳細については、「[OpsWorks スタックオペレーティングシステム](workinginstances-os.md)」を参照してください。
Berkshelf を使用するには、「[カスタムクックブックのインストール](workingcookbook-installingcustom-enable.md)」に説明されているように、明示的に有効にする必要があります。次に、インストールするクックブックを指定する `Berksfile` ファイルを、クックブックリポジトリのルートディレクトリに含めます。
Berksfile に外部クックブックソースを指定するには、デフォルトのリポジトリ URL を指定するファイルの先頭部分で source 属性を指定します。明示的にリポジトリが指定されていない限り、Berkshelf はそのソース URL でクックブックを探します。次に、インストールする各クックブックに対応する行を次の形式で追加します。
```
cookbook 'cookbook_name', ['>= cookbook_version'], [cookbook_options]
```
`cookbook` に続くフィールドが特定のクックブックを指定します。
+ [*cookbook\$1name*] (クックブックの名前) – (必須) クックブックの名前を指定します。
他のフィールドを指定しなかった場合、指定されたソース URL からクックブックがインストールされます。
+ [*cookbook\$1version*] (クックブックのバージョン) – (オプション) クックブックのバージョンを指定します。
`=` や `>=` などのプレフィックスを使用して、特定のバージョンまたは使用可能なバージョンの範囲を指定します。バージョンを指定しない場合、Berkshelf は最新のバージョンをインストールします。
+ [*cookbook\$1options*] (クックブックのオプション) – (オプション) 最後のフィールドは、リポジトリの位置などのオプションを指定する 1 つ以上のキーと値のペアを含むハッシュです。
例えば、`git` キーを含めて特定の Git リポジトリを指定したり、`tag`キーを含めて特定のリポジトリブランチを指定したりすることができます。リポジトリブランチを指定することは、通常、目的のクックブックを確実にインストールするための最適な方法です。
**重要**
Berksfile に `metadata` 行を追加し、`metadata.rb` でクックブックの依存関係を宣言することによって、クックブックを宣言することは避けてください。この処理が正常に実行されるためには、両方のファイルが同じディレクトリにある必要があります。 OpsWorks スタックでは、Berksfile はリポジトリのルートディレクトリにある必要がありますが、`metadata.rb`ファイルはそれぞれのクックブックディレクトリにある必要があります。代わりに、Berksfile 内で外部クックブックを明示的に宣言してください。
次に、クックブックを指定するさまざまな方法を示す Berksfile の例を示します。Berksfile を作成する方法の詳細については、「[Berkshelf](http://berkshelf.com/)」を参照してください。
```
source "https://supermarket.chef.io"
cookbook 'apt'
cookbook 'bluepill', '>= 2.3.1'
cookbook 'ark', git: 'git://github.com/opscode-cookbooks/ark.git'
cookbook 'build-essential', '>= 1.4.2', git: 'git://github.com/opscode-cookbooks/build-essential.git', tag: 'v1.4.2'
```
このファイルは、次のクックブックをインストールします。
+ コミュニティクックブックリポジトリにある `apt` の最新バージョン。
+ バージョン 2.3.1 以降である場合に限り、コミュニティクックブックにある `bluepill` の最新バージョン。
+ 指定されたリポジトリにある `ark` の最新バージョン。
この例の URL は GitHub のパブリックコミュニティクックブックのリポジトリ用ですが、プライベートリポジトリなど、他のリポジトリからクックブックをインストールできます。詳細については「[Berkshelf](http://berkshelf.com/)」を参照してください。
+ 指定されたリポジトリの v1.4.2 ブランチにある `build-essential` クックブック。
カスタムクックブックリポジトリには、Berksfile に加えて、カスタムクックブックを含めることができます。この場合、 OpsWorks スタックは両方のクックブックのセットをインストールします。つまり、インスタンスは最大 3 つのクックブックリポジトリを持つことができます。
+ 組み込みクックブックは、`/opt/aws/opsworks/current/cookbooks` にインストールされます。
+ カスタムクックブックリポジトリにクックブックが含まれる場合、そのクックブックは `/opt/aws/opsworks/current/site-cookbooks` にインストールされます。
+ Berkshelf を有効にし、カスタムクックブックリポジトリに Berksfile が含まれる場合、指定されたクックブックは `/opt/aws/opsworks/current/berkshelf-cookbooks` にインストールされます。
組み込みクックブックとカスタムクックブックは、セットアップ中に各インスタンスにインストールされ、カスタム[**クックブックの更新**スタックコマンド](workingstacks-commands.md)を手動で実行しない限り、後で更新されません。 OpsWorks スタックは Chef の実行`berks install`ごとに実行されるため、Berkshelf クックブックは[ライフサイクルイベント](workingcookbook-events.md)ごとに更新されます。
+ リポジトリに新しいバージョンのクックブックがある場合、このオペレーションは、リポジトリからのクックブックを更新します。
+ それ以外の場合、このオペレーションは、ローカルキャッシュから Berkshelf クックブックを更新します。
**注記**
このオペレーションは Berkshelf クックブックを上書きするため、クックブックのローカルコピーを変更している場合、その変更内容が上書きされます。詳細については「[Berkshelf](http://berkshelf.com/)」を参照してください。
また、Berkshelf クックブックとカスタムクックブックの両方を更新する **Update Custom Cookbooks** スタックコマンドを実行することによって、Berkshelf クックブックを更新することもできます。
# Chef 11.4 スタック用のレシピの実装
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
**重要**
カスタムクックブックまたはコミュニティクックブックに組み込みクックブックの名前を再使用しないでください。組込クックブックと同じ名前のカスタムクックブックは失敗する可能性があります。Chef 11.10、11.4、0.9 のスタックで使用可能な組み込みクックブックの完全なリストについては、「[GitHub の opsworks-cookbooks リポジトリ](https://github.com/aws/opsworks-cookbooks)」を参照してください。
Chef 11.4 スタックの大きな制限は、レシピで Chef の検索やデータバッグを使用できないことです。ただし、 OpsWorks Stacks は、検索で取得する多くの情報を含む[スタック設定属性とデプロイ属性](workingcookbook-json.md)を各インスタンスにインストールします。これには、以下が含まれます。
+ ホストまたはアプリケーション名など、コンソールからのユーザー定義のデータ。
+ スタックのレイヤー、アプリケーション、インスタンスなどの OpsWorks スタックサービスによって生成されたスタック設定データ、および IP アドレスなどの各インスタンスの詳細。
+ ユーザーによって提供されたデータを含み、データバッグとほぼ同じ目的で使用できる、カスタム JSON 属性。
OpsWorks スタックは、イベントの Chef 実行を開始する前に、ライフサイクルイベントごとに各インスタンスにスタック設定とデプロイ属性の最新バージョンをインストールします。データは、標準の `node[:attribute][:child_attribute][...]` 構文を通じてレシピに使用できます。たとえば、スタック設定およびデプロイ属性にはスタック名 `node[:opsworks][:stack][:name]` が含まれています。
組み込みのレシピの 1 つに含まれる次のコードは、スタック名を取得し、その名前を使用して設定ファイルを作成します。
```
template '/etc/ganglia/gmetad.conf' do
source 'gmetad.conf.erb'
mode '0644'
variables :stack_name => node[:opsworks][:stack][:name]
notifies :restart, "service[gmetad]"
end
```
スタック設定およびデプロイ属性の値の多くには、複数の属性が含まれています。必要な情報を取得するために、これらの属性を反復処理する必要があります。以下の例は、スタック設定およびデプロイ属性からの引用を示しています。便宜上、JSON オブジェクトとしてあらわされています。これには、最上位属性 `deploy` が含まれています。この最上位属性には、スタックの各アプリケーションの属性が含まれており、アプリケーションの短縮名が付いています。
```
{
...
"deploy": {
"app1_shortname": {
"document_root": "app1_root",
"deploy_to": "deploy_directory",
"application_type": "php",
...
},
"app2_shortname": {
"document_root": "app2_root",
...
}
},
...
}
```
各アプリケーション属性には、アプリケーションの特性を示す一連の属性が含まれています。例えば、`deploy_to` 属性は、アプリケーションのデプロイディレクトリを表します。次のコードは、アプリケーションの各デプロイディレクトリのユーザー、グループ、およびパスを設定します。
```
node[:deploy].each do |application, deploy|
opsworks_deploy_dir do
user deploy[:user]
group deploy[:group]
path deploy[:deploy_to]
end
...
end
```
スタック設定およびデプロイ属性の詳細については、「[OpsWorks スタックのカスタマイズ](customizing.md)」を参照してください。デプロイディレクトリの詳細については、「[Deploy レシピ](create-custom-deploy.md)」を参照してください。
Chef 11.4 のスタックはデータバッグをサポートしていませんが、[カスタム JSON](workingstacks-json.md) を指定することによって、スタック設定およびデプロイ属性に任意のデータを追加できます。レシピは、標準的な Chef のノード構文を使用して、データにアクセスできます。詳細については、「[カスタム JSON の使用](workingcookbook-json-override.md)」を参照してください。
暗号化されたデータバッグの機能が必要な場合、選択肢の 1 つとして、プライベート Amazon S3 バケットなどの安全な場所に機密性の高い属性を保存する方法があります。レシピは、すべての OpsWorks スタックインスタンスにインストールされている [AWS Ruby SDK](https://aws.amazon.com/documentation/sdkforruby/) を使用して、バケットからデータをダウンロードすることができます。
**注記**
各 OpsWorks スタックインスタンスにはインスタンスプロファイルがあります。関連付けられた [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/WorkingWithRoles.html) によって、インスタンスで実行中のアプリケーションがどの AWS リソースにアクセスできるかが指定されます。レシピで Amazon S3 バケットにアクセスするためには、ロールのポリシーに次のようなステートメントを含めて、指定されたバケットからファイルを取得するアクセス許可を付与する必要があります。
```
"Action": ["s3:GetObject"],
"Effect": "Allow",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
```
インスタンスプロファイルの詳細については、「[EC2 インスタンスで実行するアプリケーションに対するアクセス許可の指定](opsworks-security-appsrole.md)」を参照してください。
# 新しいバージョンの Chef への既存の Linux スタックの移行
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
スタックコンソール、API、または CLI を使用して、Linux OpsWorks スタックを新しい Chef バージョンに移行できます。ただし、新しいバージョンに対応するために、レシピに変更を加えることが必要になる場合があります。スタックを移行するための準備をするときに、次の点を考慮します。
+ スタックを編集またはクローンすることで OpsWorks、スタックスタックのバージョンを Chef 11 から Chef 12 に変更することはできません。Chef のメジャーバージョンアップグレードは、このセクションの手順を使用して行うことはできません。Chef 11.10 から Chef 12 への移行の詳細については、「[レシピの実装: Chef 12](workingcookbook-chef12-linux.md)」を参照してください。
+ Chef のあるバージョンから別のバージョンへの移行には多くの変更が伴い、その一部は互換性を破る変更です。
Chef 0.9 から Chef 11.4 への移行の詳細については、「[新しい Chef バージョンへの移行 ](#workingcookbook-chef11-migrate)」を参照してください。Chef 11.4 から Chef 11.10 への移行の詳細については、「[レシピの実装: Chef 11.10](workingcookbook-chef11-10.md)」を参照してください。Chef 11.10 から Chef 12 への移行の詳細については、「[レシピの実装: Chef 12](workingcookbook-chef12-linux.md)」を参照してください。
+ Chef の実行で使用される Ruby のバージョンは、Chef 0.9 および Chef 11.4 のスタックの場合 (Ruby 1.8.7)、Chef 11.10 のスタックの場合 (Ruby 2.0.0)、および Chef 12 のスタックの場合 (Ruby 2.1.6) とで異なります。
詳細については、「[Ruby のバージョン](workingcookbook-ruby.md)」を参照してください。
+ Chef 11.10 のスタックでは、クックブックのインストールの処理が、Chef 0.9 または Chef 11.4 のスタックの場合とは異なります。
この違いによって、カスタムクックブックを使用するスタックを Chef 11.10 に移行するときに問題が発生する可能性があります。詳細については、「[クックブックのインストールと優先順位](workingcookbook-chef11-10.md#workingcookbook-chef11-10-override)」を参照してください。
Chef のスタックを新しいバージョンの Chef に移行する際の推奨ガイドラインを以下に示します。
**スタックを新しいバージョンの Chef に移行するには**
1. [本稼働用スタックをクローン化します](workingstacks-cloning.md)。[**Clone Stack**] (クローンスタック) ページで、[**Advanced>>**] (アドバンスト>>) をクリックして [**Configuration Management**] (構成管理) セクションを表示し、[**Chef version**] (Chef のバージョン) を上位のバージョンに変更します。
**注記**
Chef 0.9 のスタックで作業を始める場合、直接 Chef 11.10 にアップグレードすることはできません。最初に Chef 11.4 にアップグレードする必要があります。レシピをテストする前に、Chef 11.10 にスタックを移行する場合は、更新が実行されるまで 20 分間待機してから、スタックを 11.4 から 11.10 にアップグレードします。
1. インスタンスをレイヤーに追加し、テストまたはステージング用システムにあるクローン化したスタックのアプリケーションとクックブックをテストします。詳細については、「[All about Chef ...](https://docs.chef.io/index.html)」を参照してください。
1. テスト結果が適切である場合、次のいずれかを実行します。
+ これが必要な Chef バージョンである場合、クローン化したスタックを本稼働用スタックとして使用するか、本稼働用スタックの Chef バージョンをリセットできます。
+ Chef 0.9 スタックから Chef 11.10 に 2 段階で移行している場合は、Chef 11.4 から Chef 11.10 にスタックを移行する処理を繰り返します。
**注記**
レシピをテストする場合は、[SSH を使用してインスタンスに接続](workinginstances-ssh.md)した後、[インスタンスエージェント CLI](agent.md) の [run\$1command](agent-run.md) コマンドを使用してさまざまなライフサイクルイベントに関連付けられたレシピを実行します。エージェント CLI は、特に Setup レシピをテストする場合に便利です。Setup が失敗し、インスタンスがオンライン状態になっていない場合でも使用できるからです。[Setup スタックコマンド](workingstacks-commands.md)を使用して Setup レシピを再実行することもできますが、このコマンドは Setup が成功し、インスタンスがオンラインになっている場合にのみ利用できます。
実行中のスタックを新しいバージョンの Chef に更新することができます。
**実行中のスタックを新しいバージョンの Chef に更新するには**
1. [スタックを編集](workingstacks-edit.md)し、スタックの設定の [**Chef version**] を変更します。
1. 新しい設定を保存し、 OpsWorks スタックがインスタンスを更新するのを待ちます。通常、更新には 15～20 分かかります。
**重要**
OpsWorks スタックは Chef バージョンの更新をライフサイクルイベントと同期しません。本稼働用スタックで Chef のバージョンを更新する場合は、次の[ライフサイクルイベント](workingcookbook-events.md)が発生する前に、更新が完了するように注意する必要があります。イベントが発生した場合 (主に Deploy または Configure イベント)、インスタンスエージェントは、バージョンの更新が完了しているかどうかにかかわらず、カスタムクックブックを更新し、イベントに割り当てられたレシピを実行します。バージョンの更新が完了したことを直接確認する方法はありませんが、デプロイのログに Chef のバージョンが記録されています。