📝

dockerでvolumeマウントした時のデータの実体|M1 Mac

2022/08/15に公開

dockerでvolumeマウントした際のデータが実際にはどこにあるのか?
それを調査してみました。今回はM1Mac環境で書いていきます。

結論

以下のディレクトリにあるようです。

MacOS13.4の場合
~/Library/Containers/docker/Data/vms/0/

MacOS10.15.7の場合
~/Library/Containers/com.docker.docker/Data/vms/0/

注意|Timemachineで保存するかどうか

これはDocker Desktop for macで設定していないと保存されません。
Docker Desktop for mac → preferences → Include VM in Time Machine backupsにチェックを入れると保存されます。

inspectのMountpointはバーチャルマシンのパス

MacOS上で動いているDockerは実はバーチャルマシンが一個立ち上がっていて
MacOS on バーチャルマシン on Dockerみたいな感じで動いているようです。

そしてここが厄介なのですがdocker volume inspectで出てくるMountpointは

MacOS上のパスではなく

MacOS on バーチャルマシンのパスが表示されているということです。

以下は後で確認するので一応inspectやってみます。

% docker inspect test-dbdatavolume-2022
[
    {
        "CreatedAt": "2022-08-01T04:14:50Z",
        "Driver": "local",
        "Labels": null,
        "Mountpoint": "/var/lib/docker/volumes/test-dbdatavolume-2022/_data",
        "Name": "test-dbdatavolume-2022",
        "Options": null,
        "Scope": "local"
    }
]

これはwindowsでも同じです。
LinuxはMountpointが実際のパスになっているとのことでした。

データ専用コンテナを立ててみます

テスト用のデータ専用コンテナを立ててみます。
データ専用コンテナというのはいわゆる永続化と言われる物ですが
以下のようにvolumeマウントを用いている場合Docker Desktop for Macなどで
データの初期化、再インストールなどを行うとデータも消えます。

Macのターミナルを立ち上げて以下を実行します。

% docker run -i -t --name test-datacontainer-2022 --mount source=test-dbdatavolume-2022,target=/var/lib/mysql busybox

busyboxを使用したことがない方はbusyboxのイメージがダウンロードされつつ
コンテナが立ち上がりコンテナ内でコマンドが打てる状態になる(オプションの-iと-tにより)と思います。
その状態のまま以下のコマンドでディレクトリを開いてみましょう。

/ # ls -la /var/lib
total 12
drwxr-xr-x    3 root     root          4096 Aug 11 04:13 .
drwxr-xr-x    1 root     root          4096 Aug 11 04:13 ..
drwxr-xr-x    2 root     root          4096 Aug 11 04:13 mysql

これがtargetで指定したディレクトリです。
そして--nameオプションで指定したのがコンテナ名です。確認してみましょう。
まずは以下のコマンドでbusyboxから抜けます。

# exit

これでコンテナの中からMacOS上に戻ってきました。
そして以下のコマンドを打ってみましょう。

% docker container ls -a
CONTAINER ID   IMAGE     COMMAND                  CREATED          STATUS                     PORTS     NAMES
98d200c1e389   busybox   "sh"                     29 minutes ago   Exited (0) 5 seconds ago             test-datacontainer-2022

終了はしていますがbusyboxのコンテナが作られているのがわかりますね。
そして--nameオプションで設定した名前がセットされています。

今度は--mount sourceで設定されているボリュームを確認してみます。

% docker volume list
DRIVER    VOLUME NAME
local     test-dbdatavolume-2022

ボリュームが生成されているのがわかると思います。

最初に打ったrunコマンドで以下のことを一気にやったわけです。
・busyboxのイメージがなければダウンロードする。あればそれを使う。
・コンテナを作成する。そして中に入ってコマンドが実行できるようにする。
・ボリュームを作成する。
・ボリュームをコンテナの中のディレクトリと紐付ける。(マウントする)

inspectのMountpointがないことを確認

これでボリュームが生成された状態になったと思います。しかし、前述のパスを確認してみるとないことがわかると思います。

/var/lib/docker/volumes/test-dbdatavolume-2022/_data

データの実体から復元できるかをテストしてみました

データの実体から復元できるかをテストしてみました。
詳細は以下の記事をご参照ください。

https://zenn.dev/isosa/articles/b435ab74eea3b9

番外編おまけ|Mac上のバーチャルマシンに入ってみる

以下はコンテナを一つ走らせそれを経由してMacOS on バーチャルマシンにアクセスできるコマンドとのことです。

% docker run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh

MacOS on バーチャルマシンにアクセスしたらinspectで確認したディレクトリを見てみましょう。

# ls -la /var/lib/docker/volumes/test-dbdatavolume-2022/_data

データが何もない状態だとこのディレクトリも空になっていますが
データを保存した状態(dockerで前述のデータ専用コンテナを利用してアプリをインストール起動した状態)だと
大量のファイルやディレクトリが保存されているのがわかると思います。

参考サイト

https://note.com/w0o0ps/n/n9bc1bcd9fa59

Discussion