翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# OpsWorks レイヤーの構成を編集する
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
レイヤーの作成後、レイヤーの設定のほとんどはいつでも変更することができます (AWS のリージョンなどプロパティによっては変更できないものもあります)。レイヤーを編集すると、[**Add Layer**] (レイヤーの追加) ページにない設定にもアクセスできます。この設定は、新しい設定を保存するとすぐに有効になります。
**OpsWorks レイヤーを編集するには**
1. ナビゲーションペインで、[**Layers**] (レイヤー) をクリックします。
1. [**Layers**] (レイヤー) ページで、レイヤー名を選択して詳細ページを開きます。詳細ページには現在の設定が表示されます。
**注記**
レイヤーの名前の下にあるいずれかの名前を選択すると、詳細ページの関連タブに直接移動します。
1. [**Edit**] をクリックし、[**General Settings**]、[**Recipes**]、[**Network**]、[**EBS Volumes**]、[**Security**] の中から適切なタブを選択します。
次のセクションでは、すべてのレイヤーで使用できるさまざまなタブの設定について説明します。一部のレイヤーには、レイヤー固有の追加設定があり、ページの上部に表示されます。さらに、注記のとおり、一部の設定は Linux ベースのスタックでのみ使用できます。
**Topics**
+ [全般設定](#workinglayers-basics-edit-general)
+ [recipe](#workinglayers-basics-edit-recipes)
+ [Network](#workinglayers-basics-edit-network)
+ [EBS ボリューム](#workinglayers-basics-edit-ebs)
+ [セキュリティ](#workinglayers-basics-edit-security)
+ [CloudWatch Logs](#w2ab1c14c53c21c11c23)
+ [タグ](#w2ab1c14c53c21c11c25)
## 全般設定
すべてのレイヤーは次のように設定されます。
**Auto healing enabled**
レイヤーのインスタンスに対して[自動ヒール](workinginstances-autohealing.md)が有効かどうかを示します。デフォルトの設定は、[**Yes**] です。
**Custom JSON**
このレイヤーのすべてのインスタンスで Chef レシピに渡される JSON 形式のデータ。たとえば、これを使用してデータを独自のレシピに渡すことができます。詳細については、「[カスタム JSON の使用](workingstacks-json.md)」を参照してください。
カスタム JSON は、デプロイ、レイヤー、およびスタックの各レベルで宣言できます。一部のカスタム JSON を、スタック全体または個別のデプロイでのみ表示する場合に、この操作を実行することをお勧めします。または、たとえば、デプロイレベルで宣言されたカスタム JSON で、レイヤーレベルで宣言されたカスタム JSON を一時的に上書きしたいとします。複数のレベルでカスタム JSON を宣言する場合、デプロイレベルで宣言されたカスタム JSON は、レイヤーレベルおよびスタックレベルの両方で宣言されたカスタム JSON より優先されます。レイヤーレベルで宣言されたカスタム JSON は、スタックレベルでのみ宣言されたカスタム JSON より優先されます。
OpsWorks スタックコンソールを使用してデプロイのカスタム JSON を指定するには、**アプリのデプロイ**ページで**アドバンスト** を選択します。[**Custom Chef JSON**] ボックスにカスタム JSON を入力し、[**Save**] を選択します。
OpsWorks スタックコンソールを使用してスタックのカスタム JSON を指定するには、スタック設定ページでカスタム JSON を**カスタム JSON **ボックスに入力し、**保存**を選択します。
詳細については、「[カスタム JSON の使用](workingstacks-json.md)」および「[アプリケーションのデプロイ](workingapps-deploying.md)」を参照してください。
**Instance shutdown timeout**
[Shutdown ライフサイクルイベント](workingcookbook-events.md)をトリガーしてから Amazon EC2 インスタンスを停止または終了するまでの OpsWorks スタックの待機時間 (秒単位) を指定します。デフォルトの設定は 120 秒です。設定の目的は、インスタンスを終了する前に、インスタンスの Shutdown レシピに対して、タスクを完了するための十分な時間を与えることです。カスタム Shutdown レシピでさらに時間が必要な場合は、それに応じて設定を変更します。インスタンスのシャットダウンの詳細については、「[インスタンスの停止](workinginstances-starting.md#workinginstances-starting-stop)」を参照してください。
このタブのその他の設定は、レイヤーの種類によって異なり、レイヤーの [**Add Layer**] (レイヤーの追加) ページの設定と同じです。
## recipe
[**Recipes**] タブには次の設定が含まれます。
[**Custom Chef recipes**]
レイヤーのライフサイクルイベントにカスタム Chef レシピを割り当てることができます。詳細については、「[レシピの実行](workingcookbook-executing.md)」を参照してください。
## Network
[**Network**] タブには次の設定が含まれます。
**エラスティックロードバランシング**
あらゆる Layer に Elastic Load Balancing のロードバランサーをアタッチできます。 OpsWorks その後、スタックはレイヤーのオンラインインスタンスをロードバランサーに自動的に登録し、オフラインになると登録を解除します。ロードバランサーの接続ドレイニング機能を有効にしている場合は、 OpsWorks スタックがサポートするかどうかを指定できます。詳細については、「[Elastic ロードバランシングレイヤー](layers-elb.md)」を参照してください。
[**Automatically Assign IP Addresses**]
OpsWorks スタックがレイヤーのインスタンスにパブリック IP アドレスと Elastic IP アドレスのどちらを自動的に割り当てるかを制御できます。このオプションを有効にすると、次のようになります。
+ instance store-backed インスタンスの場合、 OpsWorks スタックはインスタンスが起動されるたびにアドレスを自動的に割り当てます。
+ Amazon EBS-backed インスタンスの場合、インスタンスが初めて起動されると、 OpsWorks スタックは自動的にアドレスを割り当てます。
+ インスタンスが複数のレイヤーに属している場合、少なくとも 1 つのレイヤーの自動割り当てを有効にしている場合、 OpsWorks Stacks はアドレスを自動的に割り当てます。
パブリック IP アドレスの自動割り当てを有効にすると、新しいインスタンスにのみ適用されます。 OpsWorks スタックは既存のインスタンスのパブリック IP アドレスを更新できません。
スタックを VPC で実行している場合、パブリック IP アドレスと Elastic IP アドレスを別個に設定できます。次の表はパブリック IP アドレスと Elastic IP アドレスが対話する方法を説明しています。
![\[Table showing interactions between public IP addresses, Elastic IP addresses, and instance network configurations.\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/ip-address.png)
インスタンスには、 スタックサービス、Linux OpsWorks パッケージリポジトリ、クックブックリポジトリと通信する方法が必要です。パブリック IP アドレスや Elastic IP アドレスを指定しない場合は、NAT など、レイヤーのインスタンスが外部サイトと通信するためのコンポーネントを VPC に含める必要があります。詳細については、「[VPC でのスタックの実行](workingstacks-vpc.md)」を参照してください。
スタックが VPC で実行されていない場合は、[**Elastic IP addresses**] のみを設定できます。
+ **Yes**: インスタンスの初回起動時に、インスタンスに Elastic IP アドレスが割り当てられます。Elastic IP アドレスを割り当てることができない場合は、パブリック IP アドレスが割り当てられます。
+ **No**: インスタンスを起動するたびに、パブリック IP アドレスが割り当てられます。
## EBS ボリューム
[**EBS Volumes**] タブには、次の設定が含まれます。
EBS 最適化インスタンス
レイヤーのインスタンスを Amazon Elastic Block Store (Amazon EBS) 用に最適化する必要があるかどうか。詳細については、「[Amazon EBS 最適化インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html)」を参照してください。
**Additional EBS Volumes**
(Linux のみ) [Amazon EBS volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) (Amazon EBS ボリューム) をレイヤーのインスタンスに追加、またはレイヤーのインスタンスから削除することができます。インスタンスを起動すると、 OpsWorks スタックによってボリュームが自動的に作成され、インスタンスにアタッチされます。スタックの EBS ボリュームを管理するには、[**Resources**] ページを使用できます。詳細については、「[リソース管理](resources.md)」を参照してください。
+ [**Mount point**] (マウントポイント) - (必須) EBS ボリュームをマウントするマウントポイントまたはディレクトリを指定します。
+ [**\$1 Disks** (\$1 Disks)] - (オプション) RAID 配列を指定した場合は、配列のディスク数を指定します。
各 RAID レベルのディスク数はデフォルトの値に設定されていますが、リストから数を選択してディスク数を増やすことも可能です。
+ [**Size total (GiB)**] (合計サイズ (GiB)) - (必須) ボリュームのサイズ (GiB 単位) を指定します。
RAID 配列の場合、この設定は各ディスクのサイズではなく配列の合計サイズを指定します。
次の表は、各ボリュームタイプで許容される最小および最大ボリュームサイズをまとめたものです。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/workinglayers-basics-edit.html)
+ [**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 までバースト可能です。
ボリュームをレイヤーに追加するか、レイヤーから削除する場合は、次の点に注意してください。
+ ボリュームを追加すると、すべての新しいインスタンスに新しいボリュームが追加されますが、 OpsWorks スタックは既存のインスタンスを更新しません。
+ ボリュームを削除する場合、新しいインスタンスにのみ適用されます。既存のインスタンスのボリュームは削除されません。
### マウントポイントの指定
任意のマウントポイントを指定することができます。ただし、一部のマウントポイントは OpsWorks スタックまたは Amazon EC2 用に予約されており、Amazon EBS ボリュームには使用しないでください。`/home` や `/etc` などの一般的な Linux システムフォルダは使用しないでください。
以下のマウントポイントは 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 インスタンスストア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)」を参照してください。 OpsWorks スタックのカスタム AMI を作成する方法の詳細については、「」を参照してください[カスタム AMI の使用](workinginstances-custom-ami.md)。
次の例は、ボリュームのマウントポイントが autofs と競合しないよう、どのようにカスタムレシピを使用できるかを示しています。特定のユースケースに応じて適応してください。
**マウントポイントの競合を回避するには**
1. Amazon EBS ボリュームを任意のレイヤーに割り当てます。ただし、`/mnt/workspace` など、autofs と競合しないマウントポイントを使用します。
1. Amazon EBS ボリュームにアプリケーションディレクトリと、`/srv/www/` からそのディレクトリへのリンクを作成する、以下のカスタムレシピを実装します。カスタムレシピの実装方法の詳細については、「[クックブックとレシピ](workingcookbook.md)」と「[OpsWorks スタックのカスタマイズ](customizing.md)」を参照してください。
```
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
```
1. 「`depends 'deploy'`」行をカスタムクックブックの `metadata.rb` ファイルに追加します。
1. [このレシピをレイヤーの Setup イベントに割り当てます。](workingcookbook-executing.md)
## セキュリティ
[**Security**] タブには次の設定が含まれます。
**セキュリティグループ**
レイヤーには、セキュリティグループを少なくとも 1 つ関連付ける必要があります。スタック[を作成](workingstacks-creating.md)または[更新](workingstacks-edit.md)するときにセキュリティグループを関連付ける方法を指定します。 OpsWorks スタックには、標準の組み込みセキュリティグループのセットが用意されています。
+ デフォルトのオプションは、 OpsWorks スタックが適切な組み込みセキュリティグループを各レイヤーに自動的に関連付けることです。
+ 組み込みセキュリティグループが自動的に関連付けされないように設定し、レイヤーの作成時にカスタムセキュリティグループを各レイヤーに関連付けることも可能です。
セキュリティグループの詳細については、「[セキュリティグループの使用](workingsecurity-groups.md)」を参照してください。
レイヤーの作成後、**Security Groups** を使い、[**Custom security groups**] リストからセキュリティグループを選択してレイヤーに追加することができます。セキュリティグループをレイヤーに追加すると、 OpsWorks Stacks はそれをすべての新しいインスタンスに追加します。(再起動されたインスタンスストアインスタンスは新しいインスタンスとして起動されるため、新しいセキュリティグループもあります）。 OpsWorks スタックは、オンラインインスタンスにセキュリティグループを追加しません。
次のように、[**x**] をクリックして既存のセキュリティグループを削除することができます。
+ OpsWorks スタックに組み込みセキュリティグループを自動的に関連付けることを選択した場合は、**x** をクリックして以前に追加したカスタムセキュリティグループを削除できますが、組み込みグループを削除することはできません。
+ 自動的に組み込みセキュリティグループが関連付けられないように設定した場合は、元のセキュリティグループも含め、任意の既存のセキュリティグループを削除することができます。ただし、レイヤーにはセキュリティグループを少なくとも 1 つ関連付けておく必要があります。
レイヤーからセキュリティグループを削除した後、 OpsWorks スタックは新しいインスタンスまたは再起動されたインスタンスに追加しません。 OpsWorks スタックはオンラインインスタンスからセキュリティグループを削除しません。
スタックが VPC で実行されている場合は、Amazon EC2 コンソール、API、または CLI を使用して、オンラインインスタンスのセキュリティグループを追加または削除できます。ただし、このセキュリティグループは OpsWorks スタックコンソールに表示されません。セキュリティグループを削除する場合、Amazon EC2 も使用する必要があります。詳細については、「[セキュリティグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html)」を参照してください。
次の点に注意してください。
+ より制限の厳しいセキュリティグループを追加しても、組み込みセキュリティグループのポートアクセスの設定は制限されません。複数のセキュリティグループがある場合、Amazon EC2 は最も制限の緩い設定を使用します。
+ 組み込みセキュリティグループの設定は変更しないでください。スタックを作成すると、 OpsWorks スタックは組み込みのセキュリティグループの設定を上書きするため、次回スタックを作成するときに行った変更は失われます。
より制限が厳しい設定のセキュリティグループをレイヤーに使用する必要がある場合は、次のステップに従います。
1. 適切な設定のカスタムセキュリティグループを作成し、適切なレイヤーに追加します。
カスタム設定が必要なレイヤーが 1 つだけの場合も、スタックの各レイヤーに組み込みセキュリティグループの他にセキュリティグループを少なくとも 1 つ追加する必要があります。
1. [スタックの設定を編集](workingstacks-edit.md)し、[**Use OpsWorks security groups**] の設定を [**No**] に切り替えます。
OpsWorks スタックは、すべてのレイヤーから組み込みのセキュリティグループを自動的に削除します。
セキュリティグループの詳細については、「[Amazon EC2 セキュリティグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)」を参照してください。
**EC2 インスタンスプロファイル**
レイヤーのインスタンスの EC2 プロファイルを変更することができます。詳細については、「[EC2 インスタンスで実行するアプリケーションに対するアクセス許可の指定](opsworks-security-appsrole.md)」を参照してください。
## CloudWatch Logs
[**CloudWatch Logs**] (CloudWatch ログ) タブでは、Amazon CloudWatch Logs を有効または無効にできます。CloudWatch Logs の統合は、Chef 11.10、Chef 12 Linux ベースのスタックで動作します。CloudWatch Logs の統合の有効化、および CloudWatch Logs コンソールで管理するログの指定の詳細については、「[スタックでの Amazon CloudWatch Logs OpsWorks の使用](monitoring-cloudwatch-logs.md)」を参照してください。
## タグ
[**Tags**] タブでは、レイヤーにコスト配分タグを適用することができます。タグを追加したら、 AWS Billing and Cost Management コンソールでアクティブ化できます。タグを作成する場合、タグ付けされた構造内すべてのリソースにタグを適用することになります。例えば、あるレイヤーにタグを適用すると、そのレイヤーのすべてのインスタンス、Amazon EBS ボリューム、および Elastic Load Balancing ロードバランサーにそのタグを適用することになります。タグをアクティブ化し、それらを使用して OpsWorks スタックリソースのコストを追跡および管理する方法の詳細については、*請求情報とコスト管理ユーザーガイド*の[「コスト配分タグの使用](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)」と[「ユーザー定義のコスト配分タグのアクティブ化](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)」を参照してください。 OpsWorks スタックへのタグ付けの詳細については、[タグ](tagging.md) を参照してください。