翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# レイヤーの拡張
<a name="workingcookbook-extend"></a>

**重要**  
この 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)

# レシピを使用したスクリプトの実行
<a name="workingcookbook-extend-scripts"></a>

**重要**  
この 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 デプロイフックの使用
<a name="workingcookbook-extend-hooks"></a>

**重要**  
この 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 ジョブの実行
<a name="workingcookbook-extend-cron"></a>

**重要**  
この 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 インスタンスでパッケージをインストールおよび設定
<a name="workingcookbook-extend-package"></a>

**重要**  
この 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) にある組み込みクックブックを参照してください。