

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

# Chef Server から OpsWorks スタックへの移行
<a name="best-practices-server-migrate"></a>

**重要**  
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。

 OpsWorks スタックは Chef に基づいているため、Chef Server から OpsWorks スタックへの移行は比較的簡単です。このトピックでは、 OpsWorks スタックで動作するように Chef Server コードを変更するためのガイドラインを示します。

**注記**  
11.10 より前のバージョンの Chef を使用したスタックの移行はお勧めしません。それらのバージョンは chef-solo に基づいており、Chef 検索やデータバッグがサポートされていないためです。

**Topics**
+ [レイヤーへのロールのマッピング](#best-practices-server-migrate-roles)
+ [データバッグの使用](#best-practices-server-migrate-data-bags)
+ [Chef の検索の使用](#best-practices-server-migrate-search)
+ [クックブックとレシピの管理](#best-practices-server-migrate-cookbooks)
+ [Chef 環境の使用](#best-practices-server-migrate-environments)

## レイヤーへのロールのマッピング
<a name="best-practices-server-migrate-roles"></a>

Chef Server では、ロールを使用して、目的と設定が同じインスタンス (Java アプリケーションサーバーをホストするインスタンスのセットなど) を定義および管理します。[OpsWorks スタックレイヤー](workinglayers.md)は基本的に Chef ロールと同じ目的を果たします。レイヤーは、設定、インストールされるパッケージ、アプリケーションのデプロイ手順などが同じ Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのセットを作成するためのブループリントです。

OpsWorks スタックには、複数のタイプのアプリケーションサーバー、HAProxy ロードバランサー、MySQL データベースマスター、Ganglia モニタリングマスター用の[一連の組み込みレイヤー](workinglayers.md)が含まれています。例えば、組み込み [Java App Server](layers-java.md) (Java アプリケーションサーバー) レイヤーは、Tomcat サーバーをホストするインスタンスを作成するためのブループリントです。

 OpsWorks スタックに移行するには、各ロールを同等の機能を提供するレイヤーに関連付ける必要があります。ロールによっては、いずれかの組み込みレイヤーのみ使用できる場合があります。また、さまざまな程度のカスタマイズが必要になる場合があります。まずは、組み込みレイヤーの機能と各レイヤーに関連付けられているレシピを調べることで、最低限必要なロールの機能が用意されているかどうかを確認します。組み込みレイヤーの詳細については、「[レイヤー](workinglayers.md)」と「[OpsWorks スタックレイヤーリファレンス](layers.md)」を参照してください。組み込みレシピを確認するには、[OpsWorks 「Stacks public GitHub repository](https://github.com/aws/opsworks-cookbooks)」を参照してください。

この後の作業の進め方は、以下のように、レイヤーが各ロールにどの程度一致するかによって異なります。

**組み込みレイヤーがロールのすべての機能をサポートする**  
必要に応じて若干のカスタマイズにより、組み込みレイヤーを直接使用できます。例えば、ロールが Tomcat サーバーをサポートしている場合、Java アプリケーションサーバーレイヤーのレシピはすでに、若干のカスタマイズにより、そのロールのすべてのタスクを処理するようになっていることがあります。たとえば、レイヤーの組み込みレシピで、カスタム Tomcat または Apache 設定が使用されるように、該当する[属性](workingcookbook-attributes.md)または[テンプレート](workingcookbook-template-override.md)を上書きできます。

**組み込みレイヤーがロールの一部の機能のみをサポートする**  
レイヤーの拡張により、[組み込みレイヤー](workingcookbook-extend.md)を使用できる場合があります。この拡張には一般的に、不足している機能をサポートするカスタムレシピの実装と、レイヤーのライフサイクルイベントへのそれらのレシピの割り当てが含まれます。たとえば、Tomcat サーバーをホストする同じインスタンスに Redis サーバーをインストールするロールがあるとします。レイヤーのインスタンスに Redis をインストールするカスタムレシピを実装し、そのレシピをレイヤーの Setup イベントに割り当てることで、ロールの機能と一致するように Java アプリケーションサーバーレイヤーを拡張できます。

**組み込みレイヤーがロールの機能を適切にサポートしない**  
カスタムレイヤーを実装します。たとえば、MongoDB データベースサーバーをサポートするロールがあり、この機能がいずれの組み込みレイヤーでもサポートされていないとします。必要なパッケージのインストールやサーバーの設定などを行うレシピを実装し、そのレシピをカスタムレイヤーのライフサイクルイベントに割り当てることで、レイヤーでこの機能がサポートされるようにできます。一般的に、少なくともロールのレシピのいくつかはこの目的に使用できます。カスタムレイヤーを実装する方法の詳細については、「[カスタム Tomcat サーバーレイヤーの作成](create-custom.md)」を参照してください。

## データバッグの使用
<a name="best-practices-server-migrate-data-bags"></a>

Chef Server では、データバッグを使用してユーザー定義のデータをレシピに渡すことができます。
+ クックブックにデータを保存すると、Chef によってそのデータは各インスタンスにインストールされます。
+ パスワードなどの機密データには、暗号化されたデータバッグを使用できます。

 OpsWorks スタックはデータバッグをサポートします。レシピは Chef Server とまったく同じコードを使用してデータを取得できます。ただし、このサポートには以下の制限と違いがあります。
+ データバッグは Chef 11.10 Linux 以降のスタックでのみサポートされています。

  Chef の以前のバージョンを実行している Windows スタックと Linux スタックでは、データバッグはサポートされていません。
+ データバッグはクックブックのリポジトリに保存しません。

  その代わりに、カスタム JSON を使用してデータバッグのデータを管理します。
+ OpsWorks スタックは、暗号化されたデータバッグをサポートしていません。

  パスワードや証明書などの機密データを暗号化された形式で保存する必要がある場合は、プライベート S3 バケットに保存することをお勧めします。これで、[Amazon SDK for Ruby](https://aws.amazon.com/documentation/sdk-for-ruby/) を使用するカスタムレシピを作成できます。例については、[ SDK for Ruby を使用する](cookbooks-101-opsworks-s3.md)を参照してください。

詳細については、「[データバッグの使用](workingcookbook-chef11-10.md#workingcookbook-chef11-10-databag)」を参照してください。

## Chef の検索の使用
<a name="best-practices-server-migrate-search"></a>

Chef Server では、IP アドレスやロール設定などのスタック設定情報がサーバーに保存されます。レシピは Chef 検索を使用してこのデータを取得します。 OpsWorks スタックは少し異なるアプローチを使用します。たとえば、Chef 11.10 Linux スタックは Chef クライアントのローカルモードに基づいています。このモードは Chef クライアントのオプションの 1 つであり、インスタンスでローカルに Chef Server の軽量バージョン (Chef Zero) が実行されます。Chef Zero では、インスタンスのノードオブジェクトに保存されたデータに対する検索がサポートされています。

 OpsWorks スタックは、リモートサーバーにスタックデータを保存する代わりに、ライフサイクルイベントごとにスタック[設定とデプロイ属性](workingcookbook-json.md)のセットを各インスタンスのノードオブジェクトに追加します。これらの属性は、スタック設定のスナップショットとなります。Chef Server と同じ構文を使用して、サーバーからのレシピの取得に必要なデータの大部分を定義します。

多くの場合、 OpsWorks スタックのレシピの検索依存コードを変更する必要はありません。Chef 検索はスタック設定とデプロイ属性を含むノードオブジェクトで動作するため、 スタックの検索クエリは通常 Chef Server OpsWorks とまったく同じように機能します。

主な例外は、スタック設定属性とデプロイ属性に、インスタンスに属性をインストールするときに OpsWorks スタックが認識するデータのみが含まれていることです。特定のインスタンスで属性をローカルに作成または変更した場合、それらの変更は OpsWorks スタックに伝達されず、他のインスタンスにインストールされているスタック設定およびデプロイ属性に組み込まれません。検索を使用して、そのインスタンス上の属性値のみを取得できます。詳細については、「[Chef の検索の使用](workingcookbook-chef11-10.md#workingcookbook-chef11-10-search)」を参照してください。

Chef Server との互換性のために、 OpsWorks Stacks はノードオブジェクトに一連の`role`属性を追加します。各属性にはスタックのレイヤー属性の 1 つが含まれます。レシピで検索キーとして `roles` を使用している場合、検索コードを変更する必要はありません。クエリによって、対応するレイヤーのデータが自動的に返されます。たとえば、以下の両方のクエリによってレイヤー`php-app`の属性が返されます。

```
phpserver = search(:node, "layers:php-app").first
```

```
phpserver = search(:node, "roles:php-app").first
```

## クックブックとレシピの管理
<a name="best-practices-server-migrate-cookbooks"></a>

OpsWorks スタックと Chef Server では、クックブックとレシピの処理が多少異なります。Chef Server の場合:
+ すべてのクックブックは独自に実装するかコミュニティクックブックを使用することで用意します。
+ クックブックはサーバーに保存します。
+ レシピは手動でまたは定期的なスケジュールで実行します。

 OpsWorks スタックの場合:
+ OpsWorks スタックは、組み込みレイヤーごとに 1 つ以上のクックブックを提供します。これらのクックブックによって、組み込みレイヤーのソフトウェアのインストールと設定、アプリケーションのデプロイなど、標準的なタスクが処理されます。

  組み込みクックブックによって実行されないタスクを処理するには、カスタムクックブックをスタックに追加するか、またはコミュニティクックブックを使用します。
+  OpsWorks スタッククックブックは、S3 バケットや Git リポジトリなどのリモートリポジトリに保存します。

  詳細については、「[クックブックの保存](#best-practices-server-migrate-cookbooks-store)」を参照してください。
+ [レシピは手動で実行](workingcookbook-manual.md)できますが、通常 OpsWorks 、インスタンスの[ライフサイクル中にキーポイントで発生する一連のライフサイクルイベント](workingcookbook-events.md)に応じて、 スタックでレシピを実行します。

  詳細については、「[レシピの実行](#best-practices-server-migrate-cookbooks-execute)」を参照してください。
+ OpsWorks スタックは Chef 11.10 スタックでのみ Berkshelf をサポートします。Berkshelf を使用してクックブックの依存関係を管理する場合、Chef 11.4 以前のバージョンを実行しているスタックを使用することはできません。

  詳細については、「[Berkshelf の使用](workingcookbook-chef11-10.md#workingcookbook-chef11-10-berkshelf)」を参照してください。

**Topics**
+ [クックブックの保存](#best-practices-server-migrate-cookbooks-store)
+ [レシピの実行](#best-practices-server-migrate-cookbooks-execute)

### クックブックの保存
<a name="best-practices-server-migrate-cookbooks-store"></a>

Chef Server では、クックブックをサーバーに保存し、サーバーからインスタンスにデプロイします。 OpsWorks スタックでは、S3 または HTTP アーカイブ、Git または Subversion リポジトリなどのリポジトリにクックブックを保存します。ク[ックブックをインストールする](workingapps-creating.md)ときに OpsWorks 、 スタックがリポジトリからスタックのインスタンスにコードをダウンロードするために必要な情報を指定します。

Chef Server から移行するには、これらのリポジトリのいずれかにクックブックを配置する必要があります。クックブックのリポジトリを構築する方法については、「[クックブックリポジトリ](workingcookbook-installingcustom-repo.md)」を参照してください。

### レシピの実行
<a name="best-practices-server-migrate-cookbooks-execute"></a>

 OpsWorks スタックでは、各レイヤーにセットアップ、設定、デプロイ、デプロイ解除、シャットダウンの一連の[ライフサイクルイベント](workingcookbook-events.md)があり、それぞれがインスタンスのライフサイクル中のキーポイントで発生します。カスタムレシピを実行するには、一般的に、そのレシピを該当するレイヤーのイベントに割り当てます。そのイベントが発生すると、割り当てられたレシピが OpsWorks スタックによって実行されます。たとえば、インスタンスの起動の完了後に Setup イベントが発生するため、一般的にこのイベントに、パッケージのインストールと設定やサービスの開始などのタスクを実行するレシピを割り当てます。

[Execute Recipes スタックコマンド](workingstacks-commands.md)を使用して、レシピを手動で実行できます。このコマンドは開発やテストに便利ですが、このコマンドを使用して、ライフサイクルイベントに割り当てられていないレシピを実行することもできます。また、Execute Recipes コマンドを使用して、Setup および Configure イベントを手動でトリガーすることもできます。

 OpsWorks スタックコンソールに加えて、[AWS CLI ](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)または [SDKs](https://aws.amazon.com/tools/) を使用してレシピを実行できます。これらのツールは、すべての [OpsWorks スタック API アクション](https://docs.aws.amazon.com/opsworks/latest/APIReference/Welcome.html)をサポートしていますが、API よりも簡単に使用できます。[create-deployment](https://docs.aws.amazon.com/cli/latest/reference/opsworks/create-deployment.html) CLI コマンドを使用して、割り当てられたすべてのレシピを実行するライフサイクルイベントをトリガーします。このコマンドを使用して、イベントをトリガーすることなく、1 つ以上のレシピを実行することもできます。同等の SDK コードは、特定の言語に依存しますが、一般的に CLI コマンドに似ています。

以下の例で説明しているのは、`create-deployment` CLI コマンドを使用して、アプリケーションのデプロイを自動化する 2 つの方法です。
+ 1 つのインスタンスが属するカスタムレイヤーをスタックに追加することで、アプリケーションを定期的にデプロイします。

  インスタンスで `cron` ジョブを作成して、指定したスケジュールでそのコマンドを実行する、カスタム Setup レシピをレイヤーに追加します。`cron` ジョブを作成するレシピの使用方法の例については、「[Linux インスタンスでの cron ジョブの実行](workingcookbook-extend-cron.md)」を参照してください。
+ `create-deployment` CLI コマンドを使用してアプリケーションをデプロイするタスクを、継続的統合パイプラインに追加します。

## Chef 環境の使用
<a name="best-practices-server-migrate-environments"></a>

OpsWorks スタックは Chef 環境をサポートしていません。 `node.chef_environment` は常に を返します`_default`。