Reprise du message précédent :
Hello Messieurs, je commence à utiliser Docker au boulot dans une optique d'optimisation de workflow, et j'ai une petite question de noob.
 
Soit une application Node.js utilisant une BD quelconque (Redis dans le cas présent mais peu importe). Cette application est packagée dans un container Docker, mais le container n'inclut pas Redis, qui est déjà installé sur le serveur.
 
Y'a t'il un moyen pour que l'appli du container utilise le serveur Redis installé sur le serveur, sans être obligé de refaire le container pour l'y inclure ni de lier le container de l'appli à un autre container Redis ?
 
Merci

Ton conteneur peut tout à fait adresser des services extérieurs, pour peu qu'il lui soit accessible via le réseau (pas de filtrage explicite quoi, et routage Ok).

Effectivement, c'est tout bête : je n'ai eu qu'à rajouter le paramètre --add-host=nom_du_serveur:ip_du_serveur dans mon docker run, et c'est terminé.
Merci :-)

En passant : http://www.journaldunet.com/soluti [...] t-changer/
 
XaT

Y a de vilains raccourcis et quelques erreurs dans cet article ("ulimit" )

J'sais pas, j'ai pas lu. J'attendais un retour pour le lire

XaT

 
 
Toujours pas pris le temps d'étudier Docker...
 
Je m'y mets  
 
par curiosité et pour voir si ça va pouvoir me servir.

Enfin trouvé un livre PRO sur le sujet :
https://leanpub.com/the-devops-2-toolkit

Putain les annonces sur Swarm de la DockerCon  

yes swarm pousse bien je trouve.  
Plus adapté qu'apache mesos d'après les retours (niveau cluster)

Ben là c'est surtout qu'il implémente enfin les même features que kubernetes, sauf que c'est inclus dans le Docker engine de base, et que c'est simple à déployer (tout le contraire de kubernetes donc).
 
Les devs de kubernetes peuvent retourner en enfer, pour mon plus grand plaisir

y'a google derrière qd meme
 
Mais oui Swarm pousse dans le bon sens

Ca vient de Google à la base, mais ils ne sont pas tant que ça derrière.
 
Et ça explique aussi pourquoi ça marche bien dans GCE, et beaucoup moins bien ailleurs
 
En plus c'est la techno choisi par RedHat pour openshift v3, comme preuve que c'est une techno overkill et inmaintenable on ne peut pas faire mieux

Dis pas ça au pote qui bosse chez red hat
 
De toute façon il n'existe que 3 solutions cluster (tu me dis si je me trompe) Kuber, Swarm et mesos.  
 
Tu es sur quoi en ce moment?

Y a rancher aussi qui a son propre orchestrateur.
Y a Nomad de hashicorp mais qui est plus généraliste, un peu comme mesos.
 
Perso je n'en utilise aucun en prod, ce n'est pas/plus mon métier
Mais je suis pro-swarm depuis le début

Une question pour les barbus
 
Quelles sont les best practice pour la gestion des images ?
 
- utiliser uniquement l'image officielle publique du hub public et faire un RUN apt-get install apache/tomcat/etc COPY etc dans le docker file ?
- construire soit même ses images from scratch avec les bons composants natifs (apache-php...) ? Chiant
- combiner les images officielles avec du puppet/chef/etc ?
 
Pour le stockage des images, idem, que faire ?
- le hub public
- la partie private du hub docker ou un service en ligne
- ou son propre hub privé ?
 
Logiquement pull hub public et push stockage privé je dirai, mais tout dépend de la gestion des image, d’où la première question.

 
On va partir sur Rancher, en tout cas en tests  

Hello,

Je repasse après bien des années xD

Swarm est tout intégré ca c'est chouette.

Comment gérez vous votre stockage docker ?  flocker ou plugins docker ?

Ben ça dépends des applis.
 
J'évalue flocker en ce moment, mais bon, je suis un peu déçu de l'implémentation de ceph (qui est pas super maintenue).
 
Après je trouve que tous les autres drivers de volume pour Docker sont au mieux au même niveau (rexray, convoy), mais pour la plupart c'est pire, ou sans grand intérêt (containX/netshare).
Bref, c'est quand même plutôt bof pour le moment.
 
Au final, des bons vieux partages NFS distribués (à condition que ton serveur NFS soit en haute dispo) et une bonne organisation des datas c'est au final le moins complexe et donc le moins sujet à problème (avis perso).
 
Après, encore une fois, faut voir en fonction des applis que tu déploies, y a pas UNE solution idéale pour tous les cas.

Sinon pour ceux qui veulent comprendre un peu mieux la gestion du réseau dans la 1.12 (avec des choses qui ne concernent pas que la 1.12 d'ailleurs) : https://blog.docker.com/2016/08/doc [...] etworking/
 
Perso ça a répondu à pas mal des questions que je me posais, et pour lesquelles je n'avais pas réussi à trouver de réponses jusque là

 
 
Je suis allé à une petite session découverte, je drap ça pour plus tard  

J'ai un container qui dépend d'un cluster mysql, il est donc censé l'attaquer avec l'ip de l'hôte ce qui fonctionne parfaitement le truc c'est que je vois sur mon routeur des drop venant de l'ip bridge du container o_O
 

 
(172.16.3.11 c'est le serveur mysql)
 
Alors tout fonctionne bien mais je me demande pourquoi un container parle avec son ip bridge alors même que le masquerade est activé
 

 
merci !  
J'ia pu discuter avec un collègue le mettant en production : constant identique ... Flocker, intéressant mais manquant de maturité.

Je vois que le networking est toujours à chier
 
XaT

Ton hôte est en 172.16.X.X, t'aurais pas une route un peu large sur le network/mask de déclarée et qui foutrait le boxon ?
Faudrait regarder comment sont les règles iptables qui sont enregistrées par Docker, et si y a pas d'autres règles non gérées par Docker qui rentreraient en conflit.

C'est quoi le nom de l'outil graphique? Swarm?

Bah je sais pas. Kitematic par exemple qui est justement cité dans ta citation ?
 
XaT

Bon on est parti en test sur de la ferme Rancher, git et jenkins (à voir si gitlab pour remplacer ces deux derniers également).
 
A voir aussi comment on modifie le reverse proxy  avec un post hook.
 
Pour le stockage, la partie la plus merdique je trouve, on va essayer de tout foutre dans le container buildé directement à partir du hub. On ne va pas dockeriser les BDD mais reprendre l'existant.
 
Après quid de la partie log et monitoring ? Pas trop sur sur ce point.

Salut,
Il y a des utilisateurs du gui Panamax ici?  
On fait comment pour installer sa ? https://hub.docker.com/r/diouxx/glpi/
 
J'ai importé le fichier en YML et sa ne fonctionne pas

C'est la fête des GUI et autres managers \o/

drap
 
Je gère plus de 800T de stockage et 1400 threads de calcul ! Je commence des tests pour passer tout ça sous docker, j'ai du boulot ^^

surtout le stockage et le réseau

Perso pour l'instant, docker => faciliter le delivery applicatif ...... sans stockage ... et réseau

 
Je sais pas si c tres utile ds ton cas

 
Pourquoi tu dis ça ? ça m'intéresse d'avoir d'autres points de vue, je rate peut être quelque chose.
L'architecture à évolué de machine physique à openvz (augmentation du nombre de machine virtuelle moins puissante du coup) puis lxc/kvm (actuellement).
Lxc est plus lent que openvz et sur des millions de calcul ça se ressent, je pense que Docker va améliorer les performances, mais je me trompe peut être, réponse ici dans quelques semaines.

docker c pour le devOps et la chaine de developpement, pour le reste c une erreur

Faudrait savoir sur quels aspects LXC pêchait par rapport à openvz (perfs en calcul pur ?), parce que Docker et LXC utilisent les mêmes mécanismes du noyau pour l'isolation, donc bon...
Après quand tu parles de lxc/kvm, tu veux dire dur lxc dans du kvm ? Et du coup vous allez faire du Docker dans du kvm ?

N'importe quoi

non
faire du conteneur pour autre chose que du delivery applicatif franchement je vois pas en prod

Ben la livraison applicative, ou plus généralement le packaging, ça se cantonne pas au devops et à l'automatisation de la chaine de build.
Je peux t'assurer que y a beaucoup de tres grosse boites/centres de recherche qui s'y intéressent pour les aspects "livrables" et isolation/sécurité, sans faire de devops ou d'intégration continue ou de dev tout court.

si tu as des liens je prends pr ma culture perso :jap

 
isolation/sécurité et Docker dans la même phrase, c'est succès assuré dans 100% des confs auxquelles j'ai assisté cette année    
 
Pourtant pas des conf anti-docker, surtout quand ça s'appelle ContainerCon