7.8. Source-to-Image (S2I) プロセスのトラブルシューティング
7.8.1. Source-to-Image (S2I) のトラブルシューティングのストラテジー
Source-to-Image (S2I) を使用して、再現可能な Docker 形式のコンテナーイメージをビルドします。アプリケーションソースコードをコンテナーイメージに挿入し、新規イメージをアセンブルして実行可能なイメージを作成できます。新規イメージには、ベースイメージ (ビルダー) およびビルドされたソースが組み込まれています。
S2I プロセスで障害が発生する場所を特定するには、以下の各 S2I ステージに関連する Pod の状態を確認できます。
- ビルド設定の段階 で、ビルド Pod はベースイメージおよびアプリケーションのソースコードからアプリケーションコンテナーイメージを作成するために使用されます。
- デプロイメント設定の段階 で、デプロイメント Pod はビルド設定段階でビルドされたアプリケーションコンテナーイメージからアプリケーション Pod をデプロイするために使用されます。デプロイメント Pod は、サービスやルートなどの他のリソースもデプロイします。デプロイメント設定は、ビルド設定が成功すると開始されます。
-
デプロイメント Pod のアプリケーション Pod の起動後 に、アプリケーションの障害が実行中のアプリケーション Pod 内で発生する可能性があります。たとえば、アプリケーション Pod が
Running
状態であっても、アプリケーションは予想通りに動作しない可能性があります。このシナリオでは、実行中のアプリケーション Pod にアクセスして、Pod 内のアプリケーションの障害を調査できます。
S2I の問題のトラブルシューティングを行う際には、以下のストラテジーに従います。
- ビルド、デプロイメント、およびアプリケーション Pod ステータスの監視
- 問題が発生した S2I プロセスのステージの判別
- 失敗したステージに対応するログの確認
7.8.2. Source-to-Image 診断データの収集
S2I ツールは、ビルド Pod とデプロイメント Pod を順番に実行します。デプロイメント Pod は、ビルドステージで作成されたアプリケーションコンテナーイメージに基づいてアプリケーション Pod をデプロイします。S2I プロセスで障害が発生する場所を判別するために、ビルド、デプロイメント、およびアプリケーション Pod のステータスを監視します。次に、これに応じて診断データを収集します。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - API サービスが機能している。
-
OpenShift CLI (
oc
) がインストールされている。
手順
S2I プロセス全体での Pod のステータスを確認し、障害が発生するステージを判別します。
$ oc get pods -w 1
- 1
-w
を使用して、Ctrl+C
を使用してコマンドを終了するまで Pod で変更の有無を監視します。
障害のある Pod のログでエラーの有無を確認します。
ビルド Pod が失敗する場合、ビルド Pod のログを確認します。
$ oc logs -f pod/<application_name>-<build_number>-build
注記または、
oc logs -f bc/<application_name>
を使用して、ビルド設定のログを確認できます。ビルド設定のログには、ビルド Pod からのログが含まれます。デプロイメント Pod が失敗する場合、デプロイメント Pod のログを確認します。
$ oc logs -f pod/<application_name>-<build_number>-deploy
注記または、
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>
7.8.3. アプリケーションの障害を調査するためのアプリケーション診断データの収集
アプリケーションの障害は実行中のアプリケーション Pod 内で発生する可能性があります。このような状態では、以下のストラテジーを使用して診断情報を取得できます。
- アプリケーション Pod に関連するイベントを確認します。
- アプリケーション Pod からログを確認します。これには、OpenShift Logging フレームワークによって収集されないアプリケーション固有のログファイルが含まれます。
- アプリケーション機能を対話的にテストし、アプリケーションコンテナーで診断ツールを実行します。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
特定のアプリケーション Pod に関連するイベントをリスト表示します。以下の例では、
my-app-1-akdlg
という名前のアプリケーション Pod のイベントを取得します。$ oc describe pod/my-app-1-akdlg
アプリケーション Pod からのログを確認します。
$ oc logs -f pod/my-app-1-akdlg
実行中のアプリケーション Pod 内で特定のログをクエリーします。標準出力 (stdout) に送信されるログは OpenShift Logging フレームワークによって収集され、これは前述のコマンドの出力に含まれます。以下のクエリーは、標準出力 (stdout) に送信されないログにのみ必要です。
Pod 内で root 権限なしにアプリケーションログにアクセスできる場合は、以下のようにログファイルを連結します。
$ oc exec my-app-1-akdlg -- cat /var/log/my-application.log
アプリケーションログの表示に root アクセスが必要な場合は、root 権限でデバッグコンテナーを起動し、コンテナー内でログファイルを表示できます。プロジェクトの
DeploymentConfig
オブジェクトからデバッグコンテナーを起動します。通常、Pod ユーザーは root 以外の権限で実行しますが、問題を調査するために一時的な root 権限で Pod のトラブルシューティングを実行することは役に立ちます。$ oc debug dc/my-deployment-configuration --as-root -- cat /var/log/my-application.log
注記oc debug dc/<deployment_configuration> --as-root
を-- <command>
を追加せずに実行する場合、デバッグ Pod 内で root アクセスでインタラクティブなシェルにアクセスできます。
インタラクティブなシェルでアプリケーション機能を対話的にテストし、アプリケーションコンテナーで診断ツールを実行します。
アプリケーションコンテナーでインタラクティブなシェルを起動します。
$ oc exec -it my-app-1-akdlg /bin/bash
- シェルからアプリケーションの機能を対話的にテストします。たとえば、コンテナーのエントリーポイントコマンドを実行して、結果を確認することができます。次に、ソースコードを更新し、S2I プロセスでアプリケーションコンテナーを再ビルドする前に、コマンドラインから直接に変更をテストします。
コンテナー内で利用可能な診断バイナリーを実行します。
注記一部の診断バイナリーを実行するには、root 権限が必要です。このような状況では、
oc debug dc/<deployment_configuration> --as-root
を実行して、問題のある Pod のDeploymentConfig
オブジェクトに基づいて、root 権限でデバッグ Pod を起動できます。次に、デバッグ Pod 内から診断バイナリーを root として実行できます。
診断バイナリーがコンテナー内で利用できない場合は、
nsenter
を使用して、コンテナーの namespace 内でホストの診断バイナリーを実行できます。以下の例では、ホストのip
バイナリーを使用して、コンテナーの namespace 内でip ad
を実行します。ターゲットノードのデバッグセッションに入ります。この手順は、
<node_name>-debug
というデバッグ Pod をインスタンス化します。$ oc debug node/my-cluster-node
/host
をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の/host
にホストの root ファイルシステムをマウントします。root ディレクトリーを/host
に変更すると、ホストの実行パスに含まれるバイナリーを実行できます。# chroot /host
注記Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform 4.16 クラスターノードは、イミュータブルです。クラスターの変更を適用するには、Operator を使用します。SSH を使用したクラスターノードへのアクセスは推奨されません。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、
oc
操作がその影響を受けます。この場合は、代わりにssh core@<node>.<cluster_name>.<base_domain>
を使用してノードにアクセスできます。ターゲットコンテナー ID を判別します。
# crictl ps
コンテナーのプロセス ID を確認します。この例では、ターゲットコンテナー ID は
a7fe32346b120
です。# crictl inspect a7fe32346b120 --output yaml | grep 'pid:' | awk '{print $2}'
ホストの
ip
バイナリーを使用して、コンテナーの namespace 内でip ad
を実行します。この例では、31150
をコンテナーのプロセス ID として使用します。nsenter
コマンドは、ターゲットプロセスの namespace を入力し、その namespace でコマンドを実行します。この例のターゲットプロセスはコンテナーのプロセス ID であるため、ip ad
コマンドは、ホストからコンテナーの namespace で実行されます。# nsenter -n -t 31150 -- ip ad
注記デバッグノードなどの特権付きコンテナーを使用している場合のみ、コンテナーの namespace 内でホストの診断バイナリーを実行できます。
7.8.4. 関連情報
- S2I ビルドストラテジーの詳細は、Source-to-Image (S2I) ビルド を参照してください。