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

# AWS OpsWorks Stacks Detach in Place ツールの使用
<a name="using-stacks-detach-tool"></a>

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

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

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

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

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

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

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

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

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

## プロセスの仕組み
<a name="using-stacks-detach-tool-process"></a>

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

## 制限事項
<a name="using-stacks-detach-tool-limitations"></a>

Detach In Place ツールの主な目的は、OpsWorks スタックインスタンスを安全にデタッチすることです。このセクションでは、 ツールの制限事項を要約します。
+  **Windows SSM Agent** – SSM Agent がインスタンスにインストールされていない場合は、手動でインストールする必要があります。エージェントを最新バージョンに更新しない場合も同様です。
+ **Time/Load Auto Scaling インスタンス** – デタッチツールは、Auto Scaling が有効になっているインスタンスをサポートしていません。デタッチするインスタンスで Auto Scaling を無効にする必要があります。
+ アクセス**許可** – デタッチツールは、OpsWorks コンソールの**アクセス許可**ページで指定された IAM エンティティを作成または生成しません。
+ **アプリ** – デタッチツールは、OpsWorks の外部でアプリを作成または生成しません。

## 開始方法
<a name="using-stacks-detach-tool-gs"></a>

### ステップ 1: 前提条件が満たされていることを確認する
<a name="using-stacks-detach-tool-step1"></a>

Detach In Place ツールの 3 つのコマンドはすべて Python スクリプトであり、ローカル、EC2 インスタンス、または を使用して実行できます[AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html#how-to-get-started)。

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

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

### ステップ 2: スクリプトをダウンロードする
<a name="using-stacks-detach-tool-step2"></a>

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
   ```

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

   ```
   unzip detach_in_place_script.zip
   ```

   ファイルを解凍すると、次のファイルを使用できます。
   + README.md 
   + LICENSE
   + NOTICE
   + requirements.txt
   + TODO.py

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

   ```
   pip install pipenv
   ```

### ステップ 3: スクリプトを実行する
<a name="using-stacks-detach-tool-step3"></a>

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

```
pipenv install -r requirements.txt
pipenv shell
```

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

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/using-stacks-detach-tool.html)

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

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

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

**Topics**
+ [例 1: レイヤーがすべての前提条件を満たし、デタッチの対象かどうかを確認します。](#using-stacks-detach-tool-step3-ex1)
+ [例 2: レイヤーのすべてのインスタンスをデタッチする](#using-stacks-detach-tool-step3-ex2)
+ [例 3: レイヤーのすべてのインスタンスをバッチでデタッチする](#using-stacks-detach-tool-step3-ex3)
+ [例 4: レイヤーのすべてのリソースをクリーンアップし、レイヤーを削除する](#using-stacks-detach-tool-step3-ex4)
+ [例 5: スタックのすべてのリソースをクリーンアップし、スタックを削除する](#using-stacks-detach-tool-step3-ex5)

#### 例 1: レイヤーがすべての前提条件を満たし、デタッチの対象かどうかを確認します。
<a name="using-stacks-detach-tool-step3-ex1"></a>

次のコマンドは、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: レイヤーのすべてのインスタンスをデタッチする
<a name="using-stacks-detach-tool-step3-ex2"></a>

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

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

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

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

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

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

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

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

#### 例 3: レイヤーのすべてのインスタンスをバッチでデタッチする
<a name="using-stacks-detach-tool-step3-ex3"></a>

次のコマンドは、[前の例](#using-stacks-detach-tool-step3-ex2)と同じ操作を行います。唯一の違いは、インスタンスをバッチでデタッチすることです。

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

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

#### 例 4: レイヤーのすべてのリソースをクリーンアップし、レイヤーを削除する
<a name="using-stacks-detach-tool-step3-ex4"></a>

次のコマンドは、レイヤーのすべてのリソースを反復処理して削除します。より詳細には、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: スタックのすべてのリソースをクリーンアップし、スタックを削除する
<a name="using-stacks-detach-tool-step3-ex5"></a>

次のコマンドは、すべてのレイヤーを反復処理し、各レイヤーのリソースを反復処理します。レイヤーごとに、 コマンドは 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 からデタッチした後もリソースを運用し続ける
<a name="using-stacks-detach-tool-step4"></a>

`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>`

1. [https://docs.aws.amazon.com/cli/latest/reference/servicecatalog-appregistry/associate-resource.html](https://docs.aws.amazon.com/cli/latest/reference/servicecatalog-appregistry/associate-resource.html) コマンドを実行します。

さらに、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`  | 

#### デタッチ後のタスクの実行
<a name="using-stacks-detach-tool-step4-tasks"></a>

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


| タスク | 説明 | 
| --- | --- | 
|  ライフサイクルイベントの実行  |  `detach` コマンドを実行し、 オプションを選択した場合、スクリプトは 5 つの OpsWorks ライフサイクルイベントに一致する 5 つのオートメーションドキュメントを作成します。 各オートメーションドキュメントの名前は、 の形式に従います`layer-id_lifecycle-event_automation_document`。 Systems Manager で OpsWorks の動作をシミュレートするには、プロビジョニング、EC2 インスタンスの終了、レシピのデプロイ/削除時に自動化の実行を手動でトリガーする必要があります。  | 
|  カスタム JSON の更新  |  スタックとレイヤーのカスタム JSON は、デタッチ時に指定された S3 バケット、または作成される新しい S3 バケットに保存されます。 JSON ファイルに保存されているファイル名は次のとおりです。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/using-stacks-detach-tool.html)  | 
|  ライフサイクルイベントの実行リストの変更  |  各ライフサイクルイベントの実行リストは、対応するオートメーションドキュメントで定義されています。実行リストを変更するには、AppRegistry アプリケーションで Automation ドキュメントを検索し、 `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 つのチェックが発生します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/using-stacks-detach-tool.html) コマンドでは、SSM エージェントを更新し、必要なアクセス許可を追加して、Session Manager を使用してインスタンスに接続することもできます。SSH キーが存在する場合は、インスタンスに SSH することもできます。  | 

#### Systems Manager Application Manager インスタンスタブの使用
<a name="using-stacks-detach-tool-step4-instancetab"></a>

デタッチ後、Application Manager [インスタンスタブでインスタンス](https://docs.aws.amazon.com/systems-manager/latest/userguide/application-manager-working-instances.html)を表示および管理できます。

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