AWS OpsWorks
ユーザーガイド (API バージョン 2013-02-18)

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

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

注記

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

Layer へのロールのマッピング

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

AWS OpsWorks スタックには、アプリケーションサーバー、HAProxy ロードバランサー、MySQL データベースマスター、Ganglia モニタリングマスターのタイプ別に、組み込みレイヤーのセットが用意されています。たとえば、組み込み Java アプリケーションサーバー Layer は、Tomcat サーバーをホストするインスタンスを作成するための青写真です。

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

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

組み込み Layer がロールのすべての機能をサポートする

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

組み込み Layer がロールの一部の機能のみをサポートする

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

組み込み Layer がロールの機能を適切にサポートしない

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

データバッグの使用

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

  • クックブックにデータを保存すると、Chef によってそのデータは各インスタンスにインストールされます。

  • パスワードなどの機密データには、暗号化されたデータバッグを使用できます。

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

  • データバッグは Chef 11.10 Linux 以降のスタックでのみサポートされています。

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

  • データバッグはクックブックのリポジトリに保存しません。

    その代わりに、カスタム JSON を使用してデータバッグのデータを管理します。

  • AWS OpsWorks スタックでは、暗号化されたデータバッグはサポートされていません。

    パスワードや証明書などの機密データを暗号化された形式で保存する必要がある場合は、プライベート S3 バケットに保存することをお勧めします。これで、Amazon SDK for Ruby を使用するカスタムレシピを作成できます。例については、「Ruby の SDK の使用」を参照してください。

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

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 検索は、スタック設定とデプロイ属性を保存しているノードオブジェクトに対して動作するため、AWS OpsWorks スタックでの検索クエリは通常、Chef Server での動作とまったく同じように動作します。

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

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

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

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

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

  • すべてのクックブックは独自に実装するかコミュニティクックブックを使用することで用意します。

  • クックブックはサーバーに保存します。

  • レシピは手動でまたは定期的なスケジュールで実行します。

AWS OpsWorks スタックで使用する場合。

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

    組み込みクックブックによって実行されないタスクを処理するには、カスタムクックブックをスタックに追加するか、またはコミュニティクックブックを使用します。

  • AWS OpsWorks スタックのクックブックは S3 バケットや Git リポジトリなどリモートリポジトリに保存します。

    詳細については、「クックブックの保存」を参照してください。

  • レシピは手動で実行できますが、一般的には AWS OpsWorks スタックによって、インスタンスのライフサイクル中の重要な時点で発生する一連のライフサイクルイベントに応じて実行されます。

    詳細については、「レシピの実行」を参照してください。

  • AWS OpsWorks スタックでは、Chef 11.10 スタックの Berkshelf のみがサポートされています。Berkshelf を使用してクックブックの依存関係を管理する場合、Chef 11.4 以前のバージョンを実行しているスタックを使用することはできません。

    詳細については、「Berkshelf の使用」を参照してください。

クックブックの保存

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

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

レシピの実行

AWS OpsWorks スタックでは、各 Layer に一連のライフサイクルイベント (Setup、Configure、Deploy、Undeploy、Shutdown) があり、各イベントがインスタンスのライフサイクル中の重要な時点で発生します。カスタムレシピを実行するには、一般的に、そのレシピを該当する Layer のイベントに割り当てます。そのイベントが発生すると、割り当てられたレシピが AWS OpsWorks スタックによって実行されます。たとえば、インスタンスの起動の完了後に Setup イベントが発生するため、一般的にこのイベントに、パッケージのインストールと設定やサービスの開始などのタスクを実行するレシピを割り当てます。

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

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

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

  • 1 つのインスタンスが属するカスタム Layer をスタックに追加することで、アプリケーションを定期的にデプロイします。

    インスタンスで cron ジョブを作成して、指定したスケジュールでそのコマンドを実行する、カスタム Setup レシピを Layer に追加します。cron ジョブを作成するレシピの使用方法の例については、「Linux インスタンスでの cron ジョブの実行」を参照してください。

  • create-deployment CLI コマンドを使用してアプリケーションをデプロイするタスクを、継続的統合パイプラインに追加します。

Chef 環境の使用

AWS OpsWorks スタックでは、Chef 環境はサポートされていません。node.chef_environment によって常に _default が返されます。