「クリーンな」イメージでのデバッグの苦労
私はDockerイメージをビルドする際、常に「軽量でコンパクト」であることを優先しています。alpineやdistrolessを使用することで、イメージのサイズを200MBからわずか5〜10MBに削減できます。これはデプロイを高速化するだけでなく、セキュリティの脆弱性を最小限に抑えることにも繋がります。
しかし、この軽量さは諸刃の剣でもあります。ある時、本番環境でデータベース接続エラーが発生しました。確認のためにdocker exec -it app shを実行したところ、executable file not found in $PATHというメッセージが表示されました。distrolessイメージにはシェルもcurlもlsも入っていません。エラーを特定するために、イメージを再ビルドし、ツールを追加してレジストリにプッシュし、再度デプロイし直さなければなりませんでした。このプロセスで15〜20分もの時間を無駄にしてしまいました。
Lệnh docker debugコマンドは、この問題を根本的に解決するために誕生しました。元のイメージを変更することなく、どんなに「空っぽ」なコンテナであっても、フルセットのツールを備えた環境で中に入ることができます。
docker debugの仕組み
ターゲットコンテナ内で直接実行する代わりに、docker debugは「サンドボックス（sandbox）」環境を作成します。この環境には、vim、nano、htop、curl、gitなどの一般的なツールがあらかじめ含まれています。その後、エラーが発生しているコンテナ의ファイルシステムをこのサンドボックスにマウントします。
最大の利点は、元の状態を維持できることです。コンテナは通常通り動作し続け、不要なツールがインストールされることもありませんが、内部の隅々まで調査するための「道具」はすべて揃っています。
インストールと準備
この機能は現在、Docker Desktop（Pro、Team、Businessプラン）で利用可能です。Linuxを使用している場合は、Docker CLIプラグインを介してインストールできます。以下のコマンドで、お使いの環境が対応しているか確認してください：
docker debug --versionターミナルに特定のバージョンが返されれば準備完了です。そうでない場合は、Docker Desktopを最新バージョンにアップデートして試してみてください。
実践：実行中のコンテナをデバッグする
例えば、非常に軽量なalpine版のNginxコンテナがあるとします。設定ファイルを確認したいけれど、vimをインストールするのは面倒だという場合、次を実行するだけです：
docker debug <コンテナIDまたは名前>すぐに新しいシェルが表示されます。ここでは、lsやcat、リソース監視のためのtopなどを自由に使用できます。
ちょっとしたコツ：数千行の長いJSONを返すAPIをデバッグする場合、ターミナルで読むのは非常に疲れます。私はよくその内容をコピーして、toolcraft.appのJSON Formatterを使用して整形しています。この方法は、コンテナにフォーマット用プラグインを無理やりインストールするよりも遥かに高速です。
ファイルシステムへの介入
デバッグ環境では、ターゲットコンテナのファイルシステム全体がマウントされます。仮説をテストするために、設定ファイルを直接編集することも可能です：
# Nginx設定のクイック編集
vim /etc/nginx/nginx.confこれらの変更は通常、一時的なものであることに注意してください。しかし、Dockerfileに正式に反映させる前にエラーを確認する際には非常に役立ちます。
ネットワークとプロセスの詳細調査
マイクロサービス間の接続エラーは、常に難しい課題です。docker debugを使えば、netstatやdrill（非常に強力なnslookupの代替ツール）が最初から用意されています。
# リッスンしているポートを確認
netstat -tulpn
# コンテナ間の内部DNSを確認
drill database-service本番イメージにiputilsやbind-toolsを苦労してインストールする必要はもうありません。すべてがDockerのツールボックスに統合されています。
停止したコンテナ（Stopped）からのデータ復旧
これが私の一番のお気に入り機能です。コンテナがクラッシュ（Exited状態）した場合、docker execコマンドは使えません。通常はログを確認することしかできませんが、ログに原因が記録されていないこともあります。
docker debugを使用すると、停止したコンテナにアクセスできます。そのコンテナの最後のスナップショットに基づいて環境が初期化されます：
docker debug <停止したコンテナID>以前、設定ファイルの構文エラーで起動直後にサービスが停止してしまったという「難解な」ケースを解決したことがあります。docker debugのおかげで、docker logsには表示されなかった内部ログファイルを読み取ることができました。
効果的に使用するための注意点
非常に強力なツールですが、戸惑わないために以下の点に注意してください：
- アクセス権限: このコマンドにはDockerソケットへの介入権限が必要です。本番環境でこのコマンドを実行できるユーザーを厳格に管理してください。
- 速度: 初回実行時は、Dockerがツールボックスイメージをダウンロードするのに約30秒かかります。2回目以降はほぼ瞬時に実行されます。
- 正しい考え方: デバッグを一時的な修正で終わらせないでください。原因を特定した後は、必ずDockerfileやConfig Mapに戻って根本から修正するようにしましょう。
ネットワークテストのためだけにcurlやtelnetをインストールすることに飽き飽きしているなら、今すぐdocker debugを試してみてください。イメージをクリーンで安全な状態に保ちつつ、トラブル発生時には非常に管理しやすくなります。
