次の方法で共有

コンテナー内の永続ストレージ

コンテナー内にデータを保持できる機能が重要なアプリの場合や、コンテナーのビルド時に、コンテナー内に含まれていないファイルを表示する場合があります。 永続的ストレージは、次の 2 つの方法でコンテナーに提供できます。

  • バインド マウント
  • 名前付きボリューム

Docker には ボリュームの使用方法 に関する優れた概要が用意されているため、最初に読むのが最善です。 このページの残りの部分では、Linux と Windows の違いに焦点を当て、Windows での例を示します。

バインド マウント

バインド マウントを 使用すると、コンテナーでディレクトリをホストと共有できます。 これは、コンテナーを再起動した場合に使用できるローカル コンピューターにファイルを格納する場所を設定する場合や、複数のコンテナーと共有する場合に便利です。 コンテナーを複数のコンピューターで実行して同じファイルにアクセスする場合は、代わりに名前付きボリュームまたは SMB マウントを使用する必要があります。

注

クラスター共有ボリューム (CSV) へのバインドマウントはサポートされていません。コンテナー ホストとして機能する仮想マシンは CSV ボリュームで実行できます。

権限

バインド マウントに使用されるアクセス許可モデルは、コンテナーの分離レベルによって異なります。

Hyper-V 分離を使用するコンテナーでは、単純な読み取り専用または読み取り/書き込みアクセス許可モデルが使用されます。 LocalSystem アカウントを使用して、ホスト上のファイルにアクセスします。 コンテナーでアクセスが拒否された場合は、 LocalSystem がホスト上のそのディレクトリにアクセスできることを確認します。 読み取り専用フラグを使用すると、コンテナー内のボリュームに加えられた変更は、ホスト上のディレクトリに対して表示または永続化されません。

プロセス分離を使用する Windows コンテナーは、コンテナー内のプロセス ID を使用してデータにアクセスするため、若干異なります。つまり、ファイル ACL が受け入れられます。 コンテナーで実行されているプロセスの ID (Windows Server Core の場合は "ContainerAdministrator"、Nano Server コンテナーの場合は "ContainerUser" は既定で) は、 LocalSystemではなくマウントされたボリューム内のファイルとディレクトリへのアクセスに使用され、データを使用するためのアクセス権を付与する必要があります。

これらの ID はコンテナーのコンテキスト内にのみ存在し、ファイルが格納されているホストには存在しないため、ACL を構成してコンテナーへのアクセスを許可する場合は、 Authenticated Users などの既知のセキュリティ グループを使用する必要があります。

Warnung

C:\などの機密性の高いディレクトリを信頼されていないコンテナーにバインドマウントしないでください。 これにより、通常はアクセスできないホスト上のファイルを変更でき、セキュリティ侵害が発生する可能性があります。

使用例:

  • docker run -v c:\ContainerData:c:\data:RO 読み取り専用アクセスの場合
  • docker run -v c:\ContainerData:c:\data:RW 読み取り/書き込みアクセス用
  • docker run -v c:\ContainerData:c:\data 読み取り/書き込みアクセスの場合 (既定)

シンボリック リンクはコンテナー内で解決されます。 シンボリック リンクであるコンテナーまたはシンボリック リンクを含むコンテナーにホスト パスをバインドマウントする場合、コンテナーはそれらにアクセスできません。

SMB マウント

Windows Server バージョン 1709 以降では、"SMB グローバル マッピング" と呼ばれる機能により、ホストに SMB 共有をマウントし、その共有上のディレクトリをコンテナーに渡すことができます。 コンテナーは、特定のサーバー、共有、ユーザー名、またはパスワードを使用して構成する必要はありません。これはすべて、代わりにホストで処理されます。 コンテナーは、ローカル ストレージがある場合と同じように動作します。

構成手順

  1. コンテナー ホストで、リモート SMB 共有をグローバルにマップします。

    $creds = Get-Credential
New-SmbGlobalMapping -RemotePath \\contosofileserver\share1 -Credential $creds -LocalPath G:

    このコマンドは、資格情報を使用してリモート SMB サーバーで認証します。 次に、リモート共有パスを G: ドライブ文字にマップします (その他の使用可能なドライブ文字も指定できます)。 このコンテナー ホストで作成されたコンテナーで、データ ボリュームを G: ドライブ上のパスにマップできるようになりました。

    注

    コンテナーに SMB グローバル マッピングを使用する場合、コンテナー ホスト上のすべてのユーザーがリモート共有にアクセスできます。 コンテナー ホストで実行されているアプリケーションも、マップされたリモート共有にアクセスできます。

  2. グローバルにマウントされた SMB 共有 Docker にマップされたデータ ボリュームを含むコンテナーを作成 -it --name デモ -v g:\ContainerData:c:\AppData1 mcr.microsoft.com/windows/servercore:ltsc2019 cmd.exe

    コンテナー内では、c:\AppData1 がリモート共有の "ContainerData" ディレクトリにマップされます。 グローバルにマップされたリモート共有に格納されているデータは、コンテナー内のアプリケーションで使用できます。 複数のコンテナーは、同じコマンドを使用して、この共有データに対する読み取り/書き込みアクセスを取得できます。

この SMB グローバル マッピングのサポートは、次のような互換性のある SMB サーバーの上で動作できる SMB クライアント側の機能です。

  • 記憶域スペース ダイレクト (S2D) または従来の SAN 上のスケールアウト ファイル サーバー
  • Azure Files (SMB 共有)
  • 従来のファイル サーバー
  • SMB プロトコルのサード パーティの実装 (例: NAS アプライアンス)

注

SMB グローバル マッピングは、DFS 名前空間 (DFSN) フォルダーをサポートしていません。 たとえば、DFSN ルート共有を New-SmbGlobalMapping -LocalPath Z: -RemotePath \\contoso.com\share1'にマップすると、そのルートのフォルダー ターゲットを読み取ると、"ネットワークの場所に到達できません" というエラーが返されます。

名前付きボリューム

名前付きボリュームを使用すると、名前でボリュームを作成し、コンテナーに割り当てて、後で同じ名前で再利用できます。 作成された場所の実際のパスを追跡する必要はありません。名前のみ。 Windows 上の Docker エンジンには、ローカル コンピューター上にボリュームを作成できる名前付きボリューム プラグインが組み込まれています。 複数のマシンで名前付きボリュームを使用する場合は、追加のプラグインが必要です。

手順の例:

  1. docker volume create unwound - "unwound" という名前のボリュームを作成する
  2. docker run -v unwound:c:\data microsoft/windowsservercore - c:\data にマップされたボリュームでコンテナーを開始する
  3. コンテナー内の c:\data にいくつかのファイルを書き込み、コンテナーを停止します
  4. docker run -v unwound:c:\data microsoft/windowsservercore - 新しいコンテナーを開始する
  5. 新しいコンテナーで dir c:\data を実行する - ファイルはまだ存在します

注

Windows Server はターゲット パス名 (コンテナー内のパス) を小文字に変換します。つまり、 -v unwound:c:\MyData、または Linux コンテナー内の -v unwound:/app/MyData は、 c:\mydataのコンテナー内のディレクトリ、または Linux コンテナー内の /app/mydata がマップされます (存在しない場合は作成されます)。