翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# OpsWorks for Puppet Enterprise のトラブルシューティング
**重要**
この AWS OpsWorks for Puppet Enterprise サービスは 2024 年 3 月 31 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
このトピックでは、OpsWorks for Puppet Enterprise に関する一般的な問題と、それらの問題について推奨される解決方法を示します。
**Topics**
+ [一般的なトラブルシューティングのヒント](#w2ab1b7c45b9)
+ [特定のエラーのトラブルシューティング](#tshooterrors-puppet)
+ [その他のヘルプとサポート](#tshooterrors-puppet-support)
## 一般的なトラブルシューティングのヒント
Puppet マスターを作成または操作できない場合は、エラーメッセージやログを表示すると、問題のトラブルシューティングに役立ちます。以下のタスクでは、Puppet マスターに関する問題のトラブルシューティングを行うときの一般的な開始点を示します。特定のエラーと解決方法については、このトピックの「[特定のエラーのトラブルシューティング](#tshooterrors-puppet)」セクションを参照してください。
+ Puppet マスターを起動できない場合は、OpsWorks for Puppet Enterprise コンソールを使用してエラーメッセージを表示します。Puppet マスターのプロパティページで、サーバーの起動と実行に関連するエラーメッセージが、ページの一番上に表示されます。エラーは CloudFormation、Puppet マスターの作成に使用される OpsWorks for Puppet Enterprise、または Amazon EC2 のサービスから発生する可能性があります。プロパティページでは、実行中のサーバーで発生するイベントを表示することもできます。これには、障害イベントメッセージが含まれる場合があります。
+ EC2 に関する問題を解決するため、SSH を使用してサーバーのインスタンスに接続してログを表示します。EC2 インスタンスのログは `/var/log/aws/opsworks-cm` ディレクトリに保存されています。これらのログでは、OpsWorks for Puppet Enterprise が Puppet マスターを起動中にコマンド出力が収集されます。
## 特定のエラーのトラブルシューティング
**Topics**
+ [サーバーの状態は **[接続が失われました]**](#tshooterrors-puppet-connection-lost)
+ [サーバーの作成が「リクエストされた設定は現在サポートされていません」というメッセージで失敗する](#w2ab1b7c45c11b6)
+ [サーバーの Amazon EC2 インスタンスが作成できない](#w2ab1b7c45c11b8)
+ [サービスロールのエラーによりサーバーを作成できない](#w2ab1b7c45c11c10)
+ [Elastic IP アドレスの制限を超えた](#w2ab1b7c45c11c12)
+ [ノードの自動関連付けに失敗する](#w2ab1b7c45c11c14)
+ [システムメンテナンスの失敗](#tshooterrors-puppet-maintenance-fails)
### サーバーの状態は **[接続が失われました]**
**問題:** サーバーのステータスに**[接続が失われました]**と表示される。
**原因:** これは、 の外部のエンティティが OpsWorks for Puppet Enterprise サーバーまたはそのサポートリソースに変更 OpsWorks を加えた場合に最もよく発生します。 は**、Connection lost** 状態の Puppet Enterprise サーバーに接続して、バックアップの作成、オペレーティングシステムパッチの適用、Puppet の更新などのメンテナンスタスクを処理 OpsWorks できません。その結果、サーバーが重要なアップデートを見逃したり、セキュリティ上の問題の影響を受けやすくなったり、またはその他の理由で期待どおりに動作しない可能性があります。
**解決策:** 次の手順を試して、サーバーの接続を復元してください。
1. サービスロールに必要な権限がすべてあることを確認してください。
1. サーバーの「**設定**」ページの「**ネットワークとセキュリティ**」で、サーバーが使用しているサービスロールへのリンクを選択します。これにより、 IAM コンソールに表示されるサービスロールが開きます。
1. 「**アクセス許可**」のタブで、`AWSOpsWorksCMServiceRole` が「**アクセス許可ポリシー**」リストに含まれていることを確認します。リストにない場合は、`AWSOpsWorksCMServiceRole` 管理ポリシーをロールに手動で追加してください。
1. 「**信頼関係**」のタブで、ユーザーに代わって役割を引き受ける `opsworks-cm.amazonaws.com` サービスを信頼する信頼ポリシーがサービスロールに含まれていることを確認します。ロールで信頼ポリシーを使用する方法の詳細については、[「ロールの変更 (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html)」または AWS 「セキュリティブログ記事」の[「IAM ロールで信頼ポリシーを使用する方法](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)」を参照してください。
1. インスタンスプロファイルに必要な権限がすべてあることを確認してください。
1. サーバーの「**設定**」ページの「**ネットワークとセキュリティ**」で、サーバーが使用しているインスタンスプロファイルへのリンクを選択します。これにより、 IAM コンソールに表示されるインスタンスプロファイルが開きます。
1. 「**権限**」のタブで、`AmazonEC2RoleforSSM` と `AWSOpsWorksCMInstanceProfileRole` が両方とも「**アクセス権限ポリシー**」リストに含まれていることを確認します。一方または両方がリストにない場合は、これらの管理ポリシーを手動でロールに追加してください。
1. 「**信頼関係**」のタブで、ユーザーに代わって役割を引き受ける `ec2.amazonaws.com` サービスを信頼する信頼ポリシーがサービスロールに含まれていることを確認します。ロールで信頼ポリシーを使用する方法の詳細については、[「ロールの変更 (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html)」または AWS 「セキュリティブログ記事」の[「IAM ロールで信頼ポリシーを使用する方法](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)」を参照してください。
1. Amazon EC2 コンソールで、OpsWorks for Puppet Enterprise サーバーのリージョンと同じリージョンにいることを確認し、サーバーが使用している EC2 インスタンスを再起動します。
1. `aws-opsworks-cm-instance-`*server-name* という名前の EC2 インスタンスを選択します。
1. [**インスタンスの状態**]メニューで、[**インスタンスの再起動**] を選択します。
1. サーバーが再起動して完全にオンラインになるまで最大 15 分かかります。
1. OpsWorks for Puppet Enterprise コンソールのサーバー詳細ページで、サーバーのステータスが **[正常]** であることを確認します。
上記の手順を実行してもサーバーステータスが **[接続が失われました]** のままの場合は、次のいずれかを試してください。
+ [新しいサーバーを作成し](gettingstarted-opspup-create.md)、[元のサーバーを削除して](opspup-delete-server.md)、サーバーを交換してください。現在のサーバー上のデータが重要な場合は、[最新のバックアップからサーバーを復元し](opspup-restore.md)、[元の応答しないサーバーを削除する前に](opspup-delete-server.md) データが最新であることを確認してください。
+ [AWS Support](#tshooterrors-puppet-support)にお問い合わせください。
### サーバーの作成が「リクエストされた設定は現在サポートされていません」というメッセージで失敗する
**問題:** Puppet Enterprise サーバーの作成を試みているが、「リクエストされた設定は現在サポートされていません。サポートされている設定についてドキュメントをご確認ください」のようなエラーメッセージでサーバーの作成が失敗する。
**原因:** Puppet マスターに対してサポートされていないインスタンスタイプが指定された可能性があります。[ハードウェア専有インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html)用など、デフォルトでないテナンシーを持つ VPC で Puppet サーバーの作成を選択した場合、指定された VPC 内のすべてのインスタンスも、専有テナンシーまたはホストテナンシーのインスタンスである必要があります。t2 など一部のインスタンスタイプはデフォルトテナンシーでしか使用できないため、Puppet マスターインスタンスタイプは指定された VPC でサポート可能でない場合があり、そのためにサーバーの作成が失敗します。
**解決策:** デフォルト以外のテナンシーを持つ VPC を選択した場合は、専用テナンシーをサポートできる m4 インスタンスタイプを使用します。
### サーバーの Amazon EC2 インスタンスが作成できない
**問題:** サーバーの作成が、次のようなエラーメッセージにより失敗する。「The following resource(s) failed to create: [EC2Instance]。Failed to receive 1 resource signal(s) within the specified duration」
**原因:** この問題のほとんどが、EC2 インスタンスでネットワークアクセスが可能でないことが原因です。
**解決策:** インスタンスにアウトバウンドインターネットアクセスがあり、 AWS サービスエージェントがコマンドを発行できることを確認します。VPC (単一のパブリックサブネットを持つ VPC) で **DNS 解決** が有効になっていて、サブネットで **[パブリック IP の自動割り当て] **設定が有効になっていることを確認します。
### サービスロールのエラーによりサーバーを作成できない
**問題:**「Not authorized to perform sts:AssumeRole.」という状態を示すエラーメッセージが表示され、サーバーを作成できない。
**原因:** お使いのサービスロールに新しいサーバーを作成するための適切なアクセス権限がない場合に、この問題が発生する可能性があります。
**解決策:** OpsWorks for Puppet Enterprise コンソールを開きます。コンソールを使用して新しいサービスロールとインスタンスプロファイルロールを生成します。独自のサービスロールの使用を希望する場合は、**AWSOpsWorksCMServiceRole** ポリシーをロールにアタッチします。**opsworks-cm.amazonaws.com** がロールの **信頼関係** のサービス間でリストされていることを確認します。Puppet マスターに関連付けられているサービスロールに、**AWSOpsWorksCMServerRole** 管理ポリシーがアタッチされていることを確認します。
### Elastic IP アドレスの制限を超えた
**問題:**「The following resource(s) failed to create: [EIP, EC2Instance]。Resource creation cancelled, the maximum number of addresses has been reached.」という状態を示すエラーメッセージにより、サーバーを作成できない。
**原因:** アカウントで Elastic IP (EIP) アドレスの最大数を使用した場合に、この問題が発生します。EIP アドレスのデフォルトの制限は 5 です。
**解決策:** 既存の EIP アドレスを解放するか、アカウントがアクティブに使用していない EIP アドレスを削除するか、 AWS カスタマーサポートに連絡して、アカウントに関連付けられている EIP アドレスの制限を増やすことができます。
### ノードの自動関連付けに失敗する
**問題:** 新しい Amazon EC2 ノードの自動 (無人) 関連付けに失敗する。Puppet マスターに追加されたノードが Puppet Enterprise ダッシュボードに表示されない。
**原因:** `opsworks-cm` API コールで新しい EC2 インスタンスとの通信を許可するインスタンスプロファイルとして IAM ロールをセットアップしていない場合に、この問題が発生する可能性があります。
**解決策:** [OpsWorks for Puppet Enterprise でのノードを自動的に追加します](opspup-unattend-assoc.md) で説明したように、EC2 インスタンスのプロファイルにポリシーをアタッチして、`AssociateNode` と `DescribeNodeAssociationStatus` の API コールを EC2 と連携できるようにします。
### システムメンテナンスの失敗
AWS OpsWorks CM は毎週システムメンテナンスを実行し、セキュリティ更新プログラムを含む Puppet Server AWSの最新バージョンが常に OpsWorks for Puppet Enterprise サーバーで実行されていることを確認します。何らかの理由でシステムメンテナンスが失敗した場合、 は失敗 AWS OpsWorks CM を通知します。システムメンテナンスの詳細については、「[OpsWorks for Puppet Enterprise のシステムメンテナンス](opspup-maintenance.md)」を参照してください。
このセクションでは、考えられる障害の原因を説明し、解決策を提案します。
**Topics**
+ [サービスロールまたはインスタンスプロファイルのエラーによって、システムのメンテナンスが妨げられる](#w2ab1b7c45c11c16b8)
#### サービスロールまたはインスタンスプロファイルのエラーによって、システムのメンテナンスが妨げられる
**問題:** システムメンテナンスが失敗し、「STS: AssumeRole を実行する権限がありません」というエラーメッセージ、または権限に関する同様のエラーメッセージが表示されます。
**原因:** これは、使用しているサービスロールまたはインスタンスプロファイルのいずれかに、サーバー上でシステムメンテナンスを実行するための適切な権限がない場合に発生する可能性があります。
**解決策:** サービスロールとインスタンスプロファイルに必要なすべての権限があることを確認してください。
1. サービスロールに必要な権限がすべてあることを確認してください。
1. サーバーの「**設定**」ページの「**ネットワークとセキュリティ**」で、サーバーが使用しているサービスロールへのリンクを選択します。これにより、 IAM コンソールに表示されるサービスロールが開きます。
1. 「**アクセス許可**」のタブで、`AWSOpsWorksCMServiceRole` がサービスロールにアタッチされていることを確認します。`AWSOpsWorksCMServiceRole` がリストにない場合は、このポリシーをロールに追加します。
1. **opsworks-cm.amazonaws.com** がロールの **信頼関係** のサービス間でリストされていることを確認します。ロールで信頼ポリシーを使用する方法の詳細については、[「ロールの変更 (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html)」または AWS 「セキュリティブログ記事」の[「IAM ロールで信頼ポリシーを使用する方法](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)」を参照してください。
1. インスタンスプロファイルに必要な権限がすべてあることを確認してください。
1. サーバーの「**設定**」ページの「**ネットワークとセキュリティ**」で、サーバーが使用しているインスタンスプロファイルへのリンクを選択します。これにより、 IAM コンソールに表示されるインスタンスプロファイルが開きます。
1. 「**権限**」のタブで、`AmazonEC2RoleforSSM` と `AWSOpsWorksCMInstanceProfileRole` が両方とも「**アクセス権限ポリシー**」リストに含まれていることを確認します。一方または両方がリストにない場合は、これらの管理ポリシーを手動でロールに追加してください。
1. 「**信頼関係**」のタブで、ユーザーに代わって役割を引き受ける `ec2.amazonaws.com` サービスを信頼する信頼ポリシーがサービスロールに含まれていることを確認します。ロールで信頼ポリシーを使用する方法の詳細については、[「ロールの変更 (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html)」または AWS 「セキュリティブログ記事」の[「IAM ロールで信頼ポリシーを使用する方法](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)」を参照してください。
## その他のヘルプとサポート
発生している特定の問題がこのトピックで説明されていないか、このトピックの提案を試しても問題が解決しない場合は、[OpsWorks フォーラム](https://forums.aws.amazon.com/forum.jspa?forumID=153&start=0)を参照してください。
また、[AWS Support Center](https://console.aws.amazon.com/support/home#/) を参照することもできます。 AWS サポートセンターは、 AWS サポートケースを作成および管理するためのハブです。 AWS サポートセンターには、フォーラム、技術的なFAQs、サービスのヘルスステータスなど、その他の役立つリソースへのリンクも含まれています AWS Trusted Advisor。