Corriger les volumes temporaires avec les volumes Docker !

Voici un problème que je trouve pas assez bien documenté sur les images Docker officielles de certains éditeurs ! C'est un problème que j'ai rencontré, pour la création de ce blog même.

Volume managé

Un volume Docker managé permet de laisser le Docker Engine monter un volume qui se trouvera dans /var/lib/docker

Par exemple, dans un docker-compose, si on veut monter un volume pour les logs de notre conteneur Nginx, on effectuera cela :

  nginx:
    image: nginx
    ports:
      - 80:80
    volumes:
      - nginx-logs:/var/log/nginx
  
  volumes:
    nginx-logs:

Petit rappel, pour connaître le répertoire du volume nginx-logs, il suffit d'éxecuter la commande suivante :

docker volume inspect nginx-logs

Avec la version filtrée :

docker volume inspect -f={{.Mountpoint}} nginx-logs

Maintenant, cela peut poser le souci suivant. Si dans le Dockerfile de l'image utilisée, la séquence VOLUME est utilisée, alors, le conteneur ira automatiquement essayer de déposer des fichiers dans le répertoire de ce volume.

Or, si aucun volume n'est monté dans ce répertoire, vous allez vous retrouver avec plein de volumes temporaires (crées à chaque docker-compose up) comme ceci :

$ docker volume ls
DRIVER    VOLUME NAME
local     1a705beeb86227e18a79315b0b508da1a93d0091d34110116ab3f8b854ebba56
local     1f4b65b082b0c182cccc5514b599ed6e8ed0d1474f4dcbf5189a64afda4565b7
local     2b9aee5172092c5c7c8b6c17dd94765105b9364d794e29579d72155daa7f9bae
local     2b9e94ef919eb40188426214a239a6b4accb87982af15e8b10b17df3a4f42249
local     3ae340475afd87725b013ea83aeb4cf997e224c4171cce2b13f8e5974ddf3b8d
local     5b781b2dcd77b5387378850a208acd0efe0c5d5ddc49f166eea1113e880f655c
local     7ee9760152e43b0fe346e8442f43658a66134264181e6a909ead1c3c05fe141e
local     8ac57e923b4f58aa13828c2475b2e6e1fd714da84a7846e98bfe148fdc5b82b3
local     8bf6f0ce49f456020e8b93ddd4f3a3c6e7bfa869304d06d044a805ae3ccdd78b
local     8e0a2a472330da18e7cc7f08faa327f82ae805137de29978ad818196f0a17d28
local     9f7eee9311ffcc2aaae1e5e4cd1d6300e363a26b23a8108314d893973b4d3f9d
local     50e26d585b322ae55d1881bfea0063f5d1803fb960e443abe78ae252af0105bb
local     64e808855828223ca8959c31705e76b078d5aea5b9118cd727a65edd4e02ef0b
local     211e41cc312ff2bac5f0b40b281deea24515e05911c9ed50748da83b564ec895
local     288d78a88ea65be6218254b544450f27cd1cd874af4cc0c39237e5ccb01e753f
local     895ada4b07029194bbf165735c1a84dd92ab0ce1cbf0887c006ac0546d08f835
local     948cb2a1f47873013dd86305444e2603fc3e39bb59bc002e5cce1474d167bd80
local     1232634c38a53fef64254a80668ea6b9abb3ef934c1137a2d7f9c620d1a91a12

C'était le cas avec l'image Docker pour le CMS Ghost utilisé pour ce blog.

Problème causé

Le problème causé est tout simplement que lorsque j'effectuais un docker-compose down puis un docker-compose up -d, les images disparaissaient car elles étaient stockées dans ces layers temporaires.

J'ai pu le détecter avec la commande locate suivi du nom d'une image png, et voir que l'image était stockée dans un volume temporaire. Et également, en inspectant le conteneur ghost, j'ai pu voir qu'un 2e volume était monté :

Vérification

Pour vérifier si la séquence VOLUME est utilisée dans le Dockerfile, il faut se rendre sur le Docker Hub ou sur la registry depuis laquelle l'image a été pull et analyser les layers de l'image.

Nous pouvons voir qu'au layer 21 de l'image, le Volume est monté sur le répertoire /var/lib/ghost/content

Correction

Pour corriger ce souci et ne plus se retrouver avec des fichiers présents sur des volumes temporaires, il faut tout simplement monter le même volume que dans le Dockerfile de l'image.

Voici un exemple de docker-compose pour Ghost avec 2 volumes montés :

  ghost:
    image: ghost
    restart: unless-stopped
    container_name: ghost
    hostname: ghost
    env_file: .env
    volumes:
      - ghost:/var/lib/ghost
      - ghost-content:/var/lib/ghost/content
    networks:
      - ghost
  
  volumes:
    ghost:
    ghost-content:

On se retrouvera avec nos fichiers dans les volumes ghost et ghost-content et non pas sur le volume 3d19d025de210a76f6ecc885f524e8c040028b17e900d0624c13599e5695badc par exemple :)