コンテナ内からDockerにマウントされたボリュームを一覧表示する方法
マウントされたボリュームであるすべてのコンテナディレクトリを一覧表示したいと思います。
つまり私が得た同様の情報を得ることができるように
docker inspect --format "{{ .Volumes }}" <self>
しかし、コンテナ内から、そこにdockerをインストールせずに。
私は試した cat /proc/mounts、しかし私はそれのための適切なフィルターを見つけることができませんでした。
DockerホストがOSXの場合、マウントされるボリュームはタイプosxfs（またはFuse.osxfs）になります。あなたは実行することができます
mount | grep osxfs | awk '{print $3}'
マウントされているすべてのボリュームのリストを取得します。
DockerホストがLinux（少なくともUbuntu 14以降、おそらく他のホスト）の場合、ボリュームはすべて/devにあるように見えますが、コンテナーの/devファイルシステムにあるデバイスにはありません。ボリュームは、/etc/resolv.conf、/etc/hostname、および/etc/hostsと並んでいます。 mount | grep ^/devを実行して開始し、次にls /dev/*内のファイルのいずれかをフィルターで除外し、次に上記の3つのファイルをフィルターで除外すると、ホストボリュームが残ります。
mount | grep ^/dev/ | grep -v /etc | awk '{print $3}'
私の推測では、詳細はLinuxごとに異なる可能性があります。理想的ではありませんが、少なくとも理解することは可能です。
あなたが持っていたコメントの多くから読むことができるように、コンテナは最初はリソースの制限された予約された部分に過ぎず、マシンの他の部分から完全に切り離されています。 Dockerであることを認識しておらず、コンテナー内ではすべてが別個のマシンであるかのように動作します。マトリックスのようなものだと思います;）
ホストマシンのカーネルとそのリソースにアクセスできますが、フィルターで除外されたセットとして再び制限されます。これは、Unix/Linuxカーネルに付属する素晴らしい「cgroups」機能を使用して行われます。
良いニュースです。Dockerに情報を提供する方法は複数ありますが、それは自分で提供して構築する必要があるものです。
最も簡単で最も強力な方法は、ホストの/var/run/docker.sockにあるUnixソケットを、同じ場所のコンテナの内部にマウントすることです。そうすれば、コンテナ内でDockerクライアントを使用するときに、ホストのDockerエンジンと直接通信していることになります。
しかし、大きな力には大きな責任が伴います。これは素晴らしい設定ですが、あまり安全ではありません。誰かがなんとかあなたのDockerに入ると、この方法であなたのホストシステムにルートアクセスできます。
より良い方法は、環境設定を通じてマウントのリストを提供するか、マウントを予測できるようにいくつかの作り上げられた規則に固執することです。
（Docker内のエイリアスをマウントに与えるために、マウント用のパラメーターがあることに気づいていますか？）
マウントされているボリュームを確認したい場合Linuxベースのコンテナ内から/etc/mtabで「/ dev」で始まるエントリを検索し、/ etcエントリを削除できます。
$ grep "^/dev" /etc/mtab | grep -v " \/etc/"
/dev/nvme0n1p1 /var/www/site1 ext4 rw,relatime,discard,data=ordered 0 0
/dev/nvme0n1p1 /var/www/site2 ext4 rw,relatime,discard,data=ordered 0 0
Docker execコマンドはおそらくあなたが探しているものです。
これにより、既存のコンテナ内で任意のコマンドを実行できます。
例えば：
docker exec -it <mycontainer> bash
もちろん、実行しているコマンドはすべて、コンテナファイルシステムに存在している必要があります。
#docker cp >>>> Copy files/folders between a container and the local filesystem
docker cp [OPTIONS] CONTAINER:SRC_PATH DEST_PATH
docker cp [OPTIONS] SRC_PATH CONTAINER:DEST_PATH
フォルダ全体をコピーするには：
docker cp ./src/build b081dbbb679b:/usr/share/nginx/html
注–これにより、コンテナの…/ nginx/html /ディレクトリにあるビルドディレクトリがコピーされ、フォルダに存在するファイルのみがコピーされます。
docker cp ./src/build/ b081dbbb679b:/usr/share/nginx/html
注–これにより、ビルドディレクトリの内容がコンテナの…./nginx/html/ directoryにコピーされます。
Dockerストレージオプション：
ボリュームは、Docker（Linuxでは/ var/lib/docker/volume /）によって管理されるホストファイルシステムの一部に保存されます。 Docker以外のプロセスは、ファイルシステムのこの部分を変更しないでください。ボリュームは、Dockerでデータを永続化するための最良の方法です。
ボリュームを作成すると、Dockerホストのディレクトリ内に保存されます。ボリュームをコンテナにマウントする場合、このディレクトリがコンテナにマウントされます。これは、ボリュームがDockerによって管理され、ホストマシンのコア機能から分離されていることを除いて、バインドマウントが機能する方法と似ています。
特定のボリュームを複数のコンテナに同時にマウントできます。実行中のコンテナーがボリュームを使用していない場合でも、ボリュームはDockerで使用可能であり、自動的に削除されません。 docker volumePruneを使用して未使用のボリュームを削除できます。
ボリュームをマウントする場合、名前付きまたは匿名の場合があります。匿名ボリュームは、コンテナーに最初にマウントされるときに明示的な名前が付けられないため、Dockerは、特定のDockerホスト内で一意であることが保証されているランダムな名前を付けます。名前に加えて、名前付きボリュームと匿名ボリュームは同じように動作します。
ボリュームは、ボリュームドライバーの使用もサポートします。これにより、データをリモートホストまたはクラウドプロバイダーに保存できます。
バインドマウントは、ホストシステムのどこにでも保存できます。それらは重要なシステムファイルまたはディレクトリでさえあるかもしれません。 DockerホストまたはDockerコンテナー上の非Dockerプロセスは、いつでもそれらを変更できます。 Dockerの初期から利用可能です。バインドマウントは、ボリュームと比較して機能が制限されています。バインドマウントを使用すると、ホストマシン上のファイルまたはディレクトリがコンテナにマウントされます。ファイルまたはディレクトリは、ホストマシン上のフルパスによって参照されます。ファイルまたはディレクトリは、Dockerホストにすでに存在している必要はありません。まだ存在しない場合は、オンデマンドで作成されます。バインドマウントは非常にパフォーマンスが高いですが、特定のディレクトリ構造が利用可能なホストマシンのファイルシステムに依存しています。新しいDockerアプリケーションを開発している場合は、代わりに名前付きボリュームの使用を検討してください。 DockerCLIコマンドを使用してバインドマウントを直接管理することはできません。
バインドマウントを使用することの副作用の1つは、良くも悪くも、重要なシステムファイルまたはディレクトリの作成、変更、削除など、コンテナで実行されているプロセスを介してホストファイルシステムを変更できることです。これは、ホストシステム上のDocker以外のプロセスに影響を与えるなど、セキュリティに影響を与える可能性のある強力な機能です。
tmpfsマウントは、ホストシステムのメモリにのみ保存され、ホストシステムのファイルシステムに書き込まれることはありません。
Tmpfsマウントは、Dockerホストまたはコンテナー内のいずれのディスクにも永続化されません。コンテナの存続期間中にコンテナが使用して、非永続的な状態または機密情報を格納できます。たとえば、内部的には、swarmサービスはtmpfsマウントを使用してシークレットをサービスのコンテナにマウントします。
ボリュームドライバオプションを指定する必要がある場合は、-mountを使用する必要があります。 -vまたは--volume：コロン文字（:)で区切られた3つのフィールドで構成されます。フィールドは正しい順序である必要があり、各フィールドの意味はすぐにはわかりません。 o名前付きボリュームの場合、最初のフィールドはボリュームの名前であり、特定のホストマシンで一意です。匿名ボリュームの場合、最初のフィールドは省略されます。 o 2番目のフィールドは、ファイルまたはディレクトリがコンテナにマウントされるパスです。 o 3番目のフィールドはオプションであり、roなどのオプションのコンマ区切りリストです。これらのオプションについては、以下で説明します。 •--mount：複数のキーと値のペアで構成され、コンマで区切られ、それぞれがa =タプルで構成されます。 --mount構文は-vまたは--volumeよりも冗長ですが、キーの順序は重要ではなく、フラグの値は理解しやすいです。 oマウントのタイプ。バインド、ボリューム、またはtmpfsのいずれかです。このトピックではボリュームについて説明しているため、タイプは常にボリュームになります。 oマウントのソース。名前付きボリュームの場合、これはボリュームの名前です。匿名ボリュームの場合、このフィールドは省略されます。 sourceまたはsrcとして指定できます。 o宛先は、ファイルまたはディレクトリがコンテナにマウントされるパスを値として取ります。 destination、dst、またはtargetとして指定できます。 o読み取り専用オプションが存在する場合、バインドマウントは読み取り専用としてコンテナにマウントされます。 o複数回指定できるvolume-optオプションは、オプション名とその値で構成されるキーと値のペアを取ります。