docker exec / docker logs でコンテナ内部を調べる方法
はじめに
Dockerのコンテナ運用を始めると、コンテナの中で起きている事象を確認したいと思う場面が出てきます。
たとえば「アプリが正しく起動していない」「コンテナ内部のファイルを見てみたい」といったケースです。
こうしたときに有用なコマンドとして、docker exec と docker logs があります。
この2つを使えば、コンテナ内部で起きている事柄を具体的に把握できるようになります。
本記事では、それぞれのコマンドの基本的な使い方から実務における活用シーンまでを、初心者の方でも理解しやすいように解説します。
コンテナ内部を知るために覚えておきたいポイントを、具体的な例を交えながら見ていきましょう。
この記事を読むとわかること
- docker exec でコンテナ内部を操作する基本手順
- docker logs でログを取得・分析する方法
- 実際の開発や運用で遭遇するトラブルシュート事例と、その対処アプローチ
- セキュリティを含めた注意点やログ運用のポイント
これらを知っておくと、トラブルが発生したときにコンテナ内部の状況をつかみやすくなります。
本記事を参考に、効率のよいコンテナデバッグや運用を進めてみてください。
docker exec / docker logsでできること
コンテナで動作するアプリケーションが思わぬ挙動をしたとき、中の状態を直接確かめたくなる場面があります。
たとえば、ファイルが正しく配置されているか確認したり、実行中のプロセスが想定どおりになっているかなどを調べたいときです。
そんなときに役立つのが、docker exec と docker logs です。
それぞれの特徴を簡単にまとめると、以下のようになります。
docker exec
コンテナ内でコマンドを実行し、リアルタイムに操作できる
シェルに入ってファイルを確認したり、パッケージをインストールして試験的に動作を見たりできる
docker logs
コンテナが出力しているログを表示できる
標準出力（stdout）や標準エラー出力（stderr）に流れた情報を一覧で確認できる
いずれも、コンテナの状態を把握したり、アプリケーションのエラー原因を突き止めたりするために欠かせないコマンドです。
この2つを組み合わせて使うことで、より効率的に問題を解決できます。
docker execとは
docker execの基本的な役割
docker exec は、すでに実行中のコンテナに対して追加のコマンドを実行させるためのコマンドです。
コンテナが起動している最中、外からコンテナ内へ入り込み、シェルを立ち上げて操作したり、特定のプログラムを起動したりできます。
コンテナ内部のファイル構造を見たい場合や、実際にアプリケーションが配置されているか確認する場合、あるいはコンテナ内のプロセス状態を調べたい場合などに便利です。
このコマンドがあることで、コンテナをわざわざ停止させなくても問題点を直接確認できるようになります。
docker exec の使い方の一例
コンテナ名を my-container とし、そのコンテナに bash シェルで入りたい場合は、次のようにします。
docker exec -it my-container bash
ここで使われているオプションは以下の通りです。
- -i: コンテナの標準入力を有効にする
- -t: 擬似的なターミナルを割り当てる
これを実行すると、コンテナ内部で bash が起動し、コンテナ内のシェル環境に入れます。
あとは通常のLinuxサーバーにログインしたように、ファイルを参照したりコマンドを実行したりできるようになります。
ちょっとした操作ならdocker execで完結する
docker execを使えば、以下のような操作が直感的に可能になります。
- コンテナ内の特定ファイルを確認 (
cat /path/to/file) - パッケージマネージャーで不足ライブラリを導入してテスト
- プロセスの稼働状況を確認 (
ps aux,topなど)
こうした調査を手早く行えるのが、docker exec の強みです。
ただし、本番環境では権限やセキュリティポリシーを厳密に管理する必要があるため、無闇にコンテナ内部に入らないように注意することも大切です。
docker logsとは
ログの種類を把握する
一方、docker logs は、コンテナが標準出力や標準エラー出力に送っているログを表示するコマンドです。
Dockerのコンテナは、アプリケーションが出力するログをホスト側に中継しており、docker logs で簡単に参照できます。
たとえば、Webサーバーコンテナであればアクセスログやエラーログが標準出力に流れていることがあります。
また、自作のアプリケーションが console.log や print() で出力した情報が標準出力・標準エラーに流れれば、docker logs で確認できる仕組みです。
docker logs の基本的な使い方
docker logs の基本コマンド例は以下の通りです。
コンテナ名を my-container として、ログを出力するには次のようにします。
docker logs my-container
コンテナで出力されたログが、そのまま自分のターミナルに表示されます。
動作中のコンテナが大量のログを吐いている場合には、端末に一気に流れてくるかもしれません。
そこで頻繁に使われるオプションとして以下があります。
- -f: ログの追尾（tail -f のような動き）
アプリがリアルタイムで出力するログを、そのまま流し見できる - --tail: 過去のログの末尾から何行分を表示するか指定
また、重要なエラーメッセージなどを見逃さないようにするために、標準のLinuxコマンド (grep, less など) と組み合わせることも多いです。
docker execでコンテナ内部を覗く基本操作
シェルを起動して調査する
先ほど紹介したように、docker exec -it コンテナ名 bash でコンテナ内に入れます。
この状態で通常のLinuxコマンドを実行し、ファイルシステムやプロセス一覧を調べるのが基本的な流れです。
コンテナ内で以下のような調査をすることが多いでしょう。
- ファイルの在りかを確認:
ls -l /path/to/dir - 設定ファイルの内容をチェック:
cat /etc/config-file - ネットワーク設定の確認:
ip addrやnetstat -tnlpなど
シンプルにbashを起動するだけで、コンテナ内部の環境を目で確かめられます。
docker exec による一時的なコマンド実行
シェルには入らず、一発コマンドだけ実行したい場合もあります。
たとえば、コンテナ内部の /etc/hosts ファイルを確認したいなら、次のようにします。
docker exec my-container cat /etc/hosts
このように、一時的に必要なコマンドを実行して結果を標準出力で受け取れます。
bashを起動せずに済むため、ターミナルへの入退出の手間を省けます。
docker logsでログを確認する方法
スタンダード出力のログを追尾する
開発・運用中にリアルタイムでログを監視したい場面では、-f オプションを付けて使います。
例として、NginxなどのWebサーバーコンテナがあるときに、アクセスログを追尾するには次のようにします。
docker logs -f my-nginx
ログが随時出力されるたび、ターミナルにも新しい行が追加表示されていきます。
アクセス負荷試験などをしながらログを見たいときには便利です。
過去のログの確認やフィルタリング
ログの量が多いとき、すべてを眺めると大変です。
そこで便利なのが --tail オプションです。
たとえば直近の100行だけ見たい場合は次のようにします。
docker logs --tail 100 my-container
また、Linuxコマンド grep と組み合わせれば、特定のキーワードを含む行だけを抽出することも可能です。
以下のように書けば、エラー関連のメッセージを抽出できます。
docker logs my-container | grep "ERROR"
これによって、膨大なログの中から重要なポイントを素早く見つけやすくなります。
コンテナのトラブルシューティングに役立つdocker exec
ファイルの内容確認
トラブルシュート時によくあるのが、設定ファイルのミスによる問題です。
Webサーバーやデータベースの設定ファイルが書き換わっていないか確認するには、docker execでシェルに入り、ファイルを cat や less などで読むのが手軽です。
もしシェルに入り込む必要がない程度に単純な確認で済むなら、先ほど述べた一発実行の形 docker exec my-container cat /path/to/config で終わることもあります。
これならコマンド実行と同時にファイルの中身がホスト側ターミナルに表示されます。
パッケージの状態確認
コンテナイメージによっては、ベースとなるディストリビューションが異なるので、パッケージマネージャーもさまざまです。
apt, yum, apk など、Dockerfileで使われるものが違えば、中でインストールされるライブラリも違います。
docker execを使って、実際に apt list --installed のようなコマンドを叩けば、何がインストールされているのかを確認できます。
ライブラリのバージョンによる不整合などが原因でアプリケーションが動かない場合に、トラブルシュートにつながるケースもあります。
コンテナのトラブルシューティングに役立つdocker logs
デーモン系のログ確認
コンテナでデーモン（常駐プロセス）が動いている場合、標準出力にログを出すよう設定されていることがあります。
例えば、NginxやApacheなどは設定を少し変えることでアクセスログやエラーログを標準出力に流せます。
その場合、docker logs を使うだけで主要なログを一括管理できるメリットがあります。
ホスト側でログファイルを直接探す必要がなくなるので、コンテナごとにログを管理する仕組みがシンプルになりやすいです。
アプリケーションのエラーログ確認
自作のアプリケーションをコンテナ化しているなら、標準エラー出力にエラーログを出すようにしておくと、docker logs だけで手軽にチェックできます。
たとえばPythonであれば print("エラー内容", file=sys.stderr) のように書いておくと標準エラー出力に流れます。
本番稼働のアプリケーションで想定外の動作が発生した際、docker logs でエラー情報をさかのぼって調べられるのは大きな利点です。
問題があれば、ログを頼りにコンテナ内部に入ってさらに詳しく調査するといった流れになります。
実務での活用シーン
アプリケーションが動作しない場合
「コンテナは起動しているのに、アプリケーションが応答しない」ケースはよくあります。
こうしたときはまず docker logs でエラー出力がないかを確認し、原因が設定ファイルにあるかも、と思ったら docker exec でシェルに入り、設定内容を細かくチェックする流れが一般的です。
もしファイルパスの間違いなど初歩的なケアレスミスなら、コンテナ内部のファイルを見ただけで判明します。
ログにエラーが吐かれている場合も、そのメッセージをヒントにしてさらに調査を進められます。
サービスが応答しない場合
ネットワーク絡みの問題でコンテナ内のプロセスが待ち状態になっていることもあります。
docker exec -it my-container bash でコンテナに入り、netstat -tnlp や ss -lntp などのコマンドでポートがLISTENしているかどうかを確認すると、サービスがそもそも待機していない場合がわかるでしょう。
また、curl localhost:ポート番号 のようにローカルでアクセスしてみると、外部からのアクセスがブロックされているのか、アプリケーションが立ち上がっていないのかなどを見極めやすくなります。
これもdocker execを使ったトラブルシュートの代表的な例です。
コンテナを監視する運用例
本番運用では、多くのコンテナが同時に稼働している場合があります。
その際、個別にコンテナへexecしてログを見るのは手間がかかります。
しかし、一時的な調査でどうしてもコンテナ内部を直接確認したいときにはdocker execが便利です。
ふだんは監視ツールなどでログを集約していても、最終的な突き止めにはコンテナ内部の状態確認が欠かせないことがあります。
こうした場合にも、docker exec や docker logs を使い慣れていると素早い対応ができます。
docker exec / docker logsを使う上での注意点
コンテナの権限管理
docker exec は、コンテナ内部のシェルに入れる強力な手段です。
本番環境など重要な環境で誤った操作をすると、データを消してしまったり、設定ファイルを壊してしまったりするリスクがあります。
そこで、権限のあるユーザーだけが docker exec を実行できるように、sudoグループへの参加制限 や アクセス制御リスト を活用するケースがあります。
「誰がコンテナ内部に入れるのか」を明確にしておくと、トラブルを未然に防ぎやすいでしょう。
リソース競合への考慮
docker exec でコンテナ内のプロセスに手を加えると、タイミングによってはアプリケーションの挙動を変えてしまう可能性があります。
特に、高負荷状態で無理にいろいろコマンドを実行すると、CPUやメモリを余計に使ってしまうかもしれません。
また、docker logs も、巨大なログを一括で読み出すとホスト側のリソースを消費します。
本番環境で多数のログを一気に取り出す場合は、ログが大量に流れてネットワーク帯域を圧迫することもあり得ます。
こうした影響を考慮して、必要最低限の量や範囲のログだけを適切に取得する運用が望ましいでしょう。
他にもあるコンテナ内部調査のアプローチ
docker inspect
コンテナの状態や設定をJSON形式で確認できるコマンドに、docker inspect があります。
コンテナがどのようなネットワーク設定になっているのか、どのイメージから起動されたのかなど、さまざまな情報を取得できます。
ただし、docker inspect はコンテナ内部のファイルシステムやリアルタイムなプロセスの中身を見るのではなく、メタデータを参照するためのものです。
内部のログやファイルの実態をチェックしたい場合には、やはりdocker exec が必要になるでしょう。
コンテナを停止させずに対応するには
コンテナの停止を伴わないで情報を確認できる点は、docker exec と docker logs の大きな利点です。
環境によってはサービスを止められない場合もあるため、稼働中のコンテナに対してリアルタイムに調査を行えるのは助かります。
逆に、コンテナを停止させてイメージを再構築する方法もありますが、本番環境ですぐには止められないことが多いはずです。
だからこそ、この2つのコマンドが日常的な運用やトラブルシュートで重宝されるわけです。
docker logs の出力をさらに活用する
ログドライバーとの連携
Dockerにはさまざまなログドライバーが用意されており、json-file や syslog、journald などに対応できます。
これらを組み合わせることで、ログを外部のシステムに転送したり、ファイルとして保存したりできるようになります。
本格的なロギング環境を構築する場合は、コンテナから標準出力に流れたログを一元管理する仕組みが一般的です。
ただ、docker logs で見ることを前提にしているときは、json-file ドライバーなどが多く利用されています。
grepなどコマンドとの併用例
docker logs my-container | grep "POST /api/v1" のように検索をかければ、アプリケーションへの特定APIのリクエストだけを抜き出すこともできます。
同様に、| grep -v "DEBUG" のようにして不要な行を省く方法もあるでしょう。
このように、標準のLinuxコマンドをパイプで連携させると、ログ解析の自由度が高まります。
簡単な調査であれば、外部のログ管理ツールを使わなくても十分に目的を達成できるはずです。
ローカル開発環境でのデバッグ手順
docker-composeと併用
開発時に複数のコンテナを立ち上げて連携させる場合は、docker-compose を使うことがあります。
このとき、docker-compose が作成したコンテナに対しても、やることは同じです。
docker-compose ps などでコンテナ名を確認し、docker exec -it コンテナ名 bash でシェルに入り、ログは docker logs で見る形となります。
docker-compose.yml に書かれたサービス定義が複数あっても、それぞれのコンテナ名を指定すれば同様に操作可能です。
「どれが原因でエラーを出しているかわからない」といったトラブル時には、まず疑わしいコンテナのログを重点的に追うと効率的です。
volumeのマウント設定も活用
一部のファイルは、ホストマシンにマウントされていることもあります。
もし、コンテナ内部のファイル内容をすぐにホスト側で確認できる設定になっていれば、docker exec を使わなくてもファイルを直接読める可能性があります。
ただし、全てのファイルがマウントされているわけではないため、docker exec との併用が一般的です。
マウント設定によってホストとコンテナのファイルの同期状況を正しく理解しておけば、どのファイルがコンテナ内部専用なのかも区別しやすくなります。
本番環境での運用時のポイント
セキュリティ面の考え方
本番環境で docker exec を使う際は、操作を行う人がどの程度システム全体にアクセスできるのかを見極める必要があります。
root権限でシェルに入れば、コンテナ内の重要データを容易に閲覧・変更できるため、セキュリティポリシーを明確にしておくことが大切です。
また、docker logs で出力される情報にも注意が必要です。
機密情報が標準出力や標準エラー出力に含まれていると、それを扱うログ管理システムにも影響が及びます。
パスワードや秘密鍵などを誤ってログに出力しないよう、アプリケーション側で細心の注意を払うことが求められます。
ログの永続化や集中管理
docker logs を用いたログ確認は手軽ですが、コンテナが停止すると json-file ドライバーに保存されたログも場所によっては管理が煩雑になります。
大規模システムでは、FluentdやLogstashなどを使ってロギングを一元的に集約する手法がよく使われます。
本番運用では、必要に応じてログをクラウドストレージや外部のデータベースに蓄積し、長期間保管するといったことが多いです。
そのうえでリアルタイムに障害を検知する仕組みを整えつつ、いざというときには docker exec で突っ込んだ調査をする形が現場でよく見られる運用パターンです。
まとめ
Dockerコンテナを扱う上で、docker exec と docker logs は極めて重要なコマンドです。
どちらもコンテナ内部の情報をダイレクトに調べることができ、トラブルシュートやデバッグでは欠かせない手段となります。
- docker exec は、実行中コンテナにシェルで入り込んだり、コマンドを直接実行することでファイル・プロセスなどを確認
- docker logs は、コンテナが出力した標準出力・標準エラー出力のログを取得し、稼働状況やエラーを素早く把握
いずれも本番環境・開発環境問わず利用されるため、使い方に慣れておけば多様なケースで柔軟に対応できます。
ただし、権限管理やリソース消費などの注意点もあるため、実務では慎重に扱うことが大切です。
これら2つのコマンドをマスターしておくことで、コンテナ内部の状態を迷わず確認できるようになり、障害対応のスピードが格段に上がるでしょう。
みなさんのDocker運用の中で、ぜひ活用してみてください。