Pour commencer merci pour toutes tes remarques contructives.
J'aimerai savoir sur quoi tu te bases pour dire ça [...]
C'est vrai on peut faire tourner plusieurs process dans un conteneur Docker. Apparemment, c'est contre les bonnes pratiques : Best practices for writing Dockerfiles. L'idée derrière la philosophie « 1 conteneur, 1 application » est de garder les conteneurs simples (une bonne idée vu de loin) et de faire des liens entre les conteneurs si on a besoin que deux process communiquent. Mon argument est que les méchanismes pour faire des liens entre les conteneurs sont vraiment très rudimentaires dans Docker, ce qui complexifie énormément (au lieu de le simplifier) le déploiement d'applications. J'ai vraiment pas envie de configurer un réseau virtuel entre mes conteneurs pour que nginx communique avec django...
Si on doit lancer plusieurs process dans un conteneur la recommandation est d'utiliser supervisor. C'est également vrai qu'on peut le faire avec un script bash mais du coup faut lancer les premiers process en arrière-plan et de dernier en premier plan. Quant le dernier process termine, tout le conteneur est éteint. Même si ça marche, cette solution (le script bash) me laisse un arrière gout de truc ad-hoc et pas fini.
Pour ce qui est de l'installation de SSH, je ne sais pas si c'est overkill. Certes maintenant, il y docker exec (et nsenter, mais ce dernier fait clairement bidouille), mais pendant longtemps il n'y avait pas grand chose pour inspecter un conteneur.
Les mises à jour sont problématiques oui. Mais ça c'est pas propre à docker, [...]
Effectivement, ça n'est pas propre à Docker. Mais mon argument est que pour un système de contruction d'images, utiliser un versioning statique le rend complètement inutile. Comment je fais comprendre à docker build que git clone n'est pas idempotent etc. Je ne peux pas lancer toute la construction de mon container à son démarrage, ça tue l'utilité de Docker. Et d'ailleurs j'ai pas envie de lancer apt-get upgrade sur 150 machines alors que je pourrais directement déployer une image correcte.
Ça c'est ton avis. J'aurai plutôt tendance à dire que sa simplicité est sa force. [...]
Parmi les points souvent critiqués, il y a:
Pas de possibilité de faire des Dockerfile templates (Hello Packer)
Pas d'héritage multiple de Dockerfile
Pas de logique (if en fonction de variables d'environnement etc.)
Si tu trouves ça limité: qu'est-ce qui t’empêche d'utiliser Docker build avec Cloudinit, puppet ou je ne sais quel tool de on choix ? [...]
Effectivement, mais quel est alors l'intérêt de docker build si Ansible fait tout le boulot ? Le système de cache devient inutile et comme les builds docker sont horriblement lents... Et puis pourquoi ne pas utiliser directement ansible pour déployer la machine finale ?
Docker (et tout système de container) n'est PAS une solution de virtualisation, c'est juste un chroot sous stéroïdes [...]
Ça j'ai bien compris. Mais ma question est alors, à quoi ça sert un « chroot sous stéroïdes ». Je suis pas sur que ça m'aide à déployer des applications. Et les présentations de docker sont clairement trompeuses (voir le petit schéma le comparant à de la virtualisation sur What is Docker), on
laisse clairement supposer que Docker, c'est comme une VM mais sans le Guest OS.
D'ailleurs, j'ai l'impression que Docker ne sait pas sur quel pied danser. Un peu VM. Un peu truc pour compiler statiquement une application.
[^] # Re: Conclusion un peu hative
Posté par X345 . En réponse au journal Docker, la plateforme à la mode. Évalué à 10.
Pour commencer merci pour toutes tes remarques contructives.
C'est vrai on peut faire tourner plusieurs process dans un conteneur Docker. Apparemment, c'est contre les bonnes pratiques : Best practices for writing Dockerfiles. L'idée derrière la philosophie « 1 conteneur, 1 application » est de garder les conteneurs simples (une bonne idée vu de loin) et de faire des liens entre les conteneurs si on a besoin que deux process communiquent. Mon argument est que les méchanismes pour faire des liens entre les conteneurs sont vraiment très rudimentaires dans Docker, ce qui complexifie énormément (au lieu de le simplifier) le déploiement d'applications. J'ai vraiment pas envie de configurer un réseau virtuel entre mes conteneurs pour que nginx communique avec django...
Si on doit lancer plusieurs process dans un conteneur la recommandation est d'utiliser supervisor. C'est également vrai qu'on peut le faire avec un script bash mais du coup faut lancer les premiers process en arrière-plan et de dernier en premier plan. Quant le dernier process termine, tout le conteneur est éteint. Même si ça marche, cette solution (le script bash) me laisse un arrière gout de truc ad-hoc et pas fini.
Pour ce qui est de l'installation de SSH, je ne sais pas si c'est overkill. Certes maintenant, il y
docker exec(etnsenter, mais ce dernier fait clairement bidouille), mais pendant longtemps il n'y avait pas grand chose pour inspecter un conteneur.Effectivement, ça n'est pas propre à Docker. Mais mon argument est que pour un système de contruction d'images, utiliser un versioning statique le rend complètement inutile. Comment je fais comprendre à
docker buildque git clone n'est pas idempotent etc. Je ne peux pas lancer toute la construction de mon container à son démarrage, ça tue l'utilité de Docker. Et d'ailleurs j'ai pas envie de lancer apt-get upgrade sur 150 machines alors que je pourrais directement déployer une image correcte.Parmi les points souvent critiqués, il y a:
Effectivement, mais quel est alors l'intérêt de
docker buildsi Ansible fait tout le boulot ? Le système de cache devient inutile et comme les builds docker sont horriblement lents... Et puis pourquoi ne pas utiliser directement ansible pour déployer la machine finale ?Ça j'ai bien compris. Mais ma question est alors, à quoi ça sert un « chroot sous stéroïdes ». Je suis pas sur que ça m'aide à déployer des applications. Et les présentations de docker sont clairement trompeuses (voir le petit schéma le comparant à de la virtualisation sur What is Docker), on
laisse clairement supposer que Docker, c'est comme une VM mais sans le Guest OS.
D'ailleurs, j'ai l'impression que Docker ne sait pas sur quel pied danser. Un peu VM. Un peu truc pour compiler statiquement une application.