はじめに
コンテナ内で実行されるアプリケーションは通常、状態やエラーメッセージを標準出力と標準エラー出力に書き込みます。これはコンテナ化されたシステムにおける重要な設計パターンです。各コンテナが複雑なログファイルを個別に管理するのではなく、コンテナランタイムが出力ストリームを取得し、中央から利用できるようにします。
これが、コンテナイメージが従来のサーバーソフトウェアとは異なる形で構築されることが多い理由の一つです。コンテナプラットフォームでは、ログをローカルファイルに隠すよりも、有用な stdout/stderr 出力を書き込む方法がよく使われます。
開発者やシステム管理者にとって、これらのログにアクセスすることは、バックグラウンドコンテナ内で何が起きているかを把握するために重要です。Kubernetes などの実際のプラットフォームでも、この stdout/stderr モデルが集中ログ収集パイプラインの基盤になっています。
この実験では、次のことを学びます。
- 継続的に出力を生成するコンテナを実行する。
- これまでに生成されたログを取得する。
- アプリケーションの実行中にログをリアルタイムで追跡する。
- アプリケーションを停止せずに、安全に監視を終了する。
バックグラウンドプロセスを起動する
このステップでは、Docker コンテナをデタッチモードで起動します。実際のアプリケーションを再現するため、1 秒ごとにメッセージを出力する簡単なスクリプトを実行します。
デタッチモード（-d フラグ）でコンテナを実行すると、コンテナはバックグラウンドで動作するため、出力はすぐにはターミナルに表示されません。
出力自体は存在します。ただし、現在のシェルセッションに直接ストリーム出力されるのではなく、Docker によって取得されています。
次のコマンドを実行して、コンテナを起動します。
docker run -d --name web-log-app alpine sh -c "while true; do echo 'Application is running...'; sleep 1; done"
コマンドの内容：
docker run -d: コンテナをバックグラウンドで起動します。--name web-log-app: コンテナに「web-log-app」という名前を付けます。alpine: 軽量な「Alpine Linux」イメージを使用します。sh -c "...": コンテナ内で実行するコマンドです。無限ループ（while true）を実行し、各ループでメッセージ（echo）を出力してから 1 秒間停止します（sleep 1）。
コンテナが実行中であることを確認します。
docker ps
アクティブなコンテナとして web-log-app が一覧に表示されます。
既存のログを表示する
コンテナはバックグラウンドで実行されているため、その出力は現在のターミナル画面には表示されません。Docker はこの出力を取得しており、docker logs コマンドを使って表示できます。
このステップでは、コンテナの起動後に生成されたログを取得します。
次のコマンドを実行します。
docker logs web-log-app
「Application is running...」というメッセージが一覧表示されます。
仕組み：
docker logs コマンドは、その時点までに保存されたすべてのログを取得して画面に表示します。表示後はすぐに終了し、コマンドプロンプトに戻ります。これは、アプリケーションの実行履歴を確認したり、起動状態を検証したりするときに便利です。
つまり、docker logs が表示するのは現時点までの履歴出力であり、コンテナ内に入るための対話型シェルではありません。コンテナのメインプロセスが書き込んだ内容を読み取り専用で表示します。
数秒後にもう一度コマンドを実行すると、コンテナはバックグラウンドでログを生成し続けているため、より長い一覧が表示されます。
docker logs web-log-app
ログをリアルタイムで監視する
過去のログを見るだけでは不十分な場合があります。問題のデバッグやライブトラフィックの監視のために、ログが生成される様子を確認したいことがあります。これは Linux の tail -f コマンドを使う場合と似ています。
このステップでは、-f（follow）フラグを使ってログをリアルタイムでストリーム表示します。
次のコマンドを実行します。
docker logs -f web-log-app
何が起きているのでしょうか？
コマンドプロンプトには戻りません。その代わり、ターミナルがコンテナのログストリームに「接続」された状態になります。1 秒ごとに新しい「Application is running...」メッセージが表示されます。
これは概念的には tail -f と似ています。ただし、読み取っているデータの取得元は通常のファイルではなく、Docker が取得したログストリームです。
このモードは、アプリケーションを操作しながら動作を監視するときに非常に役立ちます。
デタッチして後片付けする
現在、ターミナルはログの追跡を続けているため、操作を受け付けないように見えます。コンテナは実行中で、docker logs コマンドは新しい出力を待機しています。
ログの監視を停止してコマンドプロンプトに戻るには、割り込みシグナルを送信します。
キーボードで Ctrl+C を押します。
重要なポイント：
ここで Ctrl+C を押すと、ログを表示している docker logs コマンドは停止しますが、コンテナ自体は停止しません。web-log-app コンテナはバックグラウンドで実行を続け、ログを生成し続けます。
この違いは運用上重要です。コンテナを監視する操作と、コンテナを制御する操作は別のものです。この二つを混同することは、初心者によくあるミスです。
プロセス一覧を確認すれば、これを検証できます。
docker ps
一覧に web-log-app が引き続き表示されます。
後片付け：
実験が終了したので、リソースを解放するためにコンテナを停止して削除します。ここでは、実行中のコンテナを強制的に削除する docker rm -f を使用します。このコマンドは停止と削除をまとめて実行します。
docker rm -f web-log-app
まとめ
この実験では、Docker コンテナのログにアクセスする基本的な方法を学びました。次の操作を実践しました。
- バックグラウンドプロセスを実行する:
docker run -dを使って、ターミナルを占有せずに実行する。 - 既存のログを表示する:
docker logs <container_name>を使って、過去の出力を確認する。 - ログをリアルタイムで監視する:
docker logs -f <container_name>を使って、生成された出力をその場でストリーム表示する。 - デタッチする:
Ctrl+Cを使ってログの表示を停止し、アプリケーションの実行は継続する。
これらのスキルは、さまざまな環境でコンテナ化されたアプリケーションをデバッグおよび監視するために不可欠です。
