なぜ「書きながら気づく」がうれしいのか
Dockerfile を書いて保存し、docker build](/articles/docker-infuragou-zhunitsuiteyokuaruzhi/) . を叩いてからベースイメージの pull が始まり、数分経ってようやく「パスが違う」「パッケージが見つからない」と返ってくるーー このループ、地味に時間を奪われますよね。[Docker DX は VS Code マーケットプレイスからインストールできる拡張機能で、Docker Engine がローカルで動いている環境で、Windows / macOS / Linux 双方の arm・amd64 に対応しています。
肝心の挙動は Problems パネル（Mac なら Ctrl + Shift + M）を開くと現れます。たとえば Node.js アプリの Dockerfile に対し、node:20-alpine のような小さくてサポートされたベースイメージへの置き換え提案、npm install ではなく lockfile を厳密に再現する npm ci の推奨、シグナルがきちんと転送される Exec 形式の CMD への指摘など、レビューでよく出てくるポイントがエディタ上で次々と並んでくれます。修正するたびに Problems パネルがリアルタイムで消えていく、そのフィードバックループ自体がこの拡張機能の価値です。
docker-compose.yml まで含めて「プロジェクト全体」を見てくれる
1 枚の Dockerfile だけならまだしも、実際のアプリでは docker-compose.yml と組み合わせて Postgres などを並べることが多いですよね。ここで Docker DX の良さが一段上がります。Compose スキーマと隣の Dockerfile を一緒に解釈してくれるため、build: . にカーソルを合わせると実際に解決される Dockerfile のプレビューが出たり、未定義の env / network / volume を参照した瞬間に警告が出たりします。ブロック内の補完も単なるインデント推測ではなくスキーマ準拠なので、environment: や ports: での入力ミスを早めに潰せます。
たとえばわざと db サービスを database にリネームしたまま DATABASE_URL と depends_on が古い名前を指している状態を作ると、docker compose up で暗号のような接続エラーになる前に、その不整合を Problems パネルが拾ってくれます。ビルド後に「あれ、繋がらない」と頭を抱えていた時間がぐっと短くなる感覚です。
導入時に確認しておきたいこと
- まずローカルで Docker Engine が稼働していることを確認してください。拡張機能単体では解析のためのランタイム前提があるので、ここが外れると Problems パネルが空のままになります。
- 既存プロジェクトで試すときは
Dockerfileとdocker-compose.ymlを同じディレクトリに置いて、はじめて「プロジェクト全体を見る」挙動が活きてきます。 - 試すなら最初は小さな Node アプリで十分です。
node:20-alpineへの書き換えとnpm ciへの変更を Problems パネル経由で通すと、レビュー観点の動きが体感しやすいですよ。
次のステップとしては、CI 上の docker build を回す前にこの拡張機能で一度 Problems パネルを空にしておく、というフローを朝の儀式にしてみると、再現性のあるローカル検証と CI の役割分担がはっきりしてくるはずです。まずは手元の Dockerfile を 1 つ開いて、Problems パネルが何を言ってくるか覗いてみてください。