Dans cet article, le second de la série sur les volumes, je vais aborder un nouvel usage des volumes, la création de contextes séparés. En effet, avoir un nom de répertoire différent entre l’intérieur et l’extérieur du conteneur peut apporter un certain nombre d’avantages.
Séparation de logs
Prenons l’exemple d’un conteneur avec une application qui log tout dans /var/log/app/ avec les options de montage des volumes il est possible de lancer 3 fois cette même application et de sauver les fichiers générés dans 3 répertoires différents :
:::shell
docker run -v /data/logs/app1:/var/log/app --name app1 conteneur
docker run -v /data/logs/app2:/var/log/app --name app2 conteneur
docker run -v /data/logs/app3:/var/log/app --name app3 conteneur
C’est par exemple utilisé pour sauvegarder les logs d’une application que l’on doit démultiplier pour faire face à la charge.
Pour une bonne analyse, il faudra, à intervalle régulier, collecter l’ensemble des fichiers. La centralisation de ces logs en continu dans un moteur dédié serait probablement plus efficace, mais un peu plus complexe à mettre en œuvre.
Certains vont faire remarquer qu’il est possible de lancer l’application de cette façon :
:::shell
docker run -v /data/logs:/var/log/app --name app1 conteneur
docker run -v /data/logs:/var/log/app --name app2 conteneur
docker run -v /data/logs:/var/log/app --name app3 conteneur
Mais attention, il est peut probable que notre application lancée 3 fois arrive à gérer correctement l’accès concurrent aux mêmes fichiers de logs. Des applications comme Tomcat ou WebLogic ouvrent les fichiers au démarrage et écrivent dedans en continue en supposant être les seules au monde. De plus, en centralisant de cette façon on retombe sur le problème de système de fichiers partagé, abordé dans l’article précédent.
Contextes clients
Monter un répertoire différent pour plusieurs conteneurs identique peut aussi
être utilisé pour différencier différentes instances d’un même conteneur.
Prenons l’exemple d’une application qui lit et écrit l’ensemble de ses données
applicatives dans /home/application. Il est possible de dédier chaque
instance à un usage donné.
:::shell
docker run -v /data/client1:/home/application --name app1 conteneur
docker run -v /data/client2:/home/application --name app2 conteneur
Avec cette configuration, chaque conteneur va pouvoir vivre sa vie avec ses
propres données. Plus besoins de loadbalancer devant pour agréger le trafic
vers les 2 conteneurs, mais 2 URLs différents pour accéder à 2 contextes
clients différents. On peut imaginer que pour utiliser “app1” il faut visiter
http://client1.app.com et pour se retrouver sur app2
http://client2.app.com. C’est un bon moyen de cloisonner les clients sans
trop d’efforts, mais attention, si le nombre de clients est trop grand, la
gestion des multiples conteneurs risque fort d’être périlleuse.
Conclusion
Dans le cas d’une multiplication de conteneur pour faire face à une augmentation de charge, il est possible de rapidement démultiplier les répertoires de logs, mais l’usage d’un serveur de centralisation à base de Logstash sera probablement bien plus générateur de valeur.
Dans le cadre d’une séparation de clients, il est important de regarder le nombre de contextes à réaliser avant de choisir une solution à base de volumes.
Photo par Ricky Artigas