OpenShift：アプリケーションの構成と運用

ロギングとデバッグ

最後に、設定ポイントではありませんが、デプロイ時のデバッグ方法やログの確認方法について簡単に紹介していきます。

ログの種類と見方

まず、アプリケーション開発者側から確認する基本的なログは、コンテナの出力ログ（oc logs <pod名>）とeventログ（oc get events）になります。oc logsはすでに今回の記事で使っていますが、いくつかのオプションを紹介しておきます。まず、コンテナのプロセスが終了してしまった場合、Podは自動で再起動されていることが多いでしょう。そうなると、oc logsは再起動後の稼働状態となったコンテナのログを取得するため、あまり有効ではありません。その場合、-p（--previous）オプションを指定します。

$ oc logs -p <POD名>

-pオプションを指定することで、現在稼働しているPodの1つ前のコンテナのログが確認できます。コンテナのRESTARTカウントが増えていた場合や、CrashLoopのステータスになっていた場合には、まずはoc logs -pを確認するのが有効です。

次に、--all-containersオプションです。

$ oc logs --all-containers <POD名>

サイドカーコンテナを使って、Pod内に複数のコンテナが存在する場合には、このオプションが便利でしょう。例えば、以下のprometheus-k8s-0 Podは、コンテナが4つも起動しています。コンテナを1つずつ確認しても良いですが、--all-containersを使ってざっと確認するのが便利です。

$ oc get pod prometheus-k8s-0
NAME               READY     STATUS    RESTARTS   AGE
prometheus-k8s-0   4/4       Running   1          21h

さて、Podのコンテナプロセスが何らか原因で停止している場合には、コンテナのログを確認すれば良いのですが、外的要因で障害が発生した場合には、コンテナのログには何も出力されていません。この場合、eventログが有効になります。

$ oc get event

eventログはクラスタで発生したイベントのログで、例えば最初に見たLiveness ProbeやReadiness Probeによる再起動のイベントや、ストレージのmountイベントのログも出力されています。

アプリケーション開発者側でログを確認する場合には、まずは上記のoc logsとoc get eventを確認するのが良いでしょう。

またOpenShiftでは、EFKスタック（ElasticSearch、Fluentd、Kibanaによる分析基盤）を使ってログの可視化も可能です。クラスタ管理者がOpenShift用に提供されているEFKスタックをデプロイしていれば、ユーザーはKibanaからログを見ることも可能です。

デバッグ方法

さて、次はデバッグ方法です。デバッグの方法は問題の状況や環境によって千差万別です。ここでは、よく使うコマンドを簡単に紹介していきます。

まず、oc rshでのコンテナ環境へのログインです。コンテナが稼働していれば、このコマンドでコンテナにログインし、ディレクトリ・ファイルのパーミッションや設定ファイルを直接確認できます。また、ネットワークのトラブル時にも、コンテナにrshでログインして、ネットワーク疎通や名前解決を確認するのは有効な手段になります。

oc rsh <POD名>

ちょっとした隠し技として、ネットワークのトラブルシューティング時に、netstatやdig、tcpdumpといったコマンドがインストールされていないコンテナ上でのデバッグ方法を紹介します。コンテナにこれらのコマンドがない場合には、nsenterコマンドを使ってNodeホスト上からコンテナのネットワーク環境に入ります。

# nsenter -t <ホスト上で見えるコンテナのプロセスID> -n -- netstat -anp

こうすることで、ホスト上のコマンドを使って、コンテナ環境でのネットワークのトラブルシューティングが可能です。もちろんNodeホスト上にsshログインできる権限が必要になるので、ここまで行う場合には、クラスタ管理者と連携が必要になります。

次にoc cpコマンドは、コンテナ内のファイルをローカルにコピーするコマンドです。設定ファイルやログファイルをローカルにコピーすることができます。

oc cp <POD名>:/ファイルパス/ /出力先/ファイル/パス

最後に、oc debugというコマンドを紹介して終わりにします。oc debugコマンドは、指定したオブジェクトをインタラクティブなshellで立ち上げるコマンドです。コンテナが起動できないときに、このコマンドを使うと便利です。実際にdc/go-httpdを指定して立ち上げてみましょう。

# oc debug dc/go-httpd
Defaulting container name to go-httpd.
Use 'oc describe pod/go-httpd-debug -n ch05' to see all of the containers in this pod.

Debugging with pod/go-httpd-debug, original command: /bin/sh -c go run main.go
Waiting for pod to start ...
If you don't see a command prompt, try pressing enter.
/app #

コマンドを実行すると、いくつかのメッセージとコマンドプロンプトが起動しました。この新しく起動したPodは、go-httpdのDeploymentConfigから起動コマンドをshellに変更したPodです。/bin/sh -c go run main.goはまだ実行されていない状態です。

oc debug

この状態から/bin/sh -c go run main.goを実行して、エラーログを確認しても良いですし、起動オプションがあれば、それを変更するのも良いでしょう。インタラクティブなシェルで実行できるので、非コンテナ環境でのデバッグ作業と同じように、できることの幅が広がります。

本章では、アプリケーションの運用に関わる設定内容を確認し、実際に動かしてみました。かなり駆け足での紹介となりましたが、どういったことができるか大まかな機能を把握していただければ幸いです。