un conteneur est éphémère. En effet, lorsqu'il est détruit, tout ce qui était contenu dans le conteneur disparaît et ne laisse aucune trace, même sur l'hôte. Toutes les données sont donc supprimées.
Les volumes permettent aux conteneurs de persister les données d'un conteneur sur la machine hôte ou sur un support. Ces données sont gardées en mémoire de manière permanente afin de les exporter ou de les importer et les réutiliser soit par d'autres conteneurs ou par d'autres systèmes.

Intérets :

1. Persister de la données
2. Permet de faire des backups
3. Partage entre multiple conteneur
4. Répartition des permissions sur multiconteneurs
5. En local ou distants
   

Il existe trois types de volumes expliqués ci-dessous.

Seulement disponible sur Linux, ces volumes sont crées par docker. Les données sont stockées uniquement dans la mémoire RAM du système hôte et attachés au container. Cette option permet créer un espace de travail temporaire en mémoire, qui sera donc perdu à l’arrêt du conteneur.
Il n'y a donc pas de persistance de données, cependant les performances de vitesses d'accès aux données sont plus importantes.

docker run --mount type=tmpfs, dst=/chemin/destination/dans/conteneur, tmpfs-size=100M, tmpfs-mode=770 nom-image

\\

Cette fonctionnalité permet de mapper (créer un point de montage) entre un dossier de l'ordinateur local (lhôte) et un dossier de conteneur. Les données local (point de montage) vont montées dans le répertoire du conteneur. Ils offrent un moyen pratique de partager des données (fichiers et repertoires) entre l’hôte et le(s) conteneur(s).
Cette méthode se distingue par sa flexibilité et sa facilité d’utilisation, offrant une solution pratique pour le développement et les tests, ainsi que pour des scénarios de production spécifiques.

L'utilisation du bind mount peut être nécessaire dans les cas suivants :

• Permet la persistance de données après suppression de conteneur.
• Permet l'accès à des dossiers ou des fichiers partagés entre votre hôte et les conteneurs (logs, fichier de .conf, etc).
  
• Faciliter le partage de code entre l'hôte et les conteneurs, dans le cadre d'un environnement de développement (code sources visible immédiatement dans le conteneur, hot reload).
  
• Ce type de montage est utile lorsque nous accédons et modifions fréquemment un fichier et que le conteneur lui ne doit pas le modifier ou alors de façon peu fréquente.
  

A savoir que les dossiers et fichiers de l'hôte prennent le dessus sur les dossiers et fichiers du conteneur. Les fichiers et dossiers déjà existants non présent chez l'hôte seront inaccessible mais ne seront pas supprimées.

docker run --mount type=bind, src=/dossier/source/hote, dst=/dossier/dst/conteneur ImageOuRepository
docker run --mount type=bind, src=/dosstest/test-contnr, dst=/srv/conteneur ubuntu:20.04

Globalement, bind mount est pratique pour le développement et aussi pour un accès direct aux fichiers de l'ôte.
Il est moins sécurié car le conteneur peut accéder à des fichiers sensibles.

Cette fonctionnalité permet à docker de gérer un répertoire de stockage de donnéeds généralement crée dans /var/lib/docker/volumes. Ainsi leur persistance après suppression du conteneur, les données sont sauvegardées. Il est géré entièrement par l'API, quel que soit le système. C’est la solution à privilégier dans le cas de système hétérogènes.
Le volume est extrêmement pratique dans le cas d'utilisation de bases de données ou autres applications ou de fichiers applicatifs initiaux présents dans une image.
L'utilisation de volume managé peut être nécessaire pour les critères suivants :

• SECURITE : les volumes sont isolés du système de fichiers hôte.
  
• PORTABILITE : de ces volumes permet de gérer les volumes contenant des données persistantes (databases, Uploads, fichier .conf, etc…) sont faciles à migrer entre hôtes docker.
  
• PARTAGE : des volumes entre conteneurs connectés est réalisable en toute sécurité.
  
• SAUVEGARDE : Les volumes peuvent être stockés sur des hôtes distants, des fournisseurs de cloud, sur stockage NFS, etc…
  
• RESTAURATION : Les nouveaux volumes peuvent avoir leur contenu prérempli par un conteneur.
  
• PERFORMANCE I/O : Les volumes écrivent directement sur le système de fichiers hôte, sans passer par le driver de stockage du conteneur.
  

Un volume nommé sera créé à la demande si son nom (la source, ou ‘src’) n’existe pas, et sera réutilisé s’il existe.
Si un volume nommé vide est monté sur un conteneur où le point d’accroche (destination) n’est pas vide et contient fichiers et/ou dossiers, alors ces fichiers sont copiés dans le volume hôte en question avant démarrage du conteneur (pratique pour les databases, applications et fichiers applicatifs initiaux présents dans une image).

docker volume ls    # Lister les volumes
docker volume create  nom_volume    # Créer manuellement un volume (simple dossier vide)
docker volume rm nom_volume    # Supprimer un volume s'il n'est utilisé par aucun conteneur existant
docker volume inspect nom_volume    # Lister les informations du volume
docker volume prune    # Nettoyer les volumes non utilisés (peut ajouter option -f)
docker volume rm $(docker volume ls -q) # Supprime tous les volumes Docker

docker run --mount type=volume, src=/dossier/source/hote, dst=/dossier/dst/conteneur ImageOuRepository
docker run --mount type=volume,src=/srv/telegraf,dst=/srv/telegraf bash

La plus courte et plus légère :

# Dans le cas d'un bind mount
docker run -v <volume_hôte>:<dossier_conteneur>[:ro]
# Dans le cas d'un volume nommé
docker run -v <volume_nommé>:<dossier_conteneur>[:ro]

La plus complète :

--mount type=bind,src=<source>,dst=<destination>,readonly
--mount type=volume,src=<source>,dst=<destination>
--mount type=tmpfs,dst=<destination>(,tmpfs-size=50M,tmpfs-mode=0770 bash)

Nous pouvons créer un volume nommé dans un fichier docker-compose.yml. Il doit être défini à deux endroits :

1. Dans la section volumes: du service concerné
2. Dans la section globale volumes: en bas du fichier

version: '3.3'
 
services:
  web:
    #Nous précisons le contexte où le conteneur devra récupéré les fichiers necessaires à son build 
    build: 
      context: ./web/
      dockerfile: dockerfile
 
    ports: #choix du port (8000 est le port de la machine hote, 80 est le port utilisé par le service du conteneur)
      - 8000:80
    volumes:    # VolumeWebS monté à l'emplacement /var/www/html du conteneur
      - VolumeWebS:/var/www/html
 
Volumes:      # Déclaration du volume
  VolumeWebS:

La section volumes monte le volume nommé VolumeWebS dans le conteneur à l’emplacement /var/www/html
La section globale volumes déclare le volume nommé VolumeWebS. Si le volume n’existe pas docker le créer automatiquement dans /var/lib/docker/volumes/NomVolume.

version: '3.3'
 
services:
  web:
    #Nous précisons le contexte où le conteneur devra récupéré les fichiers nécessaires à son build 
    build: 
      context: ./web/
      dockerfile: dockerfile
 
    ports: #choix du port (8000 est le port de la machine hote, 80 est le port utilisé par le service du conteneur)
      - 8000:80
    volumes:    # VolumeWebS monté à l'emplacement /var/www/html du conteneur
      - VolumeWebS:/var/www/html
 
Volumes:      # Déclaration du volume
  VolumeWebS :
  driver: local
  driver_opts:
    type: none
    device: /chemin/dossier/local
    o: bind

• driver: local: utilise le driver local de Docker
• type: none + o: bind : indique que le volume est un bind mount
• device: /chemin/dossier/local : chemin absolu sur ton hôte déjà existant avec droit d'accès à ce dossier par docker avant docker-compose up
• VolumeWebS:/var/www/html : monte ce dossier dans le conteneur à /var/www/html. Ce volume est nommé mais agit comme un bind mount. Il ne sera donc pas stocké dans /var/lib/docker/volumes