Lors de notre session au Ch'tiJug, expliquant entre deux anecdotes que Docker peut même être lancé à l'intérieur d'un autre container Docker, on (amis, j'ai oublié ton nom) nous a suggéré de faire un calcul récursif de suite de Fibonacci via des containers Docker.
Il n'en fallait pas autant pour lancer David sur la piste d'un projet aussi inutile qu'indispensable, dont il a publié le résultat : https://github.com/dgageot/fiboid "Fibo Inside Docker". Ce gars ne dors jamais, ou bien il est vraiment cinglé, ou peut être les deux, en tout cas svp ne l'encouragez pas.
A quoi ça sert ?
Sur l'exemple de David : a rien - enfin si, à tester la capacité de Docker à fonctionner en mode "poupée russe" et voir jusqu'où il peut aller.
Dans l'absolu, je suis longtemps resté perplexe, mais j'ai depuis vu passer plusieurs usages.
1. Builder des images Docker.
eBay a adopté Mesos et Docker, et a publié un papier dessus. Depuis Jenkins, un container Docker est donc lancé sur le cluster Mesos pour héberger chaque build. Jusque là, c'est simple, sauf que ce build veut lui même construire et tester des images Docker, et va donc lancer Docker dans l'image Docker. On a donc un premier niveau d'imbrication.
2. Packager un environnement multi-noeud.
Il n'en fallait pas autant pour lancer David sur la piste d'un projet aussi inutile qu'indispensable, dont il a publié le résultat : https://github.com/dgageot/fiboid "Fibo Inside Docker". Ce gars ne dors jamais, ou bien il est vraiment cinglé, ou peut être les deux, en tout cas svp ne l'encouragez pas.
A quoi ça sert ?
Sur l'exemple de David : a rien - enfin si, à tester la capacité de Docker à fonctionner en mode "poupée russe" et voir jusqu'où il peut aller.
Dans l'absolu, je suis longtemps resté perplexe, mais j'ai depuis vu passer plusieurs usages.
1. Builder des images Docker.
eBay a adopté Mesos et Docker, et a publié un papier dessus. Depuis Jenkins, un container Docker est donc lancé sur le cluster Mesos pour héberger chaque build. Jusque là, c'est simple, sauf que ce build veut lui même construire et tester des images Docker, et va donc lancer Docker dans l'image Docker. On a donc un premier niveau d'imbrication.
2. Packager un environnement multi-noeud.
Tester rapidement un project composé de N containers, ça signifie aujourd'hui fournir N images Docker et le script de lancement qui va bien (voir aussi le format containers.yml de Google). Une autre façon de faire, c'est de définir un Dockerfile qui lance les N conteneurs Docker de l'application. A nouveau, imbrication de containers
Je suppose qu'il y a plein d'autres cas intéressant à inventer.
Là ou fiboid est intéressant, c'est qu'il montre COMMENT imbriquer les containers. Car l'approche naïve que j'ai moi aussi testée dans le TGV qui me ramenais à Rennes, coincé entre deux valises d'un wagon bondé, c'est de lancer sans plus de scrupules "docker run" dans mon Dockerfile - sauf que ça ne marche pas. Sans 3G et avec les cuisses qui cuisent, je n'ai pas insisté :'(
Il y a en effet une petite manip pas triviale, résumée dans l'exemple de David par le script startdocker
Le premier truc à savoir c'est qu'il faut que le container tourne en mode "privilégié" pour pouvoir exploiter les containers (auxquels il est lui-même soumis), à savoir les API cgroup, les restrictions AppArmor, etc (je ne détaille pas car je n'y connais rien).
Ensuite, exploiter les cgroups depuis un container nécessite un minimum de collaboration avec l'hôte qui porte le container courant. Il faut donc synchroniser les cgroups du container avec ceux de l'hôte. Le reste du script est lié a divers raffinements et contournements, pour finalement lancer un démon Docker dans le container, qui permettra de lancer la commande "docker run" comme prévu.
Le principe d'imbrication des containers a été démontré initialement (afaik) par Jerôme Petazzoni, dont David a repris la recette. Le script wrapdocker ayant 3 mois, soit une éternité dans le contexte de Docker, il est possible que certains hacks ne soient plus nécessaires. Si quelqu'un en maitrise les détails, faites lui une pull-request :)
Je suppose qu'il y a plein d'autres cas intéressant à inventer.
Là ou fiboid est intéressant, c'est qu'il montre COMMENT imbriquer les containers. Car l'approche naïve que j'ai moi aussi testée dans le TGV qui me ramenais à Rennes, coincé entre deux valises d'un wagon bondé, c'est de lancer sans plus de scrupules "docker run" dans mon Dockerfile - sauf que ça ne marche pas. Sans 3G et avec les cuisses qui cuisent, je n'ai pas insisté :'(
Il y a en effet une petite manip pas triviale, résumée dans l'exemple de David par le script startdocker
Le premier truc à savoir c'est qu'il faut que le container tourne en mode "privilégié" pour pouvoir exploiter les containers (auxquels il est lui-même soumis), à savoir les API cgroup, les restrictions AppArmor, etc (je ne détaille pas car je n'y connais rien).
Ensuite, exploiter les cgroups depuis un container nécessite un minimum de collaboration avec l'hôte qui porte le container courant. Il faut donc synchroniser les cgroups du container avec ceux de l'hôte. Le reste du script est lié a divers raffinements et contournements, pour finalement lancer un démon Docker dans le container, qui permettra de lancer la commande "docker run" comme prévu.
Le principe d'imbrication des containers a été démontré initialement (afaik) par Jerôme Petazzoni, dont David a repris la recette. Le script wrapdocker ayant 3 mois, soit une éternité dans le contexte de Docker, il est possible que certains hacks ne soient plus nécessaires. Si quelqu'un en maitrise les détails, faites lui une pull-request :)
0 commentaires:
Enregistrer un commentaire