翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# よくある質問
以下の FAQ では、よく寄せられる質問に対する回答を示します。
**Topics**
+ [どの AWS OpsWorks Stacks バージョンを移行できますか?](#w2ab1c14c43c19b7)
+ [移行したインスタンスではどの Chef バージョンを使用できますか?](#w2ab1c14c43c19b9)
+ [どのリポジトリタイプを移行できますか?](#w2ab1c14c43c19c11)
+ [プライベート Git リポジトリを引き続き使用できますか?](#w2ab1c14c43c19c13)
+ [インスタンスへのアクセスにはどの SSH キーを使用できますか?](#w2ab1c14c43c19c15)
+ [インスタンスが自動的にスケールイン/スケールアウトされるのはなぜですか?](#w2ab1c14c43c19c17)
+ [自動スケーリングをオフにすることはできますか?](#w2ab1c14c43c19c19)
+ [起動した EC2 インスタンスでカーネルとパッケージの更新を実行できますか?](#w2ab1c14c43c19c21)
+ [インスタンスの EBS ボリュームにデータが含まれていないのはなぜですか?](#w2ab1c14c43c19c23)
+ [起動テンプレートに記載されている EBS ボリュームがマウントされないのはなぜですか?](#w2ab1c14c43c19c25)
+ [Chef レシピとマウント EBS ボリュームのログはどこにありますか?](#w2ab1c14c43c19c27)
+ [移行スクリプトのデバッグログはどこから入手できますか?](#w2ab1c14c43c19c29)
+ [移行スクリプトは CloudFormation テンプレートのバージョニングをサポートしていますか?](#w2ab1c14c43c19c31)
+ [複数の Layer を移行できますか?](#w2ab1c14c43c19c33)
+ [`SecureString` パラメータを作成するにはどうしたらよいですか?](#w2ab1c14c43c19c35)
+ [新しい Auto Scaling グループのインスタンスを終了イベントから保護する方法を教えてください。](#w2ab1c14c43c19c37)
+ [移行スクリプトではどのようなロードバランサーを利用できますか?](#w2ab1c14c43c19c39)
+ [カスタムクックブック設定レシピは移行されますか?](#w2ab1c14c43c19c41)
+ [新しく作成したインスタンスで、デプロイ、アンデプロイのレシピを実行できますか?](#w2ab1c14c43c19c43)
+ [Auto Scaling グループが対象とするサブネットを変更できますか?](#w2ab1c14c43c19c45)
## どの AWS OpsWorks Stacks バージョンを移行できますか?
Chef 11.10 と Chef 12、Amazon Linux、 Amazon Linux 2、Ubuntu、および Red Hat Enterprise Linux 7 のスタックのみを移行できます。
## 移行したインスタンスではどの Chef バージョンを使用できますか?
移行したインスタンスは Chef バージョン 11 ～ 14 を使用できます。
**注記**
Windows のスタックの移行はサポートされていません。
## どのリポジトリタイプを移行できますか?
S3、 Git、および HTTP のリポジトリタイプを移行できます。
## プライベート Git リポジトリを引き続き使用できますか?
はい、プライベート Git リポジトリを引き続き使用できます。
プライベート GitHub リポジトリを使用する場合は、SSH 用の新しい `Ed25519` ホストキーを作成する必要があります。これは、GitHub が SSH でサポートされるキーを変更し、暗号化されていない Git プロトコルを削除したためです。`Ed25519` ホストキーの詳細については、GitHub のブログ投稿 [「GitHub の Git プロトコルセキュリティの改善」](https://github.blog/2021-09-01-improving-git-protocol-security-github/) を参照してください。新しい `Ed25519` ホストキーを生成したら、この SSH キー用の Systems Manager `SecureString` パラメータを作成し、パラメータ名を `--repo-private-key` パラメータの値として使用します。Systems Manager `SecureString` パラメータの作成方法の詳細については、「AWS Systems Manager ユーザーガイド」の「[SecureString パラメータの作成 (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html#param-create-cli-securestring)」を参照してください。
その他の Git リポジトリタイプでは、この SSH キー用の Systems Manager `SecureString` パラメータを作成し、そのパラメータ名をスクリプトの `--repo-private-key` パラメータの値として使用します。
## インスタンスへのアクセスにはどの SSH キーを使用できますか?
スクリプトを実行すると、スクリプトはスタックに設定されている SSH キーとインスタンスを移行します。SSH キーを使用してインスタンスにアクセスできます。スタックとインスタンスに SSH キーが提供されている場合、スクリプトはスタックのキーを使用します。どの SSH キーを使用するべきかわからない場合は、EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) でインスタンスを確認してください。EC2 コンソールの **詳細** ページには、インスタンスの SSH キーが表示されます。
## インスタンスが自動的にスケールイン/スケールアウトされるのはなぜですか?
自動スケーリングは、Auto Scaling グループのスケールしているルールに基づいてインスタンスをスケールします。グループの [**最小**]、[**最大**]、[**必要な容量**] の値を設定できます。Auto Scaling グループは、これらの値を更新すると、それに応じて容量を自動的にスケールします。
## 自動スケーリングをオフにすることはできますか?
Auto Scaling グループの [**最小**]、[**最大**]、[**必要な容量**] の値を同じ数値に設定することで、自動スケーリングを無効にできます。たとえば、常に 10 個のインスタンスを用意したい場合は、[**最小**]、[**最大**]、[**必要な容量**] の値を 10 に設定します。
## 起動した EC2 インスタンスでカーネルとパッケージの更新を実行できますか?
デフォルトでは、EC2 インスタンスの起動時にカーネルとパッケージの更新が行われます。次の手順を使用して、起動した EC2 インスタンスでカーネルまたはパッケージの更新を実行します。例えば、デプロイまたは設定のレシピを実行した後に、更新を適用できます。
1. EC2 インスタンスに接続します。
1. 次の `perform_upgrade` 関数を作成し、インスタンスで実行します。
```
perform_upgrade() {
#!/bin/bash
if [ -e '/etc/system-release' ] || [ -e '/etc/redhat-release' ]; then
sudo yum -y update
elif [ -e '/etc/debian_version' ]; then
sudo apt-get update
sudo apt-get dist-upgrade -y
fi
}
perform_upgrade
```
1. カーネルとパッケージの更新後、EC2 インスタンスの再起動が必要な場合があります。再起動が必要かどうかを確認するには、次の `reboot_if_required` 関数を作成して EC2 インスタンスで実行します。
```
reboot_if_required () {
#!/bin/bash
if [ -e '/etc/debian_version' ]; then
if [ -f /var/run/reboot-required ]; then
echo "reboot is required"
else
echo "reboot is not required"
fi
elif [ -e '/etc/system-release' ] || [ -e '/etc/redhat-release' ]; then
export LC_CTYPE=en_US.UTF-8
export LC_ALL=en_US.UTF-8
LATEST_INSTALLED_KERNEL=`rpm -q --last kernel | perl -X -pe 's/^kernel-(\S+).*/$1/' | head -1`
CURRENTLY_USED_KERNEL=`uname -r`
if [ "${LATEST_INSTALLED_KERNEL}" != "${CURRENTLY_USED_KERNEL}" ];then
echo "reboot is required"
else
echo "reboot is not required"
fi
fi
}
reboot_if_required
```
1. `reboot_if_required` 実行結果が `reboot is required` メッセージに表示された場合は、EC2 インスタンスを再起動します。`reboot is not required` メッセージを受け取った場合、EC2 インスタンスを再起動する必要はありません。
## インスタンスの EBS ボリュームにデータが含まれていないのはなぜですか?
スクリプトを実行すると、スクリプトは EBS ボリュームの設定を移行し、 OpsWorks スタックと Layer の代替アーキテクチャを作成します。このスクリプトでは、実際のインスタンスやインスタンスに含まれるデータは移行されません。このスクリプトは、 EBS ボリュームの設定を Layer レベルで移行し、空の EBS ボリュームを起動した EC2 インスタンスにアタッチするだけです。
次の手順を実行して、以前のインスタンスの EBS ボリュームからデータを引き出します。
1. 以前のインスタンスの EBS ボリュームのスナップショットを取得します。スナップショットの作成の詳細については、Amazon EC2 ユーザーガイドの [「Amazon EBS スナップショットの作成」](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html)を参照してください。
1. スナップショットからボリュームを作成する スナップショットからボリュームを作成する方法の詳細については、Amazon EC2 ユーザーガイドの「[スナップショットからボリュームを作成する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-volume.html#ebs-create-volume-from-snapshot)」を参照してください。
1. 作成したボリュームをインスタンスにアタッチします。詳細については、Amazon EC2 ユーザーガイドの「[インスタンスへの Amazon EBS ボリュームのアタッチ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-attaching-volume.html)」を参照してください。
## 起動テンプレートに記載されている EBS ボリュームがマウントされないのはなぜですか?
EBS ボリュームの `--launch-template` パラメータに起動テンプレート ID を指定すると、スクリプトは EBS ボリュームをアタッチしますが、ボリュームはマウントしません。起動した EC2 インスタンス用にスクリプトが作成した `MountEBSVolumes` RunCommand ドキュメントを実行することで、アタッチされた EBS ボリュームをマウントできます。
`--launch-template` パラメータを設定しない場合、スクリプトはテンプレートを作成し、Auto Scaling グループが新しい EC2 インスタンスを起動すると、Auto Scaling グループは自動的に EBS ボリュームをアタッチし、アタッチされたボリュームを Layer 設定で設定されたマウントポイントにマウントする `SetupAutomation` コマンドを実行します。
## Chef レシピとマウント EBS ボリュームのログはどこにありますか?
OpsWorks は、`--command-logs-bucket` パラメータに値を指定することで指定できる S3 バケットにログを配信します。デフォルトの S3 バケット名の形式は、`aws-opsworks-stacks-application-manager-logs-account-id` です。Chef レシピログは `ApplyChefRecipes` プレフィックスに保存されます。マウント EBS ボリュームログは `MountEBSVolumes` プレフィックスに保存されます。スタックから移行されるすべてのレイヤーは、同じ S3 バケットにログを配信します。
**注記**
S3 バケットのライフサイクル設定には、30 日後にログを削除するルールが含まれています。30 日以上ログを保持する場合は、 S3 バケットのライフサイクル設定のルールを更新する必要があります。
現在、OpsWorks はシェフ `setup` と `terminate` レシピのみをログに記録します。
## 移行スクリプトのデバッグログはどこから入手できますか?
このスクリプトは、`aws-opsworks-stacks-transition-logs-account-id` という名前のバケットにデバッグログを格納します。デバッグログは、S3 バケットの `migration_script` フォルダーで、移行した Layer の名前と一致するフォルダーにあります。
## 移行スクリプトは CloudFormation テンプレートのバージョニングをサポートしていますか?
このスクリプトは、移行したいレイヤーまたはスタックの代替を作成する CloudFormation タイプの Systems Manager ドキュメントを生成します。同じパラメーターを使用してスクリプトを再実行すると、以前にエクスポートされたレイヤーテンプレートの新しいバージョンがエクスポートされます。テンプレートバージョンは、スクリプトログと同じ S3 バケットに保存されます。
## 複数の Layer を移行できますか?
スクリプトの `--layer-id` パラメーターは一つのレイヤーに渡されます。複数のレイヤーを移行するには、異なる `--layer-id` でスクリプトを再実行して渡します。
同じ OpsWorks スタックの一部であるレイヤーは、アプリケーションマネージャーの同じアプリケーションの下に一覧表示されます。
1. Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、[**Application Manager**] を選択します。
1. [**アプリケーション**] セクションで、[**カスタムアプリケーション**] を選択します。
1. アプリケーションを選択します。アプリケーション名は `app-stack-name-first-six-characters-stack-id` で始まります。
1. アプリで始まる最上位の要素には、OpsWorks スタックに対応するすべてのコンポーネントが表示されます。これには、OpsWorks レイヤーに対応するコンポーネントが含まれます。
1. レイヤーに対応するコンポーネントを選択すると、そのレイヤーのリソースが表示されます。OpsWorks レイヤーを表すコンポーネントは、「**カスタムアプリケーション**」セクションからも個別のアプリケーションとして表示されます。
## `SecureString` パラメータを作成するにはどうしたらよいですか?
Systems Manager を使用して `SecureString` パラメータを作成できます。Systems Manager `SecureString`パラメータの作成方法の詳細については、AWS Systems Manager 「ユーザーガイド」の[「SecureString パラメータ（AWS CLI）の作成)」](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html#param-create-cli-securestring)または[「Systems Manager パラメータ(コンソール)を作成する」](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html)を参照してください。
`SecureString`、`--http-username`、`--http-password`または `--repo-private-key` パラメータの値としてパラメータを指定する必要があります。
## 新しい Auto Scaling グループのインスタンスを終了イベントから保護する方法を教えてください。
`TRUE` に `--enable-instance-protection` パラメータを設定し、`protected_instance` タグキーを終了イベントから保護したい各 EC2 インスタンスに追加することでインスタンスを保護できます。`--enable-instance-protection` パラメータを `TRUE` に設定して `protected_instance` タグキーを追加すると、スクリプトは新しい Auto Scaling グループにカスタム終了ポリシーを追加し、`ReplaceUnhealthy` プロセスを中断します。`protected_instance` タグキーが付いたインスタンスは、以下の終了イベントから保護されます。
+ スケールインイベント
+ インスタンスの更新
+ リバランシング
+ インスタンスの最大存続期間
+ インスタンスの終了の一覧表示
+ 異常のあるインスタンスの終了と交換
**注記**
保護するインスタンスには `protected_instance` タグキーを設定する必要があります。タグキーでは大文字と小文字が区別されます。そのタグキーを持つインスタンスは、タグ値に関係なく保護されます。
カスタム終了ポリシーの実行時間を短縮するには、`default_sample_size` 関数コード変数の値を更新することで、Lambda 関数が保護対象インスタンスのフィルタリングに使用するデフォルトのインスタンス数を増やすことができます。デフォルト値は 15 です。`default_sample_size` を増やすと、Lambda 関数に割り当てられるメモリを増やす必要が生じる場合があります。これにより、Lambda 関数のコストが増加します。 AWS Lambda の料金については、「[AWS Lambda の料金](https://aws.amazon.com/)」を参照してください。
## 移行スクリプトではどのようなロードバランサーを利用できますか?
このスクリプトには三つのロードバランサーオプションがあります。
+ (推奨) 新しいApplication Load Balancer を作成します。デフォルトでは、スクリプトは新しいApplication Load Balancer を作成します。`--lb-type`パラメータを`ALB`にも設定できます。Application Load Balancers 詳細については、「Elastic Load Balancing ユーザーガイド」の [「Application Load Balancer とは？」](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)を参照してください。
+ Application Load Balancer がオプションでない場合は、`--lb-type` パラメータを `Classic` に設定してClassic Load Balancer を作成します。このオプションを選択した場合、OpsWorks Layer にアタッチされた既存の Classic Load Balancer はアプリケーションとは別に保持されます。Application Load Balancer の詳細については、Elastic Load Balancing：Classic Load Balancer ユーザーガイドの[「Classic Load Balancerとは？」](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/introduction.html)を参照してください 。
+ `--lb-type` パラメーターを `None` に設定することで、既存のロードバランサーをアタッチできます。
**重要**
AWS OpsWorks スタックのレイヤーに対して新しい Elastic Load Balancing ロードバランサーを作成することをお勧めします。既存の Elastic Load Balancing ロードバランサーを使用する場合は、まず、他の目的で使用されておらず、インスタンスがアタッチされていないことを確認する必要があります。ロードバランサーがレイヤーにアタッチされた後、OpsWorks は既存のインスタンスをすべて削除して、レイヤーのインスタンスのみを処理するようにロードバランサーを設定します。レイヤーにアタッチした後でロードバランサーの設定を Elastic Load Balancing コンソールまたは API を使用して変更することは技術的には可能ですが、そうしないでください。この変更は永続的ではないためです。
**既存の OpsWorks レイヤーロードバランサーを Auto Scaling グループに接続するには**
1. `--lb-type` パラメーターを `None` に設定して移行スクリプトを実行します。値を `None` に設定すると、スクリプトはロードバランサーを複製したり作成したりしません。
1. スクリプトが CloudFormation スタックをデプロイしたら、Auto Scaling グループ `Min` `Max` と `Desired capacity` 値を更新し、アプリケーションをテストします。
1. スクリプトの出力に表示されている `Link to the template` を選択します。ターミナルを閉じた場合は、次の手順を実行してテンプレートにアクセスしてください。
1. Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、[**Application Manager**] を選択します。
1. 「**CloudFormation スタック**」を選択し、「**テンプレートライブラリ**」を選択します。
1. 「**Owned by me**」を選択し、テンプレートを探します。
1. CloudFormation テンプレートから、**アクション**メニューから「**編集**」を選択します。
1. CloudFormation テンプレートの `ApplicationAsg` リソースセクション内の `LabelBalancerNames` プロパティを更新します。
```
ApplicationAsg:
DependsOn: CustomTerminationLambdaPermission
Properties:
#(other properties in ApplicationAsg to remain unchanged)
LoadBalancerNames:
- load-balancer-name
HealthCheckType: ELB
```
1. Auto Scaling グループインスタンスのヘルスチェックにロードバランサーのヘルスチェックも使用させたい場合は、`HealthCheckType` 以下のセクションを削除して`ELB`を入力してください。EC2 ヘルスチェックのみが必要な場合は、テンプレートを変更する必要はありません。
1. 変更内容を保存します。保存すると、新しいデフォルトバージョンのテンプレートが作成されます。レイヤーのスクリプトを初めて実行し、コンソールに変更を初めて保存した場合、新しいバージョンは 2 です。
1. [**アクション**] から [**プロビジョニングスタック**] を選択します。
1. テンプレートのデフォルトバージョンを使用することを確認します。必ず「**既存のスタックを選択**」を選択し、更新する CloudFormation スタックを選択してください。
1. 「**レビューとプロビジョニング**」ページが表示されるまで、以降の各ページで [**次へ**] を選択します。**レビューとプロビジョニング**ページで、 **がカスタム名で IAM リソースを作成する AWS CloudFormation 可能性があること**と、**選択したテンプレートの変更によって既存の AWS リソースが AWS CloudFormation 更新または削除される可能性があることの両方を選択します。**
1. [**Provision stack]** (スタックのプロビジョニング) を選択します。
更新をロールバックする必要がある場合は、次の手順を実行します。
1. [**アクション**] を選択してから、**スタックのプロビジョニング** を選択します。
1. [**既存のバージョンの一つを選択**] を選択し、次に以前のテンプレートバージョンを選択します。
1. **既存スタックの選択**を選択し、更新するCloudFormation スタックを選択します。
## カスタムクックブック設定レシピは移行されますか?
Configure カスタムクックブックをセットアップイベント中に実行することはサポートされていません。このスクリプトは、カスタムクックブックの設定レシピを移行し、お客様に代わって Systems Manager 自動化ランブックを作成します。しかし、レシピを手動で実行する必要があります。
設定レシピを実行するには、次のステップに従います。
1. Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、[**Application Manager**] を選択します。
1. [**アプリケーション**] セクションで、[**カスタムアプリケーション**] を選択します。
1. アプリケーションを選択します。アプリケーション名は `app-stack-name` で始まります。
1. 「**リソース**」を選択し、次に「設定ランブック ****」を選択します。
1. **[オートメーションを実行]** を選択します。
1. 設定レシピを実行するインスタンス ID を選択し、**実行** を選択します。
## 新しく作成したインスタンスで、デプロイ、アンデプロイのレシピを実行できますか?
このスクリプトでは、Layer の設定に応じて 3 つの自動化ランブックを作成できます。
+ セットアップ
+ 構成する
+ 終了
このスクリプトでは、`AWS-ApplyChefRecipes Run Command` ドキュメントの入力値を含む次の Systems Manager パラメータを作成することもできます。
+ セットアップ
+ デプロイ
+ 構成する
+ Undeploy
+ 終了
スケールアウトイベントが発生すると、セットアップオートメーションランブックが自動的に実行されます。これには、元の OpsWorks Layer からのカスタムクックブックレシピの設定とデプロイが含まれます。スケールインイベントが発生すると、ターミナルのオートメーションランブックが自動的に実行されます。ターミナルオートメーションランブックには、元の OpsWorks Layer のシャットダウンレシピが含まれています。
レシピを手動で実行、アンデプロイ、または設定する場合は、次の手順を実行します。
1. Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、[**Application Manager**] を選択します。
1. [**アプリケーション**] セクションで、[**カスタムアプリケーション**] を選択します。
1. アプリケーションを選択します。アプリケーション名は `app-stack-name-first-six-characters-stack-id` で始まります。Application Manager の [**概要**] タブが開きます。
1. [**リソース**] を選択し、次に自動化ランブックの設定を選択します。
1. **[オートメーションを実行]** を選択します。
1. `applyChefRecipesPropertiesParameter` オートメーションランブックの入力パラメータについては、正しい Systems Manager パラメータを参照してください。Systems Manager パラメータ名は*event* の値が`Configure` という `/ApplyChefRecipes-Preset/OpsWorks-stack-name-OpsWorks-layer-name-first-six-characters-stack-id/event`、または、`Deploy`、実行したいレシピに応じている `Undeploy` という形式に従います。
1. レシピを実行するインスタンス ID を選択し、**実行** を選択します。
## Auto Scaling グループが対象とするサブネットを変更できますか?
デフォルトでは、Auto Scaling グループは OpsWorks スタック VPC 内のすべてのサブネットに適用されます。スパンのサブネットを更新するには、次の手順に従います。
1. スクリプトの出力に表示されている `Link to the template` を選択します。ターミナルを閉じた場合は、次の手順を実行してテンプレートにアクセスしてください。
1. Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、[**Application Manager**] を選択します。
1. 「**CloudFormation スタック**」を選択し、「**テンプレートライブラリ**」を選択します。
1. 「**Owned by me**」を選択し、テンプレートを探します。
1. 「**アクション**」から「**プロビジョニングスタック**」を選択します。
1. デフォルトのテンプレートを使用することを確認します。**既存スタックの選択**を選択し、更新するCloudFormation スタックを選択します。
**注記**
`--provision-application` パラメータを `FALSE` に設定してスクリプトを実行した場合は、新しい CloudFormation スタックを作成する必要があります。
1. `SubnetIDs` パラメータには、Auto Scaling グループが対象とするサブネット ID をカンマで区切ったリストを指定します。
1. 「**レビューとプロビジョニング**」ページが表示されるまで 「**次へ**」を選択します。
1. **レビューとプロビジョニング**ページで、 **がカスタム名で IAM リソースを作成する CloudFormation 可能性があることを承認**し、**選択したテンプレートの変更により CloudFormation が既存の AWS リソースを更新または削除する可能性があることを理解**します。
1. [**Provision stack]** (スタックのプロビジョニング) を選択します。