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

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

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

重要

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

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

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

レシピの実行

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

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

AWS OpsWorks スタックコンソールに加えて、AWS CLI または SDKs を使用してレシピを実行できます。これらのツールは、すべての 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。