Docker ビルド チェックの概要: ベスト プラクティスを使用した Dockerfile の最適化

本日、 Docker Desktop4 .33 を使用した Docker ビルド チェック のリリースを発表できることを嬉しく思います。Docker ビルド チェックは、チームがコンテナ イメージを構築するためのベスト プラクティスを学習し、それに従うのに役立ちます。 Docker ビルドを実行すると、ビルドで検出されたチェック違反に対する警告の一覧が表示されます。プロアクティブなアプローチを取り、ビルドの警告と問題を早期に解決することで、ダウンストリームの時間と頭痛の種を節約できます。 

バナー:Dockerでウィービエイトベクターデータベースを設定する方法

なぜDockerビルドチェックを作成したのですか?

開発者との会話の中で、多くの人がコンテナイメージを構築するためのベストプラクティスを学び、それに従うのに苦労していることがわかりました。 2024 の「アプリケーション開発の現状」レポートによると、Docker ユーザーの 35% が、Dockerfile の作成と編集を上位 3 つのタスクの 1 つとして挙げています。しかし、回答者の 55%は、Dockerfileの作成がサポートとして最も選択されているタスクであると報告しています。 

多くの場合、開発者は Docker Buildのドキュメントを読み、物事を機能させるために必要な変更を加え、次に進む余裕はありません。 Docker ビルドは、 docker build を実行すると "機能" する可能性がありますが、適切に記述されていない Dockerfile は、次のような品質問題を引き起こす可能性があります。

  • 保守や更新が難しい
  • 隠れたバグや予期しないバグを封じ込める 
  • パフォーマンスが最適ではない

Docker ユーザーとの会話では、ビルドのパフォーマンスを向上させるために Dockerfile を最適化したいと考えている、現在のベスト プラクティスを認識していない、ビルドのガイドを受けたいと考えているという声を聞きました。 

ビルドの問題を調査して修正すると、時間が無駄になります。 Docker Build チェックは、開発者が最初から適切に構造化された Dockerfile を作成し、既存のベスト プラクティスから学べるようにするために作成されました。 ビルド チェックを使用すると、チームはビルドの問題に費やす時間を減らし、イノベーションとコーディングにより多くの時間を費やすことができます。   

なぜDockerビルドチェックを使用する必要があるのですか? 

より良いDockerfileを作成し、時間を節約したい! 

私たちは、ビルドの専門家のコミュニティから一連のベストプラクティスを収集し、それらをDocker Buildツールに体系化しました。 Docker ビルド チェックを使用して、マルチステージ ビルドや ベイクなど、ローカルワークフローと CI ワークフローのすべてのステージを評価し、 Docker Desktop の [ビルド] ビューで詳細を確認できます。 スキップするルールを選択することもできます。 

Docker ビルド チェックには、CLI と Docker Desktop の [ビルド] ビューからアクセスできます。 

リンティング以上のもの:Docker Buildチェックは強力で高速です 

リンティングツールは通常、一連のルールに照らしてテキストファイルを評価するだけです。 Docker Buildのネイティブ部分であるDocker Buildチェックのルールは、単なるリンティングよりも強力で正確です。 Docker ビルド チェックでは、渡された引数や使用される基本イメージを含むビルド全体を評価します。 これらのチェックは、Dockerfile を編集するときにリアルタイムで実行できるほど高速です。 ビルドの完全な実行を待たずに、ビルドをすばやく評価できます。 

ローカルビルドを確認する

新しい Dockerfile または更新された Dockerfile をコミットまたは共有する前に評価することをお勧めします。 docker buildを実行すると、Dockerfile の問題と警告の概要がわかるようになりました。

ビルド チェック 433 f1
図 1: 4 つのチェック警告が表示された Docker ビルド。

これらの特定の問題に関する詳細情報を取得するには、 docker --debug buildを使用して Docker CLI にデバッグ フラグを指定できます。 この情報には、警告の種類、警告が発生する場所、および警告の解決方法に関する詳細情報へのリンクが含まれます。 

ビルド チェック 433 f2
図 2: チェック警告のデバッグ出力を作成します。

ビルドをすばやく確認

ビルド中にこれらのチェックを実行するのは素晴らしいことですが、変更を加えたり問題を修正したりするときに毎回完全なビルドが実行されるのを待つのは時間がかかる場合があります。 このため、ビルド コマンドの一部として --check フラグを追加しました。 

# The check flag can be added anywhere as part of your build command
docker build . --check
docker build --check .
docker build --build-arg VERSION=latest --platfrom linux/arm64 . --check

次の図に示すように、既存のビルド コマンドにフラグを追加すると、ビルド全体を実行しなくても、ビルド構成の完全な評価が行われます。 この迅速なフィードバックは、通常 1 秒未満で完了するため、開発プロセスがスムーズになります。 

ビルド チェック 433 f3
図 3:ビルドの実行中のチェック。

CI ビルドを確認する

デフォルトでは、警告付きで Docker ビルドを実行しても、ビルドは失敗しません (0 以外の終了コードが返されます)。 ただし、CI ビルドの回帰をキャッチするには、次の宣言を追加して、エラーを生成するようにチェックに指示します。 

# syntax=docker/dockerfile:1
# check=error=true

FROM alpine
CMD echo "Hello, world!"

CI でのマルチステージビルドの確認

ビルド中は、指定されたステージ/ターゲット (その依存を含む) のみが実行されます。 ワークフローにステージ チェック ステップを追加して、Dockerfile の完全な評価を行うことをお勧めします。 これは、フルビルドを実行する前に自動テストを実行する方法と似ています。

警告が検出された場合は、ゼロ以外の終了コードが返されるため、ワークフローが失敗するため、問題がキャッチされます。

docker build --check .

Docker Build Cloud でのビルドの確認

もちろん、これは Docker Build Cloud とも、ローカルと CI の両方でシームレスに機能します。 既存のクラウドビルダーを使用して、ビルドを評価します。あなたのチームは、Docker Build Cloud のパフォーマンスと、ビルドがベスト プラクティスに合致しているという安心感を兼ね備えたメリットを得られるようになりました。 実際、チェックを拡大すると、Docker Build Cloudビルドのパフォーマンスがさらに向上するはずです。

ビルド チェック 433 f4
図 4:Docker Build Cloudでチェックを実行する。

ルールの設定

ビルド チェックで skip 引数を使用してルールを柔軟に構成できます。 また、 skip=all または skip=none を指定して、ルールのオンとオフを切り替えることもできます。 JSONArgsRecommendedルールとStageNameCasingルールをスキップする例を次に示します。

# syntax=docker/dockerfile:1
# check=skip=JSONArgsRecommended,StageNameCasing

FROM alpine AS BASE_STAGE
CMD echo "Hello, world!"

Docker Desktop の [ビルド] ビューを深く掘り下げる

Docker Desktop の [ビルド] ビューでは、ビルド警告の出力を確認できます。 Dockerfile で警告の原因を特定し、それらを迅速に解決する方法を理解するのが簡単になりました。

ビルドエラーと同様に、Docker Desktop でビルドを検査すると、警告が Dockerfile にインラインで表示されます。

ビルド チェック 433 f5
図 5: ビルドは、Docker Desktop の [ビルド] ビューで警告をチェックします。

次は何ですか? 

その他のチェック

新しいビルドチェックにより、Dockfileにベストプラクティスを適用できるようになったことを嬉しく思いますが、これはほんの始まりに過ぎません。 現在の一連のチェックに加えて、ビルドのより包括的な評価を提供するために、さらに多くのチェックを追加する予定です。さらに、Docker ビルドのカスタム チェックとポリシーを含めることを楽しみにしています。

IDE統合

ビルドの問題を早期に特定すればするほど、その解決が容易になり、コストも安くなります。 ビルドチェックをお気に入りのIDEと統合して、入力時にリアルタイムのフィードバックを得ることができるようにする予定です。

ビルド チェック 433 f6
図 6: VS Code に表示されるチェック違反。

GitHub Actions と Docker Desktop

Docker Desktop では既にビルド チェックの警告を確認できますが、より詳細な分析情報は近日中に Docker Desktop にも公開される予定です。 ご存知かもしれませんが、最近、GitHub Actions のベータ リリース で Docker ビルドの検査を発表し、この新機能に基づいて、チェック警告の調査のサポートを含める予定です。

今すぐ始める

Docker ビルド チェックの使用を開始するには、今すぐ Docker Desktop の 4.33 にアップグレードし、既存の Dockerfile で試してみてください。ビルドチェックの詳細な内訳については、 ドキュメント をご覧ください。 

さらに詳しく