OpsWorks Layer の設定の編集 - AWSOpsWorks

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

OpsWorks Layer の設定の編集

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

OpsWorks Layer を編集するには

  1. ナビゲーションペインで、[Layers] をクリックします。

  2. [Layers] ページで、レイヤー名を選択して詳細ページを開きます。詳細ページには現在の設定が表示されます。

    注記

    レイヤーの名前の下にあるいずれかの名前を選択すると、詳細ページの関連タブに直接移動します。

  3. [Edit] をクリックし、[General Settings]、[Recipes]、[Network]、[EBS Volumes]、[Security] の中から適切なタブを選択します。

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

全般設定

すべての Layer は次のように設定されます。

Auto healing enabled

Layer のインスタンスに対して自動ヒールが有効かどうかを示します。デフォルトの設定は、[Yes] です。

Custom JSON

この Layer のすべてのインスタンスで Chef レシピに渡される JSON 形式のデータ。たとえば、これを使用してデータを独自のレシピに渡すことができます。詳細については、「カスタム JSON の使用」を参照してください。

注記

カスタム JSON は、デプロイ、Layer、およびスタックの各レベルで宣言できます。一部のカスタム JSON を、スタック全体または個別のデプロイでのみ表示する場合に、この操作を実行することをお勧めします。または、たとえば、デプロイレベルで宣言されたカスタム JSON で、Layer レベルで宣言されたカスタム JSON を一時的に上書きしたいとします。複数のレベルでカスタム JSON を宣言する場合、デプロイレベルで宣言されたカスタム JSON は、Layer レベルおよびスタックレベルの両方で宣言されたカスタム JSON より優先されます。Layer レベルで宣言されたカスタム JSON は、スタックレベルでのみ宣言されたカスタム JSON より優先されます。

AWS OpsWorks スタックコンソールを使用してデプロイ用のカスタム JSON を指定するには、[Deploy App (アプリのデプロイ)] ページで [Advanced (詳細設定)] を選択します。[Custom Chef JSON] ボックスにカスタム JSON を入力し、[Save] を選択します。

AWS OpsWorks スタックコンソールを使用してスタック用のカスタム JSON を指定するには、スタックの設定ページで [Custom JSON (カスタム JSON)] ボックスにカスタム JSON を入力して、[Save (保存)] を選択します。

詳細については、「カスタム JSON の使用」および「アプリケーションのデプロイ」を参照してください。

Instance shutdown timeout

AWS OpsWorks スタックが Shutdown ライフサイクルイベントをトリガーした後に Amazon EC2 インスタンスを停止または終了する前に待機する時間 (秒単位) を指定します。デフォルトの設定は 120 秒です。設定の目的は、インスタンスを終了する前に、インスタンスの Shutdown レシピに対して、タスクを完了するための十分な時間を与えることです。カスタム Shutdown レシピでさらに時間が必要な場合は、それに応じて設定を変更します。インスタンスのシャットダウンの詳細については、「インスタンスの停止」を参照してください。

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

レシピ

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

[Custom Chef recipes]

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

ネットワーク

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

Elastic Load Balancing

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

[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 など、Layer のインスタンスが外部サイトと通信するためのコンポーネントを VPC に含める必要があります。詳細については、「VPC でのスタックの実行」を参照してください。

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

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

  • No: インスタンスを起動するたびに、パブリック IP アドレスが割り当てられます。

EBS ボリューム

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

EBS 最適化インスタンス

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

Additional EBS Volumes

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

  • Mount point –(必須) EBS ボリュームをマウントするマウントポイントまたはディレクトリを指定します。

  • # 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 までバースト可能です。

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

  • ボリュームを追加すると、すべての新しいインスタンスに新しいボリュームが追加されますが、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 と競合しないようにするため、エフェメラルデバイスマウントポイントは指定しないでください。使用されるエフェメラルデバイスマウントポイントは、特定のインスタンスのタイプ、およびインスタンスが instance store–backed と Amazon EBS–backed のどちらであるかによって決まります。autofs との競合を避けるため、次を実行します。

  • 特定のインスタンスタイプのエフェメラルデバイスマウントポイントと、使用するバッキングストアを確認します。

  • Instance store-backed インスタンス用のマウントポイントは、Amazon EBS-backed インスタンスに切り替えた場合に autofs と競合する可能性があります。また、逆に切り替えた場合も同様です。

注記

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

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

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

  1. Amazon EBS ボリュームを任意のレイヤーに割り当てます。ただし、autofs と競合しないマウントポイント (/mnt/workspace など) を使用します。

  2. 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
  3. depends 'deploy'」行をカスタムクックブックの metadata.rb ファイルに追加します。

  4. このレシピを Layer の Setup イベントに割り当てます。

セキュリティ

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

個のセキュリティグループ

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

  • デフォルトのオプションでは、AWS OpsWorks Stacks により自動的に適切な組み込みセキュリティグループが各レイヤーに関連付けられます.

  • 組み込みセキュリティグループが自動的に関連付けされないように設定し、Layer の作成時にカスタムセキュリティグループを各 Layer に関連付けることも可能です。

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

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

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

  • AWS OpsWorks スタックが自動的に組み込みセキュリティグループを関連付けるように設定している場合は、[x] をクリックして、前に追加したカスタムセキュリティグループを削除できます。ただし、組み込みセキュリティグループは削除できません。

  • 自動的に組み込みセキュリティグループが関連付けられないように設定した場合は、元のセキュリティグループも含め、任意の既存のセキュリティグループを削除することができます。ただし、Layer にはセキュリティグループを少なくとも 1 つ関連付けておく必要があります。

レイヤーからセキュリティグループを削除した場合、AWS OpsWorks スタックによって新しいインスタンスまたは再開されたインスタンスに追加されることはありません。AWS OpsWorks スタックは、オンラインインスタンスからセキュリティグループを削除しません。

注記

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

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

  • より制限の厳しいセキュリティグループを追加しても、組み込みセキュリティグループのポートアクセスの設定は制限されません。複数のセキュリティグループがある場合、Amazon EC2 は最も制限の緩い設定を使用します。

  • 組み込みセキュリティグループの設定は変更しないでください。AWS OpsWorks スタックでは、スタックの作成時に組み込みのセキュリティグループの設定が上書きされるため、設定に変更を加えても、次回スタックを作成するときには変更内容は失われています。

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

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

    カスタム設定が必要な Layer が 1 つだけの場合も、スタックの各 Layer に組み込みセキュリティグループの他にセキュリティグループを少なくとも 1 つ追加する必要があります。

  2. スタックの設定を編集し、[Use OpsWorks security groups] の設定を [No] に切り替えます。

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

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

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

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

[CloudWatch Logs]

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

Tags (タグ)

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