Puppet Enterprise OpsWorks のトラブルシューティング - AWS OpsWorks
一般的なトラブルシューティングのヒント特定のエラーのトラブルシューティングその他のヘルプとサポート

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

Puppet Enterprise OpsWorks のトラブルシューティング

重要

この AWS OpsWorks for Puppet Enterprise サービスは 2024 年 3 月 31 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、 AWS re:Post または AWS Premium Support を通じて AWS Support チームにお問い合わせください。

このトピックには、Puppet Enterprise OpsWorks の問題に関する一般的ないくつかの解決策と、それらの問題に対する推奨される解決策が含まれています。

一般的なトラブルシューティングのヒント

Puppet マスターを作成または操作できない場合は、エラーメッセージやログを表示すると、問題のトラブルシューティングに役立ちます。以下のタスクでは、Puppet マスターに関する問題のトラブルシューティングを行うときの一般的な開始点を示します。特定のエラーと解決方法については、このトピックの「特定のエラーのトラブルシューティング」セクションを参照してください。

  • OpsWorks Puppet マスターの起動に失敗した場合のエラーメッセージを表示するには、 for Puppet Enterprise コンソールを使用します。Puppet マスターのプロパティページで、サーバーの起動と実行に関連するエラーメッセージが、ページの一番上に表示されます。エラーは、Puppet Enterprise OpsWorks の場合は AWS CloudFormation、または Puppet マスターの作成に使用される Amazon EC2 のサービスから発生する可能性があります。プロパティページでは、実行中のサーバーで発生するイベントを表示することもできます。これには、障害イベントメッセージが含まれる場合があります。

  • EC2 に関する問題を解決するため、SSH を使用してサーバーのインスタンスに接続してログを表示します。EC2 インスタンスのログは /var/log/aws/opsworks-cm ディレクトリに保存されています。これらのログは OpsWorks 、 for Puppet Enterprise が Puppet マスターを起動している間にコマンド出力をキャプチャします。

特定のエラーのトラブルシューティング

サーバーの状態は [接続が失われました]

問題: サーバーのステータスに[接続が失われました]と表示される。

原因： これは、 以外のエンティティ AWS OpsWorks が OpsWorks for Puppet Enterprise サーバーまたはそのサポートリソースに変更を加えた場合に最もよく発生します。 は、接続が失われた状態の Puppet Enterprise サーバーに接続して、バックアップの作成、オペレーティングシステムパッチの適用、Puppet の更新などのメンテナンスタスクを処理する AWS OpsWorks ことはできません。その結果、サーバーが重要なアップデートを見逃したり、セキュリティ上の問題の影響を受けやすくなったり、またはその他の理由で期待どおりに動作しない可能性があります。

解決策: 次の手順を試して、サーバーの接続を復元してください。

  1. サービスロールに必要な権限がすべてあることを確認してください。

    1. サーバーの「設定」ページの「ネットワークとセキュリティ」で、サーバーが使用しているサービスロールへのリンクを選択します。これにより、 IAM コンソールに表示されるサービスロールが開きます。

    2. 「アクセス許可」のタブで、AWSOpsWorksCMServiceRole が「アクセス許可ポリシー」リストに含まれていることを確認します。リストにない場合は、AWSOpsWorksCMServiceRole 管理ポリシーをロールに手動で追加してください。

    3. 「信頼関係」のタブで、ユーザーに代わって役割を引き受ける opsworks-cm.amazonaws.com サービスを信頼する信頼ポリシーがサービスロールに含まれていることを確認します。ロールで信頼ポリシーを使用する方法の詳細については、「ロールの変更 (コンソール）」または AWS 「セキュリティブログ記事」の「IAM ロールで信頼ポリシーを使用する方法」を参照してください。

  2. インスタンスプロファイルに必要な権限がすべてあることを確認してください。

    1. サーバーの「設定」ページの「ネットワークとセキュリティ」で、サーバーが使用しているインスタンスプロファイルへのリンクを選択します。これにより、 IAM コンソールに表示されるインスタンスプロファイルが開きます。

    2. 「権限」のタブで、AmazonEC2RoleforSSM と AWSOpsWorksCMInstanceProfileRole が両方とも「アクセス権限ポリシー」リストに含まれていることを確認します。一方または両方がリストにない場合は、これらの管理ポリシーを手動でロールに追加してください。

    3. 「信頼関係」のタブで、ユーザーに代わって役割を引き受ける ec2.amazonaws.com サービスを信頼する信頼ポリシーがサービスロールに含まれていることを確認します。ロールで信頼ポリシーを使用する方法の詳細については、「ロールの変更 (コンソール）」または AWS 「セキュリティブログ記事」の「IAM ロールで信頼ポリシーを使用する方法」を参照してください。

  3. Amazon EC2 コンソールで、Puppet Enterprise OpsWorks サーバーの リージョンと同じリージョンにいることを確認し、サーバーが使用している EC2 インスタンスを再起動します。

    1. aws-opsworks-cm-instance-server-name という名前の EC2 インスタンスを選択します。

    2. [インスタンスの状態]メニューで、[インスタンスの再起動] を選択します。

    3. サーバーが再起動して完全にオンラインになるまで最大 15 分かかります。

  4. OpsWorks for Puppet Enterprise コンソールのサーバーの詳細ページで、サーバーのステータスが正常になったことを確認します。

上記の手順を実行してもサーバーステータスが [接続が失われました] のままの場合は、次のいずれかを試してください。

サーバーの作成が「リクエストされた設定は現在サポートされていません」というメッセージで失敗する

問題: Puppet Enterprise サーバーの作成を試みているが、「リクエストされた設定は現在サポートされていません。サポートされている設定についてドキュメントをご確認ください」のようなエラーメッセージでサーバーの作成が失敗する。

原因: Puppet マスターに対してサポートされていないインスタンスタイプが指定された可能性があります。ハードウェア専有インスタンス用など、デフォルトでないテナンシーを持つ 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 の自動割り当て] 設定が有効になっていることを確認します。

サービスロールのエラーによりサーバーを作成できない

問題： サーバーの作成が失敗し、「sts: を実行する権限がありません」というエラーメッセージが表示されるAssumeRole。

原因: お使いのサービスロールに新しいサーバーを作成するための適切なアクセス権限がない場合に、この問題が発生する可能性があります。

解決策： OpsWorks for Puppet Enterprise コンソールを開きます。コンソールを使用して、新しいサービスロールとインスタンスプロファイルロールを生成します。独自のサービスロールを使用する場合は、AWSOpsWorksCMServiceRoleポリシーをロールにアタッチします。opsworks-cm.amazonaws.com がロールの 信頼関係 のサービス間でリストされていることを確認します。Puppet マスターに関連付けられているサービスロールに AWSOpsWorksCMServiceRole管理ポリシーがアタッチされていることを確認します。

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 アドレスを解放するか、アカウントがアクティブに使用していないアドレスを削除できます。または、 AWS カスタマーサポートに連絡して、アカウントに関連付けられている EIP アドレスの制限を増やすことができます。

ノードの自動関連付けに失敗する

問題: 新しい Amazon EC2 ノードの自動 (無人) 関連付けに失敗する。Puppet マスターに追加されたノードが Puppet Enterprise ダッシュボードに表示されない。

原因: opsworks-cm API コールで新しい EC2 インスタンスとの通信を許可するインスタンスプロファイルとして IAM ロールをセットアップしていない場合に、この問題が発生する可能性があります。

解決策: OpsWorks for Puppet Enterprise でノードを自動的に追加する で説明したように、EC2 インスタンスのプロファイルにポリシーをアタッチして、AssociateNode と DescribeNodeAssociationStatus の API コールを EC2 と連携できるようにします。

システムメンテナンスの失敗

AWS OpsWorks CM は毎週システムメンテナンスを実行し、セキュリティ更新プログラムを含む で AWSテストされた最新バージョンの Puppet Server が、常に OpsWorks for Puppet Enterprise サーバーで実行されていることを確認します。何らかの理由でシステムメンテナンスが失敗した場合、 は失敗 AWS OpsWorks CM を通知します。システムメンテナンスの詳細については、「Puppet Enterprise OpsWorks の でのシステムメンテナンス」を参照してください。

このセクションでは、考えられる障害の原因を説明し、解決策を提案します。

サービスロールまたはインスタンスプロファイルのエラーによって、システムのメンテナンスが妨げられる

問題： システムメンテナンスが失敗し、「sts: を実行する権限がありません」というエラーメッセージAssumeRole、またはアクセス許可に関する同様のエラーメッセージが表示される。

原因: これは、使用しているサービスロールまたはインスタンスプロファイルのいずれかに、サーバー上でシステムメンテナンスを実行するための適切な権限がない場合に発生する可能性があります。

解決策: サービスロールとインスタンスプロファイルに必要なすべての権限があることを確認してください。

  1. サービスロールに必要な権限がすべてあることを確認してください。

    1. サーバーの「設定」ページの「ネットワークとセキュリティ」で、サーバーが使用しているサービスロールへのリンクを選択します。これにより、 IAM コンソールに表示されるサービスロールが開きます。

    2. 「アクセス許可」のタブで、AWSOpsWorksCMServiceRole がサービスロールにアタッチされていることを確認します。AWSOpsWorksCMServiceRole がリストにない場合は、このポリシーをロールに追加します。

    3. opsworks-cm.amazonaws.com がロールの 信頼関係 のサービス間でリストされていることを確認します。ロールで信頼ポリシーを使用する方法の詳細については、「ロールの変更 (コンソール）」または AWS 「セキュリティブログ記事」の「IAM ロールで信頼ポリシーを使用する方法」を参照してください。

  2. インスタンスプロファイルに必要な権限がすべてあることを確認してください。

    1. サーバーの「設定」ページの「ネットワークとセキュリティ」で、サーバーが使用しているインスタンスプロファイルへのリンクを選択します。これにより、 IAM コンソールに表示されるインスタンスプロファイルが開きます。

    2. 「権限」のタブで、AmazonEC2RoleforSSM と AWSOpsWorksCMInstanceProfileRole が両方とも「アクセス権限ポリシー」リストに含まれていることを確認します。一方または両方がリストにない場合は、これらの管理ポリシーを手動でロールに追加してください。

    3. 「信頼関係」のタブで、ユーザーに代わって役割を引き受ける ec2.amazonaws.com サービスを信頼する信頼ポリシーがサービスロールに含まれていることを確認します。ロールで信頼ポリシーを使用する方法の詳細については、「ロールの変更 (コンソール）」または AWS 「セキュリティブログ記事」の「IAM ロールで信頼ポリシーを使用する方法」を参照してください。

その他のヘルプとサポート

発生している特定の問題がこのトピックで説明されていないか、このトピックの提案を試しても問題が解決しない場合は、AWS OpsWorks フォーラムを参照してください。

また、AWS Support Center を参照することもできます。 AWS サポートセンターは、 AWS サポートケースを作成および管理するためのハブです。 AWS サポートセンターには、フォーラム、技術上のFAQs、サービスのヘルスステータス、 など、その他の役立つリソースへのリンクも含まれています AWS Trusted Advisor。