AWS OpsWorks Stacks Detach in Place ツールの使用 - AWS OpsWorks
プロセスの仕組み制限入門

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

AWS OpsWorks Stacks Detach in Place ツールの使用

重要

この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。

このセクションでは、 AWS OpsWorks Stacks Detach in Place ツールを使用して OpsWorks スタックサービスから OpsWorks インスタンスをデタッチする方法について説明します。

デタッチしたインスタンスは に残りますが AWS アカウント、OpsWorks を使用して管理することはできなくなります。代わりに、Amazon EC2 AWS Systems Managerまたは EC2 互換アプローチを使用して、インスタンスを設定および管理します。

大まかに言うと、デタッチプロセスには次のステップが含まれます。

  1. このツールは、検証チェックを実行して、リソースをデタッチする準備ができていることを確認します。

  2. このツールは、OpsWorks スタックからカスタム JSON をエクスポートし、Amazon S3 にオブジェクトとして保存します。

  3. このツールは、各 OpsWorks スタックのライフサイクルイベントを表す Systems Manager Automation ドキュメントを作成します。

  4. このツールは、デタッチされているすべてのインスタンスの AWS Service Catalog AppRegistry カタログを作成し、OpsWorks レイヤーから Elastic Load Balancing (ELB) ロードバランサーをデタッチします。

  5. 最後に、このツールは Amazon Relational Database Service (Amazon RDS) インスタンスを含む他のリソースをデタッチおよび登録解除します。

プロセスの仕組み

Detach In Place ツールは、レイヤーのデタッチに進む前にインスタンスをチェックして設定するための一連のステップをガイドする、次の 3 つのコマンドとウィザードのようなエクスペリエンスを提供します。

コマンド 説明

handle-prerequisites

このコマンドは、レイヤー内のすべてのインスタンスがデタッチの対象であるかどうかを分析し、前提条件を解決します。インスタンスは OpsWorks で正常な状態である必要があり、時間または負荷ベースの自動スケーラーを持つことはできません。また、最新の OpsWorks エージェントバージョンがインストールされている必要があります。

さらに、コマンドは、すべてのインスタンスに SSM エージェントをサポートするために必要なアクセス許可があるかどうか、および最新の SSM エージェントバージョンがインストールされているかどうかを確認します。コマンドは、SSM エージェントが存在しない場合はインストールし、最新バージョンを使用していない場合は SSM エージェントを更新します。コマンドは、必要なアクセス許可も追加します。

detach

このコマンドは、指定されたレイヤーのすべての OpsWorks インスタンスをデタッチします。

まず、 コマンドは前提条件チェックを実行して、レイヤーがデタッチの対象となることを確認します。前提条件を解決しない場合は、強制的にデタッチするオプションが表示されます。

次に、 コマンドは、OpsWorks タグ付け APIs を介して、またはレイヤーとスタックからのタグの伝播を介してインスタンスに追加されたすべてのタグが保持されることを示します。デタッチが完了したら、関連する EC2 APIs を使用してこれらのタグのいずれかを削除できます。

次に、 コマンドは Chef 関連の設定を SSM パラメータにエクスポートするかどうかをチェックします。

Classic Load Balancer がレイヤーにアタッチされている場合、コマンドはダウンタイムを防ぐためにロードバランサーをデタッチできるかどうかを尋ねます。

cleanup

このコマンドは、OpsWorks のすべてのエンティティをアカウントから削除します。これにより、インスタンスが終了し、すべてのスタックが削除されます。これは、アカウントをクリーンアップする最後のステップとして不要になったリソースに使用する必要があります。

注記

cleanup コマンドを実行する前に、新しいセットアップを数日間実行することをお勧めします。これにより、スタックから必要な設定を必要に応じて簡単に利用できるようになります。

制限

Detach In Place ツールの主な目的は、OpsWorks スタックインスタンスを安全にデタッチすることです。このセクションでは、 ツールの制限事項を要約します。

  • Windows SSM Agent – SSM Agent がインスタンスにインストールされていない場合は、手動でインストールする必要があります。エージェントを最新バージョンに更新しない場合も同様です。

  • Time/Load Auto Scaling インスタンス – デタッチツールは、Auto Scaling が有効になっているインスタンスをサポートしていません。デタッチするインスタンスで Auto Scaling を無効にする必要があります。

  • アクセス許可 – デタッチツールは、OpsWorks コンソールのアクセス許可ページで指定された IAM エンティティを作成または生成しません。

  • アプリ – デタッチツールは、OpsWorks の外部でアプリを作成または生成しません。

入門

ステップ 1: 前提条件が満たされていることを確認する

Detach In Place ツールの 3 つのコマンドはすべて Python スクリプトであり、ローカル、EC2 インスタンス、または を使用して実行できますAWS CloudShell。

AWS CloudShell はブラウザベースのシェルで、一般的なツール ( AWS CLI や Python など) がプリインストールされている selected AWS リージョン. AWS CloudShell comes のリソースに AWS コマンドラインでアクセスできます。を使用する場合は AWS CloudShell、コンソールへのサインインに使用するのと同じ認証情報を使用します。

このチュートリアルでは、 を使用していることを前提としています AWS CloudShell。

ステップ 2: スクリプトをダウンロードする

  1. 次のコマンドを実行して、移行スクリプトとすべての関連ファイルを含む zip ファイルをダウンロードします。

    aws s3api get-object \
--bucket detach-in-place-bucket-prod-us-east-1 \
--key detach_in_place_script.zip detach_in_place_script.zip

  2. 次のコマンドを実行してファイルを解凍します。

    unzip detach_in_place_script.zip

    ファイルを解凍すると、次のファイルを使用できます。

    • README.md

    • LICENSE

    • NOTICE

    • requirements.txt

    • TODO.py

  3. 必要に応じて、次のコマンドpipenvを実行して をインストールします。

    pip install pipenv

ステップ 3: スクリプトを実行する

まず、次のコマンドを実行してスクリプトを実行できるように環境を設定します。

pipenv install -r requirements.txt
pipenv shell

次に、スクリプトパラメータを確認します。

コマンド パラメータ 説明 タイプ 必須 [Default] (デフォルト)

handle-prerequisites

--layer-id

デタッチするレイヤーの ID。

String

はい

-

--region

OpsWorks スタックのリージョン。OpsWorks スタック Region と API エンドポイント Region が異なる場合は、スタック Region を使用してください。これは、OpsWorks スタックの他のリソース部分 (EC2 インスタンスやサブネットなど) と同じ Region です。

String

いいえ

us-east-1

detach

--layer-id

デタッチするレイヤーの ID。

String

はい

-

--batch-size

レイヤーからデタッチするインスタンスの数 (5 など）。

String

いいえ

-

--region

OpsWorks スタックのリージョン。OpsWorks スタック Region と API エンドポイント Region が異なる場合は、スタック Region を使用してください。これは、OpsWorks スタックの他のリソース部分 (EC2 インスタンスやサブネットなど) と同じ Region です。

String

いいえ

us-east-1

cleanup

--stack-id

削除するスタックの ID。

String

いいえ

相互に排他的に、レイヤー ID またはスタック ID のいずれかを指定する必要があります

--layer-id

削除するレイヤーの ID

String

いいえ

--region

OpsWorks スタックのリージョン。OpsWorks スタック Region と API エンドポイント Region が異なる場合は、スタック Region を使用してください。これは、OpsWorks スタックの他のリソース部分 (EC2 インスタンスやサブネットなど) と同じ Region です。

String

いいえ

us-east-1

、、 handle-prerequisites cleanup コマンドで使用可能なオプションを確認するにはdetach、次のように --helpオプションを指定してコマンドを実行します。

python3 layer_detacher.py detach --help
python3 layer_detacher.py handle-prerequisites --help
python3 layer_detacher.py cleanup --help

これで、開始する準備が整いました。次の例は、さまざまなユースケースでコマンドを実行する方法を示しています。

例 1: レイヤーがすべての前提条件を満たし、デタッチの対象であるかどうかを確認する

次のコマンドは、OpsWorks レイヤー (およびそのレイヤーに含まれるインスタンス) に関する情報を読み取り、以下の前提条件が満たされているかどうかを確認します。

  • すべてのインスタンスはオンラインです。

  • Load/Time Auto Scaling インスタンスはありません。

  • すべてのインスタンスには最新の OpsWorks エージェントがあります。

  • すべてのインスタンスには、最新の SSM Agent がインストールされ、設定されています。

  • すべてのインスタンスには SSH キーペアがあります。

  • すべてのインスタンスは 1 つのレイヤーに属します。

python3 layer_detacher.py handle-prerequisites \
--layer-id opsworks-layer-id \
--region opsworks-stack-region

例 2: レイヤーのすべてのインスタンスをデタッチする

次のコマンドは、レイヤーのすべてのインスタンスを反復処理し、インスタンスが前提条件を満たしているかどうかを確認し、前提条件を満たすすべてのインスタンスを並行してデタッチしようとします。1 つ以上の前提条件が満たされない場合、コマンドは残りの非準拠インスタンスに強制デタッチオプションを提供します。

インスタンスをデタッチする前に、 コマンドは次の操作を行います。

  1. カスタム JSON を保存し、S3 にアップロードします。

  2. レイヤーの OpsWorks ライフサイクルイベントごとに SSM Automation ドキュメントを作成し、オートメーションドキュメントの実行ログを S3 にアップロードします。

  3. デタッチされるすべてのインスタンスに対して AppRegistry アプリケーションを作成します。アプリケーションには、デタッチされたすべてのインスタンスとリソースを保持するリソースグループが関連付けられています。リソースには、ライフサイクルイベントとカスタム Chef レシピに関する情報を保持する SSM Automation ドキュメントと SSM パラメータが含まれます。

  4. Classic Load Balancer が存在する場合は、レイヤーからデタッチします。

このコマンドは OpsWorks リソースのみを変更します。EC2 インスタンスのステータスは変わりません。

python3 layer_detacher.py detach \
--layer-id opsworks-layer-id \
--region opsworks-stack-region

例 3: レイヤーのすべてのインスタンスをバッチでデタッチする

次のコマンドは、前の例と同じ処理を行います。唯一の違いは、インスタンスをバッチでデタッチすることです。

このコマンドは OpsWorks リソースのみを変更します。EC2 インスタンスのステータスは変わりません。

python3 layer_detacher.py detach \
--layer-id opsworks-layer-id \
--region opsworks-stack-region \
--batch-size 5

例 4: レイヤーのすべてのリソースをクリーンアップし、レイヤーを削除する

次のコマンドは、レイヤーのすべてのリソースを反復処理して削除します。詳細については、OpsWorks と EC2 のすべてのインスタンスを停止および削除し、ロードバランサーをデタッチして、Amazon RDS インスタンス、Elastic IPsボリュームの登録を解除します。リソースをクリーンアップすると、レイヤーが削除されます。

このコマンドは、OpsWorks リソースと EC2 インスタンスを削除します。EC2 インスタンスをそのまま使用する場合は、 detach コマンドを使用する前に cleanup コマンドを使用します。これにより、cleanupコマンドは残りのリソースをすべて削除します。

python3 layer_detacher.py cleanup \
--layer-id opsworks-layer-id \
--region opsworks-stack-region

例 5: スタックのすべてのリソースをクリーンアップし、スタックを削除する

次のコマンドは、すべてのレイヤーを反復処理し、各レイヤーのリソースを反復処理します。レイヤーごとに、 コマンドは OpsWorks と EC2 のすべてのインスタンスを停止および削除し、ロードバランサーをデタッチして、Amazon RDS インスタンス、Elastic IPsボリュームを登録解除します。次に、 コマンドはレイヤーを削除します。このスタックに属するすべてのレイヤーで同じプロセスが実行されます。最後に、すべてのレイヤーが削除されると、スタックは削除されます。

このコマンドは、OpsWorks リソースと EC2 インスタンスを削除します。EC2 インスタンスをそのまま使用する場合は、 detach コマンドを使用する前に cleanup コマンドを使用します。これにより、cleanupコマンドは残りのリソースをすべて削除します。

python3 layer_detacher.py cleanup \
--stack-id opsworks-stack-id \
--region opsworks-stack-region

ステップ 4: OpsWorks からデタッチした後もリソースを運用し続ける

detach コマンドを実行すると、ツールはデタッチされたレイヤーに対応する新しい AWS Service Catalog AppRegistry アプリケーションを作成します。アプリケーション名は の形式に従いますlayer-name---layer-id。また、 OpsWorksLayerId タグを追加して、デタッチされたレイヤーに一致するアプリケーションを一意に識別します。

このアプリケーションに新しい AWS リソース (新しい EC2 インスタンスなど) を追加するには、次のいずれかを実行します。

  1. リソースに AppRegistry アプリケーションの一意のアプリケーションタグをタグ付けします。

    タグキー: awsApplication

    値: arn:aws:resource-groups:region:account-id:group/application-name/application-id>

  2. associate-resource コマンドを実行します。

さらに、AppRegistry アプリケーションごとにリソースグループが作成されます。リソースグループには、次のタグが含まれています。

タグキー 値

EnableAWSServiceCatalogAppRegistry

TRUE

aws:servicecatalog:applicationName

application-name

aws:servicecatalog:applicationId

application-id

aws:servicecatalog:applicationArn

arn:aws:servicecatalog:region:account-id:/applications/application-id

デタッチ後のタスクの実行

次の表は、デタッチ後にタスクを実行する方法に関する情報を示しています。

タスク 説明

ライフサイクルイベントの実行

detach コマンドを実行し、 オプションを選択した場合、スクリプトは 5 つの OpsWorks ライフサイクルイベントに一致する 5 つのオートメーションドキュメントを作成します。

各オートメーションドキュメントの名前は、 の形式に従いますlayer-id_lifecycle-event_automation_document。

Systems Manager で OpsWorks の動作をシミュレートするには、プロビジョニング、EC2 インスタンスの終了、レシピのデプロイ/削除時に自動化の実行を手動でトリガーする必要があります。

カスタム JSON の更新

スタックとレイヤーのカスタム JSON は、デタッチ時に指定された S3 バケット、または作成される新しい S3 バケットに保存されます。

JSON ファイルに保存されるファイル名は次のとおりです。

  • layercustomjson.json

  • stackcustomjson.json

ライフサイクルイベントの実行リストの変更

各ライフサイクルイベントの実行リストは、対応するオートメーションドキュメントで定義されます。実行リストを変更するには、AppRegistry アプリケーションでオートメーションドキュメントを検索し、 RunListパラメータを変更します。

自動化ドキュメントがトリガーする は OpsWorks と同じソースをサポートしているためAWS-ApplyChefRecipes、レシピとクックブックを更新するプロセスは変更されません。

自動ヒーリング/自動スケーリングの管理

インスタンスをデタッチすると、OpsWorks エージェントはアンインストールします。エージェントがないと、OpsWorks は異常なインスタンスを自動的に修復または置き換えることも、フリートを自動スケーリングすることもできません。自動スケーリングを続行し、失敗したインスタンスを置き換えるには、Amazon EC2 Auto Scaling グループを作成します。Amazon EC2 が置き換えが必要な異常なインスタンスを検出すると、グループは新しいインスタンスを起動して希望する容量を維持します。

Load Balancerの管理

レイヤーが Classic Load Balancer を使用している場合、detachコマンドはインスタンスの登録を解除する前にデタッチします。これは、デタッチの過程ですべての ELB インスタンスの関連付けが Amazon EC2 に保持され、ダウンタイムがゼロになるようにするために行われます。プロセスが完了すると、EC2 で ELB を管理できるようになります。

インスタンスへの接続

handle-prerequisites または detach コマンドを実行すると、次の 2 つのチェックが行われます。

  • SSM Agent のバージョンとアクセス許可

  • SSH キー

コマンドでは、SSM エージェントを更新し、必要なアクセス許可を追加して、Session Manager を使用してインスタンスに接続することもできます。SSH キーが存在する場合は、インスタンスに SSH 接続することもできます。

Systems Manager Application Manager Instances タブの使用

デタッチ後、Application Manager インスタンスタブでインスタンスを表示および管理できます。

インスタンスタブには、ステータス、ヘルス状態、最後のコマンドステータスなど、アプリケーションの EC2 インスタンスに関する集計情報が表示されます。このタブを使用すると、コマンド履歴、アラーム状態、Systems Manager エージェントの状態など、個々のインスタンスに関する詳細情報を表示できます。インスタンスタブには、Chef レシピの適用、インスタンスの起動または停止、Auto Scaling グループへのインスタンスの追加または削除など、さまざまなアクションも用意されています。