Comment j'ai lancé Docker à l'intérieur de Docker et ce qui en est résulté

Bonjour à tous ! Dans mon l'article précédent, j'avais promis de parler du lancement de Docker dans Docker et des aspects pratiques de cette activité. Il est temps de tenir ma promesse. Un DevOps expérimenté pourrait objecter que ceux qui ont besoin de Docker dans Docker se contentent généralement de transférer le socket du démon Docker de l'hôte dans le conteneur, et cela suffit dans 99 % des cas. Mais ne vous dépêchez pas de me lancer des cookies, car nous allons vraiment aborder le lancement de Docker à l'intérieur de Docker. Cette solution possède de nombreuses applications possibles, et cette article en traite une. Alors, asseyez-vous confortablement et redressez vos mains.

Début

Tout a commencé un soir de septembre pluvieux, lorsque je nettoyais une machine louée pour 5 $ sur Digital Ocean, qui s'est figée à cause du fait que Docker avait envahi les 24 Go d'espace disque disponible avec ses images et conteneurs. L'ironie était que toutes ces images et conteneurs étaient transitoires et n'étaient nécessaires que pour tester le bon fonctionnement de mon application chaque fois qu'une nouvelle version d'une bibliothèque ou d'un framework sortait. J'ai essayé d'écrire des scripts shell et de configurer des tâches cron pour nettoyer le désordre, mais cela n'a pas servi : chaque fois, cela se terminait inévitablement par un espace disque de mon serveur complètement consommé et un serveur figé (au mieux). À un moment donné, je suis tombé sur un article sur comment lancer Jenkins dans un conteneur et comment il pouvait créer et supprimer des pipelines de compilation via le socket du démon Docker transféré vers lui. L'idée m'a plu, mais j'ai décidé d'aller plus loin et d'expérimenter le lancement direct de Docker dans Docker. Je pensais alors qu'il était tout à fait logique de télécharger des images Docker et de créer des conteneurs pour toutes les applications dont j'avais besoin pour tester à l'intérieur d'un autre conteneur (appelons-le conteneur de staging). L'idée était de lancer le conteneur de staging avec l'option -rm, qui supprime automatiquement tout le conteneur avec tout son contenu à son arrêt. J'ai fouillé l'image Docker de Docker lui-même (https://hub.docker.com/_/docker), mais elle s'est révélée trop encombrante et je n'ai pas réussi à la faire fonctionner comme je le voulais, alors j'avais envie de tout faire par moi-même.

Pratique. Échecs.

J'ai pour objectif de faire fonctionner le conteneur comme je le souhaite, et j'ai poursuivi mes expériences, ce qui a entraîné une multitude d'erreurs. Le résultat de ma quête d'autopunition est l'algorithme suivant :

1. Lançons le conteneur Docker en mode interactif.

   docker run --privileged -it docker:18.09.6

   Notez la version du conteneur, un pas à droite ou à gauche et votre DinD se transforme en citrouille. En réalité, tout se casse assez souvent avec la sortie d'une nouvelle version.
   Nous devons immédiatement accéder au shell.

2. Essayons de voir quels conteneurs sont en cours d'exécution (Réponse : aucun), mais exécutons la commande quand même :

   docker ps

   Vous serez un peu surpris, mais en fait, le démon Docker n'est même pas lancé :

   error during connect: Get http://docker:2375/v1.40/containers/json: dial tcp: lookup docker on 
   192.168.65.1:53: no such host

3. Lançons-le nous-mêmes :

   dockerd &

   Une autre mauvaise surprise :

   failed to start daemon: Error initializing network controller: error obtaining controller instance: failed 
   to create NAT chain DOCKER: Iptables not found

4. Installons les paquets iptables et bash (travailler dans bash est bien plus agréable que dans sh) :

   apk add --no-cache iptables bash

5. Lançons bash. Enfin, nous sommes de retour dans un shell familier.

6. essayons de relancer Docker :

   dockerd &

   Nous devrions voir un long défilement de journaux se terminant par :

   INFO[2019-11-25T19:51:19.448080400Z] Daemon has completed initialization          
   INFO[2019-11-25T19:51:19.474439300Z] API listen on /var/run/docker.sock

7. Appuyez sur Entrée. Nous sommes de nouveau dans bash.

À partir de ce moment, nous pouvons essayer de lancer d'autres conteneurs à l'intérieur de notre conteneur Docker, mais que faire si nous voulons démarrer un autre conteneur Docker à l'intérieur de notre conteneur Docker ou si quelque chose ne va pas et que le conteneur "s'écrase" ? Recommencer depuis le début.

Conteneur DinD personnel et nouvelles expériences

Pour ne pas répéter les étapes décrites ci-dessus encore et encore, j'ai créé mon propre conteneur DinD :

https://github.com/alekslitvinenk/dind

Une solution DinD fonctionnelle m'a permis de lancer Docker à l'intérieur de Docker de manière récursive et d'effectuer des expériences plus audacieuses.
Je vais maintenant décrire une telle expérience (réussie) avec le lancement de MySQL et Nodejs.
Les plus impatients peuvent voir comment cela s'est passé ici.

Alors, commençons :

1. Lançons DinD en mode interactif. Dans cette version de DinD, nous devons mapper manuellement tous les ports que nos conteneurs fils peuvent utiliser (je travaille déjà là-dessus).

   docker run --privileged -it 
   -p 80:8080 
   -p 3306:3306 
   alekslitvinenk/dind

   Nous accédons au bash, où nous pouvons immédiatement commencer à lancer des conteneurs enfants.

2. Lançons MySQL :

   docker run --name mysql -e MYSQL_ROOT_PASSWORD=strongpassword -d -p 3306:3306 mysql

3. Nous nous connectons à la base de données comme nous le ferions localement. Nous vérifions que tout fonctionne.

4. Lançons le deuxième conteneur :

   docker run -d --rm -p 8080:8080 alekslitvinenk/hello-world-nodejs-server

   Notez que le mapping de port ici sera exactement 8080:8080, car nous avons déjà mappé le port 80 de l'hôte au conteneur parent sur le port 8080.

5. Allons sur localhost dans le navigateur et vérifions que le serveur répond « Hello World ! ».

Dans mon cas, l'expérience avec les conteneurs Docker imbriqués s'est avérée assez positive et je vais continuer à développer le projet et l'utiliser pour le staging. Je pense que c'est une solution beaucoup plus légère que Kubernetes et Jenkins X. Mais c'est mon opinion subjective.

Je pense que c'est tout pour l'article d'aujourd'hui. Dans le prochain article, je décrirai plus en détail les expériences avec l'exécution récursive de Docker dans Docker et le montage de répertoires dans des conteneurs imbriqués.

P.S. Si vous trouvez ce projet utile, n'hésitez pas à lui donner une étoile sur GitHub, à le forker et à en parler à vos amis.

Éditer1 J'ai corrigé des erreurs et mis l'accent sur 2 vidéos

Source : habr.com