全般設定 recipe ネットワーク EBS ボリュームセキュリティ CloudWatch ログタグ

OpsWorks レイヤーの設定の編集

重要

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

レイヤーを作成すると、一部のプロパティ (AWSリージョンなど) はイミュータブルですが、ほとんどのレイヤー設定はいつでも変更できます。レイヤーを編集すると、[Add Layer] (レイヤーの追加) ページにない設定にもアクセスできます。この設定は、新しい設定を保存するとすぐに有効になります。

OpsWorks レイヤーを編集するには

ナビゲーションペインで、[Layers] (レイヤー) をクリックします。
[Layers] (レイヤー) ページで、レイヤー名を選択して詳細ページを開きます。詳細ページには現在の設定が表示されます。

注記
レイヤーの名前の下にあるいずれかの名前を選択すると、詳細ページの関連タブに直接移動します。
編集をクリックして、一般設定 、レシピ、ネットワーク 、ボリューム 、セキュリティ のタブを選択します。 EBS

次のセクションでは、すべてのレイヤーで使用できるさまざまなタブの設定について説明します。一部のレイヤーには、レイヤー固有の追加設定があり、ページの上部に表示されます。さらに、注記のとおり、一部の設定は Linux ベースのスタックでのみ使用できます。

全般設定

すべてのレイヤーは次のように設定されます。

Auto healing enabled: レイヤーのインスタンスに対して自動ヒールが有効かどうかを示します。デフォルトの設定は、[Yes] です。
カスタム JSON: このレイヤー内のすべてのインスタンスの Chef レシピに渡されるJSON形式のデータ。たとえば、これを使用してデータを独自のレシピに渡すことができます。詳細については、「カスタムの使用 JSON」を参照してください。

注記
デプロイ、レイヤー、スタックJSONレベルでカスタムを宣言できます。これは、スタック全体または個々のデプロイにのみカスタムJSONを表示する場合に実行できます。または、例えば、レイヤーレベルでJSON宣言されたカスタムを、デプロイレベルでJSON宣言されたカスタムで一時的に上書きできます。複数のレベルでカスタムJSONを宣言する場合、デプロイレベルでJSON宣言されたカスタムは、レイヤーレベルとスタックレベルの両方でJSON宣言されたカスタムよりも優先されます。レイヤーレベルでJSON宣言されたカスタムは、スタックレベルでのみJSON宣言されたカスタムよりも優先されます。
を使用するには AWS OpsWorks スタックコンソールでデプロイJSONのカスタムを指定するには、アプリケーションのデプロイページでアドバンスト を選択します。カスタムをカスタム Chef JSON JSON ボックスに入力し、保存を選択します。
を使用するには AWS OpsWorks スタックコンソールでスタックJSONのカスタムを指定し、スタック設定ページでカスタムをJSONカスタムJSONボックスに入力し、保存を選択します。
詳細については、「カスタムの使用 JSON」および「アプリケーションのデプロイ」を参照してください。
Instance shutdown timeout: 期間 (秒単位) を指定します。 AWS OpsWorks スタックは、Amazon EC2インスタンスを停止または終了する前に、Shutdown ライフサイクルイベントをトリガーした後に待機します。デフォルトの設定は 120 秒です。設定の目的は、インスタンスを終了する前に、インスタンスの Shutdown レシピに対して、タスクを完了するための十分な時間を与えることです。カスタム Shutdown レシピでさらに時間が必要な場合は、それに応じて設定を変更します。インスタンスのシャットダウンの詳細については、「インスタンスの停止」を参照してください。

このタブのその他の設定は、レイヤーの種類によって異なり、レイヤーの [Add Layer] (レイヤーの追加) ページの設定と同じです。

recipe

[Recipes] タブには次の設定が含まれます。

[Custom Chef recipes]: レイヤーのライフサイクルイベントにカスタム Chef レシピを割り当てることができます。詳細については、「レシピの実行」を参照してください。

ネットワーク

[Network] タブには次の設定が含まれます。

Elastic Load Balancing

あらゆる Layer に Elastic Load Balancing のロードバランサーをアタッチできます。 AWS OpsWorks スタックによってその後、自動的にレイヤーのオンラインインスタンスがロードバランサーに登録され、インスタンスがオフラインになった場合は登録が解除されます。ロードバランサーの Connection Draining 機能を有効にしている場合は、 AWS OpsWorks スタックがサポートします。詳細については、「Elastic ロードバランシングレイヤー」を参照してください。

[Automatically Assign IP Addresses]

以下を制御できます。 AWS OpsWorks スタックは、レイヤーのインスタンスにパブリック IP アドレスまたは Elastic IP アドレスを自動的に割り当てます。このオプションを有効にすると、次のようになります。

instance store-backed インスタンスの場合、 AWS OpsWorks スタックは、インスタンスが起動されるたびにアドレスを自動的に割り当てます。
Amazon EBS-backed インスタンスの場合、 AWS OpsWorks スタックは、インスタンスが初めて起動されたときにアドレスを自動的に割り当てます。
インスタンスが複数のレイヤーに属している場合、 AWS OpsWorks スタックは、少なくとも 1 つのレイヤーに対して自動割り当てを有効にしている場合、アドレスを自動的に割り当てます。

注記

パブリック IP アドレスの自動割り当てを有効にすると、自動割り当ては新しいインスタンスにのみ適用されます。 AWS OpsWorks スタックで、既存のインスタンスのパブリック IP アドレスを更新することはできません。

スタックがで実行されている場合VPC、パブリック IP アドレスと Elastic IP アドレスの設定は異なります。次の表はパブリック IP アドレスと Elastic IP アドレスが対話する方法を説明しています。

Table showing interactions between public IP addresses, Elastic IP addresses, and instance network configurations.

注記

インスタンスには、と通信する方法が必要です。 AWS OpsWorks スタックサービス、Linux パッケージリポジトリ、クックブックリポジトリ。パブリック IP アドレスまたは Elastic IP アドレスを指定しない場合、レイヤーのインスタンスが外部サイトと通信NATできるようにするなどのコンポーネントをに含めるVPC必要があります。詳細については、「でのスタックの実行 VPC」を参照してください。

スタックがで実行されていない場合はVPC、Elastic IP アドレスが唯一の設定です。

Yes: インスタンスの初回起動時に、インスタンスに Elastic IP アドレスが割り当てられます。Elastic IP アドレスを割り当てることができない場合は、パブリック IP アドレスが割り当てられます。
No: インスタンスを起動するたびに、パブリック IP アドレスが割り当てられます。

EBS ボリューム

EBS ボリュームタブには、次の設定が含まれます。

EBS 最適化インスタンス

レイヤーのインスタンスを Amazon Elastic Block Store (Amazon EBS) 用に最適化するかどうか。詳細については、「Amazon EBS最適化インスタンス」を参照してください。

追加EBSボリューム

(Linux のみ) レイヤーのインスタンスに Amazon EBSボリュームを追加または削除できます。インスタンスを起動すると、 AWS OpsWorks スタックは自動的にボリュームを作成し、インスタンスにアタッチします。リソースページを使用して、スタックのEBSボリュームを管理できます。詳細については、「リソース管理」を参照してください。

マウントポイント – (必須) EBSボリュームをマウントするマウントポイントまたはディレクトリを指定します。
# ディスク – (オプション) RAID配列を指定した場合、配列内のディスクの数。

各RAIDレベルにはデフォルトのディスク数がありますが、リストからより大きなディスク数を選択できます。

[Size total (GiB)] (合計サイズ (GiB)) - (必須) ボリュームのサイズ (GiB 単位) を指定します。

RAID 配列の場合、この設定は各ディスクのサイズではなく、配列の合計サイズを指定します。

次の表は、各ボリュームタイプで許容される最小および最大ボリュームサイズをまとめたものです。

ボリュームタイプ	最小サイズ (GiB)	最大サイズ (GiB)
マグネティック	1	1024
プロビジョニング済み IOPS (SSD）	4	16384
汎用 (SSD）	1	16384
スループット最適化 (HDD）	500	16384
コールド HDD	500	16384

ボリュームタイプ – (オプション) マグネティック、汎用、スループット最適化 SSD、コールド HDD、HDDまたは PIOPSボリュームを作成するかどうかを指定します。

デフォルト値は Magnetic です。
Encrypted – (オプション) EBSボリュームのコンテンツを暗号化するかどうかを指定します。
IOPS ディスクごと – (プロビジョンドSSDボリュームIOPSSSDと汎用ボリュームに必須) プロビジョンドボリュームIOPSSSDまたは汎用SSDボリュームを指定する場合は、IOPSディスクごとに も指定する必要があります。

プロビジョニングされたIOPSボリュームの場合、ボリュームの作成時にIOPSレートを指定できます。IOPS プロビジョニングされたの比率とリクエストされたボリュームサイズは最大 30 です (つまり、3000 のボリュームは 100 GB 以上IOPSである必要があります）。汎用 (SSD) ボリュームタイプには、ボリュームサイズ x 3 IOPSのベースラインがあり、最大 10000 IOPSで、30 分間最大 3000 IOPSまでバーストできます。

ボリュームをレイヤーに追加するか、レイヤーから削除する場合は、次の点に注意してください。

ボリュームを追加すると、新しいインスタンスごとに新しいボリュームが取得されますが、 AWS OpsWorks スタックは既存のインスタンスを更新しません。
ボリュームを削除する場合、新しいインスタンスにのみ適用されます。既存のインスタンスのボリュームは削除されません。

マウントポイントの指定

任意のマウントポイントを指定することができます。ただし、一部のマウントポイントはでの使用のために予約されていることに注意してください。 AWS OpsWorks スタックまたは Amazon EC2およびは Amazon EBSボリュームに使用しないでください。/home や /etc などの一般的な Linux システムフォルダは使用しないでください。

次のマウントポイントは、が使用するために予約されています。 AWS OpsWorks スタック。

/srv/www
/var/log/apache2 (Ubuntu)
/var/log/httpd (Amazon Linux)
/var/log/mysql
/var/www

autofs (自動マウントデーモン) は、インスタンスの起動または再起動時に /media/ephemeral0 のようなエフェメラルデバイスマウントポイントを使用してマウントをバインドします。このオペレーションは、Amazon EBSボリュームがマウントされる前に実行されます。Amazon EBSボリュームのマウントポイントが autofs と競合しないようにするには、エフェメラルデバイスマウントポイントを指定しないでください。可能なエフェメラルデバイスマウントポイントは、特定のインスタンスタイプ、およびインスタンスストアバックか Amazon EBSバックかによって異なります。autofs との競合を避けるため、次を実行します。

特定のインスタンスタイプのエフェメラルデバイスマウントポイントと、使用するバッキングストアを確認します。
インスタンスストアベースのインスタンスで動作するマウントポイントは、Amazon –backed インスタンスに切り替えると autofs EBSと競合する可能性があり、その逆も同様であることに注意してください。

注記

インスタンスストアのブロックデバイスマッピングを変更する場合は、カスタムを作成できますAMI。詳細については、「Amazon EC2 Instance Store」を参照してください。のカスタムを作成する方法の詳細については、AMI「」を参照してください。 AWS OpsWorks スタックについては、「」を参照してくださいカスタム AMI の使用。

次の例は、ボリュームのマウントポイントが autofs と競合しないよう、どのようにカスタムレシピを使用できるかを示しています。特定のユースケースに応じて適応してください。

マウントポイントの競合を回避するには

Amazon EBSボリュームを目的のレイヤーに割り当てますが、autofs と競合しない /mnt/workspace などのマウントポイントを使用します。

Amazon EBSボリュームにアプリケーションディレクトリを作成し、からリンクする次のカスタム recipe を実装します/srv/www/。カスタムレシピの実装方法の詳細については、「クックブックとレシピ」と「カスタマイズ AWS OpsWorks スタック」を参照してください。



mount_point = node['ebs']['raids']['/dev/md0']['mount_point'] rescue nil

if mount_point
  node[:deploy].each do |application, deploy|
    directory "#{mount_point}/#{application}" do
      owner deploy[:user]
      group deploy[:group]
      mode 0770
      recursive true
    end

    link "/srv/www/#{application}" do
      to "#{mount_point}/#{application}"
    end
  end
end

「depends 'deploy'」行をカスタムクックブックの metadata.rb ファイルに追加します。
このレシピをレイヤーの Setup イベントに割り当てます。

セキュリティ

[Security] タブには次の設定が含まれます。

セキュリティグループ

レイヤーには、セキュリティグループを少なくとも 1 つ関連付ける必要があります。スタックの作成または更新時に、セキュリティグループを関連付ける方法を指定します。 AWS OpsWorks Stacks では、組み込みセキュリティグループの標準セットが用意されています。

デフォルトのオプションはです。 AWS OpsWorks スタックは、適切な組み込みセキュリティグループを各レイヤーに自動的に関連付けます。
組み込みセキュリティグループが自動的に関連付けされないように設定し、レイヤーの作成時にカスタムセキュリティグループを各レイヤーに関連付けることも可能です。

セキュリティグループの詳細については、「セキュリティグループの使用」を参照してください。

レイヤーの作成後、Security Groups を使い、[Custom security groups] リストからセキュリティグループを選択してレイヤーに追加することができます。セキュリティグループをレイヤーに追加すると、 AWS OpsWorks スタックは、すべての新しいインスタンスに追加します。(再開されるインスタンスストアのインスタンスは新しいインスタンスとして起動されるため、新しいセキュリティグループを持ちます)。 AWS OpsWorks スタックでは、オンラインインスタンスへのセキュリティグループの追加は行われません。

次のように、[x] をクリックして既存のセキュリティグループを削除することができます。

をにすることを選択した場合 AWS OpsWorks スタックは自動的に組み込みセキュリティグループを関連付けます。x をクリックして以前に追加したカスタムセキュリティグループを削除できますが、組み込みグループを削除することはできません。
自動的に組み込みセキュリティグループが関連付けられないように設定した場合は、元のセキュリティグループも含め、任意の既存のセキュリティグループを削除することができます。ただし、レイヤーにはセキュリティグループを少なくとも 1 つ関連付けておく必要があります。

レイヤーからセキュリティグループを削除すると、 AWS OpsWorks スタックは、新しいインスタンスや再起動されたインスタンスに追加しません。 AWS OpsWorks スタックは、オンラインインスタンスからセキュリティグループを削除しません。

注記

スタックがで実行されている場合VPC、Amazon EC2コンソール、、APIまたはを使用して、オンラインインスタンスのセキュリティグループを追加または削除できますCLI。ただし、このセキュリティグループはに表示されません。 AWS OpsWorks スタックコンソール。セキュリティグループを削除する場合は、Amazon も使用する必要がありますEC2。詳細については、「セキュリティグループ」を参照してください。

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

より制限の厳しいセキュリティグループを追加しても、組み込みセキュリティグループのポートアクセスの設定は制限されません。複数のセキュリティグループがある場合、Amazon は最も許容される設定EC2を使用します。
組み込みセキュリティグループの設定は変更しないでください。スタックを作成すると、 AWS OpsWorks スタックは組み込みのセキュリティグループの設定を上書きするため、次回スタックを作成するときに行った変更は失われます。

より制限が厳しい設定のセキュリティグループをレイヤーに使用する必要がある場合は、次のステップに従います。

適切な設定のカスタムセキュリティグループを作成し、適切なレイヤーに追加します。

カスタム設定が必要なレイヤーが 1 つだけの場合も、スタックの各レイヤーに組み込みセキュリティグループの他にセキュリティグループを少なくとも 1 つ追加する必要があります。
スタック設定を編集し、セキュリティグループの使用 OpsWorks設定を「いいえ」に切り替えます。

AWS OpsWorks スタックは、すべてのレイヤーから組み込みのセキュリティグループを自動的に削除します。

セキュリティグループの詳細については、「Amazon EC2 Security Groups」を参照してください。

EC2 インスタンスプロファイル

レイヤーのインスタンスのEC2プロファイルを変更できます。詳細については、「EC2 インスタンスで実行されるアプリケーションのアクセス許可の指定」を参照してください。

CloudWatch ログ

CloudWatch Logs タブでは、Amazon CloudWatch Logs を有効または無効にできます。 CloudWatch Logs の統合は、Chef 11.10 および Chef 12 の Linux ベースのスタックと連携します。Logs 統合を有効にし、 CloudWatch Logs コンソールで管理する CloudWatch ログを指定する方法の詳細については、「」を参照してくださいAWS OpsWorks スタックでの Amazon CloudWatch Logs の使用。

[Tags] タブでは、レイヤーにコスト配分タグを適用することができます。タグを追加したら、でアクティブ化できます。 AWS Billing and Cost Management console。タグを作成する場合、タグ付けされた構造内すべてのリソースにタグを適用することになります。例えば、レイヤーにタグを適用する場合、レイヤー内のすべてのインスタンス、Amazon EBSボリューム、または Elastic Load Balancing ロードバランサーにタグを適用します。タグをアクティブ化し、それを使用してのコストを追跡および管理する方法の詳細については、「」を参照してください。 AWS OpsWorks スタックリソースについては、「請求情報とコスト管理ユーザーガイド」の「コスト配分タグの使用」および「ユーザー定義のコスト配分タグの有効化」を参照してください。 https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html でのタグ付けの詳細については、「」を参照してください。 AWS OpsWorks スタックについては、「」を参照してくださいタグ。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

OpsWorks レイヤーの作成

自動ヒーリングの使用