Alors finalement, en pratique, quel problème résout Docker ? Est-ce que ses multiples défauts n'en font pas une couche de complexité inutile ?
Conclusion très pertinente. Je suis en train de travailler sur docker en tant que sujet de projet (je suis en licence) et je doit dire que certains points sont à développer sur cette solution.
Docker ne remplacera pas une solution de conteneurs traditionnel comme LXC. Docker est fait pour isoler les applications, pas pour créer un système virtuel.
Moi même je reste dubitatif quand à son utilisation dans une infrastructure de cloud computing, en tout cas dans l'etat, notament à cause de la partie réseau et de l'intégration avec le système.
Mais pour le développement, c'est un réel avantage. On travaille sur son application sereinement , sans impacté son système et sans perdre en performance. On ajoute ses propres bibliothèques et configuration, sans que rien sur l'hôte ne soit modifié.
C'est rapide, ça fonctionne en gros comme git (chaque action sur le conteneur créé une nouvelle couche associé à un commit). Ainsi on peut facilement revenir à un Etat antérieur. Docker sur ce point la fonctionne déja très bien.
Mais c'est quand la partie réseau est impliqué que ça change. en effet docker est une couche d'abstraction à LXC et maintenant lib-contenair. Dès le debut il créé un bridge et connecte les VM. Des services comme DHCP ne marche pas.
Par rapport à un LXC ou il suffit d'utiliser les outils du noyau , c'est vrai que rajouter une telle complexité peut paraître inutile.
Mais ne pas oublier que Docker n'est pas stable, et que en fait on cherche toujours à définir son cadre d'utilisation.
Ne pas oublier que Docker est fais pour déployer des applications, pas simuler un système. C'est là la différence avec LXC.
# Des usages à cerner
Posté par anarnux . En réponse au journal Docker, la plateforme à la mode. Évalué à 8.
Conclusion très pertinente. Je suis en train de travailler sur docker en tant que sujet de projet (je suis en licence) et je doit dire que certains points sont à développer sur cette solution.
Docker ne remplacera pas une solution de conteneurs traditionnel comme LXC. Docker est fait pour isoler les applications, pas pour créer un système virtuel.
Moi même je reste dubitatif quand à son utilisation dans une infrastructure de cloud computing, en tout cas dans l'etat, notament à cause de la partie réseau et de l'intégration avec le système.
Mais pour le développement, c'est un réel avantage. On travaille sur son application sereinement , sans impacté son système et sans perdre en performance. On ajoute ses propres bibliothèques et configuration, sans que rien sur l'hôte ne soit modifié.
C'est rapide, ça fonctionne en gros comme git (chaque action sur le conteneur créé une nouvelle couche associé à un commit). Ainsi on peut facilement revenir à un Etat antérieur. Docker sur ce point la fonctionne déja très bien.
Mais c'est quand la partie réseau est impliqué que ça change. en effet docker est une couche d'abstraction à LXC et maintenant lib-contenair. Dès le debut il créé un bridge et connecte les VM. Des services comme DHCP ne marche pas.
Par rapport à un LXC ou il suffit d'utiliser les outils du noyau , c'est vrai que rajouter une telle complexité peut paraître inutile.
Mais ne pas oublier que Docker n'est pas stable, et que en fait on cherche toujours à définir son cadre d'utilisation.
Ne pas oublier que Docker est fais pour déployer des applications, pas simuler un système. C'est là la différence avec LXC.