新しいスタックを作成する - AWS OpsWorks
作成するスタックのタイプを選択します。基本オプション詳細オプション

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

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

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 には [ID OpsWorks ] というラベルが付いています。

リージョン

(必須) インスタンスが起動される 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 User Guide」(Billing and Cost Management ユーザーガイド) の「Using Cost Allocation Tags」(コスト配分タグの使用)および「Activating User-Defined Cost Allocation Tags」(ユーザー定義のコスト配分タグのアクティブ化)を参照してください。AWS OpsWorks スタックへのタグ付けの詳細については、タグ を参照してください。

詳細オプション

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

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

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

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

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

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

[IAM role] (IAM ロール)

(オプション) スタックの AWS Identity and Access Management (IAM) ロール。AWS OpsWorks スタックはこれを使用して、ユーザーの代わりに AWS を操作します。

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

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

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

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

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

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

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

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

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

  • US West (N. California) リージョン

  • カナダ (中部) リージョン (API のみ) AWS Management Console で作成されたスタックは使用できません

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

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

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

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

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

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

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

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

  • 欧州 (パリ) リージョン

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

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

Hostname theme

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

OpsWorks エージェントバージョン

(オプション) 新しいバージョンが使用可能になったときに、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 の使用」を参照してください。

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

AWS OpsWorks スタックでは、標準的な一連の組み込みセキュリティグループがレイヤーごとに 1 つ提供され、デフォルトでレイヤーに関連付けられています。「 OpsWorksセキュリティグループを使用する」を選択すると、代わりに独自のカスタムセキュリティグループを指定できます。詳細については、「セキュリティグループの使用」を参照してください。

OpsWorks セキュリティグループを使用するには次の設定があります。

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

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

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

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

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

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

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