Réfléchissez bien avant d'utiliser Docker-in-Docker pour l'intégration continue ou l'environnement de test

Docker-in-Docker est un environnement virtualisé du démon Docker, exécuté à l'intérieur d'un conteneur pour créer des images de conteneur. L'objectif principal de la création de Docker-in-Docker était d'aider au développement de Docker lui-même. Beaucoup de gens l'utilisent pour exécuter Jenkins CI. Au départ, cela semble normal, mais des problèmes surviennent, que l'on peut éviter en installant Docker dans le conteneur Jenkins CI. Cet article explique comment faire cela. Si vous êtes intéressé par la solution finale sans détails, lisez simplement la dernière section de l'article intitulée « Résolution du problème ».

Docker-in-Docker : « Bon »

Il y a plus de deux ans, j'ai inséré Docker drapeau –privileged et j'ai écrit la première version de dind. L'objectif était d'aider l'équipe principale à développer Docker plus rapidement. Avant l'avènement de Docker-in-Docker, le cycle de développement typique était le suivant :

• hackity hack;
• construction (build);
• arrêt du démon Docker en cours d'exécution;
• lancement d'un nouveau démon Docker;
• test;
• répéter le cycle.

Cependant, si vous vouliez faire une construction propre et reproductible (c'est-à-dire dans un conteneur), cela devenait plus complexe :

• hackity hack;
• s'assurer qu'une version opérationnelle de Docker est en cours d'exécution;
• construire un nouveau Docker avec l'ancien Docker;
• arrêter le démon Docker;
• lancer un nouveau démon Docker;
• tester;
• arrêter le nouveau démon Docker;
• répéter.

Avec l'arrivée de Docker-in-Docker, le processus s'est simplifié :

• hackity hack;
• construction + lancement en une étape;
• répéter le cycle.

N'est-il pas vrai que c'est beaucoup mieux ?

Docker-in-Docker : « Mauvais »

Cependant, contrairement à la croyance populaire, Docker-in-Docker n'est pas composé à 100% d'étoiles, de poneys et de licornes. Je veux dire qu'il y a plusieurs problèmes dont le développeur doit être conscient.

L'une d'elles concerne LSM (modules de sécurité Linux), tels qu'AppArmor et SELinux : lors du lancement d'un conteneur, le « Docker interne » peut tenter d'appliquer des profils de sécurité qui entreront en conflit ou troubleront le « Docker externe ». C'est le problème le plus complexe à résoudre lors de la tentative de combiner la mise en œuvre d'origine du drapeau –privileged. Mes modifications fonctionnaient, et tous les tests auraient également réussi sur ma machine Debian et mes machines virtuelles de test Ubuntu, mais elles se seraient effondrées sur la machine de Michael Crosby (si je me souviens bien, il avait Fedora). Je ne peux pas me souvenir de la cause exacte du problème, mais il est possible qu'il soit survenu parce que Mike est un homme sage qui fonctionne avec SELINUX=enforce (j'ai utilisé AppArmor), et mes modifications ne prenaient pas en compte les profils SELinux.

Docker-in-Docker : le « maléfique »

Le deuxième problème est lié aux pilotes de stockage Docker. Lorsque vous exécutez Docker-in-Docker, le Docker externe fonctionne au-dessus d'un système de fichiers traditionnel (EXT4, BTRFS ou tout autre que vous avez), tandis que le Docker interne fonctionne sur un système de copy-on-write (AUFS, BTRFS, Device Mapper, etc., selon ce que le Docker externe est configuré pour utiliser). Cela entraîne de nombreuses combinaisons qui ne fonctionneront pas. Par exemple, vous ne pourrez pas exécuter AUFS au-dessus d'AUFS.

Si vous exécutez BTRFS au-dessus de BTRFS, cela devrait d'abord fonctionner, mais une fois que des sous-volumes imbriqués apparaissent, il ne sera pas possible de supprimer le sous-volume parent. Le module Device Mapper n'a pas d'espace de noms, donc si plusieurs instances de Docker l'utilisent sur une même machine, elles pourront toutes voir (et influencer) les images les unes des autres et les dispositifs de sauvegarde des conteneurs. C'est problématique.

Il existe des solutions pour contourner bon nombre de ces problèmes. Par exemple, si vous souhaitez utiliser AUFS dans Docker interne, il suffit de transformer le dossier /var/lib/docker en volume, et tout ira bien. Docker a ajouté certains espaces de noms de base aux cibles de Device Mapper, de sorte que si plusieurs appels Docker sont effectués sur une même machine, ils ne se « marcheront » pas sur les pieds.

Cependant, une telle configuration n'est pas simple, comme vous pouvez le voir dans ces articles dans le dépôt dind sur GitHub.

Docker-in-Docker : ça devient encore pire

Et qu'en est-il du cache de construction ? Cela peut être assez compliqué. Les gens me demandent souvent « si je lance Docker-in-Docker, comment puis-je utiliser les images situées sur mon hôte, plutôt que de tout retélécharger dans mon Docker interne ? »

Certaines personnes entreprenantes ont tenté de lier /var/lib/docker de l'hôte dans le conteneur Docker-in-Docker. Parfois, elles partagent /var/lib/docker entre plusieurs conteneurs.

Voulez-vous corrompre des données ? Parce que c'est exactement ce qui nuira à vos données !

Le démon Docker a clairement été conçu pour avoir un accès exclusif à /var/lib/docker. Rien d'autre ne devrait « toucher, pokéer ou tripoter » les fichiers Docker se trouvant dans ce dossier.

Pourquoi est-ce le cas ? Parce que c'est le résultat de l'une des leçons les plus difficiles apprises lors du développement de dotCloud. Le moteur de conteneurs dotCloud fonctionnait avec plusieurs processus accédant simultanément à /var/lib/dotcloud. Des astuces comme le remplacement atomique de fichiers (au lieu de l'édition sur place), le « peppering » de code avec des verrous recommandés et obligatoires, ainsi que d'autres expériences avec des systèmes sûrs comme SQLite et BDB, ne fonctionnaient pas toujours. Lorsque nous avons refait notre moteur de conteneurs, qui est finalement devenu Docker, l'un des principaux choix de conception a été de regrouper toutes les opérations de conteneurs sous un seul démon, afin de mettre fin à toute cette absurdité d'accès simultané.

Ne vous méprenez pas : il est tout à fait possible de faire quelque chose de bon, fiable et rapide, impliquant plusieurs processus et une gestion moderne du parallélisme. Mais nous pensons qu'il est plus simple et plus facile d'écrire et de maintenir du code en utilisant Docker comme seul acteur.

Cela signifie que si vous partagez le répertoire /var/lib/docker entre plusieurs instances de Docker, vous rencontrerez des problèmes. Bien sûr, cela peut fonctionner, en particulier aux premiers stades des tests. « Écoute, Ma, je peux faire tourner ubuntu avec ‘docker’ ! » Mais essayez de faire quelque chose de plus complexe, comme tirer la même image de deux instances différentes, et vous verrez le monde s'embraser.

Cela signifie que si votre système CI effectue des constructions et des reconstructions, chaque fois que vous redémarrez le conteneur Docker-in-Docker, vous risquez de réinitialiser une bombe à retardement dans son cache. Ce n'est pas génial du tout !

Résoudre le problème

Faisons un pas en arrière. Avez-vous vraiment besoin de Docker-in-Docker ou voulez-vous simplement pouvoir exécuter Docker, c'est-à-dire construire et exécuter des conteneurs et des images depuis votre système CI, pendant que ce système CI se trouve dans un conteneur ?

Je parie que la plupart des gens ont besoin de la dernière option, c'est-à-dire qu'ils veulent que le système CI, tel que Jenkins, puisse exécuter des conteneurs. Et le moyen le plus simple de le faire est d'insérer simplement le socket Docker dans votre conteneur CI, en le liant avec l'option -v.

En d'autres termes, lorsque vous démarrez votre conteneur CI (Jenkins ou autre), au lieu de bricoler quelque chose avec Docker-in-Docker, commencez-le avec la ligne:

docker run -v /var/run/docker.sock:/var/run/docker.sock ...

Maintenant, ce conteneur aura accès au socket Docker et pourra donc exécuter des conteneurs. Sauf que, au lieu de lancer des conteneurs "enfants", il lancera des conteneurs "fraternels".

Essayez cela en utilisant l'image officielle docker (qui contient le fichier binaire Docker) :

docker run -v /var/run/docker.sock:/var/run/docker.sock 
           -ti docker

Cela ressemble et fonctionne comme Docker-in-Docker, mais ce n'est pas Docker-in-Docker : lorsque ce conteneur créera des conteneurs supplémentaires, ils seront créés dans Docker de niveau supérieur. Vous n'aurez pas d'effets secondaires liés à l'imbrication, et le cache de construction sera partagé entre plusieurs appels.

Remarque : les versions précédentes de cet article conseillaient de lier le fichier binaire Docker de l'hôte au conteneur. Cela est désormais devenu peu fiable, car le mécanisme Docker ne s'applique plus aux bibliothèques statiques ou presque statiques.

Ainsi, si vous souhaitez utiliser Docker depuis Jenkins CI, vous avez 2 options :
installer Docker CLI en utilisant le système de base de paquets d'image (c'est-à-dire si votre image est basée sur Debian, utilisez les paquets .deb), utiliser l'API Docker.

Un peu de publicité 🙂

Merci de rester avec nous. Aimez-vous nos articles ? Voulez-vous voir plus de contenu intéressant ? Soutenez-nous en passants une commande ou en nous recommandant à des amis, VPS cloud pour développeurs à partir de 4,99 $, un équivalent unique des serveurs d'entrée de gamme, conçu pour vous : Toute la vérité sur le VPS (KVM) E5-2697 v3 (6 cœurs) 10 Go DDR4 480 Go SSD 1 Gbps à partir de 19 $ ou comment bien diviser un serveur ? (options disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go DDR4).

Dell R730xd deux fois moins cher dans le data center Equinix Tier IV à Amsterdam ? Uniquement chez nous 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64Go DDR4 4x960Go SSD 1Gbps 100 To à partir de 199 $ aux Pays-Bas ! Dell R420 — 2x E5-2430 2.2GHz 6C 128Go DDR3 2x960Go SSD 1Gbps 100To — à partir de 99 $ ! Lisez sur Comment construire une infrastructure de classe entreprise avec des serveurs Dell R730xd E5-2650 v4 coûtant 9000 euros pour des clopinettes ?

Source : habr.com