Il n'est pas la référence et il n'est pas implémenté partout parce qu'il n'est pas le seul. Par exemple dans l'embarqué, le système de paquet logiciel reconnu et poussé par les industrielles est Yocto (projet de la linux fondation) qui repose sur bitbake et openembedded.
Tu es étais où les 20 dernières années ? Non parce que redhat fait ça depuis le début. Soit tu paye pour avoir du redhat, soit tu utilise du centos.
Et dire que RedHat c'est pas libre c'est très très fort de café, ils ont fait énormément pour le libre dans de très nombreux domaine, les développeurs ne vivent pas que d'amour et d'eaux fraîches. Je suis pragmatique est je comprend très bien les positions de Mozilla ou de RedHat, protégé son nom n'a rien d'abusif. Faut pas mélanger les torchons et les serviettes. La liberté du code c'est la liberté du code , un point c'est tout.
Microsoft change, ouverture de C# avec migration de codeplex vers github, partenaria docker , ouverture de msbuild, compilo LLVM pour .NET Core (https://github.com/dotnet/llilc).
Depuis l'arrivé du dernier CTO y a un vrai virage vers de l'opensource qui a été pris et pas uniquement marketing y a eu de la liberation de code aussi. On peut pas juste dire que c'est du librewashing parce que c'est windows, c'est trop facile.
Mouais, sur ARM, on n'a pas de couche d'abstraction/introspection comme BIOS/ACPI/EFI/…
Donc on n'a pas "one kernel to rule them all" (alors que sur mes vieux PC d'il y a 15 ans, je peux encore booter un CD d'une distro linux quelconque). Donc c'est autrement plus complexe à maintenir (le device-tree améliore la donne, mais ça reste imparfait) et la pérennité de tes machines est largement discutable lorsque le constructeur en cesse le support.
Les choses bougent dans se domaine, il y a de plus en plus de board arm qui sont compatible avec un seul kernel (via devicetree). Et y a plusieurs travaux en cours au niveau du développement du kernel. L'un est de rendre le decivetree dynamique (pour gérer les capes à la beaglebone) et un autre qui vise à unifier ACPI et devicetree (par la j'entends avoir une API commune niveau kernel qui dispose d'un backend ACPI pour X86 et devicetree pour ARM ou POWERPC).
Après contenant les critères qui feront décolle ARM sur le marché du serveur le prix est un facteur important oui mais l'écosystème n'est pas à négliger non plus. J'ai beau avoir une stack Java (que je peux donc faire tourner sur ARM facilement) j'ai sans doute autour des outils de monitoring, de log, d'agent de déploiement etc… qui ne sont pas forcément disponible sur ARM. Et on va pas demander à un admin sys de faire de la cross compilation.
Yocto (ou pour etre précis bitbake et openembedded) permet déjà de répondre à tout tes problèmes :
Multi-plateformes (x86,arm,powerpc …) et multi-build système (make,autotools,scons,cmake…)
Gestion des dépendances (à la compilation et au runtime)
Multi-fetcher (git,svn,tarball,mercurial …)
Facile à modifier, étendre (patch et via layer)
Système de cache (ne rebuild que ce qu'il faut)
Système de package (rmp, deb ou opkg)
Il peut auto-construire ça propre toolchain
Peut exporté un SDK (Software development Kit)
Honnêtement, l'essayer c'est l'adopter. Y a juste deux bémol :
La taille (on arrive vite à plusieurs Go (entre les sources, le cache)
N'est pas vraiment pensé pour une développement en mode "agile". (Sauf si tu gère la partie fetch toit meme (avec repo android tools par example ) et en utilisant la classe externalsrc).
Comment le rappel le journal, ils ont libéré .NET et MSBUILD. Ce n'est pas rien. Ils ont tous mis sur github et non sur codeplex ce qui est aussi un changement de culture important. Donc dire que Microsoft fait de l'openwashing c'est du microsoftbashing .
Effectivement l'OS de microsoft ne va pas etre liberé du jour au lendemain mais je ne pense pas que cette phrase ne soit que du buzz. Y a un vraiment tournant qui a été pris depuis l'arrivé du nouveau CTO.
Pourquoi forcément au pire ?
Google arrive à prédire des épidémies de grippe plusieurs jours avant les systèmes traditionnel de santé vigilance. (https://www.google.org/flutrends/) Je trouve ça intéressant (et dans ce cas les infos peuvent être anonymisé). Tu peux gagner des informations précieuse sans forcément tomber dans la pire dictature.
Tout dépend comment cela est fait, par qui et dans quel but. Le qui étant le plus important (le but et le comment découlant souvent du qui).
Armes et couteaux sont toutes les deux "ni bonnes, ni mauvaise". Dans les deux cas ce ne sont pas les armes ou les couteaux qui tuent mais ce qui s'en servent. Après on fait un calcul de risque par rapport et on estime que le risque d'une arme est plus élevé que le risque d'un couteau et donc on en contrôle leur accès (permis d'arme).
Une arme est estimé plus "dangereuse" qu'un couteau mais ça n'a pas grand chose à voir avec "bon" ou "mauvais". Une arme peut servir à de "bonne chose" (Ou alors faut considérer que toutes les force de l'ordre et les chasseurs comme des pourris).
Qui estime qu'internet fait plutôt le bien ? A part quelques personnes convaincu que c'est la troisième évolution majeur de l'humanité après l'écriture et l'imprimerie, y a malheureusement beaucoup de personne qu'y le voit internet d'un mauvais oeil (Un repaire de pedo-nazi-terroriste-pirate incontrôlé).
Les inquisitions sur la technologies ça m'inquiété. Non une technologie n'est ni bonne ni mauvaise. On peut faire des choses géniales avec les big data comme de la surveillance de masse. Le problème n'est pas les big data mais à ce qu'on en fait. Sinon on fait juste plus rien, toute technologie peut etre utilisé à de mauvaise fin. Si j'écrase la tête de quelqu'un on fait quoi ? On interdit tout les marteaux même pour leur usages légitime de planter des clous ?
Le rapport entre Docker et ZooKeeper ou etcd ? L'éco-système, docker est la brique de base qui te permet de faire de l'isolation mais dès que tu veux faire du déploiement multi machine tu as d'autre besoin que juste l'isolation tels que le load balancing, la haute dispo, la découverte automatique de service etc… Et ça Mesos peut l'apporter. Mais le coeur de Mesos repose sur l'algo à consensus Zookeeper qui n'est pas celui choisi par d'autre projet gravitant autour de Docker. Kubernetes de google utilise etcd et coreOS aussi. Y a un port en cours pour intégrer Kubernetes avec Mesos. Et avoir zookeeper et etcd en parallèle c'est un peu bancal comme architecture. Donc y a un travail en cours pour avoir un backend etcd à Mesos. Y a aussi un travail en cours pour intégrer l'api de Docker Swarm.
Et pour faire tourner du Hadoop, Spark et Storm sur le meme cluster tu as besoin d'isolation, avant Mesos proposait sa propre implémentation (toujours à base de cgroups) mais depuis la version 0.20 docker est devenue une brique "1st citizen". Il se repose dessus pour fournir leur isolation. L'ancienne implémentation reste disponible, tout ceci est configurable a travers la ligne de commande qui lance le mesos-slave. Mais meme si tu fait tourner du Storm et du Spark tu as tout de meme besoin d'isolation entre ses framework et tu peux utiliser docker comme conteneur.
Docker n'est pas un framework Mesos de plus, c'est pas au même niveau dans la "stack Mesos", tu as tout en haut les frameworks (Storm,Hadoop,ElasticSearch,Jenkins,MPI,Aurora,Marathon…) et en bas, au niveau des executeurs, (sur les slave mesos) tu as le conteneur (soit l'implémentation mesos de base, soit depuis la 0.20 docker). Donc je me permet d'insister, au vue de développement en cours (le jira mesos est public), il y de plus en plus de développement qui sont fait pour s'intégrer avec l'eco-système Docker (Docker Swarm,Kubernete,support etcd) et Docker est maintenant une brique de base de la stack Mesos (Elle n'est pas irremplaçable puisque l'ancienne implémentation reste disponible mais c'est tout de même une brique de base).
Concernant LXC, oui Docker était une surcouche à LXC et ils ont implémenté libcontaineur parce qu'il en avait marre de gérer les api breaks et les X versions différentes de LXC. J'ai la flemme de me replonger dans les mailings list docker mais ça transpire même dans l'annonce officiel : http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
This drastically reduces the number of moving parts, and insulates Docker from the side-effects introduced across versions and distributions of LXC. In fact, libcontainer delivered such a boost to stability that we decided to make it the default
Au passage pour ne pas opposé docker et LXC, la libcontainer dispose de plusieurs backend (celui par défaut en go) mais rien ne t’empêche d'utiliser LXC ou LMCTFY de google etc…
Mais si tu me relis tu verra que je dis que Docker n'apporte pas grand chose technologiquement parlant mais je suis pas d'accord pour dire que le hard work était LXC. C'était tout autant du hard work d'arriver à fédérer une communauté ouverte avec des gros acteurs du domaine, qui s'accorde pour dire : "on fait plus les choses dans notre coin, on utilise docker comme API de containérisation, on parle le même language et on bâti nos outils autour de cette solution car on a une techno simple à utiliser, clairement documenté, avec un processus de décision clair et ouvert.
LXC bien que beaucoup plus vieux que Docker n'a jamais décollé parce que centré sur lui même, de la technique pur mais aucune communication autour ni vraiment de doc (Ubuntu la dessus à rater une belle occasion et maintenant il tente de ce rattraper avec lxd).
Après je pense que la discussion va devenir stérile, on parle de la même chose mais avec une vue différente, tu parle technique, je parle éco-système. Je préfère mille fois une techno "non parfaite" utilisé par tous et avec un processus de qualité (Doc,livraison,roadmap,processus pour participer clairement établie) qu'une techno "parfaite" mais peu utilisé et mal documenté …
Pour toi Mesos et Docker sont complément disjoint et techniquement parlant tu as raison.
Pour moi il forme un tout cohérent et d'un point de vue service j'ai raison.
```
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é ?
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.
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.
[^] # Re: Question à 1 million.
Posté par Tangi Colin . En réponse à la dépêche pkgsrc 2015Q2. Évalué à 2.
Il n'est pas la référence et il n'est pas implémenté partout parce qu'il n'est pas le seul. Par exemple dans l'embarqué, le système de paquet logiciel reconnu et poussé par les industrielles est Yocto (projet de la linux fondation) qui repose sur bitbake et openembedded.
# Retour vers le futur
Posté par Tangi Colin . En réponse au journal Quand le libre est un faux nez pour de la vraie propriété intellectuelle. Évalué à 10.
Tu es étais où les 20 dernières années ? Non parce que redhat fait ça depuis le début. Soit tu paye pour avoir du redhat, soit tu utilise du centos.
Et dire que RedHat c'est pas libre c'est très très fort de café, ils ont fait énormément pour le libre dans de très nombreux domaine, les développeurs ne vivent pas que d'amour et d'eaux fraîches. Je suis pragmatique est je comprend très bien les positions de Mozilla ou de RedHat, protégé son nom n'a rien d'abusif. Faut pas mélanger les torchons et les serviettes. La liberté du code c'est la liberté du code , un point c'est tout.
[^] # Re: Les temps ne changent pas partout
Posté par Tangi Colin . En réponse au journal Les temps changent. Évalué à 9.
Pour C# y a quoi qui te va pas ici : https://github.com/dotnet/roslyn ?
Microsoft change, ouverture de C# avec migration de codeplex vers github, partenaria docker , ouverture de msbuild, compilo LLVM pour .NET Core (https://github.com/dotnet/llilc).
Depuis l'arrivé du dernier CTO y a un vrai virage vers de l'opensource qui a été pris et pas uniquement marketing y a eu de la liberation de code aussi. On peut pas juste dire que c'est du librewashing parce que c'est windows, c'est trop facile.
[^] # Re: Manque l'essentiel
Posté par Tangi Colin . En réponse au journal Essai serveur ARM chez cloud.online.net. Évalué à 1.
Les choses bougent dans se domaine, il y a de plus en plus de board arm qui sont compatible avec un seul kernel (via devicetree). Et y a plusieurs travaux en cours au niveau du développement du kernel. L'un est de rendre le decivetree dynamique (pour gérer les capes à la beaglebone) et un autre qui vise à unifier ACPI et devicetree (par la j'entends avoir une API commune niveau kernel qui dispose d'un backend ACPI pour X86 et devicetree pour ARM ou POWERPC).
http://events.linuxfoundation.org/sites/events/files/slides/unified_properties_API_0.pdf
Après contenant les critères qui feront décolle ARM sur le marché du serveur le prix est un facteur important oui mais l'écosystème n'est pas à négliger non plus. J'ai beau avoir une stack Java (que je peux donc faire tourner sur ARM facilement) j'ai sans doute autour des outils de monitoring, de log, d'agent de déploiement etc… qui ne sont pas forcément disponible sur ARM. Et on va pas demander à un admin sys de faire de la cross compilation.
# YOCTO
Posté par Tangi Colin . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 1.
Yocto (ou pour etre précis bitbake et openembedded) permet déjà de répondre à tout tes problèmes :
Multi-plateformes (x86,arm,powerpc …) et multi-build système (make,autotools,scons,cmake…)
Gestion des dépendances (à la compilation et au runtime)
Multi-fetcher (git,svn,tarball,mercurial …)
Facile à modifier, étendre (patch et via layer)
Système de cache (ne rebuild que ce qu'il faut)
Système de package (rmp, deb ou opkg)
Il peut auto-construire ça propre toolchain
Peut exporté un SDK (Software development Kit)
Honnêtement, l'essayer c'est l'adopter. Y a juste deux bémol :
La taille (on arrive vite à plusieurs Go (entre les sources, le cache)
N'est pas vraiment pensé pour une développement en mode "agile". (Sauf si tu gère la partie fetch toit meme (avec repo android tools par example ) et en utilisant la classe externalsrc).
[^] # Re: De l'openwashing
Posté par Tangi Colin . En réponse au journal Windows éventuellement en open source?. Évalué à 10.
Comment le rappel le journal, ils ont libéré .NET et MSBUILD. Ce n'est pas rien. Ils ont tous mis sur github et non sur codeplex ce qui est aussi un changement de culture important. Donc dire que Microsoft fait de l'openwashing c'est du microsoftbashing .
Effectivement l'OS de microsoft ne va pas etre liberé du jour au lendemain mais je ne pense pas que cette phrase ne soit que du buzz. Y a un vraiment tournant qui a été pris depuis l'arrivé du nouveau CTO.
[^] # Re: C'est pire ailleurs
Posté par Tangi Colin . En réponse au journal L'hypocrisie du refus des « boîtes noires » à l'époque des GAFA. Évalué à 2. Dernière modification le 20 mars 2015 à 18:27.
Pourquoi forcément au pire ?
Google arrive à prédire des épidémies de grippe plusieurs jours avant les systèmes traditionnel de santé vigilance. (https://www.google.org/flutrends/) Je trouve ça intéressant (et dans ce cas les infos peuvent être anonymisé). Tu peux gagner des informations précieuse sans forcément tomber dans la pire dictature.
Tout dépend comment cela est fait, par qui et dans quel but. Le qui étant le plus important (le but et le comment découlant souvent du qui).
Armes et couteaux sont toutes les deux "ni bonnes, ni mauvaise". Dans les deux cas ce ne sont pas les armes ou les couteaux qui tuent mais ce qui s'en servent. Après on fait un calcul de risque par rapport et on estime que le risque d'une arme est plus élevé que le risque d'un couteau et donc on en contrôle leur accès (permis d'arme).
Une arme est estimé plus "dangereuse" qu'un couteau mais ça n'a pas grand chose à voir avec "bon" ou "mauvais". Une arme peut servir à de "bonne chose" (Ou alors faut considérer que toutes les force de l'ordre et les chasseurs comme des pourris).
Qui estime qu'internet fait plutôt le bien ? A part quelques personnes convaincu que c'est la troisième évolution majeur de l'humanité après l'écriture et l'imprimerie, y a malheureusement beaucoup de personne qu'y le voit internet d'un mauvais oeil (Un repaire de pedo-nazi-terroriste-pirate incontrôlé).
[^] # Re: C'est pire ailleurs
Posté par Tangi Colin . En réponse au journal L'hypocrisie du refus des « boîtes noires » à l'époque des GAFA. Évalué à 5.
Les inquisitions sur la technologies ça m'inquiété. Non une technologie n'est ni bonne ni mauvaise. On peut faire des choses géniales avec les big data comme de la surveillance de masse. Le problème n'est pas les big data mais à ce qu'on en fait. Sinon on fait juste plus rien, toute technologie peut etre utilisé à de mauvaise fin. Si j'écrase la tête de quelqu'un on fait quoi ? On interdit tout les marteaux même pour leur usages légitime de planter des clous ?
[^] # Re: Conclusion un peu hative
Posté par Tangi Colin . En réponse au journal Docker, la plateforme à la mode. Évalué à 2.
Aucun soucis pour ma part, je me suis pas sentis vexé par tes réactions et ça a été un plaisir de confronter nos point de vue.
[^] # Re: Conclusion un peu hative
Posté par Tangi Colin . En réponse au journal Docker, la plateforme à la mode. Évalué à 6.
Le rapport entre Docker et ZooKeeper ou etcd ? L'éco-système, docker est la brique de base qui te permet de faire de l'isolation mais dès que tu veux faire du déploiement multi machine tu as d'autre besoin que juste l'isolation tels que le load balancing, la haute dispo, la découverte automatique de service etc… Et ça Mesos peut l'apporter. Mais le coeur de Mesos repose sur l'algo à consensus Zookeeper qui n'est pas celui choisi par d'autre projet gravitant autour de Docker. Kubernetes de google utilise etcd et coreOS aussi. Y a un port en cours pour intégrer Kubernetes avec Mesos. Et avoir zookeeper et etcd en parallèle c'est un peu bancal comme architecture. Donc y a un travail en cours pour avoir un backend etcd à Mesos. Y a aussi un travail en cours pour intégrer l'api de Docker Swarm.
Et pour faire tourner du Hadoop, Spark et Storm sur le meme cluster tu as besoin d'isolation, avant Mesos proposait sa propre implémentation (toujours à base de cgroups) mais depuis la version 0.20 docker est devenue une brique "1st citizen". Il se repose dessus pour fournir leur isolation. L'ancienne implémentation reste disponible, tout ceci est configurable a travers la ligne de commande qui lance le mesos-slave. Mais meme si tu fait tourner du Storm et du Spark tu as tout de meme besoin d'isolation entre ses framework et tu peux utiliser docker comme conteneur.
Docker n'est pas un framework Mesos de plus, c'est pas au même niveau dans la "stack Mesos", tu as tout en haut les frameworks (Storm,Hadoop,ElasticSearch,Jenkins,MPI,Aurora,Marathon…) et en bas, au niveau des executeurs, (sur les slave mesos) tu as le conteneur (soit l'implémentation mesos de base, soit depuis la 0.20 docker). Donc je me permet d'insister, au vue de développement en cours (le jira mesos est public), il y de plus en plus de développement qui sont fait pour s'intégrer avec l'eco-système Docker (Docker Swarm,Kubernete,support etcd) et Docker est maintenant une brique de base de la stack Mesos (Elle n'est pas irremplaçable puisque l'ancienne implémentation reste disponible mais c'est tout de même une brique de base).
Concernant LXC, oui Docker était une surcouche à LXC et ils ont implémenté libcontaineur parce qu'il en avait marre de gérer les api breaks et les X versions différentes de LXC. J'ai la flemme de me replonger dans les mailings list docker mais ça transpire même dans l'annonce officiel :
http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
Au passage pour ne pas opposé docker et LXC, la libcontainer dispose de plusieurs backend (celui par défaut en go) mais rien ne t’empêche d'utiliser LXC ou LMCTFY de google etc…
Mais si tu me relis tu verra que je dis que Docker n'apporte pas grand chose technologiquement parlant mais je suis pas d'accord pour dire que le hard work était LXC. C'était tout autant du hard work d'arriver à fédérer une communauté ouverte avec des gros acteurs du domaine, qui s'accorde pour dire : "on fait plus les choses dans notre coin, on utilise docker comme API de containérisation, on parle le même language et on bâti nos outils autour de cette solution car on a une techno simple à utiliser, clairement documenté, avec un processus de décision clair et ouvert.
LXC bien que beaucoup plus vieux que Docker n'a jamais décollé parce que centré sur lui même, de la technique pur mais aucune communication autour ni vraiment de doc (Ubuntu la dessus à rater une belle occasion et maintenant il tente de ce rattraper avec lxd).
Après je pense que la discussion va devenir stérile, on parle de la même chose mais avec une vue différente, tu parle technique, je parle éco-système. Je préfère mille fois une techno "non parfaite" utilisé par tous et avec un processus de qualité (Doc,livraison,roadmap,processus pour participer clairement établie) qu'une techno "parfaite" mais peu utilisé et mal documenté …
Pour toi Mesos et Docker sont complément disjoint et techniquement parlant tu as raison.
Pour moi il forme un tout cohérent et d'un point de vue service j'ai raison.
```
[^] # Re: Conclusion un peu hative
Posté par Tangi Colin . En réponse au journal Docker, la plateforme à la mode. Évalué à 2.
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 …).
[^] # Re: Conclusion un peu hative
Posté par Tangi Colin . En réponse au journal Docker, la plateforme à la mode. Évalué à 1.
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).
[^] # Re: Conclusion un peu hative
Posté par Tangi Colin . En réponse au journal Docker, la plateforme à la mode. Évalué à 4.
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é ?
[^] # Re: Pas compris !
Posté par Tangi Colin . En réponse au journal VMWare poursuivi pour non-respect de la GPL. Évalué à 4.
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.
[^] # Re: SELinux & autres LSM ?
Posté par Tangi Colin . En réponse à la dépêche Un peu plus de sécurité sous Linux. Évalué à 4.
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 ?
# Mon avis à 2 cents sur le go template
Posté par Tangi Colin . En réponse à la dépêche Découvrez le langage Go et Camlistore le 24 mars 2015 à Grenoble. Évalué à 2.
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.
# Initiative intéressante
Posté par Tangi Colin . En réponse à la dépêche Gitlab achète Gitorious. Évalué à 2.
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é.
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par Tangi Colin . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 7.
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.
# Azure est en forte croissance mais reste toujours faible en part de marché
Posté par Tangi Colin . En réponse au journal Redhat, la grande perdante de la virtualisation Microsoft Azure ?. Évalué à 2.
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).
[^] # Re: Par rapport à LXC
Posté par Tangi Colin . En réponse au journal Migration d'une infra lamp vers docker. Évalué à 1.
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.
# Pourquoi toujours le cas du mail ?
Posté par Tangi Colin . En réponse au journal Auto-hébergement: pas toujours évident.... Évalué à 10. Dernière modification le 05 février 2015 à 18:06.
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.
[^] # Re: Python c'est mieux maintenant
Posté par Tangi Colin . En réponse au journal Je n'aime pas le code moderne. Évalué à 4.
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.
[^] # Re: Organisation
Posté par Tangi Colin . En réponse au journal SécurityDay à Lille seconde édition. Évalué à 1.
pour ce qui n'avait pas la chance d'etre sur place, on peut voir les "slides" des présentations quelque part ?
[^] # Re: Conteneur léger tel que Docker
Posté par Tangi Colin . En réponse au journal Comment faire une sandbox de mon système de fichier ?. Évalué à 6. Dernière modification le 06 janvier 2015 à 21:16.
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 - scratchtu 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.
# Conteneur léger tel que Docker
Posté par Tangi Colin . En réponse au journal Comment faire une sandbox de mon système de fichier ?. Évalué à 5. Dernière modification le 06 janvier 2015 à 17:04.
Docker peut répondre à ta problématique.