Reprise du message précédent :
jeanb disait sur je sais plus quel post que c'était dispo non ? Et sur azure aussi
 
J'ai bugé ?
 
XaT

Moi j'ai compris que sur azure ils avaient des distrib linux sur lesquelles docker pouvait tourner, et qu'ils étaient en train de bosser à pouvoir intégrer le processus de containerisation à l'environnement Windows
 
Mais comme je ne me suis jamais servis d'Azure, je ne peux pas vérifier

Une petite question concernant notre ami Docker
Est-il possible, depuis un container de faire un pass-through d'une clé USB de l'hôte ? comme une clé Tuner TNT, ou une clé WiFi ?
J'ai cherché mais surement pas correctement

EDIT: Je viens de trouver ça

Je viens de capter que mon kernel 3.2 ne marche pas très bien avec docker
Bon j'me met une vm docker et une boot2docker, etc pour test
 
XaT

Qui a testé/mit en place Shipyard ? J'ai dockerui, c'est cool mais je vais peut être testé shipyard.
Par contre j'aime pas qu'il fasse foutre un agent dans le CT
 
XaT

En fait on n'est que 3 à l'utiliser sur le forum, et en plus on ne s'en sert pas de la même façon

Ou plutôt n'importe comment
 
XaT

Drapal, faut que je m'y mette
 
Le but avoir un os tout rikiki avec des containers pour chaque appli (nginx, php, varnish....)

Si je comprend bien le fonctionnement :
 
- on dl une image contenant un OS et les softs dont on a besoin
- on démarre cette image, c'est magic ça fonctionne
 
- Comment ça se passe pour les mises à jours de ces images ?
 
J'ai une image avec une debian stable + nginx  
Je veux faire une mise à jour de mon nginx dans cette image (via apt), je boot l'image, je me connecte dedans, je fais ma mise à jour, je sors de l'image et je fais un commit.
 
C'est bien ça ?
 
Je suppose qu'on peut aussi avoir un repo perso pour stocker ces propres images ?
 
Je vois le truc comme :
 
J'ai 10 front web (iso), je gère un dock via image sur un repo, que je maintiens à jour (soft, contenu...), et je pousse ces "docks" vers mes fronts.
C'est bien ça le gros avantage du système ?
 
++
 
 
 

C'est exactement mon utilisation

La gestion des mises à jour c'est la partie avec laquelle j'ai un peu de mal.
Si tu n'as qu'une seule image, pas trop de problème, c'est comme tu l'as décrit.

Par contre quand tu commence à hiérarchiser un peu les images (genre :

Ca se complique un peu parce que si tu mets à jour ton image de base, toutes les autres ne le prennent pas en compte.
Donc ce que je fais pour l'instant, je relance un docker build de toutes mes images, une fois que c'est terminé je stop et relance tous les containers, et ensuite je supprime les images "orphelines".
Ce n'est pas des plus pratique, mais ça fonctionne.

Après je me suis fait un organisation au niveau des Dockerfile, avec des scripts, donc le build / lancement de container est assez simplifié, mais tout reconstruire à chaque fois reste assez long, du coup c'est pas le truc que je fais aussi souvent que l'update du serveur hôte

edit : et oui, tu peux avoir ton propre dépôt privé : https://github.com/docker/docker-registry

Cette question a peut être été soulevé sur leur forum
 
XaT

Drap.

J'ai testé il y a un mois Docker dans un laps de temps assez tendu, ce qui m'a gêné en faite c'est la flexibilité... le problème c'est qu'on peut tout faire mais qu'on sait pas vraiment quelles sont les bonnes pratiques
 
Je vais donc m'y remettre sérieusement, mon objectif :
 
VM Load Balancer
 
VM Docker
 - Docker Nginx avec plusieurs Vhost
 - Docker Nginx avec plusieurs Vhost
 - ...
 
J'imagine que je vais devoir changer le port de chaque Nginx pour éviter qu'ils discutent tous sur le 80 mais il y a peut être une technique pour faire quelque-chose de plus simple ?
 
Est ce qu'il existe une possibilité de redondance qui par exemple permettrait d'avoir deux hosts docker qui se surveillent et que l'un monte les dockers de l'autre en cas de panne ?

 
En fait chaque container lance nginx sur le port 80 (EXPOSE 80 dans ton Dockerfile), car c'est sur l'interface réseau virtuelle du container. C'est sur l'hôte qu'il faudra "binder" (paramètre -p de la commande docker run) sur un port différent pour chacun
 
Pour tes autres question je n'ai jamais fait de load balancing donc je ne peux pas t'aider.

Il y a un intérêt a utiliser CoreOS a la place d'une Debian ? Mon parc est "presque" entièrement en Debian (j'ai quelques Centos) je préférerais éviter ^^

A priori tu peux utiliser ce que tu veux. Moi aussi j'utilise la distrib dont j'ai l'habitude

Vous avez des vidéos ou des annonces de la dockercon Dec. 2014 ?

 
http://jaxenter.com/european-docke [...] 12950.html

Bon j'ai enfin réussi a me libérer une journée pour vraiment tester docker et mettre un truc en prod avec.
 
J'avais une VM avec deux serveurs Mumble que j'ai transformé en deux containers. Chaque container exécute Mumble sur le même port sauf qu'au niveau de hote je le map sur d'autres ports. J'en est profité pour faire un Dockerfile qui fait tout ca automatiquement (j'ai mis du temps a piger comment éxecuter un Dockerfile) bref tout fonctionne bien.
 
Il me reste tout de même trois tonnes de questions...  
 
1/ Je vois pas comment maintenir une plateforme web en prod via docker, gérer les demandes de rajout de vhost, comment je mes a jour mon site via ftp, ... Quelles sont mes actions possibles container allumé si j'ai choisi de ne pas mettre de SSH (si j'ai bien compris c'est contre la philosophie du projet) ? Parce que sur le Hub Docker j'ai regardé pas mal de Build LEMP et aucun d'entre eux installe un serveur FTP alors je me demande comment ils font pour maintenir leur site web. D'ailleurs c'est dingue tous les Builds basés sur Ubuntu  
 
2/ La persistance des données dans les containers... Je dirais qu'il y a deux méthodes populaires ! La commande "Volume" qui consiste a sortir du système AUFS le dossier dans lequel les données sont dynamiques. Dans ce scénario les données se retrouvent donc sur l'hote docker. Ou la conception d'un container pour stocker ces données. Dans ce scénario vos containers deviennent donc dépendant de ce container de stockage. Je ne sais pas qu'est ce qui est le moins pire J'aurais encore préféré que les containers puissent discuter en NFS pour mettre leurs données.
 
3/ La mise a jour des containers ! Une question hyper répandu sur le web avec des réponses qui n'ont pas l'aire de convaincre. En gros tu vires ton container, tu le rebuild en ayant fait gaffe avant a la persistance des datas (voir /2). Aucune solution sans rebuild ? Genre si j'ai fais un container avec une bdd dans /var/lib/truc/ et que j'ai pas pensé a utiliser la commande volume ?

Ce que j'ai fini par faire, c'est carrément foutre mon /etc/nginx dans un volume comme ça la config des vhost est indépendante de l'image nginx. A tout moment je peux faire des modifs dans la config (depuis l'hôte), il me suffit juste de relancer le container pour que la modif soit prise en compte.

Pour la mise à jour du site, mon /var/www est aussi dans un volume, et je passe par scp (winscp / filezilla) sur l'hôte.

Effectivement, ssh ne devrait, sauf cas spécial peut-être, pas tourner dans les containers : http://jpetazzo.github.io/2014/06/ [...] ered-evil/

En fait les 2 solutions sont identiques, elle utilisent les volumes.

Quand tu créé un container, tu peux lui indiquer de créer un ou plusieurs volume. C'est une sorte de lien vers un chemin sur l'hôte. Mais tu peux aussi lui indiquer de réutiliser les mêmes volumes qu'un autre container.

C'est ce qu'il faut faire pour la 2eme solution : créer un premier container dont le seul but est de créer les volumes, et ensuite tu lances d'autres containers avec --volumes-from, et ils bénéficieront des mêmes volumes.

Par exemple j'ai un container "dockerception", qui est lancé avec la commande :

Si je veux pouvoir contrôler docker depuis l'intérieur d'un container (le  container qui fait tourner php dans mon cas), je le lance avec

Le principal intérêt des volumes, c'est que contrairement à l'espace de stockage qui est créé pour la racine du container, ceux-ci ne sont pas détruits à l'arrêt du container, d'où la persistence.
edit : il me semble qu'à partir du moment où plus aucun container existant (actif ou pas) ne pointe vers un volume, celui-ci est détruit si le chemin côté hôte est géré par docker

Après rien ne t'empèche, je pense, d'utiliser NFS dans tes containers

Ca c'est la grosse question que je me suis posé d'entrée. A priori il n'y a pas de solution.

Par exemple imaginons une arborescence d'images docker dans ce style:

Comment faire quand une mise à jour de java est dispo? Je n'ai pas trouvé mieux que de faire un rebuild de Java, puis Appli Java1 et Appli Java2.

Et c'est là qu'il faut à mon avis bien bosser sur ses Dockerfiles et ses containers : Un container ca doit juste être un environnement complet mais vide de données.

Je fais tous mes dockerfile dans cette optique : pouvoir à tout moment jetter le container et l'image et être en mesure de le relancer juste avec un build / run

Après je sais que Docker est pas mal utilisé par des developpeurs pour faire tourner leur applis, peut être que dans ce cas l'appli en elle-même n'est pas intégrée à l'image. 'Fin je ne sais pas, j'ai l'impression d'avoir une utilisation complètement différente de pas mal de personnes

Là typiquement tu l'as dans l'os, l'avantage c'est que tu peux préciser directement dans le dockerfile que tu va utiliser des volumes, même si ce n'est pas spécifié dans la commande run.

Après en dernier recours tu as des moyens de récupérer ces données (par exemple avec un "docker cp" ), mais bon, une fois que ton container tourne "pour de vrai", il vaut mieux éviter ce genre de situation à mon avis

Merci pour tes réponses
 
Pour le dernier point j'ai fais un commit sur mon container en marche puis j'ai relancé un build avec mon Dockerfile en partant de cette image commité J'ai donc profité de ce rebuild pour améliorer mon Dockerfile avec l'utilisation de Volume.
 
Le truc top ca serait qu'on puisse dire a docker qu'on a un serveur NFS (le top serait plusieurs) et qu'automatiquement quand un container se lance et qu'il possède un "Volume" ben il met les données sur le serveur NFS. Je ne veux pas gérer le NFS via les containers. Après je pense qu'il y a moyen de bidouiller pour que /var/lib/docker/vfs/ soit sur un volume NFS, si j'ai bien compris c'est ici qu'il met les données des containers.
 
Est ce que tu aurais une idée pour  :
 
1/ Une recherche d'un fichier dans un container en marche sans rentrer dedans (genre faire un find)
2/ J'ai trouvé la commande pour copier un fichier d'un container a l'hote mais par l'inverse
3/ Quand certain docker vont commencer a bien tourner comment je vais pouvoir savoir la consommation CPU / RAM que prend tel ou tel container ?

 
J'évite de faire des commit avec des containers, justement parce que je perd le lien avec le dockerfile (après c'est juste ma façon de m'organiser, je ne dis pas que c'est la vérité absolue)
 

 
Là je ne sais pas trop, je n'ai jamais utilisé NFS. De ce que j'ai compris tu le monte comme n'importe quel système de fichier. Ce que je ferai je pense, c'est un montage NFS sur l'hôte, et je lancerai les containers avec un volume à l'intérieur de ce montage.
 
 

 
Là comme ça je ne vois pas, mais tu peux lancer l'image sur la commande /bin/bash pour avoir un nouveau container identique, et de là faire une recherche
 

 
Au niveau du Dockerfile il y a l'instruction ADD qui permet de le faire au moment du build, pour plus tard je ne sais pas si c'est faisable, sauf encore une fois à passer par des volumes
 

 
Je ne me suis pas trop penché dessus, mais de ce que j'ai pu tester :
- avec "docker top" tu obtiens le résultat de l'exécution de la commande ps sur le container
- au niveau de l'hôte tu peux voir l'ensemble des processus (j'utilise htop et je vois tout ce qui tourne sur l'hôte)
- je sais qu'il y a des projets de webUI qui existent, de mémoire ils permettent de gérer/surveiller les ressources, par exemple : http://shipyard-project.com/

 
En faite ce que je me demande c'est comment Docker gère les [Volume] quand on fait des manipulations avec les containers. Par exemple j'ai un container qui tourne qui possède des données dans /data que j'ai pris soin de spécifier dans les volumes, comment je peux faire pour rebuild ce container a partir de mon Dockerfile tout en gardant les données de l'ancien container ? On est bien d'accord que si je rebuild le container a partir de debian:wheezy par exemple avec le même Dockerfile qui a permis de construire le container qui tourne (avec les données dans /data) je ne vais pas retrouver mes donnés ?

Il y a 2 façons d'utiliser un volume :
- Soit tu précises dans ta commande run la partie hôte du volume ( -v /chemin/hôtechemin/container), donc là pas de problème, le répertoire sur l'hôte est conservé même après suppression du container
- soit tu ne le fais pas (par exemple il y a un volume déclaré dans le dockerfile mais rien dans la commande run), auquel cas docker gère la "vie" du volume côté hôte, et, si j'ai bien compris, dès que plus aucun container (aussi bien celui qui a créé le volume que tous ceux qui le référencent via --volumes-from) n'utilise le volume, il est détruit
 
Mais je te dirais que je n'ai pas poussé les tests plus que ça pour vérifier que c'était bien le fonctionnement.
 
En tout cas moi je précise toujours où sont stockées les données de mes volumes côté hôte dans mes commandes run et ça fonctionne bien, il me retrouve toujours les données.

Ok donc si je précise pas le chemin du volume sur l’hôte le volume va être lié a l'ID du container et donc si je refais un build la liaison va être perdu. En faite ca sert juste a sortir un volume du filesystem aufs pour garder les données lors des manips sur le container.
 
Si on spécifie juste le volume dans le Dockerfile ca doit marcher comme ca :
 
Container ID01 > repertoireID01/data
Container ID02 > repertoireID02/data
 
Faut que je trouve des précisions la dessus...  
 
EDIT : Quelques précisions ici http://crosbymichael.com/advanced-docker-volumes.html
 
Bref ça veut dire qu'il faut que je bosse différemment sur mes containers En même temps je m'en doutais la plupart des dockerfiles que je trouve bougent les données des applis dans le /data afin de les monter d'un coup ensuite sur l’hôte.
 
 
Pour l'instant j'ai réussi a faire 3 containers avec Dockerfile :
 
Phpmyadmin (pour mutualiser son utilisation, le Dockerfile va chercher Phpmyadmin sur le GIT pour ne pas avoir a gérer la version du package)
DNS avec Webmin pour de la réplication
Mumble
 
EDIT : J'ai retapé mes containers pour faire en sorte que les configs soient dans /data et j'ai fais en sorte que les volumes se montent dans /var/lib/docker/data. Effectivement quelque-soit ce que je fais maintenant les données ne bougent plus ! Par contre vla le nombre de paramètre qu'il faut mettre pour un run... il serait temps qu'on puisse donner plus d'ordre dans le Dockerfile
 
Maintenant ce que je me demande c'est si on peut vraiment en faire un usage d'hébergement comme OVH avec Openvz pour par exemple tailler un container avec 20G de disque / 2G de ram / 1 Core et faire une Debian avec ce qu'il faut pour qu'un client puisse gérer derrière. Faudrait que je regarde aussi les possibilités coté interface réseau pour par exemple pouvoir donner une adresse IP publique ou privé aux containers.
 
Je vais continuer a bidouiller docker en tache de fond mais j'y reviendrais a fond un peu plus tard beaucoup beaucoup de potentiel    

Pour gérer les lancements je me suis fait un script docker_run qui cherche dans le répertoire d'une image un fichier docker_run.sh, et s'il le trouve l'execute, et même principe pour les builds.
 
Comme ça quand je veux mettre à jour une image
 

 
Et il n'y a plus qu'à supprimer l'image orpheline

Astucieux j'ai souvent vu des scripts docker_run sur les dépôts de Docker quelque-chose me dit que cette usage est courant De toute façon j'avais dans l'idée de faire des scripts de démarrage afin de pouvoir par exemple vérifier que le volume NFS est bien fonctionnel avant de lancer le container. Par contre j'avais dans l'idée de up mes Dockerfile sur notre GIT afin qu'a terme je n'ai plus qu'a docker pull pour voir arriver mon image mais dans cette usage mon fichier docker_run ne sera pas pris en compte.. comment tu t'organises de ton coté ?
 
J'aimerais envoyer les logs de mes containers "docker logs container" vers mon serveur Graylog, j'ai l'impression qu'il n'y a pas pour le moment quelque-chose de simple pour faire ca... chacun y va de son petit programme

Pour l'instant c'est très archaïque, j'ai un dossier dédié au stockage des "sources" d'images docker (un sous-dossier pour chaque image, contenant le dockerfile et les éventuels autres fichiers nécessaires à la création de l'image). Chaque sous-dossier est aussi un dépôt git (local pour l'instant)
 
Je vais bientôt utiliser docker sur 2 machines, du coup je vais p't'être voir pour stocker les images sur un dépôt privé pour éviter d'avoir à faire 2 builds à chaque fois.
 
Pour les logs je ne suis pas encore penché dessus

drapal
 
Quel intérêt de faire un container nginx, un container php au lieu d'un nginx+php ?

Je sais plus où j'ai trouvé ça mais j'ai trouvé cette vidéo pas mal pour un noob de docker https://www.youtube.com/watch?v=bXSC3-mrgWA

Pour info, si vous passez de docker 1.3.2 à 1.4+ et que vos containers ne démarrent plus, il y a un paramètre à modifier dans le kernel :
 
https://github.com/tianon/docker-overlay/issues/35
 
Perso j'ai pas trop le temps/l'envie de recompiler un kernel pour la kimsufi donc je suis repassé en 1.3.2

C'est pas péché, c'est plutôt une bonne idée

Mais oui, c'est deux usages différents, donc c'est pas bête d'utiliser les deux
 
Docker : pour les dev, si tu « encadres » bien ça dans une VM dédiée à ça, c'est nickel

Perso je valide plus ce design que Docker direct sur du bare metal...
 
Donc oui, fonce

J'envisage de mettre en place un container docker avec une petite DB et nginx. Est-ce une mauvaise approche de laisser les données dans le container ? Faut-il toujours utiliser un volume ?

Concernant les backup, est-ce docker export est suffisant pour avoir une image du container ?

Je ne sais pas si vous connaissez, mais coreos c'est vraiment sympa.

J'ai monté un ptit cluster de 3 machines coreos sur EC2, ca fonctionne vraiment bien.

J'utilise FLANNEL, qui permet une communication direct en les containers même s'ils sont sur des hosts différents.

Le seul problème qui me reste, c'est la gestion de l'ip affecté au container versus un DNS.

 
Dans le cas d'une base de données, je ne vois aucune situation pour laquelle il serait intéressant d'avoir les données dans le container.
 
Dans le cas de nginx, à la limite, on peut peut-être se passer de volume (imaginons une image nginx qui contiendrait un site statique, ou même un site dynamique dont tout le contenu serait stocké dans la BDD, le container ne serait pas modifié), mais ça doit rester super spécifique parce que, par exemple, même un wordpress va avoir besoin de stocker des images, etc...
 
En général j'essaye de faire en sorte que mes containers soient totalement indépendant des données. Je peux a tout moment supprimer un container et le recréer, les données elles n'ont pas bougé.
 
Si les données sont à l'intérieur du container, ça veut dire qu'avant de le supprimer il va falloir les exporter, puis les réimporter dans le nouveau... pas très pratique.