Reprise du message précédent :
Bonjour à tous,
 
je m'essaie à Docker et j'ai quelques questions.
 
Je souhaite faire un container "data_container" qui "partagera" (je sais pas si le terme est le bon) 3 dossiers (/data, /conf, /log) aux autres containers (LAMP, owncloud, openvpn)
Cela vous semble-t-il être une bonne pratique?
 
Pour "data_container" je pars sur un dockerfile du genre:
 

 
J'ai du mal à comprendre où se trouveront physiquement les dossiers /data, /log et /conf?
Sur mon host (un ubuntu server), si oui dans quel dossier?
Dans le data_container? Dans ce cas ça se présente comme une vm (genre un fichier vmdk par exemple?) Toujours dans ce cas, il faut un moyen d'accéder aux données comme ftp/samba/nfs?
 
Dans mon container "LAMP", je devrait donc prévoir de modifier toutes les conf pour faire fonctionner les applications avec ces 3 dossiers en références?
Par exemple,  
apache /www -> /data/apache/www, etc...
 
Et ca sera au démarrage avec RUN de mon container "LAMP" que je pourrait mapper le /data de "LAMP" vers le /data de "data_container"?
 
Merci d'avance de vos précisions.
 

Un peu de lecture :
http://stackoverflow.com/questions [...] 0#20652410
http://container42.com/2013/12/16/ [...] e-pattern/
http://crosbymichael.com/advanced-docker-volumes.html
Et : http://container42.com/2014/11/18/ [...] r-madness/
 
Donc en résumé, oui c'est une bonne pratique, par contre n'utilise pas busybox comme base, et pour le reste de question lis les liens que je fournie au dessus, tu as encore visiblement une approche trop classique (virtualisation, FTP/Samba, etc.)

Bonjour,
 
Je pense qu'on se pose un peu tous les mêmes questions au début...
 
Pour tes data containers, deux possibilités :
 
- soit tu utilises un data container only, dans ce cas tes fichiers seront physiquement dans le répertoire de Docker sur ton hôte (/var/lib/docker par défaut), mais elle ne seront pas facilement lisibles.  
Tu le démarres avec :

 
(ou simplement docker create pour les versions plus récentes que la mienne).
C'est la méthode recommandée. Si j'ai bien compris les données seront persistantes tant qu'au moins un container l'utilise.
 
- soit du map un répertoire de ton hôte dans ton data container avec :

Tes données seront alors directement accessibles depuis l'hôte dans /mnt/apache.
C'est ce que j'ai fait car je préfère avoir accès à mes données sans avoir à passer par un container.
Pour chaque container, j'utilise au moins un data container pour les datas, un pour la conf et un pour les logs.
 
Dans les deux cas, tu montes tes datas dans ton container Apache avec :

 
J'ai finalement passé la plupart de mes services sous Docker, mais je me rends compte que ce n'est peut-être pas le plus adapté dans mon cas :
- sur ce principe de data container, je suis arrivé à 45 containers au total (pour 9 containers).
- le principe de lancer un process par container est très bien pour des applications simples, mais dès qu'on veut dockeriser des applis plus complexes c'est vite casse-tête. Pour des applis multi-process (par exemple nfs ou samba), il faut bidouiller par des scripts ou un pseudo init type Supervisor.
- on passe du temps à trouver comment lancer son appli (en foreground) et on bypass les scripts d'init prévus par la distribution.
- la gestion des users dans les containers est assez lourde, j'en suis arrivé à mettre en place un annuaire LDAP (qui d'ailleurs pose un problème de consommation mémoire sous Docker : https://github.com/docker/docker/issues/8231).
- si on sort les logs dans des data containers, il faut gérer leur rotation depuis l'extérieur ou via un docker exec.
- de façon générale la gestion des crontab est moins simple.
 
Je trouve les concepts de Docker vraiment intéressants, mais soit je n'ai pas encore tout assimilé soit ce n'est pas vraiment adapté à mon usage.
J'envisage de repasser sur quelque chose de plus traditionnel avec LXC (avec du stockage BTRFS qui présente des fonctionnalités intéressantes).
LXD (http://www.ubuntu.com/cloud/tools/lxd) me semble également intéressant.

Je partage ton analyse, tout vouloir faire dans docker, même si c'est faisable, c'est pas forcément toujours le plus adapté.

Le cas typique d'utilisation pour moi c'est dans un process d'intégration continu/automatisation.
Pour mettre en place une architecture plus traditionnelle (qui évolue peu souvent, qui n'a pas besoin de s'adapter à la demande et à des montées en charge régulièrement), la virtualisation ou une solution de conteneurs plus classique comme LXC reste bien plus confortable

+1

Merci pour vos réponses et les liens!
Ca m'occupera entre 2 au bureau.
 
Je vais regarder LXD aussi que je connais pas.

Hep
 
J'utilise Docker depuis son intégration dans la dernière beta de l'OS de mon NAS (Synology).
J'ai un container qui ressemble à un Debian chroot qui fait tourner différents services qui étaient avant plus ou moins 'bricolés" pour tourner sur le NAS. Maintenant que tout ça est "contenu" et fonctionnel, j'aimerai automatiser un backup distant et pour l'instant j'ai fait:
 
docker export ContainerName > ContainerName.tar
docker inspect ContainerName > ContainerName.conf
 
Ai-je tout ce qu'il faut pour recréer le container (incluant les règles NAT, les variables d'environnement, etc) ou dois-je prévoir autre chose ?
 
Merci

Ben si t 'as des volumes de données, je pense pas que le export les prenne en compte.

Non j'ai juste un bind qui monte le /volume1 du NAS. Je vais faire un restore qque part histoire de voir ce qui est réellement backupé via export.

https://blog.docker.com/2015/04/docker-release-1-6/

 
Pas mal
 

drap

Bonjour à tous.
J'ai quelques questions que j'aimerai regrouper. Je fais du développement Java et pour le moment, je déploie mon application dans un tomcat dans une vm linux. ça me va, mais j'aimerai bien tester aussi docker.
J'ai aussi un serveur git (une autre vm) et un Jenkins (une autre vm).
 
Je pourrais tout mettre sur la même machine, avec une instance tomcat comme serveur de test, et une instance comme serveur de prod et aussi jenkins et git (nexus, et tout le cirque). Mais j'ai pas envie d'avoir tout sur une même machine. Dans tous les cas, je veux séparer les instances de prod du reste.
 
Je me demandais : Quel avantage à faire tourner jenkins et mon serveur git dans 2 containers docker distincts ?
Pourquoi faire tourner jenkins dans un container docker ? (Par rapport le faire tourner dans une vm complète)
 
Au niveau architecture, si j'ai 1 host physique avec x VM dessus (kvm) dont une des vm est le host docker. Je déploie mes x containers docker dans cette vm 'host'. Est-ce une architecture raisonnable ? Est-ce que Ubuntu snappy core ou 'core os' est adapté pour le host ?
 
Merci pour votre aide, j'ai pas encore lu tous le topic et il y a certainement des réponses dedans.
 
Question subsidiaire : qemu/kvm avec vga|hdmi-passthrough  ça m'intéresse aussi. C'est pas du docker mais j'aimerai utiliser mon petit serveur aussi comme serveur xbmc ou équivalent. (dans une vm, si docker ne support pas ça)

L'avantage c'est de cloisonner tes services, comme ça si tu dois mettre à jour un truc pour un de tes services, ça n'impacte pas les autres.
C'est un peu un des gros principes/intérêt de base de Docker d'ailleurs

Pour l'OS prends une version classique d'ubuntu, tu t'embetteras beaucoup moins, les distros light sont plus orientées déploiement massif, tu risque d'essuyer des plâtres pour rien alors te prends pas la tête pour le moment.

Pour le kvm / vga passthrough, y a un topic virtualisation pour ça.

Quelqu'un utilise Docker Machine ici ?

 
 
ok merci.
Et quid de ssh ? En lisant le topic, c'était plutôt déconseillé, mais c'est quand même rudement pratique

Y a plus besoin de ssh maintenant qu'il y a exec

Clairement

Salut,
 
Comment mettre alors a dispo un conteneur a qq un qui n'a pas accés a la machine hôte ?
 
Merci.

C'est pas du tout dans la logique de Docker.
Si tu veux fonctionner comme ça, utilise plutôt lxc.

http://www.appy-geek.com/Web/Artic [...] ign=buffer
"Conteneurs : un format unique pour réconcilier Docker et CoreOS"
 
Docker commence a flipper ?
 
XaT

Je pense pas, ça fait déjà plusieurs mois qu'ils ont une stratégie d'ouverture, par exemple en rachetant socketplane mais en ouvrant les discussions sur l'API réseaux aux concurrents (weave par exemple).

Vaut mieux, sinon ils vont disparaître
 
XaT

Bof, tout le monde disait la même chose avec les solutions de virtualisation, elles sont toutes toujours là pourtant.

drapoil

Auto-mal noté
 
XaT

 
 
http://blog.docker.com/2015/11/doc [...] etworking/
 
Ca commence vraiment à poutrer méchamment Docker

dites juste une question simple :  
Si je démarre x containers depuis la même image ABC, contenant par exemple mon application et que je mets un load balancer devant (je simplifie pour le fond de la question), comment est-ce que c'est géré sur la mémoire du host ? Est-ce que l'image ABC est chargée X fois en mémoire ? Est-ce que y'a un partage ?

Oui : https://groups.google.com/forum/#!t [...] CDC_sXzbks
(cherche le premier post de Solomon Hykes)

Cool merci !! J'aurai jamais trouvé sans ton aide.

Gros drap

Effectivement, c'est tres puissant... et j'aime bien

Salut à tous !
 
Je découvre Docker et sa puissance
 
J'ai un NAS Synology DS1513+ qui ne sert pour le moment uniquement qu'au stockage... je pense avoir trouvé de quoi fournir un peu de boulot au processeur et aux 4Go de RAM (2 d'origine)
 
Je vais déjà commencer par migrer mon Munin server qui tourne sur une VM Debian sur un vieux P4

Si il y a bien un truc que je cerne pas sur Docker c'est le réseau. Beaucoup sur le net l'utilise en publiant les ports mais a grande échelle il faut bien qu'on puisse donner une ip précise aux containers. Il faut donc que les containers ne soit pas naté derrière le docker mais directement sur le réseau.
 
Comment je fais si j'ai deux containers mail ayant besoin du 25 / 443... je ne peut pas changer les ports

Tu peux toujours changer les ports tant que tes clients sont au courant
 
Mais j'avoue que j'ai un peu les mêmes interrogations
 
Après je suis sur mon day 1 sur Docker et je suis assez sur le cul de m'être emmerdé avec des VM jusque là

 
J'ai pas creusé, mais cette annonce sur la version 1.9 répond peut-être à ta question.

Hello !
 
Voici donc 1 jour que je m'intéresse à Docker
 
Forcément j'ai quelques interrogations
 
Pour commencer c'est sur le cycle de vie d'une image. Prenons l'exemple d'une image Nginx :
 
-> je crée mon image avec un nginx.conf à côté de mon Dockerfile = monNginx1.0
-> je crée un container avec cette image -> ça tourne Ok
 
 
 
Maintenant j'ai une modification de conf à faire : quelle est la best practice ?
 
On édite le fichier nginx.conf à côté de Dockerfile et on crée une nouvelle image monNginx1.1 -> on coupe l'ancien container et on lance un nouveau basé sur cette nouvelle image ?
 
Ou alors il y a plus simple, plus efficace, ...

T'utilises un load balancer.

Tu passes ta conf via un volume (comme expliqué dans le manuel de l'image nginx : https://hub.docker.com/_/nginx/   )

Ben justement je crois que j'ai un truc qui m'échappe

Je pense que tu parles de la commande

Dans ce cas on est d'accord que je peux éditer ma config en modifiant directement /some/nginx.conf -> mais comment faire pour appliquer la conf au container ?

- c'est fait automatiquement ? J'en doute
- il faut juste "reset" le container qui va rechager la conf ?