Dockerイメージ、コンテナー、およびボリュームがどこにあるか知りたいですか?
一般的なLinux環境では、Dockerイメージとコンテナーデータは次の場所にあります。
/var/lib/docker/
サーバーの容量が不足している場合は、必ずこのディレクトリを調べてください。
主に、すべてのDocker関連エンティティは/var/lib/docker
にあります。 。しかし、実際の例として、アルパインの画像とコンテナを使用して、より具体的に調べてみましょう。
docker pull
を使用するときはいつでも コマンドを実行するか、docker-compose up -d
を実行します アプリケーションの起動を準備するために、これは画像がUbuntuサーバーに保存される場所です:
/var/lib/docker/overlay2
ここで、Overlay2はUbuntuのデフォルトのDockerストレージドライバーです。これは、docker info
を実行することで確認できます。 コマンドとストレージドライバの検索:
...
Storage Driver: overlay2
...
これが自分のものと異なる場合は、Docker用に別のストレージドライバーを使用しています。同様に、ディレクトリの場所は、同じストレージドライバに従って名前が付けられます。ストレージドライバーの可用性は、カーネルのサポートによって異なります。
特定のイメージの場所を探している場合は、Dockerでプルされたイメージのinspectコマンドを使用できます。
たとえば、docker pull alpine
を使用して高山の画像を取得したとします。 。次のコマンドを実行して検査します。
[email protected]:~$ docker inspect alpine
コマンドを実行すると、Data
内に3つのフィールドが表示されます。 GraphDriver
の下のサブセクション :
...
"GraphDriver": {
"Data": {
"MergedDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/merged",
"UpperDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/diff",
"WorkDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/work"
},
...
上記のすべてのディレクトリパスは、ホストシステム上のアルパインイメージの物理的な場所です。上記の3つのフィールドにあるディレクトリという名前の大きなハッシュに注意してください:64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e
。
合計で、実際には4つのタイプのフィールドがあります。
LowerDir :これらは、オーバーレイファイルシステムの読み取り専用レイヤーです。 Dockerの場合、これらは順番に組み立てられた画像レイヤーです。
UpperDir :これは、オーバーレイファイルシステムの読み取り/書き込みレイヤーです。 Dockerの場合、これは、そのコンテナーによって行われた変更を含むコンテナー固有のレイヤーに相当します。
WorkDir :これはオーバーレイに必要なディレクトリです。内部で使用するには空のディレクトリが必要です。
MergedDir :これはオーバーレイファイルシステムの結果です。 Dockerは、コンテナーの実行時にこのディレクトリに効果的にchrootします。
このリファレンスから引用(さらに読むのに適しています)。
イメージと同様に、コンテナも同じストレージドライバベースのディレクトリ内に保存されます。
/var/lib/docker/overlay2
特定のコンテナの場所を探している場合は、inspect
を再度使用できます 実行中のコンテナーに対するコマンド。
たとえば、docker run -ti -d alpine
を使用してアルパインコンテナを実行したとします。 。 docker ps
を実行すると 、実行されていることがわかります:
[email protected]:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
cb341d6a28fa alpine "/bin/sh" 6 seconds ago Up 5 seconds confident_banzai
ここでは、コンテナの名前はランダムにconfident_banzai
になっています。 。それでは、調べてみましょう:
[email protected]:~$ docker inspect confident_banzai
上記のコマンドを実行すると、Data
内の前述の4つのフィールドすべてに気付くでしょう。 GraphDriver
の下のサブセクション 。これらのディレクトリは、コンテナデータがホストシステム上で物理的に配置されている場所です。
...
"GraphDriver": {
"Data": {
"LowerDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3-init/diff:/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/diff",
"MergedDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/merged",
"UpperDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/diff",
"WorkDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/work"
},
"Name": "overlay2"
},
...
さらに読むためのリファレンス。
上記のディレクトリは、ホストシステム内のコンテナデータの物理的な場所です。大きなハッシュ名のディレクトリを覚えておいてください:64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e
Docker画像から セクション?その下のディレクトリはdiff
と呼ばれます 、LowerDir
で確認できるように :
、これはコンテナのマウントポイントになりました-ベースイメージUpperDir
からフェッチされます !
これらのディレクトリは、コンテナを停止した後も引き続き使用できます。したがって、画像間で共通の完全なパス(MergedDir
、UpperDir
およびWorkDir
)とコンテナ(LowerDir
マウントポイント)は:
/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/
LowerDir
までのコンテナに自分自身を割り当てた後、画像の目的は連続しています レベル。これが、4つのフィールドが割り当てられ、(新しいハッシュを使用して)異なるディレクトリに基づいている理由です。後者の動的な性質により、次のようになります。
/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/
注:ベースイメージからコンテナーへのディレクトリマウントプロセスは、Dockerにボリュームをマウントする方法と非常によく似ています。 Dockerイメージやコンテナーとは異なり、ボリュームの物理的な場所は非常に単純です。ボリュームは次の場所にあります:
/var/lib/docker/volumes/
この場合、主に2つのタイプがあります。 1つは通常のDockerボリュームで、もう1つはバインドマウントです。
特定のボリュームの場所を探している場合は、docker volume ls
を使用できます。 最初にコマンドを実行し、ボリューム名またはIDを確認してください。
たとえば、ボリュームを使用して次のコマンドでアルパインコンテナを実行しました:
[email protected]:~$ docker run -ti -d --name alpine-container -v test-data:/var/lib/app/content alpine
ここで、test-data
という名前のボリューム 自動的に作成されます。 test.md
という名前のファイルを作成しましょう この場所の内部:
[email protected]:~$ docker exec alpine-container sh -c "touch /var/lib/app/content/test.md"
ファイルが実際に作成されていることを確認します:
[email protected]:~$ docker exec -ti alpine-container sh
/ # ls /var/lib/app/content/
test.md
/ # exit
docker volume ls
を実行すると 、test-data
という名前のボリューム リストされます:
[email protected]:~$ docker volume ls
DRIVER VOLUME NAME
local d502589845f7ae7775474bc01d8295d9492a6c26db2ee2c941c27f3cac4449d1
local e71ee3960cfef0a133d323d146a1382f3e25856480a727c037b5c81b5022cb1b
local test-data
最後に、ホストシステム上のファイルの実際の場所を確認できます。
[email protected]:~$ sudo ls -l /var/lib/docker/volumes/test-data/_data
total 0
-rw-r--r-- 1 root root 0 Oct 6 23:20 test.md
したがって、マウントされたボリュームのパスは、常に_data
という名前のディレクトリ内にあります。 それぞれのボリュームディレクトリ内。
docker volume inspect
を使用して、Dockerの方法でこのようなパスを確認することもできます。 コマンドの後にボリューム名またはIDを入力し、Mountpoint
を調べます 出力内のパラメータ:
[email protected]:~$ docker volume inspect test-data
[
{
"CreatedAt": "2021-10-06T23:20:20+05:30",
"Driver": "local",
"Labels": null,
"Mountpoint": "/var/lib/docker/volumes/test-data/_data",
"Name": "test-data",
"Options": null,
"Scope": "local"
}
]
バインドマウントの場所は、ホスト側の場所から直接ボリュームをマウントするため、非常に明白で、さらに簡単です。
[email protected]:~$ mkdir /home/avimanyu/test-data
[email protected]:~$ docker run -ti -d --name alpine-container -v /home/avimanyu/test-data:/var/lib/app/content alpine
この場合、test-data
という名前のバインドマウントされたボリューム コンテナ側で/var/lib/app/content
として利用できるようになります 。
概要
このクイックチュートリアルでは、一般的なLinuxベースのアプローチを採用して、ホストレベルでLinuxサーバー(この場合はUbuntu 20.04)に存在するDockerイメージ、コンテナー、およびボリュームの物理的な場所を示しました。
このアプローチに対するフィードバック、コメント、提案を共有したい場合は、下のコメントセクションにご意見をお寄せください。