「 2-10x Faster File Operation Faster with Synchronized File Shares in Docker Desktop」を参照してください。

Dockerが 買収した Mutagenのファイル共有技術がDocker Desktopにシームレスに統合され、 同期ファイル共有 機能が Docker Desktop で利用できるようになったことをお知らせします。この機能強化により、ホストからVMへの高速かつ柔軟なファイル共有が可能になり、広範なコードベースを扱う開発者のパフォーマンスが向上します。

同期されたファイル共有は、従来のバインドマウントの制限を克服し、ネイティブファイルシステムのパフォーマンスを提供するため、開発者は 2-10x x高速なファイル操作速度を享受できます。 サブスクリプション アカウント (Docker Pro、Teams、または Business) で Docker Desktop にログインするだけで、この新しい時間節約機能を体験できます。

長方形の docker desktop 同期ファイル共有 ga

開発者エクスペリエンスの向上 

同期されたファイル共有は、従来のファイル共有システムと比較して時間を節約し、開発者の生産性を向上させることで、バックエンド開発者のエクスペリエンスを変革します。 同期ファイル共有は、次のような開発者に最適です。

  • 100を超える000ファイルを含む大規模なリポジトリまたはモノレポを管理し、合計で大量のストレージを格納します。
  • 仮想ファイルシステム (VirtioFS、gRPC FUSE、osxfs など) を利用し、ワークフローのスケーラビリティの問題に直面します。
  • パフォーマンスの制限に直面し、所有権の競合を心配することなくシームレスなファイル共有ソリューションを求めています。

開始するには、[設定]に移動し、[リソース]セクション内の[ファイル共有]タブに移動します(図1)。機能とその使用方法の詳細については、 ドキュメントをご覧ください

同期されたファイル共有オプションを示す Docker デスクトップ設定のスクリーンショット。
図 1: ファイル共有 — 共有が作成され、コンテナーで使用できます。

Dockerが問題を解決する方法 

同期されたファイルシステムキャッシュを使用してバインドマウントのパフォーマンスを向上させることは新しいアイデアではありませんが、この機能は人間工学に基づいたファーストパーティソリューションとして開発者が利用できることはありませんでした。 Dockerが Mutagenを買収したことで、開発者のワークフローを桁違いに改善できる可能性のある、使いやすく透明性の高いメカニズムを提供できるようになりました。

バインドマウントは、Linuxがファイル(コード、スクリプト、イメージなど)をコンテナで使用できるようにするために使用するメカニズムです。 これらは、またはコマンドでdocker runフラグへの-v/--volumeホストパス(またはdocker createComposeの下のvolumes:ホストパス)を指定したときに取得されるものです。フォルダーが読み取り/書き込みモード (デフォルト) でバインドマウントされている場合、コンテナーはホスト ファイル システムに書き戻すこともできるため、コンテナーからファイル (ビルド製品など) を取得するのに最適です。

Docker Engine など、Linux でコンテナーをネイティブに使用する場合、この機能は Linux カーネルによって有効になり、パフォーマンスに影響を与えることはありません。 Docker Desktop のようなクロスプラットフォーム ソリューションを使用する場合、仮想化の必要性は、バインド マウントを有効にするために、ホスト システムと Linux VM の間に追加のファイル共有メカニズムが必要であることを意味します。

これまで、Dockerは、このホスト/VMファイル共有を可能にするために、ホストプラットフォームに基づいてさまざまなソリューションを利用できる、多数の仮想ファイルシステムソリューションを使用してきました。 これらのメカニズムの最新の VirtioFS は、ほとんどの開発者とプロジェクトにすぐに使用できる優れたファイル共有ソリューションを提供し、さらなる パフォーマンス改善への投資を続けています。 これらの仮想ファイルシステムは、ホスト上でファイルサーバを実行することで動作し、VM内のFUSEでバックアップされたファイルシステムを介してオンデマンドでファイルを提供します。

ほとんどの場合、仮想ファイルシステムはうまく機能しますが、追加のパフォーマンスが必要なプロジェクトもあります。 プロジェクトに数千 (または数百万) のファイル、合計で数百メガバイトまたはギガバイトが含まれている場合、開発ツールで使用される要求の厳しいシステムコールにより、動作が非常に遅くなる可能性があります。 

プロジェクトが 1 つのファイルしか含まれていなくても、このカテゴリに分類されるかもしれません — たとえば、最新のフレームワークがディレクトリ node_modules にもたらす依存関係の驚異的なツリーを見てください。 コンパイラ、動的言語ランタイム、パッケージマネージャーなどの最新の開発者ツールは、ファイルシステムをトラバースし、数千または数百万のreaddir()、、、stat()および open()///read()write()close() 呼び出しを発行するのが大好きです。仮想ファイルシステムでは、これらの各システムコールをホスト/VM境界を越えて送信する必要があります(FUSEスタックを使用する場合、Linux仮想マシン内のカーネル空間とユーザー空間間の標準のラウンドトリップが発生します)。

同期されたファイル共有の使用

ここで、同期されたファイル共有の出番です。 同期されたファイル共有を使用すると、開発者は Docker Desktop VM 内にホスト ファイル システムの場所の ext4-backed キャッシュを作成できます。 つまり、これらの高価なファイルシステム呼び出しはすべて、ネイティブファイルシステム上のLinuxカーネルによって直接処理されるようになりました。 これらのキャッシュは、Mutagenファイル同期エンジンを使用してホストファイルシステムとの同期が保たれるため、ファイルは超低レイテンシーで双方向に伝播されます。 ほとんどの開発者にとって、ファイル共有エクスペリエンスには、パフォーマンスの向上以外に目に見える違いはありません。

では、どのようなトレードオフがあるのでしょうか? まあ、ファイルを2回保存するには費用がかかります(ホスト上のオリジナルとVM内のキャッシュ)。 開発者の時間コストが高いことと比較して、ディスク容量のコストが比較的低いことを考えると、通常、このトレードオフは簡単です。

同期する内容をユーザーが制御できるように、同期されたファイル共有をきめ細かなオプトイン エクスペリエンスにしました (既定では、ハード ドライブ全体を同期したくありません)。 この手順をできるだけ簡単にするために、 [ファイル共有設定] ウィンドウで [共有の作成] を選択し、目的の場所を選択します。

また、同期ファイル共有のオプトインの性質により、段階的または選択的に導入することが容易になり、チーム全体に変更を課す必要がありません。 同期されたファイル共有のキャッシュで提供できないバインド マウントは、既定の仮想ファイル共有メカニズムにフォールバックされるため、既存のワークフローに変更はありません。 チーム メンバーは、必要に応じて同期されたファイル共有にオプトインし、コードベースの特定の部分の戦略的最適化として機能を使用できます。

結論 

私たちは、この最新の時間節約機能と、それがあなたにとって何を意味するのか、つまり、時間の解放、生産性の向上、イノベーションへの集中を可能にすることに興奮しています。 Docker Desktop は開発者エクスペリエンスのモダナイゼーションへの投資を続けており、同期されたファイル共有は最新の機能強化です。 

さらに詳しく  

フィードバック

「See 2- Docker Desktopの同期されたファイル共有で10xファイル操作速度が速くなる」に関する0の考え