AWS OpsWorks for Chef Automate のトラブルシューティング

重要

なぜなら、AWS OpsWorks Chef Automate はもはや新規顧客を受け入れていないからです。2024 年 5 月 5 日までは、既存のお客様には影響はありません。その時点でサービスは利用できなくなります。既存のお客様は、 Chef SaaS または代替ソリューションに移行することをお勧めします。詳細については、「AWS OpsWorks Chef Automate のサポート終了に関するよくある質問」を参照してください。

このトピックでは、AWS OpsWorks for Chef Automate に関する一般的な問題と、それらの問題について推奨される解決方法を示します。

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

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

• Chef サーバーを起動できない場合は、AWS OpsWorks for Chef Automate コンソールを使用してエラーメッセージを表示します。Chef サーバーの詳細ページで、サーバーの起動と実行に関連するエラーメッセージが、ページの一番上に表示されます。エラーは、Chef サーバーの作成に使用されるサービスである、AWS OpsWorks for Chef Automate、AWS CloudFormation、または Amazon EC2 から発生します。詳細ページでは、実行中のサーバーで発生するイベントを表示することもできます。これには、障害イベントメッセージが含まれる場合があります。

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

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

トピック

• サーバーは接続が切断された 状態
• フルマネージドログ管理ノードが、欠落している列の Chef Automate ダッシュボードに表示される
• Chef ボールトを作成できず、knife vault コマンドがエラーで失敗する
• サーバーの作成が「リクエストされた設定は現在サポートされていません」というメッセージで失敗する
• Chef サーバーが、Chef Automate ダッシュボードで追加された組織名を認識できない
• サーバーの Amazon EC2 インスタンスを作成できない
• サービスロールのエラーによりサーバーを作成できない
• Elastic IP アドレスの制限を超えた
• Chef Automate ダッシュボードにサインインできない
• ノードの自動関連付けに失敗する
• システムメンテナンスの失敗

サーバーは接続が切断された 状態

問題: サーバーのステータスが「接続が切断されました」と表示されます。

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

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

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 コンソールで、AWS OpsWorks for Chef Automate サーバーのリージョンと同じリージョンにいることを確認し、サーバーが使用している EC2 インスタンスを再起動します。

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

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

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

4. AWS OpsWorks for Chef Automate コンソールのサーバーの詳細ページで、サーバーの状態が 正常 になったことを確認します。

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

• 新しいサーバーを作成し、元のサーバーを削除して、サーバーを交換してください。現在のサーバー上のデータが重要な場合は、最新のバックアップからサーバーを復元し、元の応答しないサーバーを削除する前に データが最新であることを確認してください。

• AWSSupportにお問い合わせください。

フルマネージドログ管理ノードが、欠落している列の Chef Automate ダッシュボードに表示される

問題: フルマネージドログ管理ノードが、Chef Automate ダッシュボードの欠落している列に表示される。

原因: ノードが、12 時間以上 Chef Automate サーバーに接続されず、chef-clientかつノードで実行できない場合、ノードは、12 時間前の状態から変わり、Chef Automate ダッシュボードの欠落している列に移動します。

解決策: ノードがオンラインになっていることを確認してください。knife node show node_name --run-list を実行してノードで chef-client を実行できるか、または knife node show -l node_name がノードに関するすべての情報を表示するかを確認します。ノードがオフライン、あるいはネットワーク接続が切断している可能性があります。

Chef ボールトを作成できず、knife vault コマンドがエラーで失敗する

問題: knife vault コマンドを実行して、Chef Automate サーバーでボールトを作成しようとしている (ドメイン結合 Windows ベースのノードの認証情報を保存するボールトなど)。このコマンドは、次のようなエラーメッセージを返す。

WARN: Auto inflation of JSON data is deprecated. Please pass in the class to inflate or use #edit_hash (CHEF-1) 
at /opt/chefdk/embedded/lib/ruby/2.3.0/forwardable.rb:189:in `edit_data'.Please see https://docs.chef.io/deprecations_json_auto_inflate.html 
for further details and information on how to correct this problem.
WARNING: pivotal not found in users, trying clients.
ERROR: ChefVault::Exceptions::AdminNotFound: FATAL: Could not find pivotal in users or clients!

knife user list をリモートに実行すると主要ユーザーは返されないが、Chef Automate サーバーで chef-server-ctl user-show コマンドをローカルに実行すると、結果で主要ユーザーが表示される。つまり、knife vault コマンドでは主要ユーザーを見つけることはできないが、ユーザーが存在していることは確認できる。

原因: 主要ユーザーは、Chef ではスーパーユーザーと見なされており、完全な権限を持っていますが、AWS OpsWorks for Chef Automate で使用されている default 組織を含めて、いずれの組織のメンバーでもありません。コマンド knife user list は、Chef 設定の現在の組織に属するすべてのユーザーを返します。コマンド chef-server-ctl user-show は、主要ユーザーを含めて、組織にかかわらずすべてのユーザーを返します。

解決策: この問題を解決するには、knife opc を実行して、デフォルトの組織に主要ユーザーを追加します。

最初に、knife-opc プラグインをインストールする必要があります。

chef gem install knife-opc

このプラグインをインストールしたら、次のコマンドを実行して主要ユーザーをデフォルトの組織に追加します。

knife opc org user add default pivotal

もう一度 knife user list を実行して、主要ユーザーがデフォルトの組織に属していることを確認できます。結果には pivotal が表示されている必要があります。次に、もう一度 knife vault を実行してみます。

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

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

原因: Chef Automate サーバーに対してサポートされていないインスタンスタイプが指定された可能性があります。ハードウェア専有インスタンス用など、デフォルトでないテナンシーを持つ VPC で Chef Automate サーバーの作成を選択した場合、指定された VPC 内のすべてのインスタンスも、専有テナンシーまたはホストテナンシーのインスタンスである必要があります。t2 など一部のインスタンスタイプはデフォルトテナンシーでしか使用できないため、Chef Automate サーバーインスタンスタイプは指定された VPC でサポート可能でない場合があり、そのためにサーバーの作成が失敗します。

解決策: デフォルト以外のテナンシーを持つ VPC を選択した場合は、専用テナンシーをサポートできる m4 インスタンスタイプを使用します。

Chef サーバーが、Chef Automate ダッシュボードで追加された組織名を認識できない

問題: Chef Automate ダッシュボードで新しいワークフロー組織名を追加したり、無人ノード関連付けスクリプトで "default" 以外の CHEF_AUTOMATE_ORGANIZATION 値を指定したりしましたが、ノード関連付けに失敗します。AWS OpsWorks for Chef Automate サーバーが新しい組織名を認識しない。

原因: Workflow 組織名および Chef サーバー組織名が同じではありません。ウェブベースの Chef Automate ダッシュボードで新しい Workflow 組織を作成できますが、Chef サーバー組織名は作成できません。Chef Automate ダッシュボードのみを使用して、既存の Chef サーバー組織を表示できます。Chef Automate ダッシュボードで作成する新しい組織は Workflow 組織であり、Chef サーバーによって認識されません。ノードの関連付けスクリプトでそれらを指定して、新しい組織名を作成することはできません。組織が最初に Chef サーバーに追加されていないときにノードの関連付けスクリプトで組織名を参照すると、ノードの関連付けに失敗します。

解決策: Chef Server で認識される新しい組織を作成するには、knife opc org create コマンドを使用するか、chef-server-ctl org-create を実行します。

サーバーの 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.」という状態を示すエラーメッセージが表示され、サーバーを作成できない。

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

解決策: AWS OpsWorks for Chef Automate コンソールを開きます。コンソールを使用して新しいサービスロールとインスタンスプロファイルロールを生成します。独自のサービスロールの使用を希望する場合は、AWSOpsWorksCMServiceRole ポリシーをロールにアタッチします。opsworks-cm.amazonaws.com がロールの 信頼関係 のサービス間でリストされていることを確認します。Chef サーバーに関連付けられているサービスロールに、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 アドレスを解放するか、アカウントでアクティブに使用していないものを削除します。あるいは、AWS カスタマーサポートに連絡して、アカウントに関連付けられている EIP アドレスの制限を引き上げることができます。

Chef Automate ダッシュボードにサインインできない

問題: Chef Automate ダッシュボードに、「Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://myserver-name.region.opsworks-cm.io/api/v0/e/default/verify-token。(Reason: CORS header 'Access-Control-Allow-Origin' missing)」のようなエラーが表示される。「The User Id / Password combination entered is incorrect.」のようなエラーの場合もある。

原因: Chef Automate ダッシュボードが明示的に FQDN を設定していて、相対 URL を受け付けていません。現時点では、Chef サーバーの IP アドレスを使用してサインインすることはできません。サーバーの DNS 名を使用してサインインできるのみです。

解決策: Chef サーバーの IP アドレスではなく、DNS 名エントリのみを使用して Chef Automate ダッシュボードにサインインします。また、Chef Automate ダッシュボードの認証情報のリセット で説明したように、AWS CLI コマンドを実行して Chef Automate ダッシュボードの認証情報をリセットしてみることもできます。

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

問題: 新しい Amazon EC2 ノードの自動 (無人) 関連付けに失敗する。Chef サーバーに追加されたはずのノードが Chef Automate ダッシュボードに表示されず、knife client show または knife node show コマンドの結果に含まれない。

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

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

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

AWS OpsWorks CMは毎週システムメンテナンスを実行し、 Chef Server や Chef Automate Server の最新のマイナーバージョン (セキュリティアップデートを含む)がAWS OpsWorks for Chef Automateサーバー上で常に実行されていることを確認します。何らかの理由でシステムメンテナンスが失敗した場合、AWS OpsWorks CM は障害を通知します。システムメンテナンスの詳細については、「AWS OpsWorks for Chef Automate でのシステムメンテナンス」を参照してください。

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

トピック

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

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

問題: システムメンテナンスが失敗し、「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 サポートセンターには、フォーラム、技術上のよくある質問、サービス状態ステータス、AWS Trusted Advisor などの便利なリソースへのリンクも含まれています。