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

OpsWorks レイヤーの設定の編集

重要

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

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

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

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

注記
レイヤーの名前の下にあるいずれかの名前を選択すると、詳細ページの関連タブに直接移動します。
[Edit] をクリックし、[General Settings]、[Recipes]、[Network]、[EBS Volumes]、[Security] の中から適切なタブを選択します。

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

全般設定

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

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

注記
カスタム JSON は、デプロイ、レイヤー、およびスタックの各レベルで宣言できます。一部のカスタム JSON を、スタック全体または個別のデプロイでのみ表示する場合に、この操作を実行することをお勧めします。または、たとえば、デプロイレベルで宣言されたカスタム JSON で、レイヤーレベルで宣言されたカスタム JSON を一時的に上書きしたいとします。複数のレベルでカスタム JSON を宣言する場合、デプロイレベルで宣言されたカスタム JSON は、レイヤーレベルおよびスタックレベルの両方で宣言されたカスタム JSON より優先されます。レイヤーレベルで宣言されたカスタム JSON は、スタックレベルでのみ宣言されたカスタム JSON より優先されます。
AWS OpsWorks スタックコンソールを使用してデプロイのカスタム JSON を指定するには、アプリケーションのデプロイページで、アドバンスト を選択します。[Custom Chef JSON] ボックスにカスタム JSON を入力し、[Save] を選択します。
AWS OpsWorks スタックコンソールを使用してスタックのカスタム JSON を指定するには、スタック設定ページでカスタム JSON をカスタム JSON ボックスに入力し、保存を選択します。
詳細については、「カスタム JSON の使用」および「アプリケーションのデプロイ」を参照してください。
Instance shutdown timeout: Amazon EC2 インスタンスを停止または終了するまでの Shutdown ライフサイクルイベントをトリガーした後の AWS OpsWorks スタックの待機時間 (秒単位) を指定します。デフォルトの設定は 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 スタックはインスタンスが初めて起動されたときにアドレスを自動的に割り当てます。
インスタンスが複数のレイヤーに属している場合、少なくとも 1 つのレイヤーに対して自動割り当てを有効にしている場合、 AWS OpsWorks スタックは自動的にアドレスを割り当てます。

注記

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

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

注記

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

スタックが VPC で実行されていない場合は、[Elastic IP addresses] のみを設定できます。

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

EBS ボリューム

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

EBS 最適化インスタンス

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

Additional EBS Volumes

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

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

各 RAID レベルのディスク数はデフォルトの値に設定されていますが、リストから数を選択してディスク数を増やすことも可能です。

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

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

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

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

[Volume Type] (ボリュームタイプ) - (オプション) マグネティック、汎用 SSD、スループット最適化 HDD、Cold HDD、PIOPS ボリュームのいずれを作成するかどうかを指定します。

デフォルト値は Magnetic です。
[Encrypted] (暗号化) - (オプション) EBS ボリュームのコンテンツを暗号化するかどうかを指定します。
[IOPS per disk] - (プロビジョンド IOPS SSD および汎用 SSD ボリュームに必須) プロビジョンド IOPS SSD) および汎用 SSD ボリュームを指定する場合、[IOPS per disk] も指定する必要があります。

プロビジョンド IOPS ボリュームの場合、ボリュームの作成時に IOPS を指定できます。要求されたボリュームサイズに対してプロビジョニングされる IOPS の比率は最大 30 です (言い換えると、3000 IOPS のボリュームには少なくとも 100 GiB のサイズが必要です)。汎用 (SSD) ボリュームタイプの基準 IOPS はボリュームサイズの 3 倍で、最大 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 EBS でバックアップされたインスタンスに切り替えると、インスタンスストアでバックアップされるインスタンスで動作するマウントポイントが autofs と競合する可能性があり、またその逆の場合もあるので注意してください。

注記

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

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

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

Amazon EBS ボリュームを任意のレイヤーに割り当てます。ただし、/mnt/workspace など、autofs と競合しないマウントポイントを使用します。
Amazon EBS ボリュームにアプリケーションディレクトリと、/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 スタックには、標準の組み込みセキュリティグループのセットが用意されています。

デフォルトのオプションは、 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 セキュリティグループ」を参照してください。

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 コンソールでアクティブ化できます。タグを作成する場合、タグ付けされた構造内すべてのリソースにタグを適用することになります。例えば、あるレイヤーにタグを適用すると、そのレイヤーのすべてのインスタンス、Amazon EBS ボリューム、および Elastic Load Balancing ロードバランサーにそのタグを適用することになります。タグをアクティブ化して AWS OpsWorks スタックリソースのコストを追跡および管理する方法の詳細については、請求情報とコスト管理ユーザーガイドの「コスト配分タグの使用」と「ユーザー定義のコスト配分タグのアクティブ化」を参照してください。 AWS OpsWorks スタックへのタグ付けの詳細については、タグを参照してください。

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

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

ドキュメントの表記規則

OpsWorks レイヤーの作成

自動ヒーリングの使用