Gérer les ressources Docker avec Cgroups

Le mois dernier, j’ai parlé à l’ApacheCon au sujet des Cgroups. Il semble que très peu d’utilisateurs de Linux (y compris votre serviteur il n’y a pas si longtemps) connaissent les Cgroups et leur puissance. C’est bien dommage, car les Cgroups sont très puissants, et vous permettent d’allouer des ressources sur vos serveurs d’une manière beaucoup plus granulaire que n’importe quel autre outil disponible dans la boîte à outils Linux. De plus, c’est intégré directement dans le noyau et fourni d’office avec la plupart des distributions Linux.

Dans cet article, je vais expliquer comment utiliser les Cgroups avec Docker, en guise de suite à une autre présentation que j’ai faite au Docker Meetup à Austin, au Texas.

Cet article nécessite une compréhension de base des Cgroups. Si vous découvrez complètement les Cgroups, je vous recommande de jeter un œil à mon support de présentation de l’ApacheCon ainsi qu’aux ressources à la fin. N’ayez crainte cependant, nous ne plongerons pas trop profondément. Si vous parcourez simplement le support de présentation, vous devriez être en mesure de saisir les concepts de base.

Docker et Cgroups

Docker est fourni avec deux pilotes différents : LXC et libcontainer. Le pilote LXC est le pilote hérité, et libcontainer est le nouveau pilote par défaut. Dans la plupart des cas, libcontainer est le pilote préféré, car c’est là que se produit l’innovation (par exemple docker exec ne fonctionne pas avec le pilote LXC).

Il est cependant important de noter qu’il existe deux pilotes différents, car toutes les fonctionnalités de Cgroup n’ont pas encore été portées sur libcontainer (ou du moins exposées à Docker). Lorsque vous utilisez le pilote LXC, vous transmettez simplement les arguments LXC directement, tandis qu’avec libcontainer, des arguments de politique Cgroup explicites sont exposés à Docker. Vous devrez définir explicitement un pilote lorsque vous lancez le démon Docker, vous ne pouvez donc pas exécuter les deux pilotes simultanément.

Voici un exemple de la façon dont vous pouvez vérifier :

[bash light=”true”] # Avec le pilote LXC
$ docker run -d –name=’lxc_test’ \
–lxc-conf="lxc.cgroup.cpu.shares=50" \
busybox

# Avec le pilote libcontainer
$ docker run -d –name=’libcontainer_test’ \
–cpu-shares=50 \
busybox
[/bash]

Voici un aperçu de certaines fonctionnalités de Cgroup et de leur correspondance entre les deux pilotes :

Fonctionnalité	Libcontainer	LXC
Part de processeur relative	-c, –cpu-shares	–lxc-conf=”lxc.cgroup.cpu.shares”
Verrouiller sur un cœur de processeur	–cpuset-cpus	–lxc-conf=”lxc.cgroup.cpuset.cpus”
Limiter la mémoire	-m, –memory	–lxc-conf=”lxc.cgroup.cpuset.mems”

LXC

Si vous souhaitez utiliser le pilote LXC pour Docker, vous devrez d’abord l’activer. La méthode pour ce faire différera selon votre distribution Linux, mais voici les instructions sur comment activer le pilote LXC sur Ubuntu 14.04.

Comme mentionné ci-dessus, vous renoncez à un certain nombre de fonctionnalités en faisant cela. Par conséquent, à moins que vous n’ayez réellement besoin d’une fonctionnalité qui n’est pas encore exposée dans Docker à l’aide de libcontainer, vous devriez vraiment vous en tenir au pilote par défaut.

Certaines politiques Cgroup utiles qui ne sont pas encore exposées dans libcontainer incluent la régulation des E/S (traitée dans le support de présentation), ce qui peut être très pratique pour certaines applications.

Si vous avez décidé d’utiliser le pilote LXC, l’ajout d’arguments est simple. Tout ce que vous avez à faire est d’ajouter l’argument --lxc-conf et de transmettre la politique Cgroup que vous souhaitez définir.

Libcontainer

Comme vous pouvez le voir dans le tableau ci-dessus, les politiques de base de Cgroup sont déjà exposées dans la version actuelle de Docker (1.6 au moment d’écrire ces lignes).

L’utilisation de ces politiques est très simple. Si vous souhaitez par exemple verrouiller un conteneur Docker sur le premier cœur de processeur, vous ajouteriez --cpuset-cpus=0 à votre commande docker run.

Vous pouvez également utiliser l’argument --cgroup-parent avec libcontainer et définir manuellement des contraintes de ressources plus granulaires. Vous le mapperiez ensuite à ce groupe à l’aide de l’argument.

Démo : Docker avec Cgroups

Dans le screencast ci-dessous, nous utiliserons deux conteneurs Docker (‘low_prio’ et ‘high_prio’). Nous utilisons le conteneur de base ‘busybox’ et exécutons md5sum /dev/urandom pour simuler un processus gourmand en CPU. Par défaut, cela consommerait toutes les ressources CPU disponibles. Cependant, nous appliquerons deux politiques Cgroup pour gérer les ressources. Tout d’abord, nous utilisons ‘cpuset.cpus’ pour verrouiller les conteneurs sur le même cœur CPU (cœur 0).

Ensuite, nous utilisons ‘cpu.shares’ pour attribuer une part de CPU relative. Nous donnons au conteneur ‘low_prio’ une valeur de 20 et à ‘high_prio’ une valeur de 80. Cela signifie que 20% du CPU sera alloué au conteneur ‘low_prio’, et 80% du CPU sera alloué au conteneur ‘high_prio’. Veuillez noter cependant que la part relative est une échelle arbitraire (nous aurions tout aussi bien pu utiliser 2 et 8 comme valeurs).

Après avoir démontré que la gestion des ressources fonctionne bel et bien, nous lançons le même ensemble de conteneurs sans aucune politique Cgroup pour voir comment ils se comportent.

À titre de référence, voici les commandes utilisées pour lancer les conteneurs.

[bash light=”true”] $ docker run -d \
–name=’low_prio’ \
–cpuset-cpus=0 \
–cpu-shares=20 \
busybox md5sum /dev/urandom
$ docker run -d \
–name=’high_prio’ \
–cpuset-cpus=0 \
–cpu-shares=80 \
busybox md5sum /dev/urandom
[/bash]

Résumé

Si vous gérez plusieurs conteneurs Docker sur le même hôte, l’utilisation de Cgroups pour gérer les ressources entre les conteneurs est très logique. Par exemple, vous avez peut-être des tâches de traitement en arrière-plan qui s’exécutent dans un conteneur, et un autre conteneur qui sert du contenu aux utilisateurs. Dans ce cas, vous pouvez utiliser vos nouvelles connaissances pour vous assurer de donner la priorité aux conteneurs orientés utilisateur par rapport aux tâches en arrière-plan.