DB Access

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # OpsWorks スタックのカスタマイズ **重要** この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポートチームにお問い合わせください。 OpsWorks スタックの組み込みレイヤーは、多くの目的に十分な標準機能を提供します。ただし、以下の状況が考えられます。 + 組み込みのレイヤーの標準設定では最適とは言えない場合、特定の要件に合わせて最適化することができます。例えば、ワーカープロセスの最大数または `keepalivetimeout` 値などの設定に独自の値を指定することで、Static ウェブサーバーレイヤーの Nginx サーバー設定を調整することができます。 + 組み込みのレイヤー機能でも問題ありませんが、追加パッケージをインストールまたはカスタムのインストールスクリプトを実行することで拡張することができます。例えば、Redis サーバーをインストールすることで、PHP アプリケーションサーバーレイヤーを拡張することができます。 + 組み込みのレイヤーでは扱うことのできない要件があります。たとえば、 OpsWorks スタックには、一部の一般的なデータベースサーバー用の組み込みレイヤーは含まれません。レイヤーのインスタンスに、それらのサーバーをインストールするカスタムレイヤーを作成することができます。 + カスタムレイヤーのみをサポートする Windows スタックを実行しています。 OpsWorks スタックには、特定の要件を満たすようにレイヤーをカスタマイズするさまざまな方法が用意されています。次の例は、複雑さと能力の低い方から高い方の順に表示されています。 **注記** これらのアプローチのいくつかは Linux スタックにのみ当てはまります。詳細については、以下のトピックを参照してください。 + カスタム JSON を使用して、デフォルトの OpsWorks スタック設定を上書きします。 + デフォルトのスタック設定を上書きする属性ファイルを使用して、カスタム Chef OpsWorks クックブックを実装します。 + デフォルトのスタックテンプレートを上書きまたは拡張するテンプレートを使用して、カスタム Chef OpsWorks クックブックを実装します。 + シェルスクリプトを実行するシンプルなレシピが含まれるカスタムの Chef クックブックを実行します。 + ディレクトリの作成と設定、パッケージのインストール、設定ファイルの作成、アプリケーションのデプロイなどのタスクを実行するレシピを含むカスタムの Chef クックブックを実装します。スタックの Chef バージョンおよびオペレーティングシステムに応じて、レシピを上書きすることもできます。 + Chef 0.9 および 11.4 スタックでは、クックブックやレシピが同じ名前のカスタムレシピを実装して組み込みのレシピを上書きすることはできません。ライフサイクルイベントごとに、 OpsWorks スタックは常に組み込みレシピを最初に実行し、その後にカスタムレシピを実行します。これらの Chef バージョンでは、クックブックやレシピが同じ名前のレシピが 2 度実行されないため、組み込みレシピが優先され、カスタムレシピは実行されません。 + Chef 11.10 スタックの組み込みレシピは上書きできます。詳細については、「[クックブックのインストールと優先順位](workingcookbook-chef11-10.md#workingcookbook-chef11-10-override)」を参照してください。 + Windows スタックの組み込みレシピは上書きできません。 OpsWorks スタックが Windows スタックの Chef 実行を処理する方法では、組み込みレシピを上書きすることはできません。 **注記** 多くの手法はカスタムクックブックを使用するため、クックブックの実装にまだ慣れ[クックブックとレシピ](workingcookbook.md)ていない場合は、まず「」をお読みください。 [クックブックの基本](cookbooks-101-basics.md)では、カスタムクックブックの実装に関する詳細なチュートリアルを紹介し、 OpsWorks スタックインスタンスのクックブックの実装方法の詳細[OpsWorks スタック用のクックブックの実装](cookbooks-101-opsworks.md)について説明します。 **Topics** + [属性を上書きして OpsWorks スタック設定をカスタマイズする](workingcookbook-attributes.md) + [カスタムテンプレートを使用した OpsWorks スタック設定ファイルの拡張](workingcookbook-template-override.md) + [レイヤーの拡張](workingcookbook-extend.md) + [カスタム Tomcat サーバーレイヤーの作成](create-custom.md) + [スタック設定およびデプロイメント属性](workingcookbook-json.md) # 属性を上書きして OpsWorks スタック設定をカスタマイズする **重要** この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポートチームにお問い合わせください。 **注記** Windows スタックと Chef 12 Linux スタックの場合、 OpsWorks スタックは組み込みレシピとカスタムレシピに別々の Chef 実行を使用します。つまり、このセクションで説明している手法を使用して、Windows スタックおよび Chef 12 Linux スタック用の組み込み属性を上書きすることはできません。レシピとテンプレートは、レイヤーの設定やアプリケーションサーバーの設定など、インスタンスやスタックに固有の情報に対応するさまざまな Chef 属性に依存します。これらの属性には複数のソースがあります。 + **[Custom JSON]** (カスタム JSON) - オプションで、スタックを作成、更新、またはクローン化するとき、またはアプリケーションをデプロイするときに、オプションでカスタム JSON 属性を指定できます。 + **スタック設定属性** –OpsWorks スタックは、コンソール設定で指定した情報など、スタック設定情報を保持するためにこれらの属性を定義します。 + **Deployment attributes** (デプロイ属性) - AWS OpsWorks では、Deploy イベントのデプロイ関連の属性を定義します。 + **Cookbook attributes** (クックブックの属性) - 組み込みのクックブックやカスタムクックブックには、通常、1 つ以上の [attribute files](workingcookbook-installingcustom-components-attributes.md) (属性ファイル) が含まれており、属性ファイルにはアプリケーションサーバー設定などのクックブック固有の値を表す属性が含まれます。 + **Chef** (シェフ) - Chef の [Ohai tool](http://docs.chef.io/resource_ohai.html) (Ohai ツール) は、CPU タイプやインストールされているメモリなど、さまざまなシステム設定を表す属性を定義します。スタック設定属性、デプロイ属性、組み込みクックブック属性のリストについては、「[スタック設定およびデプロイ属性: Linux](attributes-json-linux.md)」および「[組み込みクックブックの属性](attributes-recipes.md)」を参照してください。Ohai の属性の詳細については、「[Ohai](https://docs.chef.io/ohai.html)」を参照してください。 Deploy や Configure などの [lifecycle event](workingcookbook-events.md) (ライフサイクルイベント) が発生したり、`execute_recipes` または `update_packages` などの [stack command](workingstacks-commands.md) (スタックコマンド) を実行すると、 OpsWorks スタックは次のように動作します。 + 対応するコマンドを、影響を受ける各インスタンスのエージェントに送信します。エージェントは適切なレシピを実行します。たとえば、Deploy イベントの場合、エージェントは組み込みの Deploy レシピを実行した後、カスタム Deploy レシピを実行します。 + カスタム JSON 属性とデプロイ属性をスタック設定属性にマージし、それらの属性をインスタンスにインストールします。カスタム JSON、スタック設定、デプロイ、クックブック、Ohai の各属性が*ノードオブジェクト*にマージされ、属性値としてレシピに渡されます。インスタンスは、スタック設定属性に関しては、すべてのカスタム JSON を含めて基本的にステートレスです。デプロイまたはスタックコマンドを実行すると、関連付けられたレシピでは、そのコマンドでダウンロードされたスタック設定属性が使用されます。 **Topics** + [属性の優先順位](workingcookbook-attributes-precedence.md) + [カスタム JSON を使用した属性の上書き](workingcookbook-json-override.md) + [カスタムクックブック属性を使用した OpsWorks スタック属性の上書き](workingcookbook-cookbook-attributes.md) # 属性の優先順位 **重要** この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポートチームにお問い合わせください。属性を一意に定義した場合、Chef によってその属性はノードオブジェクトに組み込まれるだけです。ただし、任意の属性ソースが任意の属性を定義できるため、同じ属性に複数の定義が存在し、値が異なる可能性があります。たとえば、組み込みの `apache2` クックブックは `node[:apache][:keepalive]` を定義しますが、カスタム JSON またはカスタムクックブックでこの属性を定義することもできます。属性に複数の定義がある場合、後で説明する順序に従って定義が評価され、最も優先順位の高い定義がノードオブジェクトに組み込まれます。属性は次のように定義されます。 ``` node.type[:attribute][:sub_attribute][:...]=value ``` 属性に複数の定義がある場合、タイプはどの定義が優先されるかを決定し、その定義はノードオブジェクトに組み込まれます。 OpsWorks スタックは次の属性タイプを使用します。 + **default** (デフォルト) - これは最も一般的なタイプであり、基本的に「この属性がまだ定義されていない場合はこの値を使用する」ことを意味します。属性のすべての定義が `default` タイプである場合、評価順序の最初の定義が優先され、それ以降の値は無視されます。スタックは OpsWorks 、すべてのスタック設定とデプロイ属性定義を `default` type に設定することに注意してください。 + **normal** (通常) - このタイプの属性は、評価順序で以前に定義されているすべての `default` または `normal` 属性を上書きします。たとえば、組み込みクックブックの最初の属性が `default` タイプであり、2 番目が `normal` タイプのユーザー定義属性である場合、2 番目の定義が優先されます。 + **set** (セット) - これは、古いクックブックに表示される可能性のある非推奨のタイプです。このタイプは、優先順位が同じである `normal` に置き換えられました。 Chef は、他のすべての属性定義よりも優先される `automatic` タイプなど、いくつかの追加属性タイプをサポートしています。Chef の Ohai ツールによって生成された属性定義は、すべて `automatic` タイプであるため、事実上読み取り専用です。これは通常問題ではありません。上書きする理由がなく、 OpsWorks スタックの属性とは異なるためです。ただし、カスタムクックブック属性の名前を指定するときには、Ohai 属性とは異なる名前になるように注意する必要があります。詳細については、「[属性について](http://docs.chef.io/attributes.html)」を参照してください。 **注記** Ohai ツールは、コマンドラインから実行できる実行可能ファイルです。インスタンスの Ohai 属性のリストを取得するには、ターミナルウィンドウでインスタンスにログインし、`ohai` を実行します。それによって非常に長い出力が生成することに注意してください。ノードオブジェクトにさまざまな属性定義を組み込む手順を以下に示します。 1. カスタムスタック設定属性をスタック設定属性とデプロイ属性にマージします。カスタム JSON の属性は、スタックまたは特定のデプロイに対して設定できます。これらの属性は最初に評価されるため、事実上 `normal` タイプです。1 つ以上のスタック設定の属性がカスタム JSON でも定義されている場合、カスタム JSON の値が優先されます。それ以外の場合、 OpsWorks スタックによってカスタム JSON 属性はスタック設定に組み込まれるだけです。 1. デプロイカスタム JSON 属性をスタック設定属性とデプロイ属性にマージします。カスタムのデプロイ JSON 属性も実際は `normal` タイプであるため、組み込みおよびカスタムのスタック設定 JSON や組み込みのデプロイ JSON より優先されます。 1. インスタンスのノードオブジェクトにスタック設定およびデプロイ属性をマージします。 1. インスタンスの組み込みクックブック属性をノードオブジェクトにマージします。組み込みクックブック属性はすべて `default` タイプです。1 つまたは複数の組み込みクックブック属性がスタック構成およびデプロイ属性でも定義されている場合 (通常はカスタム JSON で定義されているため)、スタック設定の定義は組み込みクックブックの定義よりも優先されます。他の組み込みクックブック属性はすべて、単にノードオブジェクトに組み込まれます。 1. インスタンスのカスタムクックブック属性をノードオブジェクトにマージします。カスタムクックブック属性は、通常 `normal` タイプまたは `default` タイプです。一意の属性はノードオブジェクトに組み込まれます。カスタムクックブック属性がステップ 1～3 でも定義されている場合 (通常はカスタム JSON で定義されているため)、優先順位はカスタムクックブック属性のタイプによって異なります。 + ステップ 1～3 で定義された属性は、カスタムクックブック `default` 属性よりも優先されます。 + カスタムクックブック `normal` 属性は、ステップ 1～3 の定義よりも優先されます。 **重要** スタック設定属性または組み込みクックブック属性を上書きするために、カスタムクックブックの `default` 属性を使用しないでください。カスタムクックブックの属性は最後に評価されるため、`default` 属性の優先順位は最も低く、何も上書きすることができません。 # カスタム JSON を使用した属性の上書き **重要** この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポートチームにお問い合わせください。 **注記** スタックは、Windows OpsWorks スタックと Linux スタックでは Chef の実行処理が異なるため、このセクションで説明する手法を Windows スタックで使用することはできません。 OpsWorks スタック属性を上書きする最も簡単な方法は、カスタム JSON で定義することです。カスタム JSON は、スタック設定およびデプロイ属性だけでなく、組み込みおよびカスタムクックブック`default`属性よりも優先されます。詳細については、「[属性の優先順位](workingcookbook-attributes-precedence.md)」を参照してください。 **重要** スタック設定およびデプロイ属性を上書きする場合は注意が必要です。例えば、`opsworks` 名前空間の属性を上書きすると、組み込みのレシピに問題が生じる可能性があります。詳細については、「[スタック設定およびデプロイメント属性](workingcookbook-json.md)」を参照してください。カスタム JSON を使用して、通常、カスタムレシピにデータを渡すために、一意の属性を定義することもできます。属性は単にノードオブジェクトに組み込まれ、レシピは標準の Chef ノード構文を使用してオブジェクトを参照できます。 ## カスタム JSON を指定する方法カスタム JSON を使用して属性値を上書きするには、最初に属性の完全修飾属性名を決定する必要があります。次に、上書きの対象となる、目的の値に設定された属性を含む JSON オブジェクトを作成します。わかりやすくするために、「[スタック設定およびデプロイ属性: Linux](attributes-json-linux.md)」および「[組み込みクックブックの属性](attributes-recipes.md)」に、一般的に使用されるスタック設定、デプロイ、および組み込みのクックブックの属性、およびそれらの完全修飾名がまとめられています。オブジェクトの親子関係は、適切な完全修飾 Chef ノードに対応している必要があります。たとえば、Apache の次の属性を変更するとします。 + ノードが `node[:apache][:keepalivetimeout]` であり、デフォルト値が `3` である [`keepalivetimeout`](attributes-recipes-apache.md#attributes-recipes-apache-keep-timeout) 属性。 + ノードが `node[:apache][:logrotate][:schedule]` であり、デフォルト値が `"daily"` である `logrotate` [`schedule`](attributes-recipes-apache.md#attributes-recipes-apache-log-schedule) 属性。この属性を上書きして、値をそれぞれ `5` と `"weekly"` に設定するために、次のカスタム JSON を使用できます。 ``` { "apache" : { "keepalivetimeout" : 5, "logrotate" : { "schedule" : "weekly" } } } ``` ## カスタム JSON を指定する場合次のタスクのカスタム JSON 構造を指定できます。 + [新しいスタックを作成する](workingstacks-creating.md) + [スタックを更新する](workingstacks-edit.md) + [スタックコマンドを実行する](workingstacks-edit.md) + [スタックをクローン化する](workingstacks-cloning.md) + [アプリケーションをデプロイする](workingapps-deploying.md) OpsWorks スタックは、タスクごとにカスタム JSON 属性をスタック設定およびデプロイ属性とマージし、インスタンスに送信してノードオブジェクトにマージします。ただし、以下の点に注意してください。 + スタックの作成、クローン化、または更新時にカスタム JSON を指定する場合、それらの属性はスタック設定およびデプロイ属性にマージされ、以降のすべてのライフサイクルイベントとスタックコマンドで使用されます。 + デプロイ用にカスタム JSON を指定する場合、それらの属性は対応するイベント専用のスタック設定およびデプロイ属性にマージされます。以降のデプロイにそれらのカスタム属性を使用する場合は、再びカスタム JSON を明示的に指定する必要があります。レシピによって使用される場合、属性はインスタンスにのみ影響することを覚えておく必要があります。属性値を上書きしても、それ以降のレシピでその属性が参照されない場合、その変更は有効ではありません。関連付けられたレシピが実行される前にカスタム JSON が送信されること、または適切なレシピが再実行されることを確認する必要があります。 ## カスタム JSON のベストプラクティスカスタム JSON を使用して任意の OpsWorks スタック属性を上書きできますが、手動での情報の入力は多少面倒であり、ソース管理の対象ではありません。カスタム JSON は以下の目的に最適です。 + 少数の属性のみを上書きする必要があり、その他の目的でカスタムクックブックを使用する必要がない場合。カスタム JSON を使用すると、数個の属性を上書きするためにのみクックブックリポジトリをセットアップして維持するためのオーバーヘッドを回避できます。 + パスワードや認証キーなどの機密情報を含む値。クックブック属性はリポジトリに保存されるため、どの機密情報にも何らかの漏洩のリスクがあります。代わりに、ダミーの値を指定した属性を定義し、カスタム JSON を使用して実際の値を設定できます。 + 異なることが予想される値。たとえば、本稼働用スタックを別の開発およびステージングスタックでサポートする方法が推奨されています。これらのスタックが、支払いを受け付けるアプリケーションをサポートしているとします。カスタム JSON を使用して支払いのエンドポイントを指定する場合、ステージングスタックのテスト URL を指定できます。更新されたスタックを本稼動用スタックに移行する準備ができたら、同じクックブックを使用し、カスタム JSON を使用して支払いのエンドポイントを本稼動用 URL に設定できます。 + 特定のスタックまたはデプロイコマンドに固有の値。 # カスタムクックブック属性を使用した OpsWorks スタック属性の上書き **重要** この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポートチームにお問い合わせください。 **注記** Windows スタックの場合、 OpsWorks スタックは組み込みレシピとカスタムレシピに別々の Chef 実行を使用します。つまり、このセクションで説明している手法を使用して、Windows スタック用の組み込み属性を上書きすることはできません。カスタム JSON OpsWorks は、スタックスタック設定と組み込みクックブック属性を上書きする便利な方法ですが、いくつかの制限があります。特に、使用するたびに、カスタム JSON を手動で入力する必要があるため、定義を管理するための確実な方法がありません。よりよい方法として、カスタムクックブック属性ファイルを使用して組み込みの属性を上書きする方法があります。これによって、定義をソース管理の下に置くことができます。カスタム属性ファイルを使用して OpsWorks スタック定義を上書きする手順は簡単です。 **OpsWorks スタック属性定義を上書きするには** 1. 「[クックブックとレシピ](workingcookbook.md)」の説明に従ってクックブックリポジトリをセットアップします。 1. 上書きする属性を含む組み込みクックブックと同じ名前でクックブックを作成します。たとえば、Apache の属性を上書きするには、カスタムクックブックの名前を apache2 にする必要があります。 1. クックブックに `attributes` フォルダを追加し、そのフォルダに `customize.rb` という名前のファイルを追加します。 1. 上書きする組み込みクックブックの属性ごとに、優先する値に設定された属性定義をファイルに追加します。属性は `normal` タイプ以上で、対応する OpsWorks Stacks 属性とまったく同じノード名である必要があります。ノード名を含む OpsWorks スタック属性の詳細なリストについては、[スタック設定およびデプロイ属性: Linux](attributes-json-linux.md)「」および「」を参照してください[組み込みクックブックの属性](attributes-recipes.md)。属性および属性ファイルの詳細については、「[属性ファイルについて](http://docs.chef.io/attributes.html)」を参照してください。 **重要** スタック属性を上書きするには、属性が OpsWorks `normal`型である必要があります。`default`型が優先されません。例えば、`customize.rb` ファイルに `default[:apache][:keepalivetimeout] = 5` という属性定義がある場合、組み込みの `apache.rb` 属性ファイル内の対応する属性が最初に評価され、優先されます。詳細については、「[属性の上書き](workingcookbook-attributes.md)」を参照してください。 1. 上書きする属性を持つ組み込みクックブックごとに、ステップ 2～4 を繰り返します。 1. スタックのカスタムクックブックを有効にし、 OpsWorks スタックがクックブックをスタックのインスタンスにダウンロードするために必要な情報を提供します。詳細については、「[カスタムクックブックのインストール](workingcookbook-installingcustom-enable.md)」を参照してください。 **注記** この手順の詳細なウォークスルーについては、「[組み込み属性の上書き](cookbooks-101-opsworks-attributes.md)」を参照してください。後続のライフサイクルイベント、デプロイコマンド、スタックコマンドで使用されるノードオブジェクトに、 OpsWorks スタック値ではなく属性定義が含まれるようになりました。たとえば、「`keepalivetimeout`」で説明した、組み込みのの `logrotate schedule` および [カスタム JSON を指定する方法](workingcookbook-json-override.md#workingcookbook-json-override-specify) の設定を上書きするには、`apache2`apache クックブックをリポジトリに追加し、次のような内容の `customize.rb` ファイルをクックブックの `attributes` フォルダに追加します。 ``` normal[:apache][:keepalivetimeout] = 5 normal[:apache][:logrotate][:schedule] = 'weekly' ``` **重要** 関連する組み込み属性ファイルのコピーを変更して、 OpsWorks スタック属性を上書きしないでください。例えば、`apache.rb` を `apache2/attributes` フォルダにコピーし、その設定の一部を変更すると、基本的に組み込みファイル内のすべての属性が上書きされます。レシピでは、コピーの属性定義が使用され、組み込みファイルは無視されます。 OpsWorks スタックによって後で組み込みの属性ファイルが変更された場合、手動でコピーを更新しない限り、レシピでは変更内容にアクセスできません。このような状況を回避するために、組み込みのすべてのクックブックには空の `customize.rb` 属性ファイルが含まれています。このファイルは、`include_attribute` ディレクティブを介してすべてのモジュールで必要です。`customize.rb` のコピーで属性を上書きすることによって、その特定の属性にのみ変更を反映できます。レシピは組み込みの属性ファイルから他の属性値を取得し、上書きしなかった属性の現在の値を自動的に取得します。このアプローチでは、クックブックリポジトリ内の属性の数を少数に抑えることができます。これにより、メンテナンスのオーバーヘッドが削減され、将来のアップグレードの管理が容易になります。 # カスタムテンプレートを使用した OpsWorks スタック設定ファイルの拡張 **重要** この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポートチームにお問い合わせください。 **注記** スタックは、Windows OpsWorks スタックと Linux スタックでは Chef の実行処理が異なるため、このセクションで説明する手法を Windows スタックで使用することはできません。 OpsWorks スタックはテンプレートを使用して設定ファイルなどのファイルを作成します。通常、このファイルは多くの設定の属性に依存します。カスタム JSON またはカスタムクックブック属性を使用して OpsWorks スタック定義を上書きする場合、優先設定は OpsWorks スタック設定の代わりに設定ファイルに組み込まれます。ただし、 OpsWorks スタックは、可能なすべての設定に属性を指定するとは限りません。一部の設定のデフォルトを受け入れ、テンプレート内で他の設定を直接ハードコードします。対応する Stacks 属性がない場合、カスタム JSON OpsWorks またはカスタムクックブック属性を使用して優先設定を指定することはできません。カスタムテンプレートを作成することによって、追加の設定を含めるように設定ファイルを拡張できます。次に、必要な任意の設定またはその他のコンテンツをファイルに追加し、ハードコーディングされた設定を変更できます。テンプレートの詳細については「[テンプレート](workingcookbook-installingcustom-components-templates.md)」を参照してください。 **注記** opsworks-agent.monitrc.erb を*除く*組み込みのテンプレートを変更できます。 **カスタムテンプレートを作成するには** 1. 組み込みクックブックと同じ構造とディレクトリ名のクックブックを作成します。次に、カスタマイズする組み込みのテンプレートと同じ名前で、適切なディレクトリにテンプレートファイルを作成します。たとえば、カスタムテンプレートを使用して Apache の `httpd.conf` 設定ファイルを拡張するには、リポジトリに `apache2` クックブックを実装し、テンプレートファイルが `apache2/templates/default/apache.conf.erb` である必要があります。まったく同じ名前を使用すると、 OpsWorks スタックはカスタムテンプレートを認識し、組み込みテンプレートの代わりに使用できます。最も簡単なのは、[組み込みクックブックの GitHub リポジトリ](https://github.com/aws/opsworks-cookbooks)から組み込みテンプレートファイルをコピーし、必要に応じて変更を加えるという方法です。 **重要** カスタマイズするテンプレートファイル以外のファイルを、組み込みクックブックからコピーしないでください。レシピなど、他の種類のクックブックファイルをコピーすると、重複する Chef リソースが作成され、エラーの原因となる可能性があります。クックブックにもカスタム属性、レシピ、関連ファイルを含めることができますが、そのファイル名は組み込みのファイル名と重複しないようにする必要があります。 1. テンプレートファイルをカスタマイズして、要件を満たす設定ファイルを作成します。設定の追加、既存の設定の削除、ハードコーディングされた属性の置換などを行うことができます。 1. カスタムクックブックをまだ有効にしてない場合は、スタック設定を編集してカスタムクックブックを有効にして、クックブックリポジトリを指定してください。詳細については、「[カスタムクックブックのインストール](workingcookbook-installingcustom-enable.md)」を参照してください。 **注記** この手順の詳細なウォークスルーについては、「[組み込みテンプレートの上書き](cookbooks-101-opsworks-templates.md)」を参照してください。テンプレートを上書きするために、レシピを実装したり[、レイヤー設定にレシピを追加](workingcookbook-assigningcustom.md)したりする必要はありません。 OpsWorks スタックは常に組み込みレシピを実行します。設定ファイルを作成するレシピが実行される際に、自動的に組み込みのテンプレートの代わりにカスタムテンプレートが使用されます。 **注記** OpsWorks スタックが組み込みテンプレートに変更を加えると、カスタムテンプレートが同期しなくなり、正しく動作しなくなる可能性があります。たとえば、テンプレートが依存ファイルを参照し、ファイル名が変更されるとします。 OpsWorks スタックはそのような変更を頻繁に行うことはありません。テンプレートが変更されると、変更が一覧表示され、新しいバージョンにアップグレードするオプションが提供されます。 OpsWorks スタックリポジトリの変更をモニタリングし、必要に応じてテンプレートを手動で更新する必要があります。 # レイヤーの拡張 **重要** この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポートチームにお問い合わせください。 OpsWorks スタックの属性を変更するか、テンプレートをカスタマイズすることで処理できる範囲を拡大し、組み込みレイヤーをカスタマイズすることが必要な場合があります。たとえば、シンボリックリンクの作成、ファイルまたはフォルダのモードの設定、追加パッケージのインストールなどを行う必要があるとします。最小限の機能に加えて他の機能も提供するには、カスタムレイヤーを拡張する必要があります。その場合、カスタマイズタスクを処理する 1 つ以上のカスタムクックブックを実装する必要があります。このトピックでは、レシピを使用してレイヤーを拡張する方法を例で示します。 Chef を初めて使う場合は、最初に「[クックブック 101](cookbooks-101.md)」をお読みください。これは、クックブックを実装してさまざまな一般的なタスクを実行する方法の基本事項を紹介するチュートリアルです。カスタムレイヤーの実装方法の詳細な例については、「[カスタム Tomcat サーバーレイヤーの作成](create-custom.md)」を参照してください。 **Topics** + [レシピを使用したスクリプトの実行](workingcookbook-extend-scripts.md) + [Chef デプロイフックの使用](workingcookbook-extend-hooks.md) + [Linux インスタンスでの cron ジョブの実行](workingcookbook-extend-cron.md) + [Linux インスタンスでパッケージをインストールおよび設定](workingcookbook-extend-package.md) # レシピを使用したスクリプトの実行 **重要** この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポートチームにお問い合わせください。必要なカスタマイズタスクを実行するスクリプトがすでにある場合、通常、レイヤーを拡張する最も簡単な方法は、スクリプトを実行する簡単なレシピを実装することです。その後、適切なライフサイクルイベント (通常は Setup または Deploy) にレシピを割り当てることも、`execute_recipes` スタックコマンドを使用してレシピを手動で実行することもできます。以下の例では Linux インスタンスでシェルスクリプトを実行しますが、Windows PowerShell スクリプトなど他のタイプのスクリプトにも同じ方法を使用できます。 ``` cookbook_file "/tmp/lib-installer.sh" do source "lib-installer.sh" mode 0755 end execute "install my lib" do command "sh /tmp/lib-installer.sh" end ``` `cookbook_file` リソースは、クックブックの `files` ディレクトリのサブディレクトリに保存されたファイルを表します。このファイルはインスタンスの指定した場所に転送されます。この例では、シェルスクリプト `lib-installer.sh` をインスタンスの `/tmp` ディレクトリに転送し、ファイルのモードを `0755` に設定します。詳細については、「[cookbook\$1file](https://docs.chef.io/chef/resources.html#cookbook-file)」を参照してください。 `execute` リソースは、シェルコマンドなどのコマンドを表します。この例では `lib-installer.sh` を実行します。詳細については、「[execute](https://docs.chef.io/chef/resources.html#execute)」を参照してください。スクリプトをレシピに組み込んで実行することもできます。次の例では Bash スクリプトを実行しますが、Chef では Csh、Perl、Python、Ruby もサポートしています。 ``` script "install_something" do interpreter "bash" user "root" cwd "/tmp" code <<-EOH #insert bash script EOH end ``` `script` リソースはスクリプトを表します。この例では Bash インタープリタを指定し、ユーザーを `"root"` に、作業ディレクトリを `/tmp` にそれぞれ設定します。次に、`code` ブロックで Bash スクリプトを実行します。このブロックには、行を必要な数だけ含めることができます。詳細については、「[script](https://docs.chef.io/chef/resources.html#script)」を参照してください。レシピを使用してスクリプトを実行する方法の詳細については、「[例 7: コマンドとスクリプトの実行](cookbooks-101-basics-commands.md)」を参照してください。Windows インスタンスで PowerShell スクリプトを実行する方法の例については、「[Windows PowerShell スクリプトを実行する](cookbooks-101-opsworks-opsworks-powershell.md)」を参照してください。 # Chef デプロイフックの使用 **重要** この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポートチームにお問い合わせください。必要なタスクを実行するカスタムレシピを実装し、適切なレイヤーの Deploy イベントに割り当てることで、デプロイをカスタマイズできます。特に他の目的でクックブックを実装する必要がない場合は、Chef デプロイメントフックを使用してカスタマイズコードを実行する、別のシンプルなアプローチがあります。さらに、組み込みレシピによってデプロイメントが実行された後に、カスタム Deploy レシピを実行します。デプロイフックを使用すると、デプロイメントの途中に（たとえば、アプリケーションのコードがリポジトリからチェックアウトされた後、Apache が再起動される前に）操作することが可能になります。 Chef では、次の 4 つのステージでアプリケーションをデプロイします。 + **Checkout** (チェックアウト) - リポジトリからファイルをダウンロードします。 + **Migrate** (移行) - 必要に応じて移行を実行します。 + **Symlink** (シンボリックリンク) - シンボリックリンクを作成します。 + **Restart** (再起動) — アプリケーションを再起動します。 Chef デプロイフックを使用すると、各ステージの完了後にユーザーが提供する Ruby アプリケーションを必要に応じて実行することで、デプロイメントを簡単にカスタマイズできます。デプロイフックを使用するには、1 つ以上の Ruby アプリケーションを実装し、アプリケーションの `/deploy` ディレクトリに配置します。(アプリケーションに `/deploy` ディレクトリがない場合は、`APP_ROOT` レベルに 1 つ作成します)。アプリケーションには、いつ実行するかを示す次のいずれかの名前を指定する必要があります。 + `before_migrate.rb` – チェックアウトステージの完了後、移行ステージの前に実行します。 + `before_symlink.rb` – 移行ステージの完了後、シンボリックリンクステージの前に実行します。 + `before_restart.rb` – シンボリックリンクステージの完了後、再起動ステージの前に実行します。 + `after_restart.rb` – 再起動ステージの完了後に実行します。 Chef デプロイフックは標準のノード構文を使用して、レシピのようなノードオブジェクトにアクセスできます。また、デプロイフックは、指定した任意の[アプリケーション環境変数](workingapps-creating.md#workingapps-creating-environment)の値にアクセスできます。ただし、`new_resource.environment["VARIABLE_NAME"] ` を使用して、`ENV["VARIABLE_NAME"]` ではなく変数の値にアクセスする必要があります。 # Linux インスタンスでの cron ジョブの実行 **重要** この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポートチームにお問い合わせください。 Linux の cron ジョブは、指定したスケジュールで 1 つ以上のコマンドを実行するよう cron デーモンに指示します。たとえば、スタックで PHP の e コマースアプリケーションをサポートするとします。毎週指定した時刻にサーバーから販売レポートが送信されるように cron ジョブをセットアップできます。cron の詳細については、Wikipedia の「[Cron](http://en.wikipedia.org/wiki/Cron)」を参照してください。Linux ベースのコンピュータまたはインスタンスで直接クローンジョブを実行する方法の詳細については、Indiana University Knowledge Base Web サイトの「[What are cron and crontab, and how do I use them?](https://kb.iu.edu/d/afiz)」を参照してください。 SSH に接続することで個別の Linux ベースのインスタンスで `cron` ジョブを手動でセットアップし `crontab` 項目を編集できますが、 OpsWorks スタックの主なメリットは、インスタンスの全レイヤーを範囲としてタスクを実行できることです。次の手順は、PHP アプリケーションサーバーレイヤーのインスタンスで `cron` ジョブをセットアップする方法を示していますが、どのレイヤーでも同じ方法を使用できます。 **レイヤーのインスタンスで `cron` ジョブをセットアップするには** 1. ジョブをセットアップする `cron` リソースを使用するレシピを含むクックブックを実装します。この例では、レシピ名を `cronjob.rb` としています。実装の詳細については後述します。クックブックとレシピの詳細については、「[クックブックとレシピ](workingcookbook.md)」を参照してください。 1. スタックにクックブックをインストールします。詳細については、「[カスタムクックブックのインストール](workingcookbook-installingcustom-enable.md)」を参照してください。 1. 次のライフサイクルイベントに割り当てて、 OpsWorks スタックでレイヤーのインスタンスでレシピを自動的に実行させます。詳細については、「[レシピを自動的に実行する](workingcookbook-assigningcustom.md)」を参照してください。 + **セットアップ** – このイベント`cronjob.rb`に割り当てると、すべての新しいインスタンスでレシピを実行するように OpsWorks スタックに指示します。 + **デプロイ** – このイベント`cronjob.rb`に割り当てると、アプリケーションをレイヤーにデプロイまたは再デプロイするときに、すべてのオンラインインスタンスでレシピを実行するように OpsWorks スタックに指示します。 `Execute Recipes` スタックコマンドを使用して、オンラインインスタンスでレシピを手動で実行することもできます。詳細については、「[スタックコマンドの実行](workingstacks-commands.md)」を参照してください。次の `cronjob.rb` の例では、サーバーから販売データを収集して電子メールでレポートを送信する、ユーザーが実装した PHP アプリケーションを週 1 回実行する cron ジョブをセットアップします。cron リソースの使用方法のその他の例については、「[cron](https://docs.chef.io/chef/resources.html#cron)」を参照してください。 ``` cron "job_name" do hour "1" minute "10" weekday "6" command "cd /srv/www/myapp/current && php .lib/mailing.php" end ``` `cron` は、`cron` ジョブを表す Chef リソースです。 OpsWorks スタックがインスタンスでレシピを実行すると、関連するプロバイダーがジョブの設定の詳細を処理します。 + `job_name` は、`cron` ジョブのユーザー定義名 (`weekly report` など) です。 + `hour`/`minute`/`weekday` では、コマンドをいつ実行するかを指定します。この例では、毎週土曜日の午前 1 時 10 分にコマンドを実行します。 + `command` では、実行するコマンドを指定します。この例では 2 つのコマンドを実行します。まず `/srv/www/myapp/current` ディレクトリに移動します。2 番目のコマンドでは、販売データを収集してレポートを送信する、ユーザーが実装した `mailing.php` アプリケーションを実行します。 **注記** デフォルトで、`bundle` コマンドでは `cron` ジョブを操作できません。これは、 OpsWorks スタックが `/usr/local/bin` ディレクトリにバンドルをインストールするためです。`bundle` ジョブで `cron` を使用するには、cron ジョブに明示的にパス `/usr/local/bin` を追加する必要があります。また、\$1PATH 環境変数が `cron` ジョブで展開されない場合があるため、\$1PATH 変数の展開に依存することなく、明示的に必要なパス情報をジョブに追加することがベストプラクティスとなります。以下の例では、`bundle` ジョブで `cron` を使用する方法を 2 種類示しています。 ``` cron "my first task" do path "/usr/local/bin" minute "*/10" command "cd /srv/www/myapp/current && bundle exec my_command" end ``` ``` cron_env = {"PATH" => "/usr/local/bin"} cron "my second task" do environment cron_env minute "*/10" command "cd /srv/www/myapp/current && /usr/local/bin/bundle exec my_command" end ``` スタックに複数のアプリケーションサーバーがある場合、PHP アプリケーションサーバーレイヤーのライフサイクルイベントに `cronjob.rb` を割り当てるのは最適な方法とは言えません。たとえば、レイヤーのすべてのインスタンスでレシピが実行されるので、ユーザーには複数のレポートが送信されることになります。この場合、適切な方法は、カスタムレイヤーを使用して 1 つのサーバーだけがレポートを送信できるようにすることです。 **レイヤーの 1 つのインスタンスでのみレシピを実行するには** 1. たとえば、PHPAdmin というカスタムレイヤーを作成し、Setup イベントと Deploy イベントに `cronjob.rb` を割り当てます。カスタムレイヤーでは、必ずしも多くのことを実行する必要はありません。この例では、PHPAdmin はインスタンスでカスタムレシピを 1 つ実行するだけです。 1. PHP アプリケーションサーバーインスタンスの 1 つを AdminLayer に割り当てます。インスタンスが複数のレイヤーに属している場合、 OpsWorks スタックは各レイヤーの組み込みレシピとカスタムレシピを実行します。 PHP アプリケーションサーバーと PHPAdminレイヤーに属しているインスタンスは 1 つだけであるため、`cronjob.rb` はそのインスタンスでのみ実行され、ユーザーは 1 つだけレポートレポートを受け取ります。 # Linux インスタンスでパッケージをインストールおよび設定 **重要** この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポートチームにお問い合わせください。組み込みレイヤーでは、特定のパッケージのみがサポートされます。詳細については、「[レイヤー](workinglayers.md)」を参照してください。Redis サーバーなど、他のパッケージをインストールするには、関連するセットアップ、設定、デプロイメントの各タスクを処理するカスタムレシピを実装します。組み込みレイヤーを拡張して、レイヤーの標準パッケージと共に目的のパッケージをインスタンスにインストールするのが最良の方法である場合もあります。例えば、PHP アプリケーションをサポートするスタックがあり、Redis サーバーを含めたい場合は、PHP アプリケーションサーバーレイヤーを拡張して、PHP アプリケーションサーバーに加えて、レイヤーのインスタンスで Redis サーバーをインストールして設定することができます。通常、パッケージのインストールレシピでは、次のようなタスクを実行する必要があります。 + 1 つ以上のディレクトリを作成し、各ディレクトリのモードを設定する。 + テンプレートから設定ファイルを作成する。 + インストーラを実行してインスタンスにパッケージをインストールする。 + 1 つ以上のサービスを開始する。 Tomcat サーバーのインストール方法の例については、「[カスタム Tomcat サーバーレイヤーの作成](create-custom.md)」を参照してください。このトピックでは、カスタム Redisレイヤーをセットアップする方法を説明していますが、ほぼ同じコードを使用して組み込みレイヤーに Redis をインストールし、設定することができます。他のパッケージのインストール方法の例については、[https://github.com/aws/opsworks-cookbooks](https://github.com/aws/opsworks-cookbooks) (https://github.com/aws/opsworks-cookbooks) にある組み込みクックブックを参照してください。 # カスタム Tomcat サーバーレイヤーの作成 **重要** この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポートチームにお問い合わせください。 **注記** このトピックでは、Linux スタックのカスタムレイヤーを実装する方法について説明します。ただし、一部の基本的な原則とコードは、特に、アプリケーションのデプロイのセクションで、Windows スタックのカスタムレイヤーの実装にも当てはまります。 OpsWorks スタックインスタンスで非標準パッケージを使用する最も簡単な方法は、[既存のレイヤーを拡張](workingcookbook-extend-package.md)することです。ただし、この方法は、レイヤーのインスタンスに標準と標準外の両方のパッケージをインストールして実行するため、常に望ましいわけではありません。要求が厳しくなりますがより強力な方法は、カスタムレイヤーを実装することです。そうすれば、レイヤーのインスタンスに対して、次の事項をほぼ完全にコントロールできるようになります。 + どのパッケージをインストールするか + 各パッケージをどのように設定するか + リポジトリからインスタンスにどのようにアプリケーションをデプロイするかコンソールまたは API のどちらを使用する場合も、「[カスタムレイヤー](workinglayers-custom.md)」で説明しているように、その他すべてのレイヤーと同様にカスタムレイヤーを作成して管理します。ただし、カスタムレイヤーの組み込みのレシピは、Ganglia クライアントをインストールして Ganglia マスターにメトリクスをレポートするなど、一部の最も基本的なタスクだけを実行します。カスタムレイヤーのインスタンスが最小限の機能にとどまらないようにするために、パッケージのインストールと設定、アプリケーションのデプロイなどのタスクを処理するための Chef レシピと関連ファイルを備えた 1 つ以上のカスタムクックブックを実装する必要があります。ただし、必ずしもすべてを最初から新しく実装する必要はありません。たとえば、標準のリポジトリの 1 つにアプリケーションを保存する場合は、組み込みのレシピを使用することで、アプリケーションをレイヤーのインスタンスにインストールする作業の多くを処理できます。 **注記** Chef を初めて使う場合は、最初に「[クックブック 101](cookbooks-101.md)」をお読みください。これは、クックブックを実装してさまざまな一般的なタスクを実行する方法の基本事項を紹介するチュートリアルです。次のウォークスルーでは、Tomcat アプリケーションサーバーをサポートするカスタムレイヤーの実装方法を説明します。このレイヤーは、パッケージのインストール、デプロイなどを処理するためのレシピを含む Tomcat というカスタムクックブックに基づいています。このウォークスルーは、Tomcat クックブックからの抜粋を含んでいます。このクックブック全体は、クックブックの [GitHub リポジトリ](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat)からダウンロードできます。[Opscode Chef](http://www.opscode.com/chef/) に慣れていない場合は、最初に「[クックブックとレシピ](workingcookbook.md)」をお読みください。 **注記** OpsWorks スタックには、本番稼働用のフル機能の [Java App Server レイヤー](layers-java.md)が含まれています。Tomcat クックブックの目的は、カスタムレイヤーの実装方法を示すことです。したがって、SSL などの機能を含まない限定バージョンの Tomcat のみをサポートしています。フル機能の実装の例については、組み込みの [opsworks\$1java](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/opsworks_java) クックブックを参照してください。 Tomcat クックブックは、インスタンスが次の特徴を持つカスタムレイヤーをサポートします。 + インスタンスは、Apache のフロントエンドで Tomcat Java アプリケーションサーバーをサポートします。 + Tomcat は、アプリケーションが JDBC `DataSource` オブジェクトを使用して、バックエンドデータストアとして機能する個別の MySQL インスタンスに接続できるように設定されています。このプロジェクトのクックブックには、複数の主要コンポーネントがあります。 + [属性ファイル](create-custom-attributes.md)には、さまざまなレシピで使用される設定が含まれます。 + [Setup レシピ](create-custom-setup.md)[は、レイヤーの Setup ライフサイクルイベントに割り当てられます。](workingcookbook-events.md)このレシピは、インスタンスの起動後に実行され、パッケージのインストールや設定ファイルの作成などのタスクを行います。 + [Configure レシピ](create-custom-configure.md)は、レイヤーの Configure ライフサイクルイベントに割り当てられます。スタックの設定変更後、主にインスタンスがオンラインになったときやオフラインになったときに実行され、必要な構成変更を処理します。 + Deploy レシピは、レイヤーの Deploy [ライフサイクル](create-custom-deploy.md)イベントに割り当てられます。このレシピは、Setup レシピの後、アプリケーションを手動でデプロイし、レイヤーのインスタンスでコードおよび関連ファイルをインストールするときに実行されます。また、サービスの再起動などの関連タスクを処理するためにも実行されます。最後のセクションである「[スタックの作成とアプリケーションの実行](create-custom-stack.md)」では、Tomcat クックブックに基づいてカスタムレイヤーを含むスタックを作成する方法、および別個の MySQLレイヤーに属するインスタンスで実行中の MySQL データベースのデータを表示するシンプルな JSP アプリケーションをデプロイして実行する方法について説明します。 **注記** Tomcat クックブックレシピは、一部の OpsWorks スタックの組み込みレシピによって異なります。各レシピのオリジンを明確にするために、このトピックでは Chef *cookbookname*::*recipename* 規則を使用してレシピを識別します。 **Topics** + [属性ファイル](create-custom-attributes.md) + [Setup レシピ](create-custom-setup.md) + [Configure レシピ](create-custom-configure.md) + [Deploy レシピ](create-custom-deploy.md) + [スタックの作成とアプリケーションの実行](create-custom-stack.md) # 属性ファイル **重要** この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポートチームにお問い合わせください。レシピを確認する前に、最初に Tomcat クックブックの属性ファイルを調べておくと便利です。属性ファイルには、そのレシピで使用するさまざまな設定ファイルが含まれています。属性は必須ではなく、レシピやテンプレートで値を単にハードコーディングすることもできます。ただし、属性を使用して構成設定を定義する場合は、スタックコンソールまたは API OpsWorks を使用して、カスタム JSON 属性を定義することで値を変更することができます。カスタム JSON 属性は、設定を変更するたびにレシピまたはテンプレートコードを書き直すよりも簡単で柔軟です。この方法では、たとえば、複数のスタックに同じクックブックを使用しながら、スタックごとに Tomcat サーバーを異なる設定にすることができます。属性および属性をオーバーライドする方法の詳細については、「[属性の上書き](workingcookbook-attributes.md)」を参照してください。次の例は、完全な属性ファイル `default.rb` を示しています。このファイルは、Tomcat クックブックの `attributes` ディレクトリにあります。 ``` default['tomcat']['base_version'] = 6 default['tomcat']['port'] = 8080 default['tomcat']['secure_port'] = 8443 default['tomcat']['ajp_port'] = 8009 default['tomcat']['shutdown_port'] = 8005 default['tomcat']['uri_encoding'] = 'UTF-8' default['tomcat']['unpack_wars'] = true default['tomcat']['auto_deploy'] = true case node[:platform] when 'centos', 'redhat', 'fedora', 'amazon' default['tomcat']['java_opts'] = '' when 'debian', 'ubuntu' default['tomcat']['java_opts'] = '-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC' end default['tomcat']['catalina_base_dir'] = "/etc/tomcat#{node['tomcat']['base_version']}" default['tomcat']['webapps_base_dir'] = "/var/lib/tomcat#{node['tomcat']['base_version']}/webapps" default['tomcat']['lib_dir'] = "/usr/share/tomcat#{node['tomcat']['base_version']}/lib" default['tomcat']['java_dir'] = '/usr/share/java' default['tomcat']['mysql_connector_jar'] = 'mysql-connector-java.jar' default['tomcat']['apache_tomcat_bind_mod'] = 'proxy_http' # or: 'proxy_ajp' default['tomcat']['apache_tomcat_bind_config'] = 'tomcat_bind.conf' default['tomcat']['apache_tomcat_bind_path'] = '/tc/' default['tomcat']['webapps_dir_entries_to_delete'] = %w(config log public tmp) case node[:platform] when 'centos', 'redhat', 'fedora', 'amazon' default['tomcat']['user'] = 'tomcat' default['tomcat']['group'] = 'tomcat' default['tomcat']['system_env_dir'] = '/etc/sysconfig' when 'debian', 'ubuntu' default['tomcat']['user'] = "tomcat#{node['tomcat']['base_version']}" default['tomcat']['group'] = "tomcat#{node['tomcat']['base_version']}" default['tomcat']['system_env_dir'] = '/etc/default' end ``` 設定自体については、関連するセクションで後ほど説明します。次の注意事項が一般的に適用されます。 + すべてのノード定義のタイプは `default` であるため、[カスタム JSON 属性](workingcookbook-json-override.md)で上書きできます。 + このファイルは、`case` ステートメントを使用して、インスタンスのオペレーティングシステムに応じて条件付きで一部の属性値を設定します。 `platform` ノードが Chef の Ohai ツールによって生成され、インスタンスのオペレーティングシステムを表します。 # Setup レシピ **重要** この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポートチームにお問い合わせください。 Setup レシピは、レイヤーの Setup [ライフサイクル](workingcookbook-events.md)イベントに割り当てられ、インスタンスの起動後に実行されます。このレシピは、パッケージのインストール、設定ファイルの作成、サービスの開始などのタスクを実行します。Setup レシピの実行が完了すると、 OpsWorks Stacks は [Deploy レシピ](create-custom-deploy.md)を実行して、新しいインスタンスにアプリケーションをデプロイします。 **Topics** + [tomcat::setup](#create-custom-setup-setup) + [tomcat::install](#create-custom-setup-install) + [tomcat::service](#create-custom-setup-service) + [tomcat::container\$1config](#create-custom-setup-config) + [tomcat::apache\$1tomcat\$1bind](#create-custom-setup-bind) ## tomcat::setup `tomcat::setup` レシピは、レイヤーの Setup ライフサイクルイベントに割り当てられます。 ``` include_recipe 'tomcat::install' include_recipe 'tomcat::service' service 'tomcat' do action :enable end # for EBS-backed instances we rely on autofs bash '(re-)start autofs earlier' do user 'root' code <<-EOC service autofs restart EOC notifies :restart, resources(:service => 'tomcat') end include_recipe 'tomcat::container_config' include_recipe 'apache2' include_recipe 'tomcat::apache_tomcat_bind' ``` `tomcat::setup` レシピは、主としてメタレシピです。Tomcat および関連パッケージのインストールと設定の詳細のほとんどを処理する一連の依存レシピが含まれています。`tomcat::setup` の最初の部分は、後で説明する次のレシピを実行します。 + [tomcat::install](#create-custom-setup-install) レシピは、Tomcat サーバーパッケージをインストールします。 + [tomcat::service](#create-custom-setup-service) レシピは、Tomcat サービスをセットアップします。 `tomcat::setup` の中央部分は、Tomcat サービスを有効にして起動します。 + Chef [service リソース](https://docs.chef.io/chef/resources.html#service)は、Tomcat サービスを起動時に有効にします。 + Chef [bash resource](https://docs.chef.io/chef/resources.html#bash) (bash リソース) は、Bash スクリプトを実行して autofs デーモンを起動します。これは、Amazon EBS-backed インスタンスに必要です。次に、このリソースは、Tomcatサービスの再起動を `service` リソースに通知します。詳細については、「[autofs](https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/s2-nfs-config-autofs.html)」(Amazon Linux の場合) または「[Autofs](https://help.ubuntu.com/community/Autofs)」(Ubuntu の場合) を参照してください。 `tomcat::setup` の最後の部分は、設定ファイルを作成し、フロントエンド Apache サーバーをインストールおよび設定します。 + [tomcat::container\$1config](#create-custom-setup-config) レシピは、設定ファイルを作成します。 + `apache2` レシピ ( の略称`apache2::default`) は、Apache サーバーをインストールして設定する OpsWorks スタックの組み込みレシピです。 + [tomcat::apache\$1tomcat\$1bind](#create-custom-setup-bind) レシピは、Tomcat サーバーのフロントエンドとして機能するように Apache サーバーを設定します。 **注記** 組み込みのレシピを使用して必要なタスクの一部を実行することにより、多くの場合、時間と労力を削減できます。このレシピは、組み込みの `apache2::default` レシピを使用することで、Apache を最初から実装する必要なくインストールします。組み込みのレシピを使用するその他の例については、「[Deploy レシピ](create-custom-deploy.md)」を参照してください。以下のセクションでは、Tomcat クックブックの Setup レシピについてさらに詳しく説明します。`apache2` レシピの詳細については、「[opsworks-cookbooks/apache2](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.4/apache2)」を参照してください。 ## tomcat::install `tomcat::install ` レシピは、Tomcat サーバー、OpenJDK、および Java コネクターライブラリをインストールします。Java コネクターライブラリは、MySQL サーバーへの接続を処理します。 ``` tomcat_pkgs = value_for_platform( ['debian', 'ubuntu'] => { 'default' => ["tomcat#{node['tomcat']['base_version']}", 'libtcnative-1', 'libmysql-java'] }, ['centos', 'redhat', 'fedora', 'amazon'] => { 'default' => ["tomcat#{node['tomcat']['base_version']}", 'tomcat-native', 'mysql-connector-java'] }, 'default' => ["tomcat#{node['tomcat']['base_version']}"] ) tomcat_pkgs.each do |pkg| package pkg do action :install end end link ::File.join(node['tomcat']['lib_dir'], node['tomcat']['mysql_connector_jar']) do to ::File.join(node['tomcat']['java_dir'], node['tomcat']['mysql_connector_jar']) action :create end # remove the ROOT webapp, if it got installed by default include_recipe 'tomcat::remove_root_webapp' ``` このレシピは、次のタスクを実行します。 1. インスタンスのオペレーティングシステムに応じて、インストールするパッケージのリストを作成します。 1. リストに各パッケージをインストールします。 Chef [package resource](https://docs.chef.io/chef/resources.html#id146) (パッケージリソース) は適切なプロバイダを使用します。`yum` Amazon Linux および `apt-get` Ubuntu の場合— インストールを処理します。package プロバイダーは、Tomcat の依存関係として OpenJDK をインストールしますが、MySQL コネクターライブラリは明示的にインストールする必要があります。 1. Chef [link リソース](https://docs.chef.io/chef/resources.html#link)を使用して、Tomcat サーバーの lib ディレクトリに JDK の MySQL コネクターライブラリへのシンボリックリンクを作成します。デフォルトの属性値を使用すると、Tomcat の lib ディレクトリは `/usr/share/tomcat6/lib` となり、MySQL コネクターライブラリ (`mysql-connector-java.jar`) は `/usr/share/java/` にあります。 `tomcat::remove_root_webapp` レシピは、ROOT ウェブアプリケーション (デフォルトでは `/var/lib/tomcat6/webapps/ROOT`) を削除して、セキュリティの問題のいくつかを回避します。 ``` ruby_block 'remove the ROOT webapp' do block do ::FileUtils.rm_rf(::File.join(node['tomcat']['webapps_base_dir'], 'ROOT'), :secure => true) end only_if { ::File.exists?(::File.join(node['tomcat']['webapps_base_dir'], 'ROOT')) && !::File.symlink?(::File.join(node['tomcat']['webapps_base_dir'], 'ROOT')) } end ``` `only_if` ステートメントにより、このレシピは、ファイルが存在する場合にのみファイルを削除します。 **注記** Tomcat のバージョンは、`['tomcat']['base_version']` 属性で指定されます。この属性ファイルでは 6 に設定されています。Tomcat 7 をインストールする場合は、この属性を上書きするためにカスタム JSON 属性を使用できます。[スタックの設定を編集](workingstacks-edit.md)し、次の JSON を、[**Custom Chef JSON**] ボックスに入力するか既存のカスタム JSON に追加します。 ``` { 'tomcat' : { 'base_version' : 7 } } ``` このカスタム JSON 属性により、デフォルトの属性が上書きされ、Tomcat のバージョンが 7 に設定されます。属性の上書きの詳細については、「[属性の上書き](workingcookbook-attributes.md)」を参照してください。 ## tomcat::service `tomcat::service` レシピは、Tomcat サービスの定義を作成します。 ``` service 'tomcat' do service_name "tomcat#{node['tomcat']['base_version']}" case node[:platform] when 'centos', 'redhat', 'fedora', 'amazon' supports :restart => true, :reload => true, :status => true when 'debian', 'ubuntu' supports :restart => true, :reload => false, :status => true end action :nothing end ``` このレシピは、Chef [service リソース](https://docs.chef.io/chef/resources.html#service)を使用して Tomcat サービス名 (デフォルトでは tomcat6) を指定し、`supports` 属性を設定して、さまざまなオペレーティングシステムでサービスの restart コマンド、reload コマンド、および status コマンドを Chef によって管理する方法を定義します。 + `true` は、Chef が init またはその他のサービスプロバイダーを使用してコマンドを実行できることを示します。 + `false` は、Chef がその他の方法でコマンドの実行を試みる必要があることを示します。 `action` が `:nothing` に設定されていることに注意してください。ライフサイクルイベントごとに、 OpsWorks スタックは [Chef 実行](https://docs.chef.io/chef_client_overview.html#the-chef-client-run)を開始し、適切なレシピセットを実行します。Tomcat クックブックは、レシピでサービスの定義を作成するがサービスの再起動はしないという一般的なパターンに従います。Chef 実行のその他のレシピは、通常、設定ファイルの作成に使用する `notifies` リソースに `template` コマンドを含めることで、再起動を処理します。通知を使用すると、設定が変更された場合にのみサービスが再起動されるため、通知はサービスの再起動のための便利な方法です。また、Chef 実行で 1 つのサービスに対して複数の再起動通知がある場合、Chef は最大で 1 回サービスを再起動します。これにより、Tomcat のエラーの一般的原因である、完全には機能していないサービスを再起動しようとする際に発生する可能性がある問題が回避されます。 Tomcat サービスは、再起動通知を使用する任意の Chef 実行に対して定義する必要があります。したがって、`tomcat::service` は複数のレシピに含まれ、それぞれの Chef 実行に対してサービスが定義されることになります。Chef 実行に `tomcat::service` の複数のインスタンスが含まれる場合のペナルティはありません。これは、Chef ではレシピの実行回数が Chef 実行ごとに 1 回のみであるためです。 ## tomcat::container\$1config `tomcat::container_config` レシピは、クックブックテンプレートファイルから設定ファイルを作成します。 ``` include_recipe 'tomcat::service' template 'tomcat environment configuration' do path ::File.join(node['tomcat']['system_env_dir'], "tomcat#{node['tomcat']['base_version']}") source 'tomcat_env_config.erb' owner 'root' group 'root' mode 0644 backup false notifies :restart, resources(:service => 'tomcat') end template 'tomcat server configuration' do path ::File.join(node['tomcat']['catalina_base_dir'], 'server.xml') source 'server.xml.erb' owner 'root' group 'root' mode 0644 backup false notifies :restart, resources(:service => 'tomcat') end ``` このレシピは、必要に応じてサービスを定義する `tomcat::service` を最初に呼び出します。このレシピの大部分は、2 つの [template resources](https://docs.chef.io/chef/resources.html#template) で構成され、クックブックのいずれかのテンプレートファイルから設定ファイルを作成し、ファイルのプロパティを設定し、Chef にサービスを再起動するよう通知します。 ### Tomcat 環境設定最初の `template` リソースは、`tomcat_env_config.erb` テンプレートファイルを使用して Tomcat 環境設定ファイルを作成します。このファイルは、`JAVA_HOME` などの環境変数の設定に使用します。デフォルトのファイル名は、`template` リソースの引数です。`tomcat::container_config` は、`path` 属性を使用し、デフォルト値を上書きして設定ファイルに `/etc/sysconfig/tomcat6` (Amazon Linux の場合) または `/etc/default/tomcat6` (Ubuntu の場合) の名前を付けます。また、`template` リソースは、ファイルの所有者、グループ、およびモードの設定を指定し、バックアップファイルを作成しないように Chef に指示します。ソースコードを確認すると、実際には 3 つのバージョンの `tomcat_env_config.erb` が存在し、それぞれ `templates` ディレクトリの異なるサブディレクトリ内にあります。`ubuntu` ディレクトリおよび `amazon` ディレクトリには、それぞれのオペレーティングシステムに対応するテンプレートが含まれます。`default` フォルダには、1 行のコメント行があるダミーのテンプレートが含まれています。このテンプレートは、サポートされていないオペレーティングシステムを使用するインスタンスでこのレシピを実行しようとした場合にのみ使用されます。`tomcat::container_config` レシピでは、使用する `tomcat_env_config.erb` を指定する必要はありません。Chef は、「[File Specificity](http://docs.chef.io/templates.html#file-specificity)」で説明されているルールに基づいて、インスタンスのオペレーティングシステム用の適切なディレクトリを自動的に選択します。この例の `tomcat_env_config.erb` ファイルは、大部分がコメントで構成されています。追加の環境変数を設定するには、適切な行をコメント解除し、新しい値を指定します。 **注記** 変更する可能性がある設定は、テンプレートにハードコーディングするのではなく、属性として定義する必要があります。そうすれば、設定を変更するためにテンプレートを書き直す必要はなく、属性を上書きするだけで済みます。次の抜粋に示すように、Amazon Linux テンプレートは 1 つの環境変数のみを設定します。 ``` ... # Use JAVA_OPTS to set java.library.path for libtcnative.so #JAVA_OPTS="-Djava.library.path=/usr/lib" JAVA_OPTS="${JAVA_OPTS} <%= node['tomcat']['java_opts'] %>" # What user should run tomcat #TOMCAT_USER="tomcat" ... ``` JAVA\$1OPTS を使用すると、ライブラリのパスなどの Java オプションを指定できます。デフォルトの属性値を使用すると、このテンプレートは Amazon Linux の Java オプションを設定しません。例えば、カスタム JSON 属性を使用して、`['tomcat']['java_opts']` 属性を上書きすることにより、独自の Java オプションを設定できます。例については、[スタックの作成](create-custom-stack.md#create-custom-stack-stack)を参照してください。次のテンプレートの抜粋に示すように、Ubuntu テンプレートは複数の環境変数を設定します。 ``` # Run Tomcat as this user ID. Not setting this or leaving it blank will use the # default of tomcat<%= node['tomcat']['base_version'] %>. TOMCAT<%= node['tomcat']['base_version'] %>_USER=tomcat<%= node['tomcat']['base_version'] %> ... # Run Tomcat as this group ID. Not setting this or leaving it blank will use # the default of tomcat<%= node['tomcat']['base_version'] %>. TOMCAT<%= node['tomcat']['base_version'] %>_GROUP=tomcat<%= node['tomcat']['base_version'] %> ... JAVA_OPTS="<%= node['tomcat']['java_opts'] %>" <% if node['tomcat']['base_version'].to_i < 7 -%> # Unset LC_ALL to prevent user environment executing the init script from # influencing servlet behavior. See Debian bug #645221 unset LC_ALL <% end -%> ``` デフォルトの属性値を使用すると、このテンプレートは次のように Ubuntu 環境変数を設定します。 + Tomcat のユーザーとグループを表す `TOMCAT6_USER` および `TOMCAT6_GROUP` は、いずれも `tomcat6` に設定されます。 ['tomcat']['base\$1version'] を `tomcat7` に設定する場合、変数名は `TOMCAT7_USER` および `TOMCAT7_GROUP` に解決され、いずれも `tomcat7` に設定されます。 + `JAVA_OPTS` は、`-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC` に設定されます。 + `-Djava.awt.headless` を `true` に設定すると、インスタンスがヘッドレスでコンソールがないことがグラフィックエンジンに通知されます。これにより、特定のグラフィカルアプリケーションの不良動作に対処します。 + `-Xmx128m` により、JVM は適切なメモリリソース (この例では 128 MB) を確保します。 + `-XX:+UseConcMarkSweepGC` は、コンカレントマークスイープガベージコレクションを指定します。これは、ガベージコレクションの一時停止を限定するのに役立ちます。詳細については、「[コンカレントマークスイープコレクタの拡張機能](http://docs.oracle.com/javase/6/docs/technotes/guides/vm/cms-6.html)」を参照してください。 + Tomcat のバージョンが 7 より前の場合、このテンプレートは、Ubuntu のバグに対処する `LC_ALL` を取り消します。 **注記** デフォルトの属性を使用すると、これらの環境変数の一部が単にデフォルト値に設定されます。一方、属性に対して環境変数を明示的に設定することは、カスタム JSON 属性を定義し、デフォルトの属性を上書きしてカスタム値を指定することを意味します。属性の上書きの詳細については、「[属性の上書き](workingcookbook-attributes.md)」を参照してください。完全なテンプレートファイルについては、[ソースコード](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat)を参照してください。 ### Server.xml 設定ファイル 2 番目の `template` リソースは、 `server.xml.erb` を使用して [`system.xml` 設定ファイル](http://tomcat.apache.org/tomcat-7.0-doc/config/)を作成します。このファイルは、servlet/JSP コンテナを設定します。`server.xml.erb` は、オペレーティングシステム固有の設定を含まないため、`template` ディレクトリの `default` サブディレクトリに配置されています。このテンプレートは、標準設定を使用しますが、Tomcat 6 または Tomcat 7 のいずれかに対して `system.xml` ファイルを作成できます。たとえば、このテンプレートのサーバーセクションの次のコードは、指定されたバージョンに合わせてリスナーを適切に設定します。 ``` <% if node['tomcat']['base_version'].to_i > 6 -%> <% end -%> <% if node['tomcat']['base_version'].to_i < 7 -%> <% end -%> <% if node['tomcat']['base_version'].to_i > 6 -%> <% end -%> ``` このテンプレートは、ハードコーディングされた設定の代わりに属性を使用しているため、カスタム JSON 属性を定義することで、設定を簡単に変更できます。例えば: ``` ``` 詳細については、[ソースコード](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat)を参照してください。 ## tomcat::apache\$1tomcat\$1bind `tomcat::apache_tomcat_bind` レシピは、Apache サーバーが Tomcat のフロントエンドとして動作すること、つまり、受信するリクエストを受け取って Tomcat に転送し、応答をクライアントに返すことを可能にします。この例では、Apache のプロキシ/ゲートウェイとして [mod\$1proxy](https://httpd.apache.org/docs/2.2/mod/mod_proxy.html) を使用します。 ``` execute 'enable mod_proxy for apache-tomcat binding' do command '/usr/sbin/a2enmod proxy' not_if do ::File.symlink?(::File.join(node['apache']['dir'], 'mods-enabled', 'proxy.load')) || node['tomcat']['apache_tomcat_bind_mod'] !~ /\Aproxy/ end end execute 'enable module for apache-tomcat binding' do command "/usr/sbin/a2enmod #{node['tomcat']['apache_tomcat_bind_mod']}" not_if {::File.symlink?(::File.join(node['apache']['dir'], 'mods-enabled', "#{node['tomcat']['apache_tomcat_bind_mod']}.load"))} end include_recipe 'apache2::service' template 'tomcat thru apache binding' do path ::File.join(node['apache']['dir'], 'conf.d', node['tomcat']['apache_tomcat_bind_config']) source 'apache_tomcat_bind.conf.erb' owner 'root' group 'root' mode 0644 backup false notifies :restart, resources(:service => 'apache2') end ``` `mod_proxy` を有効にするには、`proxy` モジュールとプロトコルベースのモジュールを有効にする必要があります。プロトコルモジュールには、次の 2 つのオプションがあります。 + HTTP: `proxy_http` + [Apache JServ Protocol](http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html) (AJP) : `proxy_ajp` AJP は、内部の Tomcat プロトコルです。このレシピの両方の [execute リソース](https://docs.chef.io/chef/resources.html#execute)が `a2enmod` コマンドを実行します。このコマンドは、必要なシンボリックリンクを作成することで、指定されたモジュールを有効にします。 + 最初の `execute` リソースは、`proxy` モジュールを有効にします。 + 2 番目の `execute` リソースは、デフォルトで `proxy_http` に設定されているプロトコルモジュールを有効にします。 AJP の方を使用する場合は、カスタム JSON を定義し、`apache_tomcat_bind_mod` 属性を上書きして、`proxy_ajp` に設定できます。 `apache2::service` レシピは、Apache サービスを定義する OpsWorks スタック組み込みレシピです。詳細については、スタック GitHub OpsWorks リポジトリの[レシピ](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.4/apache2/recipes/service.rb)を参照してください。 `template` リソースでは、`apache_tomcat_bind.conf.erb` を使用して、デフォルトで `tomcat_bind.conf` という名前のファイルを作成します。ファイルは、`['apache']['dir']/.conf.d` ディレクトリに配置されます。`['apache']['dir']` 属性は、組み込みの `apache2` 属性ファイルで定義され、デフォルトでは `/etc/httpd` (Amazon Linux の場合) または `/etc/apache2` (Ubuntu の場合) に設定されます。この `template` リソースが設定ファイルを作成または変更する場合は、`notifies` コマンドが Apache サービスの再起動をスケジュール設定します。 ``` <% if node['tomcat']['apache_tomcat_bind_mod'] == 'proxy_ajp' -%> ProxyPass <%= node['tomcat']['apache_tomcat_bind_path'] %> ajp://localhost:<%= node['tomcat']['ajp_port'] %>/ ProxyPassReverse <%= node['tomcat']['apache_tomcat_bind_path'] %> ajp://localhost:<%= node['tomcat']['ajp_port'] %>/ <% else %> ProxyPass <%= node['tomcat']['apache_tomcat_bind_path'] %> http://localhost:<%= node['tomcat']['port'] %>/ ProxyPassReverse <%= node['tomcat']['apache_tomcat_bind_path'] %> http://localhost:<%= node['tomcat']['port'] %>/ <% end -%> ``` このテンプレートは、[ProxyPass](https://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypass) ディレクティブおよび [ProxyPassReverse](https://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypassreverse) ディレクティブを使用して、Apache と Tomcat の間でトラフィックを渡すために使用するポートを設定します。両方のサーバーが同じインスタンスにあるため、1 つの localhost URL を使用することができ、どちらもデフォルトで `http://localhost:8080` に設定されます。 # Configure レシピ **重要** この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポートチームにお問い合わせください。 Configure レシピは、レイヤーの Configure [ライフサイクル](workingcookbook-events.md)イベントに割り当てられます。このイベントは、スタックのすべてのインスタンスで、インスタンスがオンライン状態になったとき、またはオンライン状態から別の状態になったときに発生します。Configure レシピを使用することで、必要に応じ、変更に対応してインスタンスの設定を調整します。Configure レシピを実装するときは、スタックの設定の変更がこのレイヤーとは無関係なインスタンスに関与している場合があることに注意してください。このレシピは、適切に応答できる必要があります。それは、場合によっては何も処理を実行しないことがあることを意味します。 ## tomcat::configure `tomcat::configure` レシピは、レイヤーの Configure ライフサイクルイベントに対応します。 ``` include_recipe 'tomcat::context' # Optional: Trigger a Tomcat restart in case of a configure event, if relevant # settings in custom JSON have changed (e.g. java_opts/JAVA_OPTS): #include_recipe 'tomcat::container_config' ``` `tomcat::configure` レシピは、2 つの依存レシピを実行するメタレシピです。 1. `tomcat::context` レシピは、ウェブアプリケーションのコンテキスト設定ファイルを作成します。このファイルは、次のセクションで説明するように、アプリケーションが MySQL インスタンスとの通信に使用する JDBC リソースを設定します。設定イベントに応じてこのレシピを実行すると、データベースレイヤーが変更された場合に、レイヤーでウェブアプリケーションのコンテキスト設定ファイルを更新することができます。 1. `tomcat::container_config` Setup レシピは、コンテナ設定のあらゆる変更をキャプチャするために再度実行されます。 `include` の `tomcat::container_config` は、この例のようにコメントアウトされます。カスタム JSON を使用して Tomcat の設定を変更する必要がある場合は、このコメントを削除できます。その後、Configure ライフサイクルイベントでは、`tomcat::container_config` を実行することにより「[tomcat::container\$1config](create-custom-setup.md#create-custom-setup-config)」で説明するように Tomcat 関連の設定ファイルを更新し、Tomcat サービスを再起動します。 ## tomcat::context Tomcat クックブックは、[J2EE DataSource](http://docs.oracle.com/javase/tutorial/jdbc/basics/sqldatasources.html) オブジェクトを使用することで、別のインスタンスで実行されている場合がある MySQL データベースサーバーにアプリケーションがアクセスできるようにします。Tomcat では、各アプリケーションに対してウェブアプリケーションのコンテキスト設定ファイルを作成してインストールすることにより、接続を有効にできます。このファイルは、アプリケーションと、アプリケーションがデータベースとの通信に使用する JDBC リソースとの間の関係を定義します。詳細については、「[コンテキストコンテナ](http://tomcat.apache.org/tomcat-7.0-doc/config/context.html)」を参照してください。 `tomcat::context` レシピの主な目的は、この設定ファイルを作成することです。 ``` include_recipe 'tomcat::service' node[:deploy].each do |application, deploy| context_name = deploy[:document_root].blank? ? application : deploy[:document_root] template "context file for #{application} (context name: #{context_name})" do path ::File.join(node['tomcat']['catalina_base_dir'], 'Catalina', 'localhost', "#{context_name}.xml") source 'webapp_context.xml.erb' owner node['tomcat']['user'] group node['tomcat']['group'] mode 0640 backup false only_if { node['datasources'][context_name] } variables(:resource_name => node['datasources'][context_name], :webapp_name => application) notifies :restart, resources(:service => 'tomcat') end end ``` Tomcat クックブック属性に加えて、このレシピは OpsWorks 、スタックが [Configure イベントでインストールするスタック設定とデプロイ属性](workingcookbook-json.md)を使用します。 OpsWorks スタックサービスは、データバッグを使用するか、各インスタンスで属性を検索してインストールすることで、レシピが通常取得する情報を含む属性を各インスタンスのノードオブジェクトに追加します。それらの属性に含まれるのは、スタック設定、デプロイされるアプリケーション、ユーザーに必要なカスタムデータに関する詳細情報です。レシピは、標準の Chef ノード構文を使用することで、スタック設定およびデプロイ属性からデータを取得できます。詳細については、「[スタック設定およびデプロイメント属性](workingcookbook-json.md)」を参照してください。Chef 11.10 スタックの場合、Chef の検索を使用してスタック設定およびデプロイデータを取得することもできます。詳細については、「[Chef の検索の使用](workingcookbook-chef11-10.md#workingcookbook-chef11-10-search)」を参照してください。 `deploy` 属性とは、コンソールまたは API を介して定義された、または OpsWorks スタックサービスによって生成されたデプロイ関連の属性を含む`[:deploy]`名前空間を指します。`deploy` 属性には、デプロイされる各アプリケーションの属性が含まれています。この属性の名前はアプリケーションの短縮名です。各アプリケーション属性には、ドキュメントのルート (`[:deploy][:appname][:document_root]`) など、アプリケーションの特性を示す一連の属性が含まれています。 `context` レシピは、最初に、[tomcat::service](create-custom-setup.md#create-custom-setup-service) を呼び出すことにより、この Chef 実行に対してサービスが定義されるようにします。次に、設定ファイルの名前を表す `context_name` 変数を定義します。拡張子の `.xml` は除外されます。デフォルトのドキュメントのルートを使用する場合、`context_name` はアプリケーションの短縮名に設定されます。それ以外の場合は、指定されたドキュメントのルートに設定されます。「[スタックの作成とアプリケーションの実行](create-custom-stack.md)」で説明する例では、ドキュメントのルートは `"ROOT"` に設定されるため、コンテキストは ROOT で、設定ファイルは `ROOT.xml` という名前になります。レシピの大部分は、デプロイされているアプリケーションのリストを対象として機能し、各アプリケーションに対して `webapp_context.xml.erb` テンプレートを使用してコンテキスト設定ファイルを作成します。この例では、1 つのアプリケーションのみをデプロイしますが、`deploy` 属性でアプリケーションのリストとして定義する必要があります。 `webapp_context.xml.erb` テンプレートは、オペレーティングシステム固有でないため、`templates`ディレクトリの `default` サブディレクトリに配置されています。このレシピは、次のように設定ファイルを作成します。 + デフォルトの属性値を使用すると、設定ファイル名は `context_name.xml` に設定され、`/etc/tomcat6/Catalina/localhost/` ディレクトリにインストールされます。スタック設定属性から取得される `['datasources']` ノードには、1 つ以上の属性が含まれます。各属性は、関連付けられたアプリケーションがデータベースとの通信に使用する JDBC データリソースにコンテキスト名をマッピングします。「[スタックの作成とアプリケーションの実行](create-custom-stack.md)」で後ほど説明するように、スタックの作成時に、ノードとそのコンテンツがカスタム JSON を使用して定義されます。この例では、ROOT コンテキスト名と jdbc/mydb という名前の JDBC リソースを関連付ける 1 つの属性を使用します。 + デフォルトの属性値を使用すると、ファイルのユーザーとグループはどちらも、Tomcat パッケージの `tomcat` (Amazon Linux の場合) または `tomcat6` (Ubuntu の場合) によって定義された値に設定されます。 + `template` リソースは、`['datasources']` ノードが存在し、`context_name` 属性を含む場合にのみ、設定ファイルを作成します。 + `template` リソースは、2 つの変数 `resource_name` と `webapp_name` を定義します。 `resource_name` は `context_name` に関連付けられているリソース名に設定され、`webapp_name` はアプリケーションの短縮名に設定されます。 + template リソースは、Tomcat サービスを再起動し、変更を読み込んでアクティブにします。 `webapp_context.xml.erb` テンプレートは、属性の固有のセットを使用する `Context` 要素を含む `Resource` 要素で構成されています。 `Resource` 属性は、コンテキスト設定の特性を示します。 + **name** (名前) - JDBC リソース名。`tomcat::context` で定義されている `resource_name` 値に設定されます。たとえば、リソース名は jdbc/mydb に設定されます。 + **auth** および **[type** (タイプ)] - これらは JDBC `DataSource` 接続の標準設定です。 + **maxActive** (マックスアクティブ)、**maxIdle** (マックスアイドル)、および **maxWait** (マックスウェイト) - アクティブ接続およびアイドル接続の最大数、および返される接続を待機する最大時間。 + **username** (ユーザーネーム) および **password** (パスワードパスワード) - データベースのユーザー名およびルートパスワード。`deploy` 属性から取得されます。 + **driverClassName** (ドライバークラス名) - JDBC ドライバのクラス名。MySQL driver に設定されます。 + **url** (url) - 接続 URL。プレフィックスはデータベースによって異なります。MySQL の場合は `jdbc:mysql` に、Postgres の場合は `jdbc:postgresql` に、SQL Server の場合は `jdbc:sqlserver` に設定する必要があります。この例では、URL を `jdbc:mysql://host_IP_Address:3306:simplejsp` に設定します。ここで、*simplejsp* はアプリケーションの短縮名です。 + **factory** (ファクトリ) - `DataSource` ファクトリ。MySQL データベースに必須です。この設定ファイルの詳細については、Tomcat Wiki のトピック「[DataSource の使用方法](http://wiki.apache.org/tomcat/UsingDataSources)」を参照してください。 # Deploy レシピ **重要** この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポートチームにお問い合わせください。 Deploy レシピは、レイヤーの Deploy [ライフサイクル](workingcookbook-events.md)イベントに割り当てられます。これは通常、アプリケーションをデプロイするたびにスタックのすべてのインスタンスで発生しますが、オプションでイベントを指定されたインスタンスのみに制限できます。 OpsWorks スタックは、Setup レシピの完了後に、新しいインスタンスで Deploy レシピも実行します。Deploy レシピの主な目的は、コードと関連ファイルをリポジトリからアプリケーションサーバーレイヤーのインスタンスにデプロイすることです。ただし、多くの場合、その他のレイヤーでも Deploy レシピを実行します。これにより、これらのレイヤーのインスタンスで、たとえば、新しくデプロイされたアプリケーションに応じて設定を更新できるようになります。Deploy レシピを実装するときは、Deploy イベントが必ずしもアプリケーションがインスタンスにデプロイされることを意味するわけではないことに注意してください。アプリケーションがスタック内の別のインスタンスにデプロイされていることを単に通知することで、そのインスタンスで必要な更新ができるようにしているだけの場合もあります。このレシピは、適切に応答できる必要があります。それは、何も処理を実行しない場合があることを意味します。 OpsWorks スタックは、標準アプリケーションタイプのアプリケーションを対応する組み込みアプリケーションサーバーレイヤーに自動的にデプロイします。アプリケーションをカスタムレイヤーにデプロイするには、アプリケーションのファイルをリポジトリからインスタンスの適切な場所にダウンロードするカスタム Deploy レシピを実装する必要があります。ただし、多くの場合、組み込みの[デプロイクックブック](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.4/deploy)を使用してデプロイの一部の側面を処理することで、記述する必要のあるコードの量を制限することができます。たとえば、サポートされているリポジトリの 1 つにファイルを保存する場合、リポジトリからレイヤーのインスタンスへのファイルダウンロードの詳細を組み込みのクックブックで処理できます。 `tomcat::deploy` レシピは、Deploy ライフサイクルイベントに割り当てられます。 ``` include_recipe 'deploy' node[:deploy].each do |application, deploy| opsworks_deploy_dir do user deploy[:user] group deploy[:group] path deploy[:deploy_to] end opsworks_deploy do deploy_data deploy app application end ... ``` `tomcat::deploy` レシピは、アプリケーション固有ではないデプロイの側面に組み込みのデプロイクックブックを使用します。`deploy` レシピ (組み込み `deploy::default` レシピの省略表現) は、`deploy` 属性のデータに基づいてユーザー、グループなどのセットアップの詳細を処理する組み込みレシピです。このレシピは、2 つの組み込みの Chef 定義 `opsworks_deploy_dir` と `opworks_deploy` を使用して、アプリケーションをインストールします。 `opsworks_deploy_dir` 定義は、アプリケーションのデプロイメント JSON のデータに基づいて、ディレクトリ構造をセットアップします。定義は、基本的にはリソース定義をパッケージするための便利な方法であり、クックブックの `definitions` ディレクトリに配置されています。レシピでは、リソースと同様に定義を使用できますが、この定義自体には、定義に含まれた単なるリソースである関連付けられたプロバイダーはありません。基盤となるリソース定義に渡されるレシピ内の変数は定義できます。`tomcat::deploy` レシピは、デプロイメント JSON のデータに基づいて、`user`、`group`、および `path` の各変数を設定します。これらの変数は、定義の [directory リソース](https://docs.chef.io/chef/resources.html#directory)に渡されます。このリソースはディレクトリを管理します。 **注記** `[:opsworks][:deploy_user][:user]` 属性と `[:opsworks][:deploy_user][:group]` 属性により、デプロイされているアプリケーションのユーザーとグループが定義されます。これらの属性は、[組み込みのデプロイクックブックの `deploy.rb` 属性ファイル](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.4/deploy/attributes/deploy.rb)で定義されています。`[:opsworks][:deploy_user][:user]` の初期値は `deploy` です。`[:opsworks][:deploy_user][:group]` のデフォルト値は、インスタンスのオペレーティングシステムによって異なります。 Ubuntu インスタンスでは、デフォルトのグループは `www-data` です。 Nginx と Unicorn を使用する Rails アプリケーションアプリケーションサーバーレイヤーのメンバーである Amazon Linux インスタンスの場合、デフォルトのグループは `nginx` です。その他のすべての Amazon Linux インスタンスの場合、デフォルトのグループは `apache` です。カスタム JSON またはカスタム属性ファイルを使用して適切な属性を上書きすることにより、設定を変更できます。詳細については、「[属性の上書き](workingcookbook-attributes.md)」を参照してください。その他の定義 `opsworks_deploy` は、アプリケーションのコードとリポジトリの関連ファイルの確認、およびそれらのインスタンスへのデプロイの詳細を、`deploy` 属性のデータに基づいて処理します。任意のアプリケーションタイプに対してこの定義を使用できます。ディレクトリ名などのデプロイの詳細はコンソールまたは API で指定して、`deploy` 属性に含まれています。ただし、`opsworks_deploy` は、Git、Subversion、S3、および HTTP という 4 つの[サポートされているリポジトリのタイプ](workingcookbook-installingcustom-repo.md)に対してのみ機能します。異なるリポジトリのタイプを使用する場合は、このコードを自分で実装する必要があります。アプリケーションのファイルを、Tomcat の `webapps` ディレクトリにインストールします。一般的な方法は、ファイルを `webapps` に直接コピーすることです。ただし、 OpsWorks スタックのデプロイは、インスタンス上に最大 5 つのバージョンのアプリケーションを保持するように設計されているため、必要に応じて以前のバージョンにロールバックできます。したがって、 OpsWorks スタックは以下を実行します。 1. `/srv/www/my_1st_jsp/releases/20130731141527` など、名前にタイムスタンプが含まれた明確に区別できるディレクトリにアプリケーションをデプロイします。 1. この一意のディレクトリに、`current` という名前が付いた `/srv/www/my_1st_jsp/current` などのシンボリックリンクを作成します。 1. `webapps` ディレクトリからステップ 2 で作成した `current` へのシンボリックリンクがまだない場合は、これを作成します。以前のバージョンにロールバックする必要がある場合は、該当するタイムスタンプが含まれた明確に区別できるディレクトリをポイントするように `current` シンボリックリンクを変更します。例えば、`/srv/www/my_1st_jsp/current` のリンクターゲットを変更します。 `tomcat::deploy` の中間のセクションは、シンボリックリンクをセットアップします。 ``` ... current_dir = ::File.join(deploy[:deploy_to], 'current') webapp_dir = ::File.join(node['tomcat']['webapps_base_dir'], deploy[:document_root].blank? ? application : deploy[:document_root]) # opsworks_deploy creates some stub dirs, which are not needed for typical webapps ruby_block "remove unnecessary directory entries in #{current_dir}" do block do node['tomcat']['webapps_dir_entries_to_delete'].each do |dir_entry| ::FileUtils.rm_rf(::File.join(current_dir, dir_entry), :secure => true) end end end link webapp_dir do to current_dir action :create end ... ``` このレシピは、まず 2 つの変数 `current_dir` と `webapp_dir` を作成して、`current` ディレクトリと `webapp` ディレクトリをそれぞれ表します。次に、`link` リソースを使用して、`webapp_dir` を `current_dir` にリンクします。 OpsWorks Stacks `deploy::default`レシピは、この例に必要ではないスタブディレクトリを作成するため、抜粋の中央部分で削除します。 `tomcat::deploy` の最後の部分は、必要に応じて Tomcat サービスを再起動します。 ``` ... include_recipe 'tomcat::service' execute 'trigger tomcat service restart' do command '/bin/true' not_if { node['tomcat']['auto_deploy'].to_s == 'true' } notifies :restart, resources(:service => 'tomcat') end end include_recipe 'tomcat::context' ``` このレシピは、最初に `tomcat::service` を実行して、この Chef 実行に対してサービスが定義されるようにします。次に、[execute リソース](https://docs.chef.io/chef/resources.html#execute)を使用して、再起動するようにサービスに通知しますが、それは `['tomcat']['auto_deploy']` が `'true'` に設定されている場合のみです。その他の場合、Tomcat は `webapps` ディレクトリ内の変更をリッスンします。これにより、明示的な Tomcat サービスの再起動が不必要になります。 **注記** `execute` リソースは実際には実質的なことを何も実行せず、`/bin/true` は単に成功コードを返すダミーのシェルスクリプトです。単に再起動通知を生成するための便利な方法として使用されています。前に説明したように、通知を使用することで、サービスが必要以上に頻繁に再起動されなくなります。最後に、`tomcat::deploy` は `tomcat::context` を実行し、バックエンドデータベースが変更されている場合は、ウェブアプリケーションのコンテキスト設定ファイルを更新します。 # スタックの作成とアプリケーションの実行 **重要** この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポートチームにお問い合わせください。このセクションでは、Tomcat クックブックを使用して、SimpleJSP という名前のシンプルな Java サーバーページ (JSP) アプリケーションを実行する基本的なスタック設定を実装する方法について説明します。スタックは、TomCustom という名前の Tomcat ベースのカスタムレイヤーと MySQL で構成されます。SimpleJSP は、TomCustom にデプロイされ、MySQL データベースの一部の情報を表示します。 OpsWorks スタックの使用方法の基本をまだ理解していない場合は、まずをお読みください[Chef 11 Linux スタックの使用開始](gettingstarted.md)。 ## SimpleJSP アプリケーション SimpleJSP アプリケーションは、データベース接続のセットアップ方法、およびスタックの MySQL データベースからデータを取得する方法の基本を示します。 ``` DB Access <%@ page language="java" import="java.sql.*,javax.naming.*,javax.sql.*" %> <% StringBuffer output = new StringBuffer(); DataSource ds = null; Connection con = null; Statement stmt = null; ResultSet rs = null; try { Context initCtx = new InitialContext(); ds = (DataSource) initCtx.lookup("java:comp/env/jdbc/mydb"); con = ds.getConnection(); output.append("Databases found:
"); stmt = con.createStatement(); rs = stmt.executeQuery("show databases"); while (rs.next()) { output.append(rs.getString(1)); output.append("
"); } } catch (Exception e) { output.append("Exception: "); output.append(e.getMessage()); output.append("
"); } finally { try { if (rs != null) { rs.close(); } if (stmt != null) { stmt.close(); } if (con != null) { con.close(); } } catch (Exception e) { output.append("Exception (during close of connection): "); output.append(e.getMessage()); output.append("
"); } } %> <%= output.toString() %> ``` SimpleJSP は、`DataSource` オブジェクトを使用して MySQL データベースと通信します。Tomcat は、[ウェブアプリケーションのコンテキスト設定ファイル](create-custom-configure.md#create-custom-configure-context)内のデータを使用し、`DataSource` オブジェクトを作成して初期化し、論理名に結合します。次に、Java Naming and Directory Interface (JNDI) ネーミングサービスで論理名を登録します。適切な `DataSource` オブジェクトのインスタンスを取得するには、`InitialContext` オブジェクトを作成し、リソースの論理名をオブジェクトの `lookup` メソッドに渡します。これにより、適切なオブジェクトを取得します。SimpleJSP の例の論理名 `java:comp/env/jdbc/mydb` には、次のコンポーネントがあります。 + ルート名前空間の `java`。名前の残りの部分とはコロン (:) で区切られます。 + 任意の追加の名前空間。スラッシュ (/) で区切られます。 Tomcat は、`comp/env` 名前空間にリソースを自動的に追加します。 + リソース名。ウェブアプリケーションのコンテキスト設定ファイルで定義され、名前空間とはスラッシュで区切られます。この例では、リソース名は `jdbc/mydb` です。データベースへの接続を確立するために、SimpleJSP は次の処理を実行します。 1. `DataSource` オブジェクトの `getConnection` メソッドを呼び出し、`Connection` オブジェクトを返します。 1. `Connection` オブジェクトの `createStatement` メソッドを呼び出し、データベースとの通信に使用する `Statement` オブジェクトを作成します。 1. 適切な `Statement` メソッドを呼び出すことで、データベースと通信します。 SimpleJSP は、`executeQuery` を呼び出し、サーバーのデータベースをリスト表示する SHOW DATABASES クエリを実行します。 `executeQuery` メソッドは、クエリの結果を含む `ResultSet` オブジェクトを返します。SimpleJSP は、返された `ResultSet` オブジェクトからデータベース名を取得し、それらを連結して出力文字列を作成します。最後に、この例では `ResultSet`、`Statement`、および `Connection` の各オブジェクトを閉じます。JSP と JDBC の詳細については、「[JavaServer Pages テクノロジー](http://docs.oracle.com/javaee/5/tutorial/doc/bnagx.html)」と「[JDBC の基本](http://docs.oracle.com/javase/tutorial/jdbc/basics/)」をそれぞれ参照してください。スタックで SimpleJSP を使用するには、SimpleJSP をリポジトリに配置する必要があります。サポートされている任意のリポジトリを使用できますが、この後のセクションで説明する例のスタックで SimpleJSP を使用するには、SimpleJSP をパブリックの S3 アーカイブに配置する必要があります。その他の標準のリポジトリの使用方法の詳細については、「[クックブックリポジトリ](workingcookbook-installingcustom-repo.md)」を参照してください。 **SimpleJSP を S3 アーカイブリポジトリに配置するには** 1. コード例を `simplejsp.jsp` という名前のファイルにコピーし、そのファイルを `simplejsp` という名前のディレクトリに配置します。 1. `.zip` ディレクトリの `simplejsp` アーカイブを作成します。 1. パブリックの Amazon S3 バケットを作成し、`simplejsp.zip` をそのバケットにアップロードして、ファイルをパブリックにします。このタスクを実行する方法については、「[Amazon Simple Storage Service の使用開始](https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html)」を参照してください。 ## スタックの作成 SimpleJSP を実行するには、次のレイヤーを含んだスタックが必要です。 + バックエンド MySQL サーバーをサポートする MySQL レイヤー。 + Tomcat サーバーインスタンスをサポートするために Tomcat クックブックを使用するカスタムレイヤー。 **スタックを作成するには** 1. OpsWorks スタックダッシュボードで、**スタックの追加**をクリックして新しいスタックを作成し、**詳細 >>** をクリックしてすべてのオプションを表示します。スタックを次のように設定します。 + **Name** (名前) - ユーザー定義のスタック名です。この例では TomStack を使用します。 + **[Use custom Chef cookbooks]** (カスタムChefのクックブックを使用) - トグルを **[Yes]** (はい) に設定します。いくつかの追加オプションが表示されます。 + **Repository type** (リポジトリタイプ) - Git + **Repository URL** (リポジトリのURL) - `git://github.com/amazonwebservices/opsworks-example-cookbooks.git` 。 + **Custom Chef JSON** (カスタムChef JSON) - 次の JSON を追加します。 ``` { "tomcat": { "base_version": 7, "java_opts": "-Djava.awt.headless=true -Xmx256m" }, "datasources": { "ROOT": "jdbc/mydb" } } ``` 残りのオプションについては、デフォルトをそのまま使用できます。カスタム JSON は、次の処理を実行します。 + Tomcat クックブックの `['base_version']` 属性を上書きして Tomcat のバージョンを 7 に設定します。デフォルト値は 6 です。 + Tomcat クックブックの `['java_opts']` 属性を上書きし、インスタンスがヘッドレスであることを指定して JVM の最大ヒープサイズを 256 MB に設定します。デフォルト値では、Amazon Linux を実行しているインスタンスに対してはオプションが設定されません。 + `['datasources]` 属性値を指定します。これにより、「[tomcat::context](create-custom-configure.md#create-custom-configure-context)」で説明するように、JDBC リソース名 (jdbc/mydb) がウェブアプリケーションのコンテキスト名 (ROOT) に割り当てられます。この最後の属性にはデフォルト値はありません。カスタム JSON で設定する必要があります。 ![\[Configuration Management interface showing Chef version options and custom JSON input field.\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/tom_add_stack.png) 1. [**Add a layer**] をクリックします。[**Layer type**] では [**MySQL**] を選択します。次に、[**Add Layer**] をクリックします。 1. ナビゲーションペインで [**Instances**] をクリックし、[**Add an instance**] をクリックします。[**Add Instance**] をクリックして、デフォルトの値をそのまま使用します。インスタンスに関する行で、[**start**] をクリックします。 1. [**Layers**] (レイヤー) ページに戻り、[**\$1 Layer**] (\$1 レイヤー) をクリックしてレイヤーを追加します。[**Layer type**] では [**Custom**] をクリックします。このテンプレートでは、**TomCustom** と **tomcustom** を、それぞれレイヤーの名前と短縮名として使用します。 ![\[Add Layer form with Custom layer type, Name, and Short name fields for creating a customized layer.\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/tom_add_custom_layer.png) 1. [**Layers**] (レイヤー) ページで、カスタムレイヤーに対して、[**Recipes**] (レシピ) をクリックし、[**Edit**] (編集) をクリックします。[**Custom Chef Recipes**] で、次のように、Tomcat クックブックのレシピをレイヤーのライフサイクルイベントに割り当てます。 + [**Setup**] には **tomcat::setup** を入力し、[**\$1**] をクリックします。 + [**Configure**] には **tomcat::configure** を入力し、[**\$1**] をクリックします。 + [**Deploy**] には **tomcat::deploy** を入力し、[**\$1**] をクリックします。次に、[**Save**] をクリックします。 . ![\[Custom Chef Recipes interface showing setup, configure, and deploy steps with options.\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/tom_events.png) 1. ナビゲーションペインで [**Apps**] をクリックし、[**Add an app**] をクリックします。次のオプションを指定し、[**Add App**] をクリックします。 + **Name** – アプリケーションの名前。この例では SimpleJSP を使用し、スタックによって生成される短縮名は simplejsp OpsWorks になります。 + **App type** (アプリケーションタイプ) - このオプションでは **Other** (その他) を設定します。 OpsWorks スタックは、関連するサーバーインスタンスに標準アプリケーションタイプを自動的にデプロイします。[**App type**] でこれ以外を選択すると、 OpsWorks スタックは単純に Deploy レシピを実行し、このレシピでデプロイを処理することになります。 + **Document root** (ドキュメントルート) - このオプションを **ROOT** に設定します。 **Document root** (ドキュメントルート) の値は、コンテキスト名を指定します。 + **Repository type** (リポジトリタイプ) - このオプションを **[S3 Archive** (S3 アーカイブ)] に設定します。 + **Repository URL** (リポジトリのURL) - このオプションは、先に作成したアプリケーションの Amazon S3 の URL に設定します。その他のオプションについては、デフォルトの設定を使用します。 ![\[Application settings form with fields for name, app type, document root, and source details.\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/tom_app.png) 1. **インスタンス**ページを使用して、TomCustom レイヤーにインスタンスを追加して起動します。 OpsWorks スタックは Setup レシピの完了後に新しいインスタンスで Deploy レシピを自動的に実行するため、インスタンスを起動すると SimpleJSP もデプロイされます。 1. TomCustom インスタンスがオンラインになったら、[**Instances**] ページでそのインスタンス名をクリックして詳細を確認します。パブリック IP アドレスをコピーします。http://*publicIP*/tc/*appname.jsp* のように URL を作成します。たとえば、この URL は **http://50.218.191.172/tc/simplejsp.jsp** のようになります。 **注記** リクエストを Tomcat に転送する Apache の URL は、デフォルトの `['tomcat']['apache_tomcat_bind_path']` 属性である `/tc/` に設定されます。SimpleJSP ドキュメントのルートは、`ROOT` に設定されます。これは、`/` に解決される特殊な値です。したがって URL は ".../tc/simplejsp.jsp" になります。 1. 前のステップの URL をブラウザに貼り付けます。次のように表示されます。 ``` Databases found: information_schema simplejsp test ``` **注記** スタックに MySQL インスタンスがある場合、 OpsWorks Stacks はアプリごとに、アプリの短縮名でという名前のデータベースを自動的に作成します。 # スタック設定およびデプロイメント属性 **重要** この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポートチームにお問い合わせください。 OpsWorks スタックは、デプロイライフサイクルイベントに応答してデプロイコマンドなど、インスタンスでコマンドを実行すると、スタックの現在の設定を記述する属性のセットをインスタンスのノードオブジェクトに追加します。デプロイイベントと [Execute Recipes スタックコマンド](workingstacks-commands.md)の場合、 OpsWorks スタックはデプロイ属性をインストールし、追加のデプロイ情報を提供します。ノードオブジェクトの詳細については、「[属性の上書き](workingcookbook-attributes.md)」を参照してください。完全修飾ノード名などの、一般的に使用されるスタック設定とデプロイメント属性の一覧については、「[スタック設定およびデプロイ属性: Linux](attributes-json-linux.md)」および「[組み込みクックブックの属性](attributes-recipes.md)」を参照してください。 **注記** Linux スタックの場合、エージェントの CLI の [get\$1json コマンド](agent-json.md)を使用して、JSON オブジェクトの形式でこれらの属性の完全なリストを取得できます。以降のセクションでは、以下のような構成の単純なスタックの Configure イベントと Deploy イベントに関連する属性を示します。 + 2 つのインスタンスを持つ PHP アプリケーションサーバーレイヤー + 1 つのインスタンスを持つ HAProxy レイヤーこの例は、PHP アプリケーションサーバーインスタンスの 1 つである **[php-app1]** のものです。属性は、わかりやすいように、JSON オブジェクトの形式で表示されます。オブジェクトの構造は属性の完全修飾名に対応付けされます。例えば、`node[:opsworks][:ruby_version]` 属性は JSON 形式では以下のように表示されます。 ``` { "opsworks": { ... "ruby_version": "1.8.7", ... } } ``` **Topics** + [属性の設定](#workingcookbook-json-configure) + [デプロイ属性](#workingcookbook-json-deploy) ## 属性の設定以下の JSON オブジェクトで示しているのは Configure イベントの属性です。このイベントは、インスタンスがオンラインまたはオフラインになったときに、スタックのすべてのインスタンスで発生します。属性には、組み込みのスタック設定属性と、イベントの前にスタック用に定義した任意の[カスタム JSON 属性](workingstacks-json.md) (この例にはありません) が含まれます。長さの関係で編集されています。さまざまな属性の詳細な説明については、「[スタック設定およびデプロイ属性: Linux](attributes-json-linux.md)」および「[組み込みクックブックの属性](attributes-recipes.md)」を参照してください。 ``` { "opsworks": { "layers": { "php-app": { "id": "4a2a56c8-f909-4b39-81f8-556536d20648", "instances": { "php-app2": { "elastic_ip": null, "region": "us-west-2", "booted_at": "2013-02-26T20:41:10+00:00", "ip": "192.0.2.0", "aws_instance_id": "i-34037f06", "availability_zone": "us-west-2a", "instance_type": "c1.medium", "private_dns_name": "ip-10-252-0-203.us-west-2.compute.internal", "private_ip": "10.252.0.203", "created_at": "2013-02-26T20:39:39+00:00", "status": "online", "backends": 8, "public_dns_name": "ec2-192-0-2-0.us-west-2.compute.amazonaws.com" }, "php-app1": { ... } }, "name": "PHP Application Server" }, "lb": { "id": "15c86142-d836-4191-860f-f4d310440f14", "instances": { "lb1": { ... } }, "name": "Load Balancer" } }, "agent_version": "104", "applications": [ ], "stack": { "name": "MyStack" }, "ruby_version": "1.8.7", "sent_at": 1361911623, "ruby_stack": "ruby_enterprise", "instance": { "layers": [ "php-app" ], "region": "us-west-2", "ip": "192.0.2.0", "id": "45ef378d-b87c-42be-a1b9-b67c48edafd4", "aws_instance_id": "i-32037f00", "availability_zone": "us-west-2a", "private_dns_name": "ip-10-252-84-253.us-west-2.compute.internal", "instance_type": "c1.medium", "hostname": "php-app1", "private_ip": "10.252.84.253", "backends": 8, "architecture": "i386", "public_dns_name": "ec2-192-0-2-0.us-west-2.compute.amazonaws.com" }, "activity": "configure", "rails_stack": { "name": null }, "deployment": null, "valid_client_activities": [ "reboot", "stop", "setup", "configure", "update_dependencies", "install_dependencies", "update_custom_cookbooks", "execute_recipes" ] }, "opsworks_custom_cookbooks": { "recipes": [ ], "enabled": false }, "recipes": [ "opsworks_custom_cookbooks::load", "opsworks_ganglia::configure-client", "ssh_users", "agent_version", "mod_php5_apache2::php", "php::configure", "opsworks_stack_state_sync", "opsworks_custom_cookbooks::execute", "test_suite", "opsworks_cleanup" ], "opsworks_rubygems": { "version": "1.8.24" }, "ssh_users": { }, "opsworks_bundler": { "manage_package": null, "version": "1.0.10" }, "deploy": { } } ``` 情報の大部分は、名前空間とも呼ばれる `opsworks` 属性に含まれています。主な属性を次に示します。 + `layers` 属性 - それぞれの属性がスタックの 1 つのレイヤーの設定を説明している、属性のセットです。レイヤーは短縮名 (この例では `php-app` と `lb`) で識別されます。その他のの短縮名の詳細については、「[OpsWorks スタックレイヤーリファレンス](layers.md)」を参照してください。 + `instances` 属性 - すべてのレイヤーにはインスタンスの短縮名が付けられた `instances` 要素があり、レイヤーのオンラインインスタンスごとに 1 つの属性が含まれています。 PHP アプリケーションサーバーレイヤーには 2 つのインスタンス (`php-app1` と `php-app2`)があります。HAProxy レイヤーには 1 つのインスタンス (`lb1`) があります。 **注記** `instances` 要素には、特定のスタック設定およびデプロイ属性が作成された時点でオンライン状態にあったインスタンスのみが含まれています。 + インスタンスの属性 - 各インスタンスの属性には、インスタンスのプライベート IP アドレスやプライベート DNS 名など、インスタンスを特徴づける一連の属性が含まれています。わかりやすいように、例には `php-app2` 属性の詳細のみを示します。他のインスタンスにも同様の情報が含まれています。 + `applications` - デプロイされるアプリケーションのリスト (この例では使用していません)。 + `stack` - スタック名 (この例では) `MyStack` + `instance` - これらの属性がインストールされるインスタンス (この例では) `php-app1` レシピは、この属性を使用して、インスタンスのパブリック IP アドレスなどの、レシピが実行されているインスタンスに関する情報を取得できます。 + `activity` - 属性を生成したアクティビティ (この例では Configure イベント)。 + `rails_stack` - Rails アプリケーションサーバーレイヤーが含まれるスタックの Rails スタックです。 + `deployment` - これらの属性がデプロイに関連付けられているかどうか。この例では、それらの属性が Configure イベントに関連付けられているため、`null` に設定されています。 + `valid_client_activities` - 有効なクライアントアクティビティのリストです。 `opsworks` 属性の後には、以下のような他の最上位属性がいくつか続きます。 + `opsworks_custom_cookbooks` - カスタムクックブックが有効化されているかどうかを示します。有効化されている場合、属性にはカスタムレシピのリストが含まれます。 + `recipes` - このアクティビティによって実行されたレシピです。 + `opsworks_rubygems` - インスタンスの RubyGems バージョンです。 + `ssh_users` - SSH ユーザーのリスト (この例にはありません)。 + `opsworks_bundler` - Bundler のバージョンとそれが有効化されているかどうかを示します。 + `deploy` - デプロイメントアクティビティに関する情報です (この例にはありません)。 ## デプロイ属性 Deploy イベントまたは [Execute Recipes スタックコマンド](workingstacks-commands.md)の属性は、組み込みのスタック設定およびデプロイ属性と、カスタムのスタック設定またはデプロイ属性で構成されます (この例にはありません)。以下の JSON オブジェクトは、**php-app1** の属性を示しています。それらの属性は、スタックの PHP インスタンスに SimplePHP アプリケーションをデプロイした Deploy イベントに関連付けられています。オブジェクトの多くは、前のセクションで説明した Configure イベントの属性に類似したスタック設定属性で構成されます。そのため、例では主にデプロイ固有の属性に焦点を当てています。さまざまな属性の詳細な説明については、「[スタック設定およびデプロイ属性: Linux](attributes-json-linux.md)」および「[組み込みクックブックの属性](attributes-recipes.md)」を参照してください。 ``` { ... "opsworks": { ... "activity": "deploy", "applications": [ { "slug_name": "simplephp", "name": "SimplePHP", "application_type": "php" } ], "deployment": "5e6242d7-8111-40ee-bddb-00de064ab18f", ... }, ... { "ssh_users": { }, "deploy": { "simplephpapp": { "application": "simplephpapp", "application_type": "php", "environment_variables": { "USER_ID": "168424", "USER_KEY": "somepassword" }, "auto_bundle_on_deploy": true, "deploy_to": "/srv/www/simplephpapp", "deploying_user": "arn:aws:iam::123456789012:user/guysm", "document_root": null, "domains": [ "simplephpapp" ], "migrate": false, "mounted_at": null, "rails_env": null, "restart_command": "echo 'restarting app'", "sleep_before_restart": 0, "ssl_support": false, "ssl_certificate": null, "ssl_certificate_key": null, "ssl_certificate_ca": null, "scm": { "scm_type": "git", "repository": "git://github.com/amazonwebservices/opsworks-demo-php-simple-app.git", "revision": "version1", "ssh_key": null, "user": null, "password": null }, "symlink_before_migrate": { "config/opsworks.php": "opsworks.php" }, "symlinks": { }, "database": { }, "memcached": { "host": null, "port": 11211 }, "stack": { "needs_reload": false } } }, } ``` `opsworks` 属性は、前のセクションで説明した例のものとほぼ同等です。以降のセクションでは、デプロイに特に関連する属性を取り上げています。 + `activity` - これらの属性に関連付けられているイベント (この例では Deploy イベント)。 + `applications` - 各アプリケーションの属性 (アプリケーションの名前、スラグ名、タイプ) のリスト。スラグ名はアプリケーションの短縮名で、 OpsWorks スタックはアプリケーション名から生成します。SimplePHP のスラグ名は simplephp です。 + `deployment` - デプロイを一意に識別するデプロイ ID。 `deploy` 属性には、デプロイされるアプリケーションに関する情報が含まれています。例えば、組み込み Deploy レシピによって、`deploy` 属性のデータが使用されて、適切なディレクトリ内のファイルがインストールされ、データベース接続ファイルが作成されます。`deploy` 属性には、デプロイされる各アプリケーションの属性が含まれています。この属性の名前はアプリケーションの短縮名です。各アプリケーション属性には、以下の属性が含まれています。 + `environment_variables` - アプリケーションに対して定義したすべての環境変数が含まれています。詳細については、「[環境可変](workingapps-creating.md#workingapps-creating-environment)」を参照してください。 + `domains` - デフォルトではアプリケーションの短縮名 (この例では simplephpapp)。カスタムドメインを割り当てている場合は、同様にそれらがここに表示されます。詳細については、「[カスタムドメインの使用](workingapps-domains.md)」を参照してください。 + `application` - アプリケーションの短縮名。 + `scm` - この要素には、リポジトリ (この例では Git リポジトリ) からアプリケーションのファイルをダウンロードするために必要な情報が含まれています。 + `database` - スタックにデータベースレイヤーが含まれている場合は、データベースの情報。 + `document_root` - ドキュメントのルートです。この例では `null` に設定されており、ルートがパブリックであることを示しています。 + `ssl_certificate_ca`、`ssl_support`、`ssl_certificate_key` - アプリケーションが SSL をサポートしているかどうかを示します。サポートしている場合、`ssl_certificate_key` および `ssl_certificate_ca` 属性は対応する証明書に設定されます。 + `deploy_to` - アプリケーションのルートディレクトリ。