Reprise du message précédent :

 
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

Ben entre 2 process sur la meme machine, et 2 process dans leurs conteneurs respectifs, oui, c'est plus isolé

ah oui forcément, entre un fauteuil à roulette et une trottinette, ya pas photo si tu cherches à te déplacer Tout est relatif

Pour répondre aux questions et à la discussion.
 
Je bosse dans un centre de recherche en génétique connu    
 
Historiquement 1 machine = 1 programme  
Il y a déjà quelques années passage sous proxmox en openvz pour augmenter virtuellement le nombre de machine, car les utilisateurs font tourner tout et n'importe quoi, interaction entre de vieux programme, donc obligé d'isoler !
Puis proxmox abandonne openvz, sous lxc perte de performance et sous kvm c'est pire et c'est logique.
 
Je teste docker car isolation des processus, et ça va faciliter le déploiement à la volé avec swarm.
Je pense gagner en performance, car il n'y aura plus XX os qui tourne et donc mois de processus système au global donc plus de place pour les process de calcul.
On voit vraiment une différence quand on a plus de 1000 machines.
 
Et même si je gagne pas de performance, on gagne en confort de déploiement sur un cluster.
Si tu veux une utilisation concrète pour le calcul regarde go-docker http://www.genouest.org/godocker/
J'ai vu une présentation, et le but à terme et de remplacer les grilles de calcul national

Voilà, le calcul scientifique c'est typiquement l'utilisation à laquelle je faisais allusion, et qui est très très loin du devops et chaine de développement (c'est plutôt archéologie et anarchie )

Ouaip isolation de ressources, gestion des dépendances, delivery appli, mais pas accepté par les rssi comme mécanisme de sécurité
Par ailleurs la partie réseau  est pas tip-top et la partie stockage encore pire ...

Bref par ici c'est docker pour le delivery et l'abstraction des dépendances logicielles pour le moment  Ca permet de matérialiser un périmètre de responsabilité par une meusure technique (ie DEV vs OPS)

Ca dépend des rssi, et ça dépends surtout de comment tu l'implémentes.
Si tu donnes accès direct à docker aux utilisateurs, effectivement, ça passera pas

Nan mais même pour des services entre machines hein et même dans les -32eme étages

Ça donne vraiment l'impression que tout le monde court après sans trop savoir pourquoi...  "Je veux du Docker."    
 
La techno est intéressante, mais en pratique...
 

+1
 

Nan, la notion d'embarquer tout dans une image légère est particulièrement intéressante pour plein de cas autres que le devops et le continous delivery.
Et beaucoup moins de contraintes que d'avoir tout ça dans une VM.

Pour les codes de calcul c'est vraiment très bien.

drapal,
 
Je suis aussi moyennent emballé par toute cette euphorie envers dockers, surtout pour de la prod, mais bon je commence à y bidouiller, parceque j'ai 1 client qui utilise cette techno.

Moi je trouve ça bien pratique pour gérer les intégrations moisies faites pas les développeurs/éditeur. Tout leur bordel se retrouve dans le container et ne vient pas pourrir les systèmes
 
Ca permet aussi de répondre rapidement à un besoin de monter en charge ou des besoins d'une équipe applicative

 
Oui mais ça, un jour ou l'autre, tu le payes

Vachement moins que quand tu dois le déployer sur une machine standard.

Ça c'est sûr

Donc du packaging de delivery
Fin bref  un soucis => une couche ""d'abstraction""

https://tsuru.io/
Qui a testé ce truc ?
 
(up!)
 
XaT

Arf, du PaaS

Si vous ne connaissez pas déjà, nous utilisons Rancher (http://rancher.com/) pour gérer un cluster de machine Docker. Cet outil intègre :
- une interface web pour lancer / stopper des machines, démarrer les containers docker etc,
- un réseau interne privé entre les containers (et les machines du cluster) via un tunnel IPsec,
- un dns interne pour tous les services internes à la stack de services,
- possibilité de lancer facilement un load balancer HA-Proxy comme frontal à vos containers (pour taper sur un Tomcat par exemple),
- pour le reste, regardez directement sur leur site et la doc
 
Leur dernière version v1.2.x est pour le moment buguée à mort parce qu'ils sont passés en architecture micro-services, mais ça devrait se stabiliser petit à petit.
 
On l'utilise pour scaler à la demande plusieurs centaines de machines sur divers providers cloud (Amazon, Digital Ocean etc.) pour des tâches à forte charge éphémères.

osef c'était pour uper

 

 
XaT

 
on avait choisi aussi rancher pr les memes raisons.  

@vanadium vous avez testé d'autres alternatives avant de choisir ? Ou des essais en cours dans un lab ?
 
XaT

tests ? on s'en fout c'est le futur ! http://sametmax.com/cest-le-futur/

C'est exactement ça

Oui, on avait un cluster Mesos auparavant piloté par Singularity. Mais c'était vrai à chier, l'API REST était dégueulasse et pleine d'effets de bords. Et puis on voulait dockeriser toute l'infra. Il nous fallait une solution open-source qui puisse orchestrer un cluster de machines.
 
Il n'y avait pas grand chose à l'époque comme alternative (c'était mi-2015) alors le choix a été vite vu, même si c'etait encore en beta à l'époque

Et pourquoi pas Swarm ? c'est natif dans docker au moins...

Parce qu'il manquait le réseau privé entre les machines, IPsec est celui fourni par Rancher. D'autre part, mi 2015 Docker swarm était loin d'être mature également (et ne l'est toujours pas), et il fallait se palucher à la main le réseau avec un outil tiers pour le réseau comme Weave par exemple.
 
EDIT : et on avait comme pré-requis de trouver une solution qui puisse démarrer les machines sur les providers Cloud via une API Rest. Rancher te permet de lancer une machine sur divers providers via leur api REST. Ca nous a permis de virer notre code backend spécifique à AWS (qui utilisait leur SDK) et au passage de proposer une solution multi-cloud (auparavant limitée à Amazon uniquement). Le gain était double : plus de fonctionnalités, moins de code à maintenir.

Je commence à m'auto former sur Docker, mais j'ai un peu de mal avec son utilisation.
Je comprend le principe des container, mais j'ai du mal à saisir les liens entre conteneurs :
Est-ce que je peux installer un conteneur sans OS qui tourne derrière ?

Par exemple, je voudrais l'utiliser sur mon serveur perso pour tester / utiliser des outils web (genre wekan / Wechat et autres) de manière simple.

Il me faut donc : un container "OS" avec ubuntu + conteneur Apache - PHP - MySQL + conteneur du service web

Comment les linker au mieux et surtout comment réduire la taille ? Pour LAMP, l'image est presque aussi lourde (100 et quelques MO) que celle d'Ubuntu !

EDIT : 427 Mb pour LAMP et 129 pour Ubuntu...

Je pense que tu peux t'arrêter la Mais c'était bien tenté
 
XaT

je m'y mets aussi et quand tu dl une image docker style lamp t'as déjà tout, l'os ET les softs qui vont bien normalement

Quand tu utilises une image LAMP, t'as déjà tout faux
(je ne parle pas de la techno - c'est un autre sujet , mais du fait d'avoir la base et l'appli dans le même conteneur).

Je sais pas pourquoi je sentais que j'allais me faire basher  
 
Ce n'est pas très commode

C'est en tombant qu'on apprend à marcher. Persévère et ignore les commentaires négatifs, tu m'aurais dit Docker il y a seulement 2ans, je n'y connaissais rien. Et aujourd'hui, j'ai encore beaucoup à apprendre.

C'est pas un bash (et la petite pique sur PHP c'était le petit cadeau du dredi ) : Faut absolument pas utiliser une image avec Apache/PHP ET MySQL dedans, ça te fait passer complètement à côté de la logique de Docker.

Donc :
- image php:apache : https://hub.docker.com/_/php/ (y a aussi moyen de séparer PHP et le serveur web en utilisant fpm, mais ça complique inutilement le bousin )
- image mysql : https://hub.docker.com/_/mysql/

Après faut surtout regarder si y a pas déjà des images pour les applis que tu veux tester.

Mais les images de type "lamp", c'est niet

Non mais j'en connais certains (n'est-ce pas) j'ai compris la taquinerie pas de soucis
Voilà, merci, ne pas utiliser de LAMP et faire un PHP-Apache + MySQL, compris    

Autre question : qu'est-ce que vous utilisez pour lancer automatiquement une commande ou un service dans un container ?
J'ai testé quelques trucs et parfois je dois entrer dans le container pour lancer une commande genre "service xxxx start"

init 0

Faut surcharger la commande ou l'entrypoint à la création du conteneur.
Ou la définir à la création de l'image.
 
Les commandes service, systemctl et autre /etc/init.d/... t'oublies, y a 'normalement' pas de système d'init dans un conteneur Docker (enfin on peut, mais encore une fois, ce n'est pas la bonne façon de faire).

Faut surtout pas démarrer de services dans un container. 1 container = un programme. Si tu sors de ce paradigme, tu vas à l'encontre de la modularité offerte par Docker.
 
Après, si tu fais des images Docker toi-même et les publie sur le Hub Docker, il peut y avoir un intérêt à réduire la taille des images. On utilise souvent alpine comme base plutôt que ubuntu pour faire des containers plus légers. Tu trouveras d'ailleurs des variantes alpine bien souvent pour les services que tu utiliseras (comme httpd par exemple)

donc si je résume: tu prends un container avec par exemple apache, auquel tu connecte un datastore local dans lequel tu as ton projet et tu fais démarrer directement ton container avec ce projet et rien d'autre?

Un apache, rien n'empêche d'avoir plusieurs sites qu'il peut héberger avec des vhosts différents. Mais dans le container, il y a Apache et rien d'autre, sinon c'est le bordel.
 
Pour faire les combinaisons dont tu as besoin (Apache + Mysql, Apache + PostgreSQL, Apache + couchbase etc), heureusement qu'il n'y a pas une image par combinaison, sinon je te dis pas la misère
 
C'est comme si on te vendait une carte mère avec un CPU soudé, c'est cool c'est tout en un, mais quand tu veux changer l'un ou l'autre...

Bonjour,
Quel VPS me conseillez vous pour héberger un petit labo Docker ?
J'hésite entre un portable chez moi accessible à distance ou un serveur virtuel.
Que me conseillez vous?