Le Blog Utux

Je rajouterai: Comment quelque chose d'aussi imbuvable que docker est parvenu à une telle popularité et pas les autres solutions dont tu parle ? (à l'exception de lxc peut être)

Question rhétorique: le marketing...

Au passage, il n'y a pas que l'outil qui soit imbuvable: la doc est tout autant merdique.

Quel est le problème avec la doc ? Je la trouve plutôt intéressante en fait, il y a un guide qui permet de prendre en main les principaux aspects, même si je regrette que l'accent soit mis sur l'utilisation d'images sur le hub plutôt que sur le fait de les construire soi même.

Après concernant le marketing, je me posais la même question. Je n'ai pas l'impression que Docker me simplifie la vie pour le moment.

Tu as raison, je dois me raviser sur la doc. Mon problème ne venait pas de leur doc, je viens de tenter de reproduire le problème que j'avais hier. Je cherchais à [installer libervia](http://wiki.goffi.org/wiki/Docker/en) pour le tester, et on doit utiliser la commande suivante pour récupérer le mot de passe admin par défaut:

```docker start --rm --volumes-from sat_data debian:jessie cat /home/sat/ADMIN_PWD```

mais docker m'a envoyé paître à cause des options --rm et --volumes-from. J'avais l'impression d'avoir perdu beaucoup de temps à trouver que je ne devais pas utiliser "start" mais plutôt "run". Il m'avait semble, hier, que chercher dans la doc "--volumes-from" ne m'avait pas conduit là où je voulais aller (une explication du contexte où utiliser cette option).

Je viens de retester et en fait, la doc me montre le bon article après avoir lancé la recherche.

Toutes mes excuses !

S'il s'agit du mot de passe root par défaut, il est facile de le changer :
$ docker run -t -i TONCONTAINER /bin/bash
(s'assurer que tu es bien entré dans le container)
# passwd
;)

Totalement d'accord avec cet article.
j'ai longtemps utilisé OpenVZ pour faire des conteneurs et c'était vraiment un bon outil (bien qu'il n'était et ne seras jamais dans le noyau officiellement).
On pouvait sauvegarder, rajouter de la RAM ou du DISK à chaud, se mettre dans la console simplement.
Alors que Docker... Moi la seule chose que j'ai retenue de ma (toute petite) expérience, c'est que pout "installer" un conteneur, faut télécharger des Mo et de Mo de version d'image à chaque fois.
Et cela donne cette impression de ne pas être vraiment une machine complète, il faut toujours faire du forwarding de port pour avoir accès au réseau.

Vous comparez un peu facilement des commandes assez différentes, quand même.
J'imagine que : docker exec -t -i gigantic_engelbart /bin/bash
peut à moindre frais faire beaucoup plus que simplement lancer une console bash.

Et pour la commande "list" de ez-jail, comment faire pour afficher uniquement les containers en cours d'exécution ?

Salut,

Pour la première remarque, on peut avoir pareil avec les jails : jexec $id $commande. Là encore je trouve que c'est plus simple.

Pour ta seconde remarque, je ne sais pas, en tant qu'admin je veux tout voir, je n'ai jamais cherché à n'avoir que la liste des containers en cours d'exécution. Mais j'entrevois deux solutions :

1. utiliser la commande jls (affiche les jails actives)
2. faire ezjail-admin list | grep DR

Le problème vient du fait que vous n'utilisez pas docker comme le produit a été pensé.
Docker n'est pas un énième système de jail/chroot/container.
C'est une surcouche à un tel système. Il n'est pas pensé pour faire tourner un linux complet mais juste à isoler et pouvoir déployer un soft (voir stack) très rapidement et du coup en masse (nombreuses instances démarré pourquoi pas à la volée).
Si vous n'avez qu'une ou deux instances docker qui tourne en permanence, ce n'est pas vraiment l'outil le plus adapté. Dans ce cas openvz ou le plus mainline lxc est recommandé.

J'ai tout à fait compris le principe, mais il y a bien peu de retours d'expérience ou d'exemples d'architecture ce qui fait que j'ai du mal à comprendre l'intérêt.
Je sais créer une image avec un Dockerfile et lancer des containers, en revanche il y a toujours des questions que je me pose :
- Si je veux modifier un simple fichier de conf, je dois reconstruire mon image et relancer des containers ?
- Même chose pour une mise à jour logicielle ?
- Si je veux modifier une option pour un container, c'est vraiment impossible ? Obligé de le détruire et en lancer un autre ?
- Comment tu t'y retrouve avec les logs sachant que tout est dispersé dans des containers ?
- Quel est l'avantage face à un système de containers plus souple (systemd-nspawn, jails, lxc) couplé à ansible/puppet ?

Alors je suis pas du tout un expert Docker mais voilà comment je vois les choses :
-En théorie, on n'a pas à utiliser les containers docker en mode interactif. Donc pas à lancer de bash ou autre shell.
-On ne devrait pas modifier un container existant. Si la conf désirée n'est plus celle du conteneur actuel, on ne doit pas éditer le fichier de conf mais refaire un docker file avec la nouvelle conf et monter une nouvelle instance.
-Pareil pour les mises à jour logicielle. On créer une nouvelle instance à jour au lieu d'updater l'ancienne.
-Pareil pour les modifs d'un containers.
-En théorie vu qu'on accède pas au rootfs de docker, toutes les données qu'il utilise doivent être dans un volume à part entière et toutes les "métadonnées" n'ont pas à être dans l'instance docker. Dans notre cas, les logs sont les "métadonnées". Donc le but du jeu est de les envoyer à un syslog distant (pourquoi pas une instance docker ne faisant que syslog pour les autres ( comme ça les logs des autres machines deviennent les data de ce container)).
Le but de tout ceci est d'avoir un système de container très léger et du coup très rapide : tu n'as pas de données dans le container (tu montes un volume accessible par X containers), ni de méta-données (logs distants, bdd de login/pass, …). Ce qui fait que le container docker est très petit en taille et donc peut être lancé/arrêté en moins d'une seconde. Du coup tu peux monter des infras sur lesquelles tu démarres/arrêtes tes containers en fonction de la charge en temps réels. Tu peux également pousser des mises à jour logiciels très rapidement avec le système d'overlay (tu as un container de base contenant ta distribution linux qui est partagé entre de nombreux containers, et la couche supérieure qui est propre à chaque instance). Par exemple tu as un container "bas" debian et par dessus tu fais un container "apache" dans lequel tu ne fais qu'installer apache et imaginons un troisième qui lui fait tourner php. Quand tu feras une mise à jour du container debian, tu mettras à jour ton container apache et ton container php (biensûr comme apache et php ne seront pas installés dans le container debian, il te restera que ces paquets à mettre à jour dans ces deux containers). Ça permet de pouvoir pousser certains patchs de sécurité simplement sur de très nombreuses machines et ça permet d'utiliser beaucoup moins d'espace de stockage.

Donc en gros docker c'est fait pour de la containerisation industrielle (et également pour les devs qui n'arrivent à faire marcher leur soft que sur leur machine) pas juste pour un container classique.
Et l'effet marketing ne provient pas vraiment de docker mais de la communauté globale qui l'utilise à tord et à travers.
Voilà voilà mon point de vue.

C'est valide, merci.

Vaste sujet que de comprendre à quoi peut bien servir docker. Initialement le but est de "simplifier" l'utilisation et l'échange des environnements de dev entre développeurs afin d'avoir la même base pour l'ensemble des développeurs (qui n'a pas affronté le classique "mais ça marche chez moi !). Ensuite les ops ont commencé à s'emparer du trucs en se disant que ce qui marche sur le poste de dev doit marcher en production (oui l'ops est feignant). Donc si on reste strictement sur des conteneurs mono serveurs, oui on peut se passer de docker. Maintenant la "force" de docker est son écosystème. Pour échanger ses conteneurs on peut utiliser une registry (publique ou privée). Quand on veut gérer une stack on utilise compose (qui gère aussi la mise à l'echelle). Quand on veut gérer plusieurs serveurs docker et repartir ses conteneurs on utilise swarm .... Docker n'a pas que des qualités mais elles sont suffisantes pour justifier son adoption.