AWS OpsWorks

  • AWS OpsWorks は、Chef を使用してクラウドエンタープライズのアプリケーションを構成および運用するための構成管理サービスです。
  • Chef の自動設定と AWS opsworks による自動化により、Chef クックブックと構成管理ソリューションを使用できます。

OpsWorks スタック

OpsWorks スタック

  • OpsWorks スタックは、スタック、ロードバランサー、Web アプリケーション、データベースサーバーなどの AWS リソースのグループ、およびそれらにデプロイされたアプリケーションを作成および管理するためのシンプルで柔軟な方法を提供します。
  • OpsWorks スタックは、スタック内のアプリケーションの配置と監視に役立ちます。
  • Chef の自動化のための Opsworks とは異なり、Opsworks スタックは Chef サーバーを必要としません。Chef サーバー自体の作業の一部を実行する。
  • OpsWorks スタックはインスタンスの正常性を監視し、必要に応じて自動修復と自動スケーリングを使用して新しいインスタンスをプロビジョニングします。
  • OpsWorks スタックは IAM と統合され、ユーザーがスタックと対話する方法、ユーザーに代わって実行できるスタック、アプリがアクセスできる AWS リソースなどを制御します。
  • OpsWorks スタック 　は、CloudWatch および CloudTrail と統合され、監視およびログ記録を可能にします。
  • OpsWorks スタックはグローバルにアクセスでき、インスタンスをグローバルに作成および管理するために使用できます。

スタック

  • スタックは、AWS OpsWorks スタックのコアコンポーネントです。
  • スタックは、共通の目的を持ち、論理的に一緒に管理する必要がある EC2、RDS インスタンスなどの AWS リソースのコンテナです。
  • スタックは、リソースをグループとして管理し、インスタンスの OS や AWS リージョンなどのデフォルトの構成設定も定義します。
  • VPC でスタックを実行して、ユーザーの直接的なやりとりから隔離することもできます。
  • Dev、QA などの異なる環境用に別々のスタックを作成できます

レイヤー

  • スタックは、レイヤと呼ばれる特殊なグループのクラウドリソースを管理するのに役立ちます。
  • レイヤーは、アプリケーションの提供やデータベースサーバーのホストなど、特定の目的を果たす EC2 インスタンスのセットを表します。
  • レイヤーは、Chef のレシピに依存して、インスタンスへのパッケージのインストール、アプリの展開、スクリプトの実行などのタスクを処理します。
  • カスタムレシピおよび関連ファイルは、1つまたは複数のクックブックにパッケージ化され、このような S3 または Git のクックブックリポジトリに保存されます。

レシピとライフサイクルイベント

  • レイヤーは、Chef のレシピに依存して、インスタンスへのパッケージのインストール、アプリの展開、スクリプトの実行などのタスクを処理します。
  • インスタンスが複数のレイヤに属している場合(アプリケーションと MySQL サーバの両方をホストするインスタンスなど)でも、OpsWorks スタックは各レイヤのレシピを実行します。
  • AWS OpsWorks スタックの機能は、セットアップ、構成、デプロイ、アンデプロイ、およびシャットダウンの一連のライフサイクルイベントであり、各インスタンスの適切なタイミングで特定のレシピセットを自動的に実行します。
    • セットアップ
      • 新しいインスタンスが起動されると、OpsWorks はセットアップイベントをトリガし、Apache 、PHP パッケージのインストールなどのレイヤ構成に従ってインスタンスを設定するためのレシピを実行します。
      • セットアップが完了すると、AWS OpsWorks はデプロイイベントをトリガして、アプリケーションを新しいインスタンスにデプロイするためのレシピを実行します。
    • 構成
      • インスタンスがオンライン状態になるか、またはそのままになるたびに、AWS OpsWorks はスタック内のすべてのインスタンスに対して Configure イベントをトリガします。
      • イベントは、各レイヤーの Configure レシピを実行して、現在のオンラインインスタンスのセットを反映するように構成を更新します。 HAProxy レイヤー の Configure レシピは、追加または削除されたアプリケーションサーバーインスタンスを反映するようにロードバランサー構成を変更できます。
    • デプロイ
      • OpsWorks は、Deploy コマンドが実行されたときにデプロイイベントをトリガし、アプリケーションを一連のアプリケーションサーバにデプロイします。
      • イベントはアプリケーションサーバー上のレシピを実行し、アプリケーションおよび関連ファイルをリポジトリからレイヤーのインスタンスにデプロイします。
    • アンデプロイ
      • アプリケーションが削除されたとき、または Undeploy コマンドが実行された場合、OpsWorks によってアンデプロイイベントが発生します。
      • イベントは、すべてのアプリケーションバージョンを削除し、追加のクリーンアップタスクを実行するためのレシピを実行します。
    • シャットダウン
      • インスタンスがシャットダウンされているときに、基になる EC2 インスタンスが実際に終了する前に、OpsWorks によってシャットダウンイベントがトリガされます。
      • イベントは、サービスのシャットダウンなどのクリーンアップタスクを実行するためのレシピを実行します。
      • OpsWorks では、シャットダウンレシピでタスクを実行するための構成可能な時間を設定し、インスタンスを終了させることができます。

インスタンス

  • インスタンスは、EC2 インスタンスなどの単一のコンピューティングリソースを表し、OS やサイズなどのリソースの基本構成を定義します。
  • OpsWorks スタックはインスタンスを作成し、レイヤーに追加します。
  • インスタンスが開始されると、OpsWorks スタックはインスタンスとそのレイヤーで指定された構成設定を使用して EC2 インスタンスを起動します。
  • EC2 インスタンスの起動が完了すると、OpsWorks スタックはインスタンスとサービス間の通信を処理するエージェントをインストールし、ライフサイクルイベントに応じて適切なレシピを実行します。
  • OpsWorks スタックはインスタンスの自動修復をサポートし、エージェントがサービスとの通信を停止した場合、OpsWorks スタックはインスタンスを自動的に停止して再起動します。
  • OpsWorks スタックは、次のインスタンスタイプをサポートします。
    • 24/7 インスタンス – 手動で起動および停止
    • 時間ベースのインスタンス – スケジュールされた時間に実行
    • 負荷ベースのインスタンス – 設定可能な負荷メトリックに基づいて自動的に開始および停止
  • コンソールや CLI などの OpsWorks スタックの外部で作成された Linux ベースのコンピューティングリソースは、OpsWorks を通じて追加、組み込み、および制御できます。

Apps

  • AWS OpsWorks スタックアプリは、S3 のようにアプリリポジトリに常駐するアプリケーションサーバー上で実行したいコードを表します。
  • アプリには、適切なアプリケーションサーバーインスタンスにコードを展開するために必要な情報が含まれています。
  • アプリを展開すると、AWS OpsWorks スタックによってデプロイイベントがトリガされ、スタックのインスタンスで展開レシピが実行されます。
  • OpsWorks は、スタックごとおよびレイヤごとに複数のアプリを展開する機能をサポートします。

AWS認定試験の練習問題

  • 質問はインターネットから収集され、答えは自分の知識と理解に基づいてマークされます（これはあなたと異なる場合があります）。
  • AWSサービスは毎日更新され、回答と質問はすぐに時代遅れになる可能性がありますので、それに応じて調査してください。
  • AWSのアップデートのペースを追うためにAWS試験の質問は更新されないため、基礎となる機能が変更されても質問が更新されないことがあります。
  • さらなるフィードバック、ディスカッション、修正を可能にします。
  1. お客様は、データセンターで Chef 構成管理を使用している顧客と作業しています。どのサービスが AWS で既存のシェフレシピを活用できるように設計されていますか？
    1. Amazon Simple Workflow Service
    2. AWS Elastic Beanstalk
    3. AWS CloudFormation
    4. AWS OpsWorks
  2. あなたのミッションは、ライトアウトデータセンター環境を作成し、これを達成するために AWS OpsWorks を使用する予定です。最初にスタックを作成し、その中で実行されているインスタンスでアプリケーションサーバー層を追加しました。次に、インスタンスにアプリケーションを追加し、これで MySQL RDS データベースインスタンスをデプロイする必要があります。バックエンドデータベースサーバーを OpsWorks スタックに追加する方法について、次の回答のうち正確な説明はどれか？3つの回答を選択
    1. 新しいデータベース層を追加し、データベースおよびアプリケーションサーバー層のデプロイアクションにレシピを追加します。(リンク参照)
    2. プライマリ AZ で障害が発生した場合に冗長性を確保するために、別のアベイラビリティーゾーンに2番目の RDS スタックを作成するには、OpsWorks の “クローンスタック” 機能を使用します。セカンダリ RDS インスタンスに切り替えるには、カスタム JSON を使用して実行できるサーバーに適した値に [:database] 属性を設定します。
    3. RDS データベース接続 (ホスト、ユーザーなど) を特徴付ける変数は、デプロイ JSON の [:deploy] [:app_name] [:database] 属性の対応する値を使用して設定されます。(リンク参照)
    4. クックブック属性はリポジトリに格納されるため、OpsWorks では、少なくとも256ビットキーを使用して RDS インスタンスの “password”: “your_password” 属性を暗号化する必要があります。
    5. カスタムレシピを使用して、アプリサーバーと RDS 層の間の接続を設定します。レシピでは、通常、構成ファイルを作成することによって、必要に応じてアプリサーバーを構成します。レシピは、ホストとデータベース名などの接続データを、すべてのインスタンスに AWS OpsWorks がインストールするスタック構成およびデプロイメント JSON 内の一連の属性から取得します。([リンク参照])
  3. あなたは、AWS への非常にトラフィックの多いノードの js アプリケーションの移行を任務としている。組織標準に準拠するためには、このアプリケーションをホストするアプリケーションサーバーを構成し、アプリケーションライフサイクルイベントをサポートするために、Chef レシピを使用する必要があります。管理上の負担を最小限に抑えながら、これらの要件を満たす展開オプションはどれですか。
    1. Opsworks 内に新しいスタックを作成する適切なレイヤをスタックに追加し、アプリケーションをデプロイします。
    2. Elastic Beanstalk の中に新しいアプリケーションを作成し、新しい環境にこのアプリケーションを展開する (シェフのレシピに準拠する必要があります)
    3. コミュニティ AMI からノード JS サーバーを起動し、起動した EC2 インスタンスにアプリケーションを手動でデプロイする
    4. EC2 インスタンスで Chef サーバーを起動して構成し、AWS CLI を活用してアプリケーションサーバーを起動し、Chef を使用してそれらのインスタンスを構成します。
  4. Web Startup　は、Elastic Load Balancer、Java / Tomcatアプリケーションサーバーの　Auto-Scaling　グループ、およびデータストアとしての　DynamoDB　を使用して、Amazon EC2　上で非常に成功したソーシャルニュースアプリケーションを実行します。 メインの　Web　アプリケーションは、メモリに非常に拘束されているので、m2.xlarge　インスタンス上で実行するのが最適です。 新しいデプロイメントでは、アプリケーションサーバー用の新しい　AMI　の半自動化された作成とテストが必要です。これにはかなりの時間がかかり、したがって1週間に1回しか実行されません。 最近、新しいチャット機能が　node.js　に実装され、アーキテクチャに統合されるのを待ちます。 最初のテストでは、新しいコンポーネントが　CPU　にバインドされていることがわかりました。Chef　の使用経験があるため、導入プロセスを合理化し、AWS OpsWorks　をアプリケーションのライフサイクルツールとして使用して、アプリケーションの管理を簡素化し、 新しいチャットモジュールを最も費用対効果の高い柔軟な方法で統合するには、AWS OpsWorks　のどの設定が必要ですか？
    1. 1つの AWS OpsWorks スタックを作成し、1つの AWS OpsWorks レイヤーを作成し、1つのカスタムレシピを作成します。
    2. 1つの AWS OpsWorks スタックを作成し、2つの AWS OpsWorks レイヤを作成し、1つのカスタムレシピ (単一環境スタック、2層の java と node.js アプリケーションを使用して、他の構成としてのみ DynamoDB 接続のレシピとカスタムレシピを作成します。リンク参照)
    3. 2つの AWS OpsWorks スタックを作成し、2つの AWS OpsWorks レイヤーを作成し、1つのカスタムレシピを作成する。
    4. 2つの AWS OpsWorks スタックを作成し、2つの AWS OpsWorks レイヤーを作成し、2つのカスタムレシピを作成します。
  5. あなたは、同じ Amazon Relational Database（RDS） データベースを基にした約10種類のソフトウェアコンポーネントで構成される複雑な顧客関係管理システムを運用しています。 AWS OpsWorks を採用して、そのアプリケーションの管理とデプロイメントを簡素化し、個々のコンポーネントごとにレイヤーを備えた AWS OpsWorks スタックを作成しました。 内部セキュリティポリシーでは、すべてのインスタンスを最新の Amazon Linux AMI で実行する必要があり、最新の Amazon Linux AMI がリリースされてから1ヶ月以内にインスタンスを置き換える必要があります。 AMI の置き換えは、アプリケーションのダウンタイムや容量の問題を引き起こすことなく行う必要があります。 あなたは、新しいAmazon Linux AMI がリリースされるとすぐに実行されるようにスクリプトを書くことに決めました。 どのソリューションがセキュリティポリシーをサポートし、要件を満たしていますか？ 2つの回答を選択
    1. 基礎となる AMI を置き換えるカスタムレシピを各レイヤに割り当てます。このカスタムレシピを段階的に実行し、新しい AMI でインスタンスを更新するには、AWS OpsWorks ライフサイクルイベントを使用します。
    2. 新しいスタックとレイヤーを同一の構成で作成し、カスタム AMI として指定された最新の Amazon Linux AMI を持つインスタンスを新しいレイヤーに追加し、DNS を新しいスタックに切り替え、古いスタックを破棄します。 （Blue-Green デプロイメント）
    3. AWS OpsWorks スタックのすべての Amazon Elastic Compute Cloud（EC2） インスタンスを識別し、各インスタンスを停止し、AMI ID プロパティを最新の Amazon Linux AMI ID の ID に置き換え、インスタンスを再起動します。 停止時間を避けるために、複数のインスタンスが同時に停止しないようにしてください。
    4. 最新の Amazon Linux AMI をスタックレベルでカスタム AMI として指定し、スタックのインスタンスを終了し、AWS OpsWorks が新しい AMI で新しいインスタンスを起動できるようにします。 （ダウンタイムにつながる）
    5. カスタム AMI として指定された最新の Amazon Linux AMI を持つ新しいインスタンスをスタックのすべての AWS OpsWorks レイヤに追加し、古い AMI を終了します。
  6. AWS OpsWorks について考える場合、スタックレイヤに割り当てることができるインスタンスタイプではないのは次のうちどれですか。
    1. 24/7 インスタンス (24/7 インスタンスがサポートされ、手動で起動し、停止するまで実行)
    2. スポットインスタンス (スポットインスタンスを直接サポートしていませんが、自動スケーリングで使用できます。リンク参照)
    3. 時間ベースのインスタンス (時間ベースのインスタンスは、指定された毎日および毎週のスケジュールで AWS OpsWorks によって実行されます)
    4. 負荷ベースのインスタンス (負荷ベースのインスタンスは、CPU 使用率などの指定された負荷メトリックに基づいて、AWS OpsWorks によって自動的に開始および停止されます)
  7. スタックを監視するために、AWS OpsWorks を直接サポートしていない次のツールはどれですか？
    1. AWS Config (リンク参照)
    2. Amazon CloudWatch メトリック（AWS OpsWorks は CloudWatch を使用して、13個のカスタムメトリックにスタック内の各インスタンスの詳細な監視を提供します）
    3. AWS CloudTrail（AWS OpsWorksはCloudTrail と統合して AWS OpsWorks API コールをすべて記録し、 S3 バケット）
    4. Amazon CloudWatch Logs（Amazon CloudWatch Logs を使用して、スタックのシステム、アプリケーション、およびカスタムログを監視できます）
  8. AWS OpsWorks について考えた場合、次のどちらが該当しますか。
    1. スタックには多くのレイヤーがあり、レイヤーには多くのインスタンスがあります。
    2. インスタンスには多くのスタックがあり、スタックには多くのレイヤーがあります。
    3. レイヤーには多くのスタックがあり、スタックには多くのインスタンスがあります。
    4. レイヤーには多くのインスタンスがあり、インスタンスには多数のスタックがあります。

リファレンス

Jayendra’s Blog

この記事は自己学習用に「AWS OpsWorks – Certification（Jayendra’s Blogより）」を日本語に訳した記事です。