Visual Studio Code を使用した Docker ビルドのデバッグ

Docker イメージの構築は、最新のアプリケーションのソフトウェア配信パイプラインの重要なコンポーネントです。これは、アプリやサービスをパッケージ化して、他のユーザーに配布したり、本番環境にデプロイしたりできるようにする方法です。Dockerfile は長い間コンテナー イメージを定義するための標準でしたが、問題が発生した場合に変更を加えたりデバッグしたりすることが困難であることが知られています。現在、ビルドのさまざまな段階で ビルド時の状態を理解することは非常に面倒 です。ARGの状態はどうでしたか?どのファイルがイメージにコピーされましたか?

最近、Docker を使用する際の開発者エクスペリエンスを向上させるために、Docker ビルド クライアント (Buildx) と VS Code 拡張機能 (Docker DX) を更新しています。今日は、VS Code と Docker Build でのビルド デバッグの導入により、そのプロセスの次の段階を共有します。

Docker の Buildx の新しいデバッグ機能を使用すると、Docker ビルドの修正に費やす時間を短縮できます。この投稿では、Visual Studio Code で Buildx デバッガーを構成し、ビルドをステップ実行して変数とイメージのファイル システムを検査し、ビルド中のイメージ内でシェルを開く方法について説明します。最後に、デバッガーの実装と、デバッガーを他のエディターに統合する方法について少し学びます。

Visual Studio Code の構成

Visual Studio Code で Dockerfile のデバッグを開始するには:

1. 最新バージョンの Docker DX 拡張機能をインストールします。
2. 最新バージョンの Docker Desktop に更新して、最新の Docker ビルド ツールを使用していることを確認します。
3. docker buildx versionを実行し、Buildx が少なくともバージョン 0.29.x であることを確認します。

起動設定の作成

Dockerfile を開き、Visual Studio Code で [実行とデバッグ] ビューを開きます。起動設定がない場合は、次のような内容が表示されます。

図 1: 起動構成が定義されていない Visual Studio Code で開かれた [実行] ビューと [デバッグ] ビュー。

「launch.jsonファイルの作成」ハイパーリンクをクリックします。起動設定がある場合は、[実行とデバッグ] ビューの右上隅にある歯車アイコンをクリックして、 launch.json ファイルを開きます。

launch.json ファイルで、Docker ビルドをデバッグするための新しい起動構成を作成します。以下のサンプルを使用して開始できます。起動設定の様々な属性の詳細については、 こちらを参照してください。

{
  "name": "Docker: Build",
  "type": "dockerfile",
  "request": "launch",
  "dockerfile": "Dockerfile",
  "contextPath": "${workspaceFolder}"
}

ブレークポイントの追加

起動構成の設定が完了したので、Dockerfile にブレークポイントを追加しましょう。エディターの左余白をクリックするか、F9を押して、RUN指示の 1 つの横にブレークポイントを配置します。ブレークポイントが追加されたことを示す円が表示されます。

デバッガの起動

これで、デバッガを起動する準備ができました。作成した起動設定を選択し、F5をクリックします。ビルドは、ブレークポイントを配置した RUN 行で一時停止する必要があります。

図 2: Visual Studio Code のブレークポイントによって中断された Docker ビルド。

デバッグ機能

次に、Buildx デバッガーが提供する 3 つの異なる機能について説明します。

変数の検査

ビルドが中断状態にある場合は、定義されている可能性のある変数を確認できます。この例では、実行されたコマンドの workdir 値を左側で見ると、内容を /app にコピーしたため、コマンドが右側のフォルダーで実行されていないことがわかります。これは、RUN行の前にWORKDIR /appを追加することで修正できます。また、画像によって定義された変数と、 VAR と NODE_VERSIONで見られるベース画像を表示できることにも注意してください。

図 3: Docker ビルドでエラーが発生し、終了するのではなくデバッガーによって中断されます。

エクスプローラー

変数を検査するだけでなく、ファイルシステムの構造を調べて、すでに存在するものとコピーしたものを確認することもできます。テキストファイルの場合、ファイルの data フィールドに示されているように、ファイルの内容も確認できます。

図 4: ビルド中のDockerイメージのファイルシステムを表示します。

対話型デバッグ

適切な Dockerfile の作成は、多くの場合、反復的なプロセスです。これは、通常、開発中のホストシステムが、構築しているイメージとほとんど類似点がないためです。Ubuntu をローカルで実行することと、Alpine Linux イメージをビルドしようとすることの違いを考えてみましょう。パッケージ名の小さな違いにより、適切な名前を検索するときに、エディターとブラウザーの間で多くの行き来が生じます。ここに行を追加してから、別の行を別の場所にコメントしてから、もう一度実行して最善を尽くす docker build 。

この反復プロセスは、デバッガーの助けを借りて合理化できるようになりました。ビルドが中断状態の場合は、[デバッグ コンソール] ビューを開き、下部の入力フィールドにカーソルを置きます。execを入力し、Enter キーを押します。ターミナルビューが開き、ビルド中のイメージにアタッチされたシェルが表示されます。

図 5: デバッグ コンソールを使用して、 exec を実行してビルド中の Docker イメージにシェルを開きます。

図 6: ビルド中の Docker イメージに、ターミナルでアクセスして検査できるようになりました。

この機能は、任意のステップで Dockerfile のイメージを簡単に開き、その内容を調べ、テスト用のコマンドを実行できるようになるため、ゲームチェンジャーです。以前は、バグのある行の後にすべてをコメントし、Dockerイメージをビルドしてから、手動で実行してシェルをイメージに開く必要がありました。これらすべてが、エディターにブレークポイントを追加し、デバッグセッションを開始することに凝縮されています。
ターミナルで行った変更は どれも保持されないため 、これは純粋に実験用であることに注意してください。下の図では、デバッガーが 3行目で一時停止されたときにファイルが作成されたことがわかります。デバッガを 4行に進めると、ファイルが消えた。

図 7: exec ターミナル内の Docker イメージへの変更は、デバッガーが別の行にステップするとリセットされます。

オープン仕様による統合

言語サーバープロトコル を実装する Docker言語サーバー での作業と同様に、Buildxデバッガーはデ バッグアダプタープロトコル を実装するため、オープンスタンダードに基づいて構築されているため、プロトコルをサポートする任意のエディターでDockerfileビルドをデバッグできます。Visual Studio Codeの他に、 Neovimの公式プラグインも提供しています。JetBrains ユーザー向けに、 LSP4IJ プラグインとうまく統合できることを確認しました。お気に入りのエディターがデバッグアダプタープロトコルをサポートしている場合は、Buildxデバッガーをそれと統合する方法があるはずです。

ありがとうございました

この機会を利用して、この機能に関するアイデアと最初の作業をしてくれた Kohei Tokunaga (ktock) に感謝したいと思います。彼がBuildxに提供した貢献は、この機能を構築して完成させるための素晴らしい基盤を提供してくれました。彼の助けがなければ、この釈放は不可能だったでしょう。ありがとう、こく平さん!

次のステップ

• Docker DX 拡張機能をダウンロードして、新しいデバッグ機能を試してください。
• フィードバックや問題は、 Docker DX と Buildx の GitHub リポジトリで共有してください。
• Docker フィードバック ページからフィードバックを送信することもできます。

詳細情報

• nvim-dap-dockerを使用してNeovimでBuildxデバッガーをセットアップします。
• LSP4IJ プラグインを使用して、JetBrains エディターで Buildx デバッガーをセットアップします。
• DAP の実装と起動の設定については、Buildx のドキュメントをお読みください。