Chef Server から AWS OpsWorks スタックへの移行 - AWS OpsWorks
レイヤーへのロールのマッピングデータバッグの使用Chef の検索の使用クックブックとレシピの管理Chef 環境の使用

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

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

重要

AWS OpsWorks Stacks は新規顧客を受け付けなくなりました。既存のお客様は、2024 年 5 月 26 日までは、通常どおり OpsWorks コンソール、API、CLI、および CloudFormation リソースを使用できます。その時点で廃止されます。この移行に備えて、できるだけ早くスタックを AWS Systems Manager に移行することをおすすめします。詳細については、「AWS OpsWorks Stacks サポート終了に関する FAQ」および「AWS Systems Manager アプリケーションマネージャへの AWS OpsWorks Stacks アプリケーションの移行」を参照してください。

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

注記

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

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

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リポジトリ」を参照してください。

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

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

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

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

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

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

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

データバッグの使用

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

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

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

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

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

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

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

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

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

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

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

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 を使用している場合、検索コードを変更する必要はありません。クエリによって、対応するレイヤーのデータが自動的に返されます。たとえば、以下の両方のクエリによってレイヤーphp-appの属性が返されます。


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 つ以上のクックブックが用意されています。これらのクックブックによって、組み込みレイヤーのソフトウェアのインストールと設定、アプリケーションのデプロイなど、標準的なタスクが処理されます。

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

  • 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 Stacksがリポジトリからスタックのインスタンスにコードをダウンロードするために必要な情報を指定します。

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

レシピの実行

AWS OpsWorks スタックでは、各レイヤーに lifecycle events (ライフサイクルイベント) (セットアップ、設定、デプロイ、アンデプロイおよびシャットダウン) が用意されており、それぞれがインスタンスのライフサイクルの重要なポイントで発生します。カスタムレシピを実行するには、一般的に、そのレシピを該当するレイヤーのイベントに割り当てます。そのイベントが発生すると、割り当てられたレシピが 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 つのインスタンスが属するカスタムレイヤーをスタックに追加することで、アプリケーションを定期的にデプロイします。

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

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

Chef 環境の使用

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