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 カタログを作成し、レイヤーから Elastic Load Balancing (ELB) ロードバランサーをデタッチします OpsWorks。

  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 など) がプリインストールされている選択した 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

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

Command パラメータ 説明 タイプ 必須 デフォルト

handle-prerequisites

--layer-id

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

文字列

あり

-

--region

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

文字列

なし

us-east-1

detach

--layer-id

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

文字列

あり

-

--batch-size

レイヤーからデタッチするインスタンスの数 (例: 5)。

文字列

なし

-

--region

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

文字列

なし

us-east-1

cleanup

--stack-id

削除するスタックの ID。

文字列

なし

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

--layer-id

削除するレイヤーの ID

文字列

なし

--region

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

文字列

なし

us-east-1

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

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 エージェントがインストールされ、設定されています。

  • すべてのインスタンスには 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: レイヤーのすべてのリソースをクリーンアップし、レイヤーを削除する

次のコマンドは、レイヤーのすべてのリソースを反復処理して削除します。より詳細には、 および EC2 内のすべてのインスタンスを停止および削除 OpsWorks し、ロードバランサーをデタッチして、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: スタックのすべてのリソースをクリーンアップしてスタックを削除する

次のコマンドは、すべてのレイヤーを反復処理し、各レイヤーのリソースを反復処理します。レイヤーごとに、 コマンドは および EC2 内のすべてのインスタンスを停止および削除 OpsWorks し、ロードバランサーをデタッチし、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パラメータを変更します。

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

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

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

Load Balancer の管理

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

インスタンスへの接続

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

  • SSM エージェントのバージョンとアクセス許可

  • SSH キー

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

Systems Manager Application Manager インスタンス タブの使用

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

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