Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
technique:docker:good_practices:storage [2020/10/13 16:21] – [Bind mount] qduchemitechnique:docker:good_practices:storage [2022/05/24 21:11] (Version actuelle) ppom
Ligne 35: Ligne 35:
 * Pour **monter un ou des fichiers existants** dans un conteneur, on utilise un bind mount, * Pour **monter un ou des fichiers existants** dans un conteneur, on utilise un bind mount,
 * Pour **assurer la persistance d'un dossier du conteneur**, qui est initialement vide, on utilise un volume Docker. * Pour **assurer la persistance d'un dossier du conteneur**, qui est initialement vide, on utilise un volume Docker.
 +
 +## Cas particulier 
 +
 +Ce paragraphe va un peu semer la confusion, désolé.
 +
 +<bootnote>
 +Les volumes Docker sont situés dans `/var/lib/docker/volumes`, en interne. En général, sur les machines qui accueillent des services publics, `/var/lib/docker` est sur une partition qui utilise le SSD, pour obtenir de bonnes performances.
 +</bootnote>
 +
 +Or, certains services demandent un stockage assez conséquent, notamment lorsqu'il s'agit de médias. Dans ce cas, il est préférable d'utiliser une partition provenant d'un HDD. La capacité des SSD est beaucoup plus faible et pas forcément pertinente pour stocker des vidéos.
 +
 +Dans le cas précis où :
 +
 +* On veut persister des médias de grande taille dans un conteneur
 +* Que `/var/lib/docker` est stocké sur un SSD
 +
 +Alors on utilisera un **bind-mount sur un dossier qui utilise un HDD**. Le chemin du dossier à monter sera donc codé en dur et sera absolu, ce qui est dommage, mais on a pas le choix.
 +
 +<bootnote>
 +Si la machine virtuelle n'a qu'un seul disque virtuel, qui utilise le SSD (à vérifier dans Proxmox), on pourra [[technique:infrastructure:new_vm_disk|ajouter un disque virtuel qui utilise le HDD]] et monter le système de fichier qu'on créera dans un dossier arbitraire, qui sera utilisé pour le bind mount.
 +</bootnote>
  
 ## Bind mount ## Bind mount
  
-Si le fichier à monter est versionné sur le dépôt `dockerfiles`, on utilisera un chemin relatif. Sinon, on utilisera des chemins absolus, ce qui enlève du côté "indépendant des machines", mais parfois on ne peut pas faire autrement. Par exemple, quand des certificats sont stockés sur une machine de production dans un dossier spécifique, on est obligés d'y faire référence.+Si le fichier à monter est versionné sur le dépôt, on utilisera un chemin relatif. Sinon, on utilisera des chemins absolus, ce qui enlève du côté "indépendant des machines", mais parfois on ne peut pas faire autrement. Par exemple, quand des certificats sont stockés sur une machine de production dans un dossier spécifique, on est obligés d'y faire référence.
  
 <bootnote important>Il convient de ne pas monter de volume sensible (par exemple ''/etc'') dans un conteneur, parce que les conteneurs peuvent par défaut modifier les volumes montés avec des privilèges ''root''. Ainsi, il ne faut surtout pas monter la socket Docker (''/var/run/docker.sock'') dans un conteneur (sauf raison exceptionnelle, *i.e.* Traefik).</bootnote> <bootnote important>Il convient de ne pas monter de volume sensible (par exemple ''/etc'') dans un conteneur, parce que les conteneurs peuvent par défaut modifier les volumes montés avec des privilèges ''root''. Ainsi, il ne faut surtout pas monter la socket Docker (''/var/run/docker.sock'') dans un conteneur (sauf raison exceptionnelle, *i.e.* Traefik).</bootnote>
  • technique/docker/good_practices/storage.1602598862.txt.gz
  • de qduchemi