Lorsque les enjeux d’un cluster de démons Docker ont été exposés au tout début du présent ouvrage, il a été expliqué que le principal besoin derrière ce mécanisme était d’assurer une montée en charge simple et efficace. L’efficacité de cette méthode dépend bien sûr de la ressource disponible, mais également de l’algorithme sous-jacent, certains passant bien à l’échelle (de manière linéaire), d’autres moins (besoin de ressources augmentant exponentiellement avec la quantité de données à traiter, par exemple). Or, Docker ne peut pas faire grand-chose pour le second critère.
Pour ce qui est du premier critère, nous avons vu plus haut que la commande scale apportait une grande simplicité à la mise en œuvre de conteneurs supplémentaires pour supporter plus de charges, et il est même possible (ceci sera évoqué un peu plus en détail dans un prochain chapitre) de rajouter des conteneurs de manière automatique. En complément, un répartiteur de charge permet de faire en sorte qu’un point d’entrée unique soit routé successivement vers les différents conteneurs, ce qui permet d’ajouter encore plus de simplicité, l’appelant ayant affaire à la même ...
Abonnement
tous les livres et vidéos ENI en illimité sans engagement
du livre imprimé ou du livre numérique