Tangi Colin a écrit 246 commentaires

Désolé je suis pas convaincu par la comparaison avec Word/OpenOffice. Ça a pas grand chose à voir (ni l'App spec container de CoreOS, ni la spec de Docker ne sont des "normes" reconnu par quels organismes de normalisation que ce soit). Peut tu me dire pourquoi la spec de CoreOS serait plus légitime ?

Que tu la préfère pour la raison technique X ou Y pourquoi pas mais ce qui me dérange c'est que tu tente de faire passer ça pour une norme et Docker pour le méchant "Word", alors que c'est tout sauf ça.

Je sais que Mesos n'est pas historiquement lié à Docker et que ça vient du monde Hadoop (Développé chez Berkley avec en partie des sous de chez Yahoo). Mais Mesos a des besoins en isolations que docker leur amène (il le faisait avant avec leur propre implémentation de cgroup), mais maintenant ils ont fait le choix d'utiliser Docker par défaut pour apporter ça et pas mal de développement tourne autour de cette technologie. Donc si j'insiste, Docker est devenue une brique technique de base de Mesos. Et si tu regarde les développements en cours ça a une influence tels qu'un travail préliminaire sur la possibilité de virer zookeeper pour mettre etcd à la place (Bonjour Kubernetes, ou CoreOS ).

Docker n'est pas parfait certes mais c'est un projet OpenSource qui évolue vite avec pas mal de monde derrière, c'est pas juste DotCloud qui décide, y a un comité consultatif avec pas mal de gros acteurs.Et un sérieux qui à fait que ça à marcher (Non parce que lxc c'est l’exemple typique des projets opensource fait par des devs pour eux meme, doc minimaliste, api/abi qui pétait à chaque version …).

Le standard commun est tout sauf une blague. Aujourd'hui Docker est un standard de fait (suffisamment de grand nom l'informatique l'utilise et reconnaisse ses api). Dire que App container Specification est un standard alors que c'est un spec écrite par CoreOS pour leur projet rocket la c'est une blague. Qui a part eux l'utilise ? Et docker a aussi une spec de leur format d'image (depuis pas très longtemps je te l'accorde).

Le loging je comprend pas, entre configurer un rsyslog et un conteneur loggly c'est le même niveau de difficulté, ça me rajoute pas une surcharge de travail monstrueuse et ça me rend un service de bien plus grande qualité.

Et pour info Mesos a de plus en plus à voir avec Docker. C'est maintenant complétement intégré avec Mesos (et un port de kubernete et de docker swarm sont en cours).

Mais mon argument est que pour un système de contruction d'images, utiliser un versioning statique le rend complètement inutile. Comment je fais comprendre à docker build que git clone n'est pas idempotent etc. Je ne peux pas lancer toute la construction de mon container à son démarrage, ça tue l'utilité de Docker. Et d'ailleurs j'ai pas envie de lancer apt-get upgrade sur 150 machines alors que je pourrais directement déployer une image correcte.

Et qu'est ce qui t’empêche de faire ça avec Docker ? Rien. Tu mets un seul fois ton image docker à jour et tu déploie cette image sur tes 150 machines (avec un docker save/export ou avec un docker registry).

Le loging sur stdout c'est un concept qui vient de chez http://12factor.net/ et ça scale bien mieux qu'un syslog. Nan parce que quand tu as 100 machines à gérer avoir du docker et du https://www.loggly.com/ par example (ou du pagger durty) c'est le bonheur par rapport à du syslog.

Je veux pas lancer un troll mais j'ai l'impression d'avoir le même débat qu'avec systemd et le traditionnel "c'était mieux avant". Docker (bien qu'apportant peu de chose techniquement parlant, google fais du container depuis 10 ans dans ses datacenter) est en train de révolutionner le monde du datacenter (isolation/déploiment…). Si google (kubernete), twitter, airbnb (mesos), redhat (openshit), ibm (bluemix) et demain microsoft … sont entrains de proposer des solutions autour de cette technologie c'est pas pour rien. On a un vrai standard commun (api utilisé par tous) qui est entrains d’émerger. Alors oui avec lxc et des scripts moulinette maison on peut faire X ou Y que docker arrive pas ou mal à faire mais quid de l'éco-système de ta solution, quid de l'écosystème compatible avec, qui de la facilité de déploiement, quid de l’inter-opérabilité ?

Je suis pas si sur que ça soit clair au vu du dossier.
Si tu regarde par la, en 2007, il avait déjà un argumentaire qui se défend :
https://communities.vmware.com/message/727031

Pour l'instant j'ai pas assez d'information pour me faire un avis. Et vu que c'est un cours de justice allemande qui va statuer l'affaire, on aura rien avant longtemps.

pour combler mon ignorance, y quelques exemple de règle simple de SELinux ? J'ai jamais vraiment compris ce qu'on pouvais faire avec. Sur un post mono-utilisateur ça a un intérêt ?

J'ai déjà eu à faire avec des logiciels écrit en go et utilisant la fonctionnalité built-in de template qui est "logic less". Quand on écrit soit même son programme c'est bien, on sépare bien les choses, mais quand on récupère un logiciel et qu'on est obligé de le patcher pour juste implémenter des fonctions à la con pour comparer deux éléments d'une liste json c'est assez chiant.

Y a un projet qui à l'air plutôt sympa dans hébergement de git (avec code libre).
Un fork de gogs : https://notabug.org/
Le design est plutôt sympa, on a pas encore toute les fonctionnalités d'un github (pull request…) mais ça à l'air activement développé.

oui enfin y a pas que pour systemd que sa serait bénéfique. Les premiers a avoir poussé pour un bus de communication au niveau kernel c'est le projet Genivi (Projet de la linux fondation pour promouvoir linux dans les véhicules) qui ont pondu http://projects.genivi.org/afbus-dbus-optimization/home . KDBUS en est l'héritier. On peut mettre beaucoup de chose sur le dos de systemd mais faut pas tout mélanger non plus.

Tout est dans le titre, azure est en forte croissance (ce n'est que des pourcentages et quand on part de si bas on ne peut que progresser). Après il faut rester lucide, en terme de part de marché amazon reste très loin devant. Et comme des entreprise comme Netflix qui représente 9% du traffic internet mondial l'utilise, leur part de marché sont pas près de changer.

Après quel part de linux tournant sur amazon sont des redhat j'en sais rien. Mais la belle progression d'Azure est toute relative et je pense pas que ça fasse si peur que ça à redhat (qui sont entrains de mettre pas mal de moyen dans openshift).

Docker n'utilise plus la librairie LXC, il utilise par défaut leur propre librairie écrite en go qui s'appelle libcontainer (il est possible d'utiliser docker avec un backend lxc (--exec-driver=lxc) ).

Niveau fonctionnalité on est a peut près au meme niveau entre docker et LXC. Il manque encore deux ou trois petits truc à la libcontainer tels que le namespace uid (avoir l'uid 0 du containeur mappé sur un uid user de la machine hôte). Pour la petite histoire ce manque était surtout du à un manque dans l'implémentation de syscall de go, depuis qui ceci à été fixé dans go 1.4 ça devrait arriver rapidement dans docker.

Docker vs lxc ? Docker à un eco-system beaucoup plus grand (intégration Google Kubernetes, Mesos, Amazon EC2, et meme bientot Microsoft…). Moins de configuration manuelle, plus de documentation, plus d'examples, plus de recettes (ansibles,puppet,…). Après effectivement si on aime ce la jouer barbu fana des script maison en ligne de commande docker est moins sexy que lxc , pour tous les autres y a pas photos.

On va sans doute me prendre pour un gros trolleur mais le cas du mail c'est toujours le premier cas qu'on sort pour l'auto-hébergement alors que c'est sans doute le moins utile/pratique/réalisable.

Parce que déjà la plupart de tes contacts ne font pas de GPG et sont sur gmail, donc niveau vie privé toussa on repassera, tes communications mails sortirons forcément de ton serveur auto-hébergé. Et de deux le mail c'est juste horrible à administrer, entre les whitelist/greylist/backlist, les anti-spam à configurer et le fait que du jour au lendemain tu peux te retrouver dans un liste de spam type spamhaus et consort à cause d'un faux positif. C'est juste le service à la con dont je laisse l'administration à d'autres. C'est rigolo de monté un serveur postfix en prototype, le gérer au quotidien c'est l'enfer.

Par contre des services d'échanges de photos/fichier avec mes proches la ça peut avoir un sens de faire de l'auto-hébergement. (Bien que ça empêche pas qu'un amis les repose sur facedebook)

Voila mes 10 cents, éviter de parler de mail lorsque vous parler d'auto-hébergement ça désert la cause je trouve.

Python pourquoi pas, par contre Django bof bof, y a des choses qui me manque dedans et qui sont pas évidant à faire ou avec des plugins non-maintenue tels que Server Sent Event par example.

Je préfère largement flask à choisir.

pour ce qui n'avait pas la chance d'etre sur place, on peut voir les "slides" des présentations quelque part ?

Premier point, je n'ai rien à vendre. C'est juste une technologie qui je connais et avec lequel je m'amuse pas mal, point.

Mais 100Mo c'est vraiment si lourd ?

Y a des conteneur qui font bien moins que 100Mo tout dépend ce que tu veut faire.
Si tu fais un tar cv --files-from /dev/null | docker import - scratch
tu te retrouve avec un conteneur qui a un overhead null. Pour des programmes compilés statiquement (trivial a faire pour des programmes écrit en go si tu utilise le compilateur cgo par exemple) tu as juste ton programme et rien de plus. Pas mal non ?
Si tu veux avoir des librairies dynamique rien ne t’empêche de les avoir sur ton OS ou dans un autre conteneur et de faire des mount-bind (docker volume).
Tu as aussi des images busybox qui font ~50Mo et l'image debian de base fait 83Mo.
Sachant qu'en plus avec docker tu utilise généralement soit aufs (unionfs) ou btrfs(copy on write) comme système de fichier tu peux pas vraiment dire qu'il y a un overhead, t'as 10 images basé sur la debian base tu te retrouve qu'avec un seul fois les 83Mo (copy on write ou unionfs).

Donc si c'est léger en taille. (Après en ressource kernel avec tout les namespaces crée c'est une autre histoire).

Et puis l'idée du titre c'était de parler de conteneur léger. Y a pas que docker, y a lmctfy de chez google , rocket de chez coreos, lxc etc… Le principe de l'isolation n'a pas été inventé chez docker.

Docker peut répondre à ta problématique.

parce que ça deviens très vite le bordel dès que tu as plusieurs "master" à maintenir (plusieurs versions en même temps). Tu te retrouve avec des branches de hotfix, des backports entre tes branches etc…

oui on garde toutes les branches, après on se base sur gerrit qui fournit quelques avantages. Toutes ses branches sont des branches de revue gerrit (gerrit crée automatique une nouvelle branche lorsque tu pousse un commit qui a un nouveau gerrit ID dans son commit de message) et c'est des branches spéciales. Spéciales dans le sens quels sont dans un refspec git séparé. Donc oui tu as toutes les branches sur le serveur mais par défaut tu ne les vois jamais. (Pas dans le refspec par défaut).
Comme les branches de revue sont très petites, le log linéaire dans la branche de master suffit la plupart du temps. Si y a une besoin précis, faut aller récupérer la bonne branche (avec le gerrit ID c'est vraiment facile) et la on a accès à tous les commits de la feature mais aussi à tous les commentaires de la revue de code gerrit, les logs de l'intégration continue etc…

La seul limitation de ce workflow c'est si tu as plusieurs "master" (si tu gère plusieurs versions en parallèle genre une branche v1.x et une branche v2.x), si tu veux backporter un commit d'une branches à l'autre on préfère passer par une nouvelle branche de revue et donc changer le gerrit ID et on inclue manuellement l'ancien gerrit ID dans le message de commit. C'est pas obligatoire mais ça permet de si retrouver plus facilement.

Utiliser se workflow sans gerrit demande à mon avis quelques adaptations. Gérer les git refspec à la main ça peut etre assez lourd (quoique à y réfléchir c'est pas si compliqué) et tous avoir dans le même refspec devient vite le bordel.

J'utilise un workflow plutot similaire mais sans rebase en soi.

Mon workflow a moi est le même, on crée des branches tout le temps (pour chaques features, bugs …)
Par contre au niveau merge on fait du squash + cherrypick de la branche à merger. Ensuite on utilise gerrit qui à la particularité de mettre un ID unique dans le message de commit donc depuis la branches d'intégration ou la master si on veut retrouver le log complet d'une feature, on regarde l'ID dans le commit de message et on retrouve la branche correspondante.

On ne rebase jamais, on ne fusionne jamais les branches, on cherry pick. Si jamais on a intégrer un changement sur la master qui doit etre retiré on le revert tout simplement. (Ce qui normalement n'arrive jamais puisque la branche d'intégration sert à éviter ça).

Peut etre que ça peut te convenir comme workflow.

Par exemple : Google’s Public DNS intercepted in Turkey

La carte semble avoir la norme CE, les certificats sont ici :
http://www.lemaker.org/index.php?m=content&c=index&a=show&catid=10&id=41

Attention il y a bien plus de XP qu'on le croit dans le monde industrielle. Par exemple la majorité des DAB (Distributeur automatique de billet) tourne sur un XP.

Encore une fois tu fais des jugements trop rapide.
Dire que les JO ça sert à rien c'est faux. Ça à déjà servit a réhabiliter un quartier de Londres qui était en mauvais état (avec dé-pollution des sols, réhabilitation des canneaux etc…). Et puis y a/aura des retombées économiques d'un tel événements. A ton avis pourquoi tout le monde se bat pour avoir les JO chez soi ?
Après on peu être critique sur cette vision, dire que les retombées économiques attendues ne sont pas suffisant par rapport à la somme investis mais c'est pas la même chose que de dire ça sert à rien parce que ça nous intéresse pas.

Et ton argumentaire sur la science est un peu facile. Vu qu'on ne sait pas par avance, allez dépensons des milliards dans des projets scientifique sans regarder les retomber possibles, si c'est scientifique dépensons on verra bien.
(ps: Je dis pas que cette mission sur mars ne sert à rien, je dis juste que l'argument qui dit si c'est scientifique on peut dépenser sans compter sans avoir un regard critique sur la dépense est faux, derrière tout projet y a des réalités économique, des investisseurs.)
Certains projet scientifique ne trouverons jamais de financement.

C'est quoi ces jugements à l'emporte pièce, on pourrait dire la même chose de cette mission. 2,5 milliards alors qu'il y a des gens qui meurent de faim sur notre bonne vielle terre. C'est ce qui est bien avec les comparaisons sans fondements on peut en conclure n'importe quoi.

Même commentaire inutile, merci pour le lien, c'est une vidéo de grande qualité. Quand il évoque la perte de nos moyens de pensée car on a perdus les mots (passage sur hiérarchie vs projet) ça ma fait toute de suite pensé aux discours de Bernard Stiegler sur la prolétarisation du savoir.

ça changerait quoi par rapport à aujourd'hui ?
Déjà tout un tas de fonctionnalité d'html5 sont implémentées par les navigateurs et utilisées par les devs webs. Le dev web c'est déjà le bordel, je vois pas en quoi sa sera plus le bordel si le WHATWG pousse en avant.