翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
新しいスタックを作成する
重要
- AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、 にお問い合わせください。 AWS Support でのチーム AWS re:Post
新しいスタックを作成するには、 AWS OpsWorks スタックダッシュボードで、スタックの追加 をクリックします。[Add Stack] ページで、スタックを設定します。完了したら、[Add Stack] をクリックします。
作成するスタックのタイプを選択します。
スタックを作成する前に、作成するスタックのタイプを決定する必要があります。ヘルプについては次の表を参照してください。
作成するもの | 次の場合に作成するスタックのタイプ | 方法については、以下の手順に従います |
---|---|---|
サンプルスタック | Linux ベースの Chef 12 スタックとサンプル Node.js アプリAWS OpsWorks を使用して、 の基本について説明します。 | |
Linux ベースの Chef 12 スタック | がAWS OpsWorks サポートする最新バージョンの Chef を使用する Linux ベースのスタックを作成します。豊富なコミュニティクックブックを活用するか、独自のカスタムクックブックを作成することを希望する高度な Chef ユーザーは、このオプションを選択します。詳細については、「Chef 12 Linux」を参照してください。 | |
Windows ベースの Chef 12.2 スタック | Windows ベースのスタックを作成します。 | |
Linux ベースの Chef 11.10 スタック | 組織で後方互換性のため Chef 11.10 と Linux の使用が必要な場合は、このスタックを作成します。 |
基本オプション
[Add Stack] ページには、以下の基本オプションがあります。
- スタックの名前
-
(必須) 内のスタックを識別するために使用される名前 AWS OpsWorks スタックコンソール。この名前は一意にする必要はありません。 AWS OpsWorks スタックは、スタックを一意に識別GUIDする であるスタック ID も生成します。例えば、update-stack などのAWSCLI
コマンドでは、スタック ID を使用して特定のスタックを識別します。 https://docs.aws.amazon.com/cli/latest/reference/opsworks/update-stack.htmlスタックの作成後、ナビゲーションペインで [Stack] を選択してから、[Stack Settings] を選択することで、その ID を見つけることができます。ID には、OpsWorks ID というラベルが付けられています。 - リージョン
-
(必須) インスタンスを起動するAWSリージョン。
- VPC
-
(オプション) スタックを起動VPCする先の の ID。すべてのインスタンスはこの で起動されVPC、後で ID を変更することはできません。
-
アカウントが EC2 Classic をサポートしている場合は、 を使用しない場合は No VPC (デフォルト値) を指定できますVPC。
EC2 Classic の詳細については、「サポートされているプラットフォーム」を参照してください。
-
アカウントが EC2 Classic をサポートしていない場合は、 を指定する必要がありますVPC。
デフォルト設定はデフォルト です。これは Classic VPCの使いやすさEC2とVPCネットワーク機能の利点を組み合わせたものです。通常の でスタックを実行する場合はVPC、VPCコンソール
、、APIまたは を使用してスタックを作成する必要がありますCLI。の を作成する方法の詳細については、VPC「」を参照してください。 AWS OpsWorks スタックスタックについては、「」を参照してくださいでのスタックの実行 VPC。一般的な情報については、「Amazon Virtual Private Cloud」を参照してください。
-
- Default Availability Zone/Default subnet
-
(オプション) この設定は、 でスタックを作成するかどうかによって異なりますVPC。
-
アカウントが EC2 Classic をサポートしており、 VPCを なし VPCに設定した場合、この設定には、インスタンスを起動するデフォルトのアベイラビリティーゾーンを指定するデフォルトのAWSアベイラビリティーゾーン というラベルが付けられます。
-
アカウントが EC2 Classic をサポートしていない場合、または を指定することを選択した場合VPC、このフィールドにはデフォルトサブネット というラベルが付けられ、インスタンスを起動するデフォルトサブネットを指定します。インスタンスの作成時にこの値を上書きすることによって、他のサブネットのインスタンスを起動できます。各サブネットは 1 つのアベイラビリティーゾーンに関連付けられます。
は、 AWS OpsWorks スタックは、インスタンス の作成時にこの設定を上書きして、別のアベイラビリティーゾーンまたはサブネットでインスタンスを起動します。
でスタックを実行する方法の詳細については、VPC「」を参照してくださいでのスタックの実行 VPC。
-
- Default operating system
-
(オプション) デフォルトで 各インスタンスにインストールされるオペレーティングシステム。次のオプションがあります。
-
組み込みの Linux オペレーティングシステムのいずれか。
-
Microsoft Windows Server 2012 R2.
-
サポートされているオペレーティングシステムの 1 つAMIに基づくカスタム。
カスタム AMIを使用する を選択した場合、オペレーティングシステムはインスタンスの作成時にAMI指定したカスタム によって決まります。詳細については、「カスタム AMI の使用」を参照してください。
使用可能なオペレーティングシステムの詳細については、「AWS OpsWorks スタックオペレーティングシステム」を参照してください。
注記
インスタンスの作成時、デフォルトのオペレーティングシステムを上書きできます。ただし、Linux オペレーティングシステムを上書きして Windows を指定したり、Windows オペレーティングシステムを上書きして Linux を指定したりはできません。
-
- デフォルトSSHキー
-
(オプション) スタックのリージョンからの 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 の場合、デフォルト設定は「いいえ」です。 Yes オプションには、 が提供するいくつかの追加設定が表示されます。 AWS OpsWorks カスタムクックブックをリポジトリ などのスタックのインスタンスにデプロイするために必要な情報を含むスタックURL。詳細は、クックブックに使用しているリポジトリによって異なります。詳細については、「カスタムクックブックのインストール」を参照してください。
- Stack color
-
(オプション) 上のスタックを表すために使用される色相 AWS OpsWorks スタックコンソール。異なるスタックに異なる色を使用することによって、開発、ステージング、本稼動用の各スタックなど、スタックを区別しやすくすることができます。
- スタックタグ
-
スタックおよびレイヤーレベルでタグを適用することができます。タグを作成する場合、タグ付けされた構造内すべてのリソースにタグを適用することになります。例えば、スタックにタグを適用する場合、タグをすべてのレイヤーに適用し、各レイヤー内で、レイヤー内のすべてのインスタンス、Amazon EBSボリューム、または Elastic Load Balancing ロードバランサーに適用します。タグをアクティブ化し、それを使用して のコストを追跡および管理する方法の詳細については、「」を参照してください。 AWS OpsWorks スタックリソースについては、「請求情報とコスト管理ユーザーガイド」の「コスト配分タグの使用」および「ユーザー定義のコスト配分タグの有効化」を参照してください。 https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html でのタグ付けの詳細については、「」を参照してください。 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します。
- デフォルトのIAMインスタンスプロファイル
-
(オプション) スタックの Amazon EC2インスタンスに関連付けるデフォルトのIAMロール。このロールは、スタックのインスタンスで実行されているアプリケーションに、S3 バケットなどのAWSリソースにアクセスするためのアクセス許可を付与します。
-
アプリケーションに特定のアクセス権限を付与するには、該当するポリシーが割り当てられた既存のインスタンスプロファイル (ロール) を選択します。
-
最初は、プロファイルのロールはアクセス許可を付与しませんが、IAMコンソール、、APIまたは を使用して適切なポリシーCLIをアタッチできます。詳細については、「EC2 インスタンスで実行されるアプリケーションのアクセス許可の指定」を参照してください。
-
- API エンドポイントリージョン
-
この設定は、スタックの基本設定で選択されたリージョンの値を使用します。次のリージョンのエンドポイントから選択できます。
-
米国東部 (バージニア北部) リージョン
-
米国東部 (オハイオ) リージョン
-
米国西部 (オレゴン) リージョン
-
US West (N. California) リージョン
カナダ (中部) リージョン (API のみ。 で作成されたスタックでは使用できません AWS Management Console
-
アジアパシフィック (ムンバイ) リージョン
-
アジアパシフィック (シンガポール) リージョン
-
アジアパシフィック (シドニー) リージョン
-
アジアパシフィック (東京) リージョン
-
アジアパシフィック (ソウル) リージョン
-
欧州 (フランクフルト) リージョン
-
欧州 (アイルランド) リージョン
-
欧州 (ロンドン) リージョン
-
欧州 (パリ) リージョン
-
南米 (サンパウロ) リージョン
あるAPIエンドポイントで作成されたスタックは、別のAPIエンドポイントでは使用できません。なぜなら、 AWS OpsWorks 必要に応じて、スタックユーザーもリージョン固有です。 AWS OpsWorks これらのエンドポイントリージョンの 1 つにユーザーをスタックして、別のエンドポイントリージョンのスタックを管理するには、スタックが関連付けられているエンドポイントにユーザーをインポートする必要があります。ユーザーのインポートの詳細については、「 へのユーザーのインポート」を参照してください。 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 つのオプションがあります。
-
自動更新 – AWS OpsWorks スタックは、更新が利用可能になるとすぐに、新しい各エージェントバージョンをスタックのインスタンスに自動的にインストールします。
-
手動更新 – AWS OpsWorks スタックは、指定されたエージェントバージョンをスタックのインスタンスにインストールします。
AWS OpsWorks スタックは、新しいエージェントバージョンが利用可能になるとスタックページにメッセージを投稿しますが、スタックのインスタンスは更新しません。エージェントを更新するには、スタック設定を手動で更新して、新しいエージェントバージョンと AWS OpsWorks その後、スタックはスタックのインスタンスを更新します。
設定 を更新することで、特定のインスタンスのデフォルトのOpsWorks エージェントバージョン設定を上書きできます。 インスタンス設定の編集この場合、そのインスタンスの設定が優先されます。たとえば、デフォルト設定は [Auto-update] ですが、特定のインスタンスに対して [Manual update] を指定しているとします。メトリック AWS OpsWorks スタックは新しいエージェントバージョンをリリースし、手動更新 に設定されているものを除くスタックのすべてのインスタンスを自動的に更新します。特定のインスタンスに新しいエージェントバージョンをインストールするには、手動でそのインスタンスの設定を更新し、新しいバージョンを指定する必要があります。
注記
コンソールに、短縮されたエージェントバージョン番号が表示されます。完全なバージョン番号を確認するには、 AWS CLI describe-agent-versions コマンド、または同等の API または SDKメソッドを呼び出します。それにより、使用可能なエージェントバージョンの完全なバージョン番号が返されます。
-
- カスタム JSON
-
(オプション) JSON構造としてフォーマットされた 1 つ以上のカスタム属性。これらの属性は、すべてのインスタンスにインストールされるスタック設定とデプロイ属性にマージされ、レシピで使用できます。例えばJSON、カスタム を使用して、デフォルト設定を指定する組み込み属性を上書きすることで、設定をカスタマイズできます。詳細については、「カスタム の使用 JSON」を参照してください。
セキュリティには、 OpsWorks セキュリティグループ を使用するという 1 つのオプションがあります。これにより、 を関連付けるかどうかを指定できます。 AWS OpsWorks スタックのレイヤーを持つ組み込みセキュリティグループをスタックします。
AWS OpsWorks スタックは、デフォルトでレイヤーに関連付けられている、レイヤーごとに 1 つずつ、組み込みのセキュリティグループの標準セットを提供します。セキュリティ OpsWorksグループを使用すると、代わりに独自のカスタムセキュリティグループを提供できます。詳細については、「セキュリティグループの使用」を参照してください。
セキュリティ OpsWorks グループの使用には、次の設定があります。
-
はい - AWS OpsWorks スタックは、適切な組み込みセキュリティグループを各レイヤーに自動的に関連付けます (デフォルト設定)。
追加のセキュリティグループを作成した後、レイヤーに関連付けることができますが、組み込みセキュリティグループを削除することはできません。
-
いいえ - AWS OpsWorks スタックは、組み込みのセキュリティグループをレイヤーに関連付けません。
適切なEC2セキュリティグループを作成し、作成する各レイヤーにセキュリティグループを関連付ける必要があります。ただし、作成時に組み込みセキュリティグループと層を手動で関連付けることもできます。カスタムセキュリティグループは、カスタム設定を必要とする層にのみ必要です。
次の点に注意してください。
-
OpsWorks セキュリティグループの使用が はい に設定されている場合、より制限の厳しいセキュリティグループをレイヤーに追加して、デフォルトのセキュリティグループのポートアクセス設定を制限することはできません。複数のセキュリティグループでは、Amazon は最も許容度の高い設定EC2を使用します。さらに、組み込みのセキュリティグループの設定を変更して、より制限の厳しい設定を作成することはできません。スタックを作成すると、 AWS OpsWorks スタックは、組み込みのセキュリティグループの設定を標準設定で上書きするため、次回スタックを作成するときに行った変更は失われます。レイヤーで組み込みのセキュリティグループよりも制限の厳しいセキュリティグループ設定が必要な場合は、 OpsWorks セキュリティグループを使用 を なし に設定し、任意の設定でカスタムセキュリティグループを作成し、作成時にレイヤーに割り当てます。
-
を誤って削除した場合 AWS OpsWorks セキュリティグループをスタックし、再作成する場合は、グループ名の大文字と小文字を含め、元のセキュリティグループと完全に重複している必要があります。グループを手動で再作成する代わりに、 AWS OpsWorks スタックがタスクを実行します。同じAWSリージョン、存在する場合は VPC、および に新しいスタックを作成するだけです。 AWS OpsWorks スタックは、削除したセキュリティグループを含め、すべての組み込みセキュリティグループを自動的に再作成します。その後、今後使用しないスタックを削除します。セキュリティグループは残ります。