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

Chef Server から AWS OpsWorks スタックへの移行

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

レイヤーへのロールのマッピング

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

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

AWS OpsWorks スタックに移行するには、各ロールを同等の機能を提供するレイヤーに関連付ける必要があります。ロールによっては、いずれかの組み込みレイヤーのみ使用できる場合があります。また、さまざまな程度のカスタマイズが必要になる場合があります。まずは、組み込みレイヤーの機能と各レイヤーに関連付けられているレシピを調べることで、最低限必要なロールの機能が用意されているかどうかを確認します。組み込みレイヤーの詳細については、「レイヤー」と「AWS OpsWorks スタックレイヤーリファレンス」を参照してください。組み込みレシピを確認するには、 AWS OpsWorks スタックパブリック GitHubリポジトリを参照してください。

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

データバッグの使用

Chef Server では、データバッグを使用してユーザー定義のデータをレシピに渡すことができます。

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

詳細については、「データバッグの使用」を参照してください。

Chef の検索の使用

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

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

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

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

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

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

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

クックブックとレシピの管理

AWS OpsWorks スタックと Chef Server では、クックブックとレシピの処理が多少異なります。Chef Server の場合:

AWS OpsWorks スタックの場合：

クックブックの保存

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

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

レシピの実行

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

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

AWS OpsWorks スタックコンソールに加えて、 AWSCLIまたは SDKs を使用してレシピを実行できます。これらのツールはすべての AWS OpsWorks スタックAPIアクションをサポートしますが、 よりも簡単に使用できますAPI。create-deployment CLI コマンドを使用して、関連するすべてのレシピを実行するライフサイクルイベントをトリガーします。このコマンドを使用して、イベントをトリガーすることなく、1 つ以上のレシピを実行することもできます。同等のSDKコードは特定の言語によって異なりますが、一般的に CLI コマンドに似ています。

次の例では、 create-deployment CLI コマンドを使用してアプリケーションのデプロイを自動化する 2 つの方法について説明します。

Chef 環境の使用

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