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

新しいスタックを作成する

AWS OpsWorks スタックダッシュボードで新しいスタックを作成するには、[Add stack] をクリックします。[Add Stack] ページで、スタックを設定します。完了したら、[Add Stack] をクリックします。

作成するスタックのタイプを選択します。

スタックを作成する前に、作成するスタックのタイプを決定する必要があります。ヘルプについては次の表を参照してください。

作成するもの 次の場合に作成するスタックのタイプ 方法については、以下の手順に従います
サンプルスタック Linux ベースの Chef 12 スタックおよび Node.js サンプルアプリケーションで AWS OpsWorks の基本について学習します。

使用開始: サンプル

Linux ベースの Chef 12 スタック AWS OpsWorks がサポートする最新バージョンの Chef を使用して、Linuxベースのスタックを作成します。豊富なコミュニティクックブックを活用するか、独自のカスタムクックブックを作成することを希望する高度な Chef ユーザーは、このオプションを選択します。詳細については、「Chef 12 Linux」を参照してください。

入門ガイド: Linux

Windows ベースの Chef 12.2 スタック Windows ベースのスタックを作成します。

入門ガイド: Windows

Linux ベースの Chef 11.10 スタック 組織で後方互換性のため Chef 11.10 と Linux の使用が必要な場合は、このスタックを作成します。

Chef 11 Linux スタックの使用開始

基本オプション

[Add Stack] ページには、以下の基本オプションがあります。

スタックの名前

(必須) AWS OpsWorks スタックコンソールでスタックを識別するために使用する名前。この名前は一意にする必要はありません。AWS OpsWorks スタックによってスタック ID も生成されます。これはスタックを一意に識別する GUID になります。たとえば、AWS CLI コマンド (update-stack など) でスタック ID を使用して、特定のスタックを識別します。スタックの作成後、ナビゲーションペインで [Stack] を選択してから、[Stack Settings] を選択することで、その ID を見つけることができます。この ID には [OpsWorks ID] というラベルが付いています。

リージョン

(必須) インスタンスが起動される AWS のリージョン。

VPC

(オプション) スタックが起動される VPC の ID。すべてのインスタンスはこの VPC 内で起動され、後でこの ID を変更することはできません。

  • アカウントが EC2 Classic をサポートしている場合、VPC を使用しないときには [No VPC] (デフォルト値) を指定できます。

    EC2 Classic の詳細については、「サポートされているプラットフォーム」を参照してください。

  • アカウントで EC2 Classic がサポートされていない場合は、VPC を指定する必要があります。

    デフォルト設定は、EC2 Classic の使いやすさと VPC のネットワーキング機能のメリットを組み合わせた、[Default VPC] です。通常の VPC でスタックを実行する場合は、VPC コンソールAPI、または CLI を使用して、その VPC を作成する必要があります。AWS OpsWorks スタックのスタックに対する VPC を作成する方法の詳細については、「VPC でのスタックの実行」を参照してください。一般的な情報については、「Amazon Virtual Private Cloud」を参照してください。

Default Availability Zone/Default subnet

(オプション) この設定は、スタックを VPC で作成しているかどうかによって異なります。

  • アカウントが EC2 Classic をサポートし、[VPC] を [No VPC] に設定している場合、この設定のラベルは [Default Availability Zone] になり、インスタンスが起動されるデフォルトの AWS アベイラビリティーゾーンを指定します。

  • アカウントが EC2 Classic をサポートしていない場合や、VPC を指定することを選択した場合、このフィールドのラベルは [Default subnet] になり、インスタンスが起動されるデフォルトのサブネットを指定します。インスタンスの作成時にこの値を上書きすることによって、他のサブネットのインスタンスを起動できます。各サブネットは 1 つのアベイラビリティーゾーンに関連付けられます。

AWS OpsWorks スタックでは、インスタンスを作成するときにこの設定を上書きすることで、別のアベイラビリティーゾーンまたはサブネットでインスタンスを起動できます。

VPC でスタックを実行する方法の詳細については、「VPC でのスタックの実行」を参照してください。

Default operating system

(オプション) デフォルトで 各インスタンスにインストールされるオペレーティングシステム。次のオプションがあります。

  • 組み込みの Linux オペレーティングシステムのいずれか。

  • Microsoft Windows Server 2012 R2.

  • サポートされているいずれかのオペレーティングシステムに基づくカスタム AMI。

    [Use Custom AMI] を選択した場合、オペレーティングシステムは、インスタンスの作成時に指定したカスタム AMI によって決まります。詳細については、「カスタム AMI の使用」を参照してください。

使用可能なオペレーティングシステムの詳細については、「AWS OpsWorks Stacks のオペレーティングシステム」を参照してください。

注記

インスタンスの作成時、デフォルトのオペレーティングシステムを上書きできます。ただし、Linux オペレーティングシステムを上書きして Windows を指定したり、Windows オペレーティングシステムを上書きして Linux を指定したりはできません。

Default SSH key

(オプション) スタックのリージョンの Amazon EC2 キーペア。デフォルト値は none です。キーペアを指定した場合、AWS OpsWorks スタックによってインスタンスにパブリックキーがインストールされます。

  • Linux インスタンスでは、SSH クライアントとプライベートキーを使用して、スタックのインスタンスにログインできます。

    詳細については、「SSH でのログイン」を参照してください。

  • Windows インスタンスでは、Amazon EC2 コンソールまたは CLI でプライベートキーを使用して、インスタンスの管理者パスワードを取得できます。

    その後、RDP クライアントでそのパスワードを使用して、管理者としてインスタンスにログインできます。詳細については、「RDP でのログイン」を参照してください。

SSH キーを管理する方法の詳細については、「SSH アクセスの管理」を参照してください。

注記

この設定を上書きするには、インスタンスの作成するときに別のキーペアを指定するか、キーペアを指定しません。

Chef version

これは、選択した Chef バージョンを示します。

Chef のバージョンの詳細については、「Chef のバージョン」を参照してください。

Use custom Chef cookbooks

スタックのインスタンスにカスタム Chef クックブックをインストールするかどうか。

Chef 12 の場合、デフォルト設定は [Yes] です。Chef 11 の場合、デフォルト設定は [No] です。[Yes] オプションでは、カスタムクックブックをそのリポジトリからスタックのインスタンスにデプロイするために必要な情報 (リポジトリ URL など) を AWS OpsWorks スタックに提供する追加の設定がいくつか表示されます。詳細は、クックブックに使用しているリポジトリによって異なります。詳細については、「カスタムクックブックのインストール」を参照してください。

Stack color

(オプション) AWS OpsWorks スタックコンソールでスタックを表すために使用される色相。異なるスタックに異なる色を使用することによって、開発、ステージング、本稼動用の各スタックなど、スタックを区別しやすくすることができます。

スタックタグ

スタックおよびレイヤーレベルでタグを適用することができます。タグを作成する場合、タグ付けされた構造内すべてのリソースにタグを適用することになります。たとえば、1 つのスタックに 1 つのタグを適用すると、すべてのレイヤーおよび各レイヤー内、またそのレイヤーのすべてのインスタンス、Amazon EBS ボリューム、または Elastic Load Balancing ロードバランサーにそのタグを適用することになります。タグを有効化して AWS OpsWorks スタックのリソースのコストを追跡および管理する方法の詳細については、Billing and Cost Management ユーザーガイドの「コスト配分タグの使用」と「ユーザー定義のコスト配分タグのアクティブ化」を参照してください。AWS OpsWorks スタックでのタグ付けの詳細については、「タグ」を参照してください。

詳細オプション

詳細設定の場合、[Advanced >>] をクリックして、[Advanced options] および [Security] セクションを表示します。

[Advanced options] セクションには、以下のオプションがあります。

デフォルトのルートデバイスのタイプ。

インスタンスのルートボリュームに使用されるストレージのタイプ。詳細については、「ストレージ」を参照してください。

  • Linux スタックでは、デフォルトで Amazon EBS-Backed ルートボリュームが使用されますが、Instance store-Backed ルートボリュームを指定することもできます。

  • Windows スタックでは、Amazon EBS-Backed ルートボリュームを使用する必要があります。

IAM ロール

(オプション) スタックの AWS Identity and Access Management (IAM) ロール。AWS OpsWorks スタックはこれを使用して、ユーザーの代わりに AWS を操作します。必要なすべてのアクセス許可を持つことを保証するには、AWS OpsWorks スタックで作成されたロールを使用する必要があります。既存の AWS OpsWorks スタックロールがない場合は、[New IAM Role] を選択して、AWS OpsWorks スタックで新しい IAM ロールを作成します。詳細については、「ユーザーに代わって AWS OpsWorks スタックがタスクを実行できるようにする」を参照してください。

デフォルトの IAM インスタンスプロフィール

(オプション) スタックの Amazon EC2 インスタンスに関連付けられるデフォルトの IAM ロール。このロールは、スタックのインスタンスで実行中のアプリケーションに、S3 バケットなどの AWS リソースにアクセスする権限を付与します。

  • アプリケーションに特定のアクセス権限を付与するには、該当するポリシーが割り当てられた既存のインスタンスプロファイル (ロール) を選択します。

  • または、[New IAM Instance Profile] を選択して、AWS OpsWorks スタックで新しいインスタンスプロファイルを作成します。

  • 初期状態では、プロファイルのロールはいずれの権限も付与しませんが、IAM コンソール、API、または CLI を使用して、該当するポリシーをロールにアタッチできます。詳細については、「EC2 インスタンスで実行するアプリケーションに対するアクセス許可の指定」を参照してください。

API エンドポイントリージョン

この設定は、スタックの基本設定で選択されたリージョンの値を使用します。次のリージョンのエンドポイントから選択できます。

  • 米国東部 (バージニア北部) リージョン

  • 米国東部 (オハイオ) リージョン

  • 米国西部 (オレゴン) リージョン

  • 米国西部 (北カリフォルニア) リージョン

  • カナダ (中部) リージョン (API のみ。AWS マネジメントコンソール で作成されたスタックは使用できません。)

  • アジアパシフィック (ムンバイ) リージョン

  • アジアパシフィック (シンガポール) リージョン

  • アジアパシフィック (シドニー) リージョン

  • アジアパシフィック (東京) リージョン

  • アジアパシフィック (ソウル) リージョン

  • 欧州 (フランクフルト) リージョン

  • 欧州 (アイルランド) リージョン

  • 欧州 (ロンドン) リージョン

  • EU (パリ) リージョン

  • 南米 (サンパウロ) リージョン

1 つの API エンドポイントで作成したスタックを他の API エンドポイントで使用することはできません。AWS OpsWorks スタックユーザーはリージョンに固有のものでもあるため、これらのエンドポイントリージョンのいずれかの AWS OpsWorks スタックユーザーに別のエンドポイントリージョンのスタックを管理させるには、スタックが関連付けられているエンドポイントにユーザーをインポートする必要があります。ユーザーをインポートする方法の詳細については、「AWS OpsWorks スタックへのユーザーのインポート」を参照してください。

Hostname theme

(オプション) 各インスタンスのデフォルトのホスト名を生成するために使用される文字列。デフォルト値は [Layer Dependent] で、インスタンスの Layer の短い名前を使用し、各インスタンスに一意の数値を追加します。たとえば、ロールに依存する Load Balancer のテーマのルートが「lb」であるとします。Layer に追加する最初のインスタンスには「lb1」、2 番目のインスタンスには「lb2」のように名前が付けられます。

OpsWorks Agent version

(オプション) 新しいバージョンが使用可能になったときに、AWS OpsWorks スタックエージェントを自動的に更新するか、指定したエージェントバージョンを使用して手動で更新するか。この機能は Chef 11.10 スタックおよび Chef 12 スタックでのみ使用できます。デフォルト設定は [Manual update] であり、最新のエージェントバージョンに設定されます。

AWS OpsWorks スタックは、各インスタンスにエージェントをインストールします。エージェントは、そのサービスとのやり取りを行うほか、ライフサイクルイベントに応じた Chef 実行の開始などのタスクを処理します。このエージェントは定期的に更新されます。スタックのエージェントバージョンを指定するときは、次の 2 つのオプションがあります。

  • Auto-update – AWS OpsWorks スタックは、更新が使用可能になるとすぐに、新しいエージェントバージョンをスタックの各インスタンスに自動的にインストールします。

  • Manual update – AWS OpsWorks スタックは、指定されたエージェントバージョンをスタックの各インスタンスにインストールします。

    AWS OpsWorks スタックは、新しいエージェントバージョンが使用可能になると、スタックページにメッセージをポストしますが、スタックのインスタンスを更新しません。エージェントを更新するには、手動でスタックの設定を更新し、新しいエージェントバージョンを指定する必要があります。これで、AWS OpsWorks スタックがスタックのインスタンスを更新するようになります。

特定のインスタンスの [OpsWorks Agent Version] のデフォルト設定を上書きすることができます。そのためには、そのインスタンスの設定を更新します。この場合、そのインスタンスの設定が優先されます。たとえば、デフォルト設定は [Auto-update] ですが、特定のインスタンスに対して [Manual update] を指定しているとします。AWS OpsWorks スタックが新しいエージェントバージョンをリリースすると、[Manual update] に設定されているインスタンスを除いて、スタックのすべてのインスタンスが自動的に更新されます。特定のインスタンスに新しいエージェントバージョンをインストールするには、手動でそのインスタンスの設定を更新し、新しいバージョンを指定する必要があります。

注記

コンソールに、短縮されたエージェントバージョン番号が表示されます。完全なバージョン番号を確認するには、AWS CLI の describe-agent-versions コマンドを呼び出すか、API または SDK の同等のメソッドを呼び出します。それにより、使用可能なエージェントバージョンの完全なバージョン番号が返されます。

Custom JSON

(オプション) JSON 構造として書式設定された 1 つ以上のカスタム属性。これらの属性は、すべてのインスタンスにインストールされるスタック設定とデプロイ属性にマージされ、レシピで使用できます。カスタム JSON を使用すると、たとえば、デフォルト設定を指定する組み込み属性を上書きして、設定をカスタマイズできます。詳細については、「カスタム JSON の使用」を参照してください。

[Security] のオプションは [Use OpsWorks security groups] の 1 つだけで、AWS OpsWorks スタックの組み込みのセキュリティグループをスタックの Layer に関連付けるかどうかを指定できます。

AWS OpsWorks スタックは組み込みセキュリティグループの標準セットを提供します。各 Layer に 1 つ提供され、デフォルトで Layer に関連付けられています。[Use OpsWorks security groups] では、代わりに独自のカスタムセキュリティグループを提供できます。詳細については、「セキュリティグループの使用」を参照してください。

[Use OpsWorks security groups] には、次の設定が含まれます。

  • [Yes] - AWS OpsWorks スタックは、自動的に各 Layer に適切な組み込みのセキュリティグループを関連付けます (デフォルトの設定)。

    追加のセキュリティグループを作成した後、Layer に関連付けることができますが、組み込みセキュリティグループを削除することはできません。

  • [No] - AWS OpsWorks スタックは、Layer に組み込みのセキュリティグループを関連付けません。

    適切な EC2 セキュリティグループを作成し、作成した各 Layer とセキュリティグループを関連付ける必要があります。ただし、作成時に組み込みセキュリティグループと層を手動で関連付けることもできます。カスタムセキュリティグループは、カスタム設定を必要とする層にのみ必要です。

次の点に注意してください。

  • [Use OpsWorks security groups] を [Yes] に設定した場合、より制限の厳しいセキュリティグループを Layer に追加することによって、デフォルトのセキュリティグループのポートアクセスの設定を制限することはできません。複数のセキュリティグループがある場合、Amazon EC2 ではより制限の緩い設定が使用されます。さらに、組み込みのセキュリティグループの設定を変更して、より制限の厳しい設定を作成することはできません。AWS OpsWorks スタックでは、スタックを作成するときに組み込みセキュリティグループの設定が標準の設定で上書きされるため、設定に変更を加えても、次回スタックを作成するときには変更内容は失われます。Layer で組み込みのセキュリティグループよりも制限の厳しいセキュリティグループの設定が必要な場合は、[Use OpsWorks security groups] を [No] に設定して、目的の設定でカスタムセキュリティグループを作成し、作成時に Layer に割り当てます。

  • 誤って削除した AWS OpsWorks スタックのセキュリティグループを再作成するには、そのセキュリティグループは、グループ名の大文字/小文字の設定を含め、元のセキュリティグループとまったく同じである必要があります。グループを手動で再作成する代わりに、AWS OpsWorks スタックによってこのタスクが実行されるようにすることをお勧めします。同じ AWS リージョン (および VPC が存在する場合は同じ VPC) に新しいスタックを作成するだけです。AWS OpsWorks スタックは削除したものも含め、すべての組み込みセキュリティグループを自動的に再作成します。その後、今後使用しないスタックを削除します。セキュリティグループは残ります。