2024 年の Docker に関する 8 つのヒントとコツ

この記事は、Docker Captain の Vladimir Mikhalev 氏の寄稿によるものです。

Dockerファンの皆さん、新年あけましておめでとうございます。 2024年が素晴らしいスタートを切ることを願っています。 Dockerのエキスパートであろうと、Dockerコミュニティに不慣れであろうと、Dockerを最適化したり、より迅速に開始したりするための最良の方法について疑問に思うかもしれません。 DockerのキャプテンおよびシニアDevOpsエンジニアとして、私はDockerを6年以上使用しており、2024年のスリリングなアップデートを楽しみにしています。  

この投稿では、実際の経験とインサイダーの知識を通じて収集したDockerの8つのヒントとコツを共有できることを嬉しく思います。

Dockerで生産性を飛躍的に向上

1。 VirtioFSを有効にして、Macでのファイル共有を高速化します

MacのDockerでのファイル共有が低調だった日々を覚えていますか?重いファイル I/O 操作と格闘し、同期が長引くたびに時計を見ていました。 それは単なる忍耐力の試練ではありませんでした。これは、ワークフローの真のボトルネックでした。

しかし、ここで朗報があります: Docker Desktop for Mac 4.6 では、それは歴史です。 [設定] > [一般] に移動し、[VirtioFS] を選択します。

パフォーマンスの飛躍は、実際に体験してみないとわからないものです。 コンテナ化されたアプリの構築、実行、更新のいずれにおいても、すべてがよりスピーディーに感じられます。 一秒一秒が重要なペースの速い開発環境にいる私たちにとって、新鮮な空気を吹き込むものです。

このアップグレードは生産性の面で大きな勝利であり、2024 年の Docker の方向性に期待している多くの理由の 1 つにすぎません。 このような改善により、Dockerは単なるツールではなく、開発の強力な味方となっています。

2。 Docker Buildキャッシュを最適化するための戦略的レイヤー化

Dockerfileの効率性についてお話ししましょう - これは、私が数え切れないほど何度も取り組んできたことです。 昔は、Dockerのビルドはスローダンスのように感じられました。 コードに小さな変更を加え、ビルドが完了するまで永遠のように感じられる時間を待ちます。 これは、特に迅速にイテレーションを行っていて、小さな変更をテストする必要がある場合に、頻繁にフラストレーションが溜まることでした。 問題を。 当社のDockerfileは効率的なキャッシュのために最適化されていなかったため、不必要な再構築や時間の浪費につながっていました。

私が学んだ秘訣は、Dockerfileに戦略的な階層化を加えることで、流れを変えることができるということです。 依存関係のインストールなど、頻繁に変更されない手順を一番上に配置します。 次に、アプリケーションコードのCOPYコマンドまたはADDコマンドを下に配置します。 

この構造はゲームチェンジャーです。 つまり、Docker は Dockerfile の上位部分にキャッシュされたレイヤーを再利用でき、実際に変更されたものだけを再構築できます。 その結果は? ビルド時間が短縮され、コーディングにより多くの時間を費やし、待ち時間を減らすことができます。

別のライフセーバーは、パッケージをインストールするときに使用 RUN --mount type=cache しています。 この小さな gem は、ビルド間でパッケージキャッシュをそのまま保持します。 イメージを構築するたびにインターネット全体を再ダウンロードする必要はもうありません。 これは、大きな依存関係で作業している場合に特に便利です。 これを実装して、ビルド効率が向上するのを見てください。

より良いアイデアを提供するために、Node.js アプリケーションの Dockerfile でこれらの原則を適用する方法を次に示します。

# Use an official Node base image
FROM node:14

# Install dependencies first to leverage Docker cache
COPY package.json package-lock.json ./

# Using cache mount for npm install, so unchanged packages aren’t downloaded every time
RUN --mount=type=cache,target=/root/.npm \
    npm install

# Copy the rest of your app's source code
COPY . .

# Your app's start command
CMD ["npm", "start"]

この Dockerfile の例では、戦略的なレイヤー化と RUN キャッシュの使用方法を実際に示し、これらのプラクティスによって Docker ビルドを大幅に最適化する方法を示します。

これらのプラクティスを採用することで、私のDockerエクスペリエンスは変わりました。 Dockerが世界を再構築する間、スピナーを見る必要はもうありません。 むしろ、迅速なイテレーション、迅速なフィードバック、生産性の向上です。 正直なところ、それこそが私たちの仕事の効率性です。

3。 ビルドを効率的に保つために肥大化を避けます 

7 月 2024 日更新: Docker Build は Docker Desktop 4でロールアウトされた GA を確認します。33。 Docker Buildチェックは、開発者が最適化されたDockerfileを作成するのをガイドし、効率を向上させ、ビルド時間を短縮します。 

Dockerの初期の頃は、ビルドのサイズがあまりにも大きいため、しばしばつまずいていました。 週末の旅行のために家全体を荷造りするようなものでした。 大量の不要なファイルをDockerデーモンに送信することになり、ビルドコンテキストが肥大化し、ビルド時間が痛々しいほど遅くなります。 物事を無駄なく俊敏に保とうとしている場合には、あまり理想的ではありません。

そのカギ。ビルドコンテキストに何を含めるかについて、よりスマートになります。 で .dockerignore、 必要なものだけを指定し、最終的な画像に寄与しないものはすべて除外します。 このアプローチは、整理整頓されたスーツケースに荷物を詰めて、必要なものだけを持っていくようなものです。 利点は 2 つあります: ビルド プロセスを高速化し、Docker デーモンに送信するデータを減らすことでリソース消費を削減できます。 これは、数え切れないほどの時間を節約する、単純でありながら強力な調整です。

もうひとつのゲームチェンジャーは、Dockerfileにマルチステージビルドを採用したことです。 複雑なアプリを構築し、最終的なイメージにすべてのビルド ツールと依存関係を含める必要があることを想像してみてください。 家を建てた後、建設作業員を連れて行くようなものです。 代わりに、マルチステージ ビルドでは、初期段階ですべてをコンパイルしてビルドし、別のステージで必要な成果物だけをコピーします。 これにより、より無駄のない、より効率的な最終画像が得られます。 これは、イメージのサイズを小さく抑えるための優れたプラクティスであるだけでなく、デプロイの迅速化とストレージコストの削減にもつながります。

これらのメソッドを実装することで、Docker ビルドの処理方法が変わりました。 ビルドが高速化され、デプロイがスムーズになり、ワークフロー全体がより合理化されたように感じられます。

4。 Docker Initでプロジェクトを開始

新しいDockerプロジェクトを開始するのが迷路を進むように感じられた昔を覚えていますか? 初期設定を手探りで行い、Dockerfileを作成し、に何を含める .dockerignoreかを考えることがよくありました。 セットアップ、compose.yamlなどなど。 

Dockerの初心者にとって、これは気が遠くなるようなことでした。 ベテランのプロにとっても、貴重な時間を食いつぶす反復的な雑用でした。 新しいプロジェクトは、車輪の再発明のようでした。率直に言って、実際のコーディングなど、もっと重要なことに集中する必要がありました。

「Docker Init」と入力します。この機能は、プロジェクトのセットアップを合理化するための命の恩人です。 これは、新しいDockerプロジェクトの基礎を処理するパーソナルアシスタントがいるようなものです。 

を実行する docker initだけで、プロジェクトに不可欠な足場が設定されます。 不要なファイルを排除するためのもの.dockerignore、プロジェクトのニーズに合わせて調整された Dockerfile、マルチコンテナ設定を管理するためのもの、さらにはREADME.Docker.mdドキュメント用のものcompose.yamlも入手できます。 

一番いいところは? カスタマイズ可能です。 たとえば、Node.js アプリで作業している場合、Docker Init は汎用の Dockerfile を提供するだけではありません。Node の環境と依存関係に合わせて調整されます。 つまり、調整が少なくなり、より多くの作業が行われるようになります。 時間を節約するだけではありません。それは正しい足で始めることであり、当て推量や定型的なコードはもう必要ありません。 最初から成功への準備が整っています。

Docker Init は私たちの状況を変えました。 以前はすべてのプロジェクトにとって退屈なスタートでしたが、今ではスムーズで合理化されたプロセスになっています。 これは、Dockerプロジェクトのローンチパッドを持っているようなもので、最初の手間をかけずに開発の中心に直接連れて行く準備ができています。

5。 Docker Scoutでソフトウェアの脆弱性をプロアクティブに見つけて修正

堅牢で安全なアプリケーションを常に追求する中で、DevOpsの世界でよくある問題にしばしば遭遇しました。 これは、12 個の移動するターゲットを同時に追跡しようとするようなものです。 Docker Scout が登場する前は、これは面倒な作業であり、セキュリティギャップに対処するために見落としや土壇場でのスクランブルにつながることがよくありました。

しかし、Docker Scout が優れているのは、脆弱性を検出する強力な機能だけではありません。 Docker Scoutは、リポジトリのランドスケープ全体を包括的に監視します。 Docker Scout をワークフローの不可欠な部分にしてから、チームやステージ全体で、安全な最終製品を提供しているという自信が高まりました。

まず、すべてのリポジトリに Docker Scout をセットアップしました。 ( Docker クイックスタート ガイドを参照してください。 これは、それぞれが特定の領土を監視する任務を負った歩哨のネットワークを展開するようなものです。 セットアッププロセスは簡単で、導入後、Scoutはリポジトリのセキュリティステータスを継続的に可視化し始めました。

Docker Scout で特に高く評価しているのは、継続的な可視性機能です。 これは、最新のセキュリティ情報で常に更新されるダッシュボードを持っているようなものです。 脆弱性の特定だけの話ではありません。私たちは、リアルタイムの洞察を提供し、情報を提供し、行動する準備を整えるツールについて話しているのです。

また、Docker Scout が問題にフラグを立てても、問題に悩まされるだけではありません。 これは、修復プロセスをガイドします。 この点はゲームチェンジャーでした。 これは、専門家がそばにいて、パッケージの更新や設定の再構成など、最善の行動方針を提案するようなものです。 このレベルのガイダンスを持つことで、セキュリティへのアプローチが事後対応型から事前対応型へと変化し、力が湧いてきます。

Docker Scoutをこのように拡張的に統合することで、ソフトウェアサプライチェーンを保護するためのアプローチに革命をもたらしました。 これは、チェック ボックス アクティビティではなくなりました。これは、当社のDevOps文化の不可欠な部分です。 アプリケーションランドスケープ全体にわたる包括的なセキュリティネットがあることを知ることで得られる安心感は? プライスレス。

このようにDocker Scoutを組み込むことで、セキュリティ体制が強化され、アプローチが根本的に変化し、安全なソフトウェアサプライチェーンが開発ライフサイクルのシームレスに統合された側面になりました。

Docker Scout を自分で試してみてください 。

6。 Docker Build Cloud で開発を加速

Dockerプロジェクトに取り組んでいて、各ビルドが渋滞の中での長いロードトリップのように感じるとします。 従来のローカルDockerビルドは、特に大規模なプロジェクトの場合、イライラするほど遅く、リソースを大量に消費する可能性があります。 あなたはそこにいて、プログレスバーが這い回るのを見ながら、マシンが負荷の下でうめき声を上げています。 足に重りを縛り付けてレースを走ろうとするようなものです。 また、ハイエンドマシンを使用する開発者はビルドを難なくこなす一方で、セットアップが控えめな開発者は遅いペースに耐えているなど、不均等な競争の場も忘れてはなりません。 この格差は、しばしば悪名高い「私のマシンで動作する」症候群につながり、開発プロセスに亀裂を生み出します。

Docker Build Cloud は、重いバックパックをジェットパックに交換するようなゲームチェンジャーです。Docker Build Cloudは、ビルドプロセスをクラウドにオフロードすることで、ローカルハードウェアに関係なく、すべての開発者に一貫性のある高速ビルド環境を提供します。 これは、チームのすべての開発者に、Docker イメージを構築するための最高級のワークステーションを提供するのと同じです。

Dockerfileをクラウドベースのビルド用に最適化することは、Docker Build Cloudの可能性を最大限に引き出すための鍵です。 レイヤー キャッシュの効率を最大化するために Dockerfile コマンドを構造化し、ビルド コンテキスト サイズを最小限に抑えることは、重要な手順です。 これは、共有キャッシュと並列ビルド機能を活用するように Dockerfile 命令を整理することであり、開発プロセスを合理化して効率を最大化するのに似ています。 Dockerfile 構造を再編成することで、重要なプロジェクトのビルド時間が半分に短縮され、面倒なプロセスが迅速かつ効率的なプロセスに変換されたことを思い出します。

ビルド時間とキャッシュの使用状況を監視することも同様に重要です。 これらの側面を注意深く監視することで、非効率性やボトルネックを特定し、タイムリーな調整や調整が可能になります。 トラフィックの多い時期に、ビルド時間が急増していることに気付きました。 キャッシュの使用状況とビルド パターンを分析することで、Dockerfile の設定ミスのあるステップを特定し、解決すると、ビルド時間を最適なレベルに戻しました。

Docker Build Cloud を採用することで、開発ワークフローに大きな変化がもたらされます。 ビルドを高速化するだけではありません。それは、調和のとれた効率的な開発環境を作ることです。 マルチステージ ビルドを実装し、基本イメージを定期的に更新することで、プロセスがさらに合理化され、ビルドが高速であるだけでなく、安全で最新の状態になります。

チームは迅速なイテレーションと効率的なリソース利用を享受し、生産性を新たな高みへと引き上げることができます。 Docker Build Cloudは、構築プロセスを雑用からスピードと効率性を特徴とするエクスペリエンスに変え、プロジェクトが単に構築されるだけでなく、最先端のクラウド環境で迅速かつシームレスに作成されることを保証します。 このDocker Build Cloudへの移行は、単なるアップグレードではありません。これは、Dockerビルドに関する新しい考え方であり、最新のソフトウェア開発に必要な俊敏性とダイナミズムと完全に一致しています。

7。 Docker Debug でコードの問題をより迅速に解決

7月2024日更新:Docker Debug の GA リリースは、Docker Desktop 4.33.

トラブルシューティングは、ピースが欠けているパズルを解くように感じることがあります。 バグが発生し、ログや構成を深く掘り下げて、問題を再現しようとしている可能性があります。 探偵の仕事と少し似ていて、すべての手がかりが重要ですが、次の手がかりがどこにあるのかよくわかりません。 このプロセスは時間がかかり、率直に言って、特に問題がとらえどころのないものであったり、環境固有のものであったりする場合は、少し頭痛の種になる可能性があります。

しかし、ここで Docker Debug が介入し、ゲームを変えます。 複雑な宝探しの真っ只中にいるときに虫眼鏡と詳細な地図を手渡されるようなものです。 Docker Debugは、Docker Buildのアップグレードであり、一連のトラブルシューティングツールをすぐに利用できます。 これは、デバッグ プロセスを試行錯誤の旅ではなく、ソリューションへのまっすぐな道筋にするように設計されています。

Docker Debug を通常のデバッグ プロセスに統合することは、ツールキットに新しいハイテク ツール セットを追加するようなものです。 ローカルデバッグとリモートデバッグの両方の機能を利用できるため、特定が困難な問題に対処する場合に非常に役立ちます。 たとえば、ログをリアルタイムで表示したり、コンテナ内でコマンドを実行したりする機能は、Docker環境内で何が起こっているかに直接連絡するようなものです。 この直接アクセスにより、知識に基づいた推測を行うのではなく、何がどこで問題になっているかを正確に把握できます。

Docker Debug を使用すると、ローカル設定と運用環境の両方の設定を模倣した環境で問題を再現して診断できます。 本番環境で発生するバグがローカル環境で常に発生するとは限らず、その逆も同様であるため、この汎用性は非常に重要です。 これは、レーストラックと市街地の両方で車をテストする能力を持っていることに似ており、さまざまな条件でのパフォーマンスの全体像を把握できます。

たとえば、アプリケーションに構造化ログを実装すると、ログが一貫したストーリーになり、Docker Debugが問題の核心に簡単に到達できるようになります。 Docker Debugのツールを使用してコンテナのヘルスチェックを定期的に実行することは、定期的なチェックを行うことに似ており、すべてがスムーズに実行されるようにしています。

ネットワークの問題やメモリリークに直面した場合、DockerDebugが頼りになるツールになります。 これにより、正確な環境を複製し、コンテナを深く掘り下げて、プロセスやネットワーク接続を検査したり、アプリケーションプロセスでデバッガを実行したりすることができます。 これは、さまざまな条件下でのアプリケーションの動作を分析して理解するための手術ツールを持っているようなものです。

Docker Debugの自然な美しさは、複雑な問題をより迅速に解決できることです。 表面的な症状だけを見ているわけではありません。深く掘り下げて根本原因を理解することができます。 これは基本的に、DockerプロジェクトのX線ビジョンを提供します。 長時間のダウンタイムや長時間のバグハントはもう必要ありません。Docker Debug を使用すると、正確かつ迅速に問題を特定、理解、解決できます。

要するに、Docker Debugをワークフローに組み込むことは、単なるアップグレードではありません。これは、より効率的で効果的、かつストレスの少ないトラブルシューティングに向けた変革的なステップです。 それは、以前は気が遠くなるような作業だったものを、開発プロセスの一部にして、より管理しやすく、わかりやすいものにすることです。 Docker Debug を使用すると、問題をより迅速に修正できるだけでなく、これらの問題の発生を未然に防ぐための分析情報も得られます。 これは、Dockerゲームを向上させ、プロジェクトの機能性、堅牢性、回復力を確保する戦略的な動きです。

8。 Testcontainers を使用した実際のインスタンスに対するテスト

Dockerの世界でのテストは、コンパスだけで鬱蒼とした森の中を進むような感覚になることがよくあります。 現実世界の状況をシミュレートするために最善を尽くしていますが、何かが足りないという感覚が常にあります。 トレッドミルでマラソンの準備をするようなもので、便利ですが、舗装道路を走るのとはまったく同じではありません。

Testcontainersは、特にDockerがAtomicJarを買収したことで、私たちのテストアプローチを覆した命の恩人です。実際のデータベース、メッセージ ブローカー、またはアプリが対話するその他のサービスをすべてテスト スイート内で起動できる機能があることを想像してみてください。 ガレージで練習する代わりに、突然本格的なリハーサルスタジオにアクセスできるようなものです。

テストコンテナを使用すると、本番環境のような環境を自動テストに直接取り込むことができます。 データベーステスト用のPostgreSQLコンテナやメッセージング用のRabbitMQのスピンアップについて話しています。 この変化は記念碑的であり、私たちは現在、本番環境で遭遇するものを厳密に反映した条件下でテストを行っています。

Testcontainers を CI/CD パイプラインにシームレスに統合しました。 つまり、すべてのビルドが実際のインスタンスに対してテストされ、開発者のマシンで合格したテストが本番環境でも合格することが保証されます。 これは、必要なときにいつでも全天候型のテストトラックを利用できるようなものです。

私たちが直面した実際のシナリオで絵を描かせてください。 開発中はすべてが正常に機能していたのに、本番環境ではバラバラになるという断続的な問題がありました。 聞き覚えがありませんか? 本番環境と同じバージョンのデータベースでテストコンテナをセットアップしたところ、突然、問題が再現可能になりました。 そして診断可能。 そして修正可能。 これは、夜間のデバッグセッションを迅速な修正に変えるターニングポイントのようなものでした。

Testcontainersの採用は、単に新しいツールを採用するだけではありません。これは、テストの方法におけるパラダイムシフトです。 これにより、テストが単に合格するだけでなく、実際の世界でどのように動作するかについて自信を持てる方法で合格することが保証されます。

というと、Docker ファンの皆さん、まだ Testcontainers の世界に飛び込んでみませんか。 テストの信頼性を高めるだけではありません。それは、開発ライフサイクル全体をより予測可能で効率的で、本番環境の現実に合わせることです。 これは、使い始めると、それなしでどうやって管理したのか疑問に思うツールの1つです。

Testcontainers の使用を開始して、ご意見をお聞かせください。

結論

これらは、私のチームと私がDockerを使用する方法に革命をもたらしたトップのヒントとコツです。 Dockerを使い始めたばかりの方も、Dockerのゲームにしばらく携わっている方も、これらのインサイトが、私たちを助けてくれたのと同じように、皆さんのお役に立てば幸いです。 

新機能についていち早く聞き、Docker エクスペリエンスの向上に役立てたいと考えている開発者の方は、 Developer Preview Program にサインアップしてください。 また、 コミュニティのSlackに参加して、他のDocker開発者とチャットしたり、独自のヒントやコツを共有したりすることもできます。

2024年が幸せな年になりますように! 実験を続けて、Dockerizingを楽しんでください!

さらに詳しく

• Docker クイックスタート ガイドをご覧ください。
• 「Docker Init: Initialize Dockerfile and Compose files with the single CLI command」をお読みください。
• ドッカースカウトをお試しください。
• Docker Build Cloud の詳細については、こちらをご覧ください。
• Testcontainers の使用を開始します。
• 開発者プレビュー プログラムにサインアップします。
• Slack の Docker コミュニティに参加しましょう。