Et qu'est ce qui t’empêche de faire ça avec Docker [...]
Faire quoi ? Déployer une image à jour de Debian ? Je viens de le dire, par défaut, avec son système de cache qui ne fonctionne pas, docker ne rééxecutera pas apt-get update; apt-get upgrade. Je sais qu'on peut bypasser le cache mais le souci est la construction des images Docker est vraiment lente.
Je veux pas lancer un troll mais j'ai l'impression d'avoir le même débat qu'avec systemd et le traditionnel "c'était mieux avant".
Oulà non. Non, c'était pas mieux avant quand on administrait les machines à la main. Surement pas. Ces dernières années, on a plein de technos qui sont apparues pour faire du DevOps, notamment tout un tas de systèmes de gestion de configuration et d'orchestration à la Puppet, Chef, Ansible et Salt. Et ça, indubitablement, c'est très bien.
Pour ce qui est du déploiement d'applications, on voit bien qu'on a besoin de containers. Une VM c'est clairement overkill pour isoler les applications; c'est totalement inutile d'aller émuler une carte réseau et les autre périphériques d'entrée-sortie. Pareil pas besoin d'avoir 15 noyaux Linux qui tournent sur une machine physique. Un seul suffira.
Oui on a besoin de conteneurs ! Mais mon argument est que docker le fait assez mal. Et l'effet de mode autour de Docker me gène parce que dès qu'on commence à l'utiliser, on se retrouve rapidement à devoir contourner toutes ses limitations, ce qui génère une charge de travail peut-être supérieure à une utilisation brute de LXC.
Et ça me fait chier, je vois bien que Docker est populaire et j'ai l'impression que c'est un boulet que je vais me trainer pendant des années.
Alors cette histoire de standard commun, c'est une blague ? Le format des conteneurs Docker est spéficique à Docker. Y'a bien un standard pour le format des conteneurs: App Container Specification mais Docker ne l'utilise pas. Rocket, le lanceur de conteneur derrière CoreOS respecte cette spécification, mais pas Docker.
La seule manière un peu raisonnable que je vois d'utiliser Docker, est l'utiliser uniquement comme lanceur de conteneurs et d'utiliser Packer pour construire les conteneurs. Mais même comme ça, on doit trouver des workaround pour pas mal de problèmes. Typiquement les conteneurs Docker ne sont pas composables facilement. C'est un merdier sans nom de faire communiquer deux conteneurs. Je peux pas fusionner deux conteneurs pour en faire un seul. Rien que faire tourner deux process dans un conteneur c'est chiant. Pour le logging, c'est bien mignon de logger sur stdout mais si j'ai 200 conteneurs qui tournent sur 5 machines, je veux que les logs arrivent à un endroit central pour savoir ce qui se passe. Docker complique ça. Même chose au niveau du monitoring. Docker complique le monitoring.
Ce qui me paraîtrait la bonne manière de faire serait que la plateforme Docker fournisse des services au containers sous forme d'API. Typiquement une API pour logger, une API pour communiquer avec d'autres conteneurs (et rêvons un peu, plus efficace qu'en émulant du réseau), une API pour accéder à un stockage persistant etc. Dans l'état actuel des choses, c'est vraiment difficile de faire des conteneurs Docker facilement composables et déployables n'importe où. Je me retrouve toujours à voir de la configuration supplémentaire sur l'hôte (logging, création et montage de répertoires pour Docker, configuration des interfaces réseau virtuelles). Sans
compter que je sais jamais sur quel pied danser au niveau de la séparation des conteneurs. Je mets nginx dans un conteneur séparé ou pas ? Pour une application web, c'est chiant de faire comme ça. Dès que j'en ai deux, faut aller créer un Dockerfile supplémentaire.
J'espère que tout ça s'améliorera avec le temps. Mais pour l'instant on a vraiment un système sous-optimal.
Bon et pour info, Mesos n'a rien à voir avec Docker et n'a pas été lancé par Twitter mais par l'amplab de l'université de Berkeley.
[^] # Re: Conclusion un peu hative
Posté par X345 . En réponse au journal Docker, la plateforme à la mode. Évalué à 10.
Faire quoi ? Déployer une image à jour de Debian ? Je viens de le dire, par défaut, avec son système de cache qui ne fonctionne pas, docker ne rééxecutera pas
apt-get update; apt-get upgrade. Je sais qu'on peut bypasser le cache mais le souci est la construction des images Docker est vraiment lente.Oulà non. Non, c'était pas mieux avant quand on administrait les machines à la main. Surement pas. Ces dernières années, on a plein de technos qui sont apparues pour faire du DevOps, notamment tout un tas de systèmes de gestion de configuration et d'orchestration à la Puppet, Chef, Ansible et Salt. Et ça, indubitablement, c'est très bien.
Pour ce qui est du déploiement d'applications, on voit bien qu'on a besoin de containers. Une VM c'est clairement overkill pour isoler les applications; c'est totalement inutile d'aller émuler une carte réseau et les autre périphériques d'entrée-sortie. Pareil pas besoin d'avoir 15 noyaux Linux qui tournent sur une machine physique. Un seul suffira.
Oui on a besoin de conteneurs ! Mais mon argument est que docker le fait assez mal. Et l'effet de mode autour de Docker me gène parce que dès qu'on commence à l'utiliser, on se retrouve rapidement à devoir contourner toutes ses limitations, ce qui génère une charge de travail peut-être supérieure à une utilisation brute de LXC.
Et ça me fait chier, je vois bien que Docker est populaire et j'ai l'impression que c'est un boulet que je vais me trainer pendant des années.
Alors cette histoire de standard commun, c'est une blague ? Le format des conteneurs Docker est spéficique à Docker. Y'a bien un standard pour le format des conteneurs: App Container Specification mais Docker ne l'utilise pas. Rocket, le lanceur de conteneur derrière CoreOS respecte cette spécification, mais pas Docker.
La seule manière un peu raisonnable que je vois d'utiliser Docker, est l'utiliser uniquement comme lanceur de conteneurs et d'utiliser Packer pour construire les conteneurs. Mais même comme ça, on doit trouver des workaround pour pas mal de problèmes. Typiquement les conteneurs Docker ne sont pas composables facilement. C'est un merdier sans nom de faire communiquer deux conteneurs. Je peux pas fusionner deux conteneurs pour en faire un seul. Rien que faire tourner deux process dans un conteneur c'est chiant. Pour le logging, c'est bien mignon de logger sur stdout mais si j'ai 200 conteneurs qui tournent sur 5 machines, je veux que les logs arrivent à un endroit central pour savoir ce qui se passe. Docker complique ça. Même chose au niveau du monitoring. Docker complique le monitoring.
Ce qui me paraîtrait la bonne manière de faire serait que la plateforme Docker fournisse des services au containers sous forme d'API. Typiquement une API pour logger, une API pour communiquer avec d'autres conteneurs (et rêvons un peu, plus efficace qu'en émulant du réseau), une API pour accéder à un stockage persistant etc. Dans l'état actuel des choses, c'est vraiment difficile de faire des conteneurs Docker facilement composables et déployables n'importe où. Je me retrouve toujours à voir de la configuration supplémentaire sur l'hôte (logging, création et montage de répertoires pour Docker, configuration des interfaces réseau virtuelles). Sans
compter que je sais jamais sur quel pied danser au niveau de la séparation des conteneurs. Je mets nginx dans un conteneur séparé ou pas ? Pour une application web, c'est chiant de faire comme ça. Dès que j'en ai deux, faut aller créer un Dockerfile supplémentaire.
J'espère que tout ça s'améliorera avec le temps. Mais pour l'instant on a vraiment un système sous-optimal.
Bon et pour info, Mesos n'a rien à voir avec Docker et n'a pas été lancé par Twitter mais par l'amplab de l'université de Berkeley.