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

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

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

重要

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

新しいスタックを作成するには、 AWS OpsWorks Stacks ダッシュボードで 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] ページには、以下の基本オプションがあります。

スタックの名前

(必須) Stacks コンソールでスタックを識別するために使用する名前。 AWS OpsWorks 名前は一意である必要はありません。 AWS OpsWorks Stacks はスタック ID も生成します。スタック 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 Stacks が別のアベイラビリティーゾーンまたはサブネットでインスタンスを起動するようにできます。

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

Default operating system

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

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

  • Microsoft Windows Server 2012 R2.

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

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

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

注記

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

Default SSH key

(オプション) スタックのリージョンの Amazon EC2 キーペア。デフォルト値は none です。key pair を指定すると、 AWS OpsWorks Stacks はパブリックキーをインスタンスにインストールします。

  • 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 オプションでは、 AWS OpsWorks リポジトリからスタックのインスタンスにカスタムクックブックをデプロイするために必要な情報 (リポジトリ URL など) を Stacks に提供するいくつかの追加設定が表示されます。詳細は、クックブックに使用しているリポジトリによって異なります。詳細については、「カスタムクックブックのインストール」を参照してください。

Stack color

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

スタックタグ

スタックおよびレイヤーレベルでタグを適用することができます。タグを作成する場合、タグ付けされた構造内すべてのリソースにタグを適用することになります。例えば、1 つのスタックに 1 つのタグを適用すると、すべてのレイヤーおよび各レイヤー内、またそのレイヤーのすべてのインスタンス、Amazon EBS ボリューム、または Elastic Load Balancing ロードバランサーにそのタグを適用することになります。タグを有効にして AWS OpsWorks Stacks リソースのコストを追跡および管理する方法の詳細については、『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 Stacks はユーザーに代わって 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 Stacks ユーザーもリージョンによって異なるため、これらのエンドポイントリージョンのいずれかの AWS OpsWorks Stacks ユーザーに別のエンドポイントリージョンのスタックを管理させたい場合は、スタックが関連付けられているエンドポイントにユーザーをインポートする必要があります。ユーザーのインポートについて詳しくは、「スタックへのユーザーのインポート」を参照してください。 AWS OpsWorks

Hostname theme

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

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

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

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

  • 自動更新 — AWS OpsWorks Stacks は、更新が可能になるとすぐに、新しいエージェントバージョンをそれぞれスタックのインスタンスに自動的にインストールします。

  • 手動更新 — AWS OpsWorks Stacks は、指定されたエージェントバージョンをスタックのインスタンスにインストールします。

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

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

注記

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

Custom JSON

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

セキュリティには [ OpsWorks セキュリティグループを使用する] という 1 つのオプションがあり、 AWS OpsWorks スタックの組み込みセキュリティグループをスタックのレイヤーに関連付けるかどうかを指定できます。

AWS OpsWorks Stacks には、レイヤーごとに 1 つずつ、ビルトインセキュリティグループの標準セットが用意されており、デフォルトではレイヤーに関連付けられています。「 OpsWorksセキュリティグループを使用する」では、代わりに独自のカスタムセキュリティグループを設定できます。詳細については、「セキュリティグループの使用」を参照してください。

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

  • はい- AWS OpsWorks Stacks は適切な組み込みセキュリティグループを各 Layer に自動的に関連付けます (デフォルト設定)。

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

  • いいえ- AWS OpsWorks Stacks は組み込みセキュリティグループをレイヤーに関連付けません。

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

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

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

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