8.7. Source-to-Image (S2I) プロセスのトラブルシューティング

1. ビルド設定の段階 で、ビルド Pod はベースイメージおよびアプリケーションのソースコードからアプリケーションコンテナーイメージを作成するために使用されます。
2. デプロイメント設定の段階 で、デプロイメント Pod はビルド設定段階でビルドされたアプリケーションコンテナーイメージからアプリケーション Pod をデプロイするために使用されます。デプロイメント Pod は、サービスやルートなどの他のリソースもデプロイします。デプロイメント設定は、ビルド設定が成功すると開始されます。
3. デプロイメント Pod のアプリケーション Pod の起動後 に、アプリケーションの障害が実行中のアプリケーション Pod 内で発生する可能性があります。たとえば、アプリケーション Pod が Running 状態であっても、アプリケーションは予想通りに動作しない可能性があります。このシナリオでは、実行中のアプリケーション Pod にアクセスして、Pod 内のアプリケーションの障害を調査できます。

1. ビルド、デプロイメント、およびアプリケーション Pod ステータスの監視
2. 問題が発生した S2I プロセスのステージの判別
3. 失敗したステージに対応するログの確認

手順

1. S2I プロセス全体での Pod のステータスを確認し、障害が発生するステージを判別します。

   $ oc get pods -w  

   1

   Copy to Clipboard Toggle word wrap

   1

   -w を使用して、Ctrl+C を使用してコマンドを終了するまで Pod で変更の有無を監視します。

2. 障害のある Pod のログでエラーの有無を確認します。

   • ビルド Pod が失敗する場合、ビルド Pod のログを確認します。

     $ oc logs -f pod/<application_name>-<build_number>-build

     Copy to Clipboard Toggle word wrap
     注記

     または、oc logs -f bc/<application_name> を使用して、ビルド設定のログを確認できます。ビルド設定のログには、ビルド Pod からのログが含まれます。

   • デプロイメント Pod が失敗する場合、デプロイメント Pod のログを確認します。

     $ oc logs -f pod/<application_name>-<build_number>-deploy

     Copy to Clipboard Toggle word wrap
     注記

     または、oc logs -f dc/<application_name> を使用して、デプロイメント設定のログを確認できます。これにより、デプロイメント Pod が正常に実行されるまで、デプロイメント Pod からログが出力されます。デプロイメント Pod の完了後に実行すると、コマンドはアプリケーション Pod からログを出力します。デプロイメント Pod の完了後も、oc logs -f pod/<application_name>-<build_number>-deploy を実行してログにアクセスできます。

   • アプリケーション Pod が失敗した場合や、アプリケーションが実行中のアプリケーション Pod 内で予想通りに動作しない場合、アプリケーション Pod のログを確認します。

     $ oc logs -f pod/<application_name>-<build_number>-<random_string>

     Copy to Clipboard Toggle word wrap

手順

1. 特定のアプリケーション Pod に関連するイベントをリスト表示します。以下の例では、my-app-1-akdlg という名前のアプリケーション Pod のイベントを取得します。

   $ oc describe pod/my-app-1-akdlg

   Copy to Clipboard Toggle word wrap

2. アプリケーション Pod からのログを確認します。

   $ oc logs -f pod/my-app-1-akdlg

   Copy to Clipboard Toggle word wrap

3. 実行中のアプリケーション Pod 内で特定のログを照会します。標準出力 (stdout) に送信されるログは OpenShift Logging フレームワークによって収集され、これは前述のコマンドの出力に含まれます。以下のクエリーは、標準出力 (stdout) に送信されないログにのみ必要です。

   1. Pod 内で root 権限なしにアプリケーションログにアクセスできる場合は、以下のようにログファイルを表示します。

      $ oc exec my-app-1-akdlg -- cat /var/log/my-application.log

      Copy to Clipboard Toggle word wrap

   2. アプリケーションログの表示に root アクセスが必要な場合は、root 権限でデバッグコンテナーを起動し、コンテナー内でログファイルを表示できます。プロジェクトの DeploymentConfig オブジェクトからデバッグコンテナーを起動します。通常、Pod ユーザーは root 以外の権限で実行しますが、問題を調査するために一時的な root 権限で Pod のトラブルシューティングを実行することは役に立ちます。

      $ oc debug dc/my-deployment-configuration --as-root -- cat /var/log/my-application.log

      Copy to Clipboard Toggle word wrap
      注記

      oc debug dc/<deployment_configuration> --as-root を -- <command> を追加せずに実行する場合、デバッグ Pod 内で root アクセスでインタラクティブなシェルにアクセスできます。

4. インタラクティブなシェルでアプリケーション機能を対話的にテストし、アプリケーションコンテナーで診断ツールを実行します。

   1. アプリケーションコンテナーでインタラクティブなシェルを起動します。

      $ oc exec -it my-app-1-akdlg /bin/bash

      Copy to Clipboard Toggle word wrap
   2. シェルからアプリケーションの機能を対話的にテストします。たとえば、コンテナーのエントリーポイントコマンドを実行して、結果を確認することができます。次に、ソースコードを更新し、S2I プロセスでアプリケーションコンテナーを再ビルドする前に、コマンドラインから直接に変更をテストします。

   3. コンテナー内で利用可能な診断バイナリーを実行します。

      注記

      一部の診断バイナリーを実行するには、root 権限が必要です。このような状況では、oc debug dc/<deployment_configuration> --as-root を実行して、問題のある Pod の DeploymentConfig オブジェクトに基づいて、root 権限でデバッグ Pod を起動できます。次に、デバッグ Pod 内から診断バイナリーを root として実行できます。

5. 診断バイナリーがコンテナー内で利用できない場合は、nsenter を使用して、コンテナーの namespace 内でホストの診断バイナリーを実行できます。以下の例では、ホストの ip バイナリーを使用して、コンテナーの namespace 内で ip ad を実行します。

   1. ターゲットノードのデバッグセッションに入ります。この手順は、<node_name>-debug というデバッグ Pod をインスタンス化します。

      $ oc debug node/my-cluster-node

      Copy to Clipboard Toggle word wrap

   2. /host をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の /host にホストの root ファイルシステムをマウントします。root ディレクトリーを /host に変更すると、ホストの実行パスに含まれるバイナリーを実行できます。

      # chroot /host

      Copy to Clipboard Toggle word wrap
      注記

      Red Hat Enterprise Linux CoreOS (RHCOS) を実行する Red Hat OpenShift Service on AWS 4 クラスターノードは、イミュータブルです。クラスターの変更を適用するには、Operator を使用します。SSH を使用したクラスターノードへのアクセスは推奨されません。ただし、Red Hat OpenShift Service on AWS API が使用できない場合、または kubelet がターゲットノード上で適切に機能していない場合は、oc 操作が影響を受けます。この場合は、代わりに ssh core@<node>.<cluster_name>.<base_domain> を使用してノードにアクセスできます。

   3. ターゲットコンテナー ID を判別します。

      # crictl ps

      Copy to Clipboard Toggle word wrap

   4. コンテナーのプロセス ID を確認します。この例では、ターゲットコンテナー ID は a7fe32346b120 です。

      # crictl inspect a7fe32346b120 --output yaml | grep 'pid:' | awk '{print $2}'

      Copy to Clipboard Toggle word wrap

   5. ホストの ip バイナリーを使用して、コンテナーの namespace 内で ip ad を実行します。この例では、31150 をコンテナーのプロセス ID として使用します。nsenter コマンドは、ターゲットプロセスの namespace を入力し、その namespace でコマンドを実行します。この例のターゲットプロセスはコンテナーのプロセス ID であるため、ip ad コマンドは、ホストからコンテナーの namespace で実行されます。

      # nsenter -n -t 31150 -- ip ad

      Copy to Clipboard Toggle word wrap
      注記

      デバッグノードなどの特権付きコンテナーを使用している場合のみ、コンテナーの namespace 内でホストの診断バイナリーを実行できます。