Encontrar punto de montaje en Docker con btrfs storage driver

Antes para el storage driver de btrfs de Docker se utilizaba el image ID para el nombre del directorio:

The image’s base layer is stored in a Btrfs subvolume under /var/lib/docker/btrfs/subvolumes.

The image ID is used as the subvolume name. E.g., a base layer with image ID «f9a9f253f6105141e0f8e091a6bcdb19e3f27af949842db93acba9048ed2410b» will be stored in /var/lib/docker/btrfs/subvolumes/f9a9f253f6105141e0f8e091a6bcdb19e3f27af949842db93acba9048ed2410b
https://github.com/saturnism/docker/blob/master/docs/userguide/storagedriver/btrfs-driver.md#image-layering-and-sharing-with-btrfs

Sin embargok, ya no es así a partir de Docker 1.10:

As of Docker 1.10, image layer IDs no longer correspond to directory names under /var/lib/docker/.
https://gdevillele.github.io/engine/userguide/storagedriver/btrfs-driver/#image-layering-and-sharing-with-btrfs

Image layers and containers are visible in the Docker host’s filesystem at /var/lib/docker/btrfs/subvolumes/. However, as previously stated, directory names no longer correspond to image layer IDs.
https://gdevillele.github.io/engine/userguide/storagedriver/btrfs-driver/#image-and-container-on-disk-constructs

Como veremos, ahora se usa un «cache-id»

Referencias: https://kingdo.club/2022/02/21/understand-layerid-diffid-chainid-cache-id/

Buscamos el nombre de la imagen de nuestro contenedor, en mi caso, del contenedor «elasticsearch» es docker.elastic.co/elasticsearch/elasticsearch:7.16.2

j@nagae ~/Documents/trabajo/bluetab % docker ps
CONTAINER ID   IMAGE                                                  COMMAND                  CREATED        STATUS                  PORTS                                                                          NAMES
1bce23a2a3c1   kong:3.3.0-alpine                                      "/docker-entrypoint.…"   3 weeks ago    Up 2 days (healthy)     0.0.0.0:8000-8001->8000-8001/tcp, :::8000-8001->8000-8001/tcp, 8443-8444/tcp   kong
496d05442d89   docker.elastic.co/elasticsearch/elasticsearch:7.16.2   "/bin/tini -- /usr/l…"   2 months ago   Up 2 days (unhealthy)   0.0.0.0:9200->9200/tcp, :::9200->9200/tcp, 9300/tcp                            elasticsearch
894da3029884   postgres:12.7-alpine                                   "docker-entrypoint.s…"   7 months ago   Up 2 days (healthy)     0.0.0.0:5432->5432/tcp, :::5432->5432/tcp                                      postgresql
9320ff4534a2   vault:1.2.3                                            "docker-entrypoint.s…"   7 months ago   Up 2 days (healthy)     0.0.0.0:8200->8200/tcp, :::8200->8200/tcp                                      vault
7d4d70b1e274   redis                                                  "docker-entrypoint.s…"   7 months ago   Up 2 days (healthy)     0.0.0.0:6380->6379/tcp, :::6380->6379/tcp                                      redis_test
c1ea5dd932ff   redis                                                  "docker-entrypoint.s…"   7 months ago   Up 2 days (healthy)     0.0.0.0:6379->6379/tcp, :::6379->6379/tcp                                      redis

Miramos las capas/layers:

j@nagae ~/Documents/trabajo/bluetab % docker inspect --format='{{json .RootFS}}' docker.elastic.co/elasticsearch/elasticsearch:7.16.2 | jq
{
  "Type": "layers",
  "Layers": [
    "sha256:9f54eef412758095c8079ac465d494a2872e02e90bf1fb5f12a1641c0d1bb78b",
    "sha256:0091885330bf1d2214b6c3590444e9ab8cddea7821bba35dda11f0b36e100328",
    "sha256:80400b84f74d6baeec27de4869cb5749a4cf617045550ab49cee9bf508cafa9d",
    "sha256:24a81c99ac7b986a1a89183df2b613c4cd75f9f0365f0f516e870d277f56643a",
    "sha256:67e50b09e7b0382e023a8cb9a77bb8800a2e85f3979c9c60a44375b1d7851d51",
    "sha256:edf0389470fe5787d4b067bb48c2d68785901035673a7b701b9e1ba76bdb0808",
    "sha256:f55879cea2360c524209ef594cbe416896aa188eb4774b4198430a3572a85c75",
    "sha256:0c1edf8e8f498d5722785bacb68a5393bfd8d073470342095bd4e182a85aade4",
    "sha256:c767c79bac593fa0b9fb451e91cfa4790e425325ca3089485483e6f691700e42"
  ]
}

Buscamos el sha256 del primer layer de la lista en /var/lib/docker/image/btrfs/layerdb/sha256/

[root@nagae sha256]# cat /var/lib/docker/image/btrfs/layerdb/sha256/9f54eef412758095c8079ac465d494a2872e02e90bf1fb5f12a1641c0d1bb78b/cache-id 
be86f413e65a5ee2dde2ee92a0ca20a4ba6f5ca539dbe1afb3b3a670dab0b878

Listamos el contenido. Como curiosidad para mí, los índices de ElasticSearch se encuentran en /var/lib/docker/btrfs/subvolumes/b85eb5cd6786d40494e66e58b93a086763546b5674d9fdf330870d5596209e05/usr/share/elasticsearch/data/nodes/0

[root@nagae sha256]# ls -l /var/lib/docker/btrfs/subvolumes/be86f413e65a5ee2dde2ee92a0ca20a4ba6f5ca539dbe1afb3b3a670dab0b878/
total 24
lrwxrwxrwx 1 root root    7 Oct  6  2021 bin -> usr/bin
drwxr-xr-x 1 root root    0 Apr 15  2020 boot
drwxr-xr-x 1 root root    0 Oct  6  2021 dev
drwxr-xr-x 1 root root 1114 Oct  6  2021 etc
drwxr-xr-x 1 root root    0 Apr 15  2020 home
lrwxrwxrwx 1 root root    7 Oct  6  2021 lib -> usr/lib
lrwxrwxrwx 1 root root    9 Oct  6  2021 lib32 -> usr/lib32
lrwxrwxrwx 1 root root    9 Oct  6  2021 lib64 -> usr/lib64
lrwxrwxrwx 1 root root   10 Oct  6  2021 libx32 -> usr/libx32
drwxr-xr-x 1 root root    0 Oct  6  2021 media
drwxr-xr-x 1 root root    0 Oct  6  2021 mnt
drwxr-xr-x 1 root root    0 Oct  6  2021 opt
drwxr-xr-x 1 root root    0 Apr 15  2020 proc
drwx------ 1 root root   30 Oct  6  2021 root
drwxr-xr-x 1 root root   40 Oct  6  2021 run
lrwxrwxrwx 1 root root    8 Oct  6  2021 sbin -> usr/sbin
drwxr-xr-x 1 root root    0 Oct  6  2021 srv
drwxr-xr-x 1 root root    0 Apr 15  2020 sys
drwxrwxrwt 1 root root    0 Oct  6  2021 tmp
drwxr-xr-x 1 root root  102 Oct  6  2021 usr
drwxr-xr-x 1 root root   90 Oct  6  2021 var


[root@nagae true-dev]# ls -l /var/lib/docker/btrfs/subvolumes/b85eb5cd6786d40494e66e58b93a086763546b5674d9fdf330870d5596209e05/usr/share/elasticsearch/data/nodes/0
total 200
drwxrwxr-x 1 j root 968 Sep  7 08:34 indices
-rw-rw-r-- 1 j root   0 Jun 29 19:03 node.lock
drwxrwxr-x 1 j root  42 Sep  4 16:32 snapshot_cache
drwxrwxr-x 1 j root 710 Sep  7 08:34 _state