Docker, présenté ici même en mars dernier, est un conteneur ou isolateur, ou encore système de cloisonnement (plus de détails en seconde partie). Il se repose sur des systèmes comme LXC, les namespaces et les cgroups (control groups) de Linux, qui permettent de limiter et isoler l'utilisation des ressources de type processeur, mémoire, disque, etc. Docker se compare aux BSD Jails et aux zones de Solaris. Il est développé en Go, sous licence Apache 2.0, tout ce qu'il y a de plus libre.
La première version de Docker date du 20 mars 2013. 16 mois plus tard, 9,308 commits de 509 contributeurs, 2.75 million de téléchargements, plus de 14,000 applications “Dockerisées”, c'est la version 1.1.0. qui est livrée. La folie Docker s'est emparée d'Internet tout entier !
Sommaire
- Petite introduction
- Changements entre la version 0.11 et 1.0
- Changements entre la version 1.0 et 1.1.0
- Packaging
- boot2docker pour Mac OS X et Windows
- Annonces de la #dockercon
- La folie Docker
-
Entretien avec Jérôme Petazzoni
- Peux-tu nous parler de ton parcours ?
- Tu fais quoi chez Docker ?
- Vous êtes combien d'employés chez Docker maintenant ? Et contributeurs ?
- Comment est-ce que vous arrivez à gérer un tel afflux de contributions ? (presque 2000 forks sur github)
- Pourquoi Go ? D'ailleurs, vous seriez pas le projet le plus important écrit dans ce langage ?
- Comment Docker s'articule-t-il avec LXC (Linux Containers) ?
- Comment Docker se compare-t-il par rapport aux BSD Jails, zones de Solaris, OpenVZ Virtuozzo, et Linux-VServer ?
- On voit tous les jours des nouveaux projets démarrer, mais Docker a eu un succès rarement vu dans le monde du logiciel libre. C'est quoi la recette de cette réussite ?
- Ta fonctionnalité préférée de Docker ?
- Les nouveautés à venir dans les prochaines versions de docker (identity, authentification…) ?
- Le fondateur (le français Solomon Hykes, Epitech 2006) a recruté un PDG, pris la fonction de CTO et reste actif sur https://github.com/shykes. En France, il aurait pris la fonction de PDG. Est-ce typique des US ?
- Tu peux nous expliquer et nous en dire plus sur l'exploit présent dans la version 0.11 ?
Petite introduction
Les conteneurs ou isolateurs, ou encore systèmes de cloisonnement permettent de faire tourner plusieurs environnements de systèmes d'exploitation sur une seule et même machine physique. Ce type de logiciel se compare avantageusement aux hyperviseurs, virtualisateurs et émulateurs, par le fait que le seul noyau qui tourne est celui de la machine physique, et il n'y a pas de couche de « virtualisation ».
Isolateur :
Émulateur :
Benchmarks :
- KVM and Docker LXC Benchmarking with OpenStack et la vidéo associée de Boden Russell (IBM) Performance Characteristics of VMs vs Docker Containers by Boden Russel (IBM)
- Preview of Docker Benchmarking at Flux7
Changements entre la version 0.11 et 1.0
Construire pour les développeurs
- Une nouvelle instruction de Docker build est apparue, COPY, qui copie les fichiers et dossiers en l'état depuis le build context;
- Améliorations autour de l'instruction ADD, et les volumes conservent le propriétaire et les permissions des fichiers pendant le build des images.
Outiller pour les admins sys
- Docker a désormais la capacité de mettre en pause et redémarrer des conteneurs, permettant aux utilisateurs de récupérer des ressources CPU pour une gestion plus fine de celles-ci.
- Mise à jour du profil de sécurité pour l'accès aux périphériques et des capacités pour les conteneurs.
- Au niveau du stockage: amélioration du backend DeviceMapper, prise en charge de XFS, gestion des périphériques physiques et amélioration des performances de la suppression d'un conteneur.
- L'IANA réserve les ports 2375 et 2376 respectivement pour le trafic HTTP et HTTPS de l'API Docker.
En plus de la correction de 40 bugs et l'amélioration de la cohérence de l'API, la documentation a été entièrement ré-écrite.
Pour les plus intéressés :
Changements entre la version 1.0 et 1.1.0
Très attendue, la nouvelle fonctionnalité .dockerignore
Vous pouvez ajouter un fichier .dockerignore à côté de votre Dockerfile ; dans ce cas, Docker va ignorer les fichiers et répertoires indiqués dans ce fichier quand il enverra le "build context" au démon.
Exemple: https://github.com/dotcloud/docker/blob/master/.dockerignore
Mettre en pause des conteneurs pendant le commit
Auparavant, faire un commit sur un conteneur actif n'était pas recommandé, à cause du risque de fichiers dans un état corrompu (par exemple, si ces fichiers étaient en cours d'écriture pendant le commit).
Les conteneurs sont maintenant mis en pause quand un commit est lancé.
Vous pouvez invalider cette fonctionnalité avec docker commit --pause=false <container_id>..
Voir la fin des logs
Vous pouvez maintenant consulter la fin des logs d'un conteneur. Par exemple, pour avoir les dix dernières lignes d'un log, avec la commande docker logs --tail 10 . Vous pouvez aussi suivre en temps réel les logs d'un conteneur sans être obligé de lire le fichier complet avec docker logs --tail 0 -f <container_id>.
Un fichier tar peut être passé en tant que contexte pour docker build
Vous pouvez donner une archive tar à docker build en tant que contexte. Cela peut être utilisé pour automatiser les docker builds, par exemple : cat context.tar | docker build - ou docker run builder_image | docker build -
Monter/binder votre système de fichiers complet dans un conteneur
/ est maintenant autorisé en tant que source de --volumes. Cela signifie que vous pouvez binder/monter votre système de fichier complet dans un conteneur, si besoin. Par exemple : docker run -v /:/my_host ubuntu:ro ls /my_host
Cependant il est maintenant interdit de monter vers /.
Autres améliorations et changements
L'allocation de port (utilisez la commande docker port pour voir le mapping) a été améliorée. Dans la version précédente, parfois Docker vous empêchait de démarrer un conteneur avec des ports précédemment alloués, que Docker croyait à tort encore alloués. Cela a été corrigé.
Un bug dans la commande docker save était apparu dans la dernière version. La commande docker save créait parfois des images avec des métadatas invalides. La commande crée maintenant des images avec des métadatas correctes.
La commande docker inspect lancée dans un conteneur affiche maintenant les conteneurs liés à ce conteneur.
Le flag de docker commit a amélioré sa validation, pour vous empêcher de commiter une image avec un nom comme -m. Les noms des images contenant des tirets peuvent entrer en conflit avec les flags de la ligne de commande.
L'API a maintenant des codes de retour améliorés pour start et stop. Essayer de démarrer un conteneur déjà démarré renvoie maintenant une erreur 304.
La performance a été globalement améliorée. Le démarrage d'un démon est plus rapide que dans les versions précédentes. La performance du démon a aussi été améliorée quand il gère un grand nombre d'images et de conteneurs.
Un problème avec les espaces et les multi-lignes dans les Dockerfiles a été corrigé.
Le flag de docker commit a amélioré sa validation, pour vous empêcher de commiter une image avec un nom comme -m. Les noms des images contenant des tirets peuvent entrer en conflit avec les flags de la ligne de commande.
L'API a maintenant des codes de retour améliorés pour start et stop. Essayer de démarrer un conteneur déjà démarré renvoie maintenant une erreur 304.
La performance a été globalement améliorée. Le démarrage d'un démon est plus rapide que dans les versions précédentes. La performance du démon a aussi été améliorée quand il gère un grand nombre d'images et de conteneurs.
Un problème avec les espaces et les multi-lignes dans les Dockerfiles a été corrigé.
Packaging
La version 1.0 est déjà disponible dans Debian Sid/Unstable.
boot2docker pour Mac OS X et Windows
boot2docker est une distribution Linux très légère, basée sur Tiny Core Linux, et créée spécifiquement pour lancer des conteneurs Docker. Elle fonctionne complètement en RAM, pèse ~27MB et boote en moins de 5s (YMMV).
boot2docker s'installe sous Windows et sous OSX.
Annonces de la #dockercon
La version 1.0 a été annoncée à l'occasion de la toute première dockercon.
Pour une première édition, elle a réuni 600 personnes (avec 400 sur liste d'attente !), ce qui peut être considéré comme un beau succès marketing.
Cette conférence a notamment été l'occasion pour l'équipe Docker d'annoncer 3 bibliothèques :
libcontainer
Libcontainer permet aux conteneurs de travailler avec les espaces de noms Linux, les control groups, les capabilities, les profils de sécurité APPArmor, les interfaces réseaux et les règles de pare-feu d'une manière cohérente et prédictible.
Dans ce cas, les conteneurs ne s'appuient plus sur des composants de l'espace utilisateur Linux comme LXC, libvirt, ou systemd-nspawn. Docker déclare : « Cela réduit fortement le nombre de parties mouvantes et protège Docker des effets de bord introduits par les versions et distributions de LXC ».
libswarm
Décrit comme « une boite à outils pour créer des services réseaux », l'objet de libswarm est de simplifier les déploiements d'applications Docker dans des configurations multi-nœuds, les nœuds pouvant tourner sur des distributions Linux différentes..
Swarm (nom/verbe) signifie essaim ou essaimer.
Cela permettra en retour de faciliter l'adoption de Docker en entreprise pour les déploiements d'applications sans devoir choisir une plateforme de clustering. Solomon Hykes, fondateur de Docker et développeur de libswarm déclare dans un entretien récent avec Phil Whelan d'ActiveState: "Je ne crois pas qu'il devrait y avoir une seule plateforme de clustering dominante que tout le monde utiliserait".
Démo venant de Dockercon sur youtube :/
libchan
Libchan est une bibliothèque réseau ultra-légère qui permet aux services réseaux de communiquer de la même manière que les goroutines communiquent en utilisant des canaux :
- Simple message passing
- Synchronisation pour la programmation parallèle
- Nesting : les canaux peuvent envoyer (vers) des canaux
- Libchan gère les options de transport suivantes :
- In-memory Go channel
- Unix socket
- Raw TCP
- TLS
- HTTP2/SPDY
- Websocket
Voir cette discussion sur libchan avec le créateur de Docker (shykes pour Solomon Hykes)
Des spécifications sont précisées.
La folie Docker
Docker est super « à la mode » ! En 15 mois, à peine, et parti de quasiment rien, il devient un logiciel majeur dont tout le mode parle, même le PDG de Microsoft, Satya Nadella, qui a tweeté ce lien sur l'utilisation de Docker dans le cloud Azure de Microsoft !
Entretien avec Jérôme Petazzoni
Peux-tu nous parler de ton parcours ?
Jérôme Petazzoni : j'ai eu un bac S en 1996. Après deux ans de prépa (Maths Sup' et Spé) où j'ai fait trop peu d'informatique à mon goût, je suis parti décrocher un Master d'informatique à l'Université de Marne-la-Vallée (qui depuis s'appelle "Paris Est"). Ensuite, j'ai fait un peu de tout, tant que ça touchait de près ou de loin à Linux ou l'Open Source ; avec une grosse préférence pour les projets d'infrastructure. Je ne vais pas copier-coller mon CV, je pense que ça ennuierait tout le monde. Mais une expérience importante pour la suite, ça a été de découvrir Xen en 2004. L'année suivante, je m'associe avec un ami pour monter Enix et miser à fond sur l'hébergement de VM.
C'est peu après cette époque que je rencontre Solomon, co-founder de dotCloud (l'ancien nom de Docker). Il avait besoin de serveurs, on en avait ; on cherchait une solution de déploiement, c'était justement ce sur quoi travaillait dotCloud : nous étions faits pour nous entendre. C'est comme ça qu'en 2010, il m'a proposé de le rejoindre à San Francisco pour s'occuper de l'infrastructure et des "ops" pour dotCloud, qui venait de déménager pour la Californie.
Tu fais quoi chez Docker ?
Jérôme Petazzoni : plein de choses ! Avant de lancer Docker, nous avons développé et opéré un PAAS (dotCloud, concurrent d'Heroku). Il existe encore et je fais partie de l'équipe qui s'en occupe.
Mais j'aide aussi régulièrement les "core maintainers" (qui travaillent à plein temps sur Docker) ainsi que ceux qui développent les produits SAAS que nous offrons autour de Docker. Tu es victime d'un bug kernel mystique qui fait rebooter ta machine quand tu démarres un conteneur orienté vers l'Ouest ? Ta partition BTRFS prétend être pleine alors que "df" indique le contraire ? Tes règles iptables repeignent en rouge le trafic multicast qui sort de tes conteneurs ? Je peux t'aider !
En parallèle, je fais beaucoup d' "évangélisme", en l'occurrence sous forme de présentations dans diverses conférences (LinuxCon, OSCON…) et dans d'innombrables meet-ups locaux afin de faire connaître Docker, rencontrer nos utilisateurs, et discuter avec eux de leurs besoins et leurs attentes vis-à-vis du projet.
Vous êtes combien d'employés chez Docker maintenant ? Et contributeurs ?
Jérôme Petazzoni : on est une quarantaine d'employés, mais je serais incapable de donner un chiffre précis, car on recrute sans arrêt ! 5 personnes travaillent à plein temps sur le "Docker Engine" (la partie Open Source), mais quasiment toute l'équipe a contribué à un moment ou à un autre, que ça soit une petite feature, un bug fix, de la documentation … Mais l'essentiel du développement est maintenant entre les mains de la communauté, avec plus de 500 contributeurs au total. Il arrive assez souvent que la "core team" ne fasse que de la revue de code des jours durant, pour gérer toutes les contributions que l'on reçoit.
Comment est-ce que vous arrivez à gérer un tel afflux de contributions ? (presque 2000 forks sur github)
Jérôme Petazzoni : tout d'abord, il y a un processus très clair. Le fichier CONTRIBUTING à la racine du dépôt du projet définit tout dans les détails. Pour simplifier, toutes les contributions passent par une "pull request" sur GitHub. Le code et la documentation doivent suivre certaines règles très strictes. Chaque partie du dépôt est gérée par des mainteneurs. Pour qu'une modification soit acceptée (qu'il s'agisse d'une contribution externe ou interne à Docker Inc.!), elle doit être validée par la majorité absolue des mainteneurs concernés. Si seule la documentation change, seuls les mainteneurs de la documentation sont impliqués ; si c'est la gestion du réseau, ça sera d'autres personnes, et ainsi de suite. Si une modification concerne plusieurs sections, il faut l'accord de tout le monde.
Détail intéressant : il y a plus de 20 mainteneurs à ce jour, et moins de la moitié sont employés par Docker Inc. ; ça montre que, le projet est bel et bien entre les mains de la communauté. D'ailleurs, on recherche en permanence de nouveaux mainteneurs pour aider à traiter ce flot de contributions. À bon entendeur …
Comme il y a souvent plus de 100 pull requests ouvertes à un instant donné, nous avons développé un outil en ligne de commande pour faciliter le processus ; par exemple, pour permettre à un mainteneur d'identifier les pull requests le concernant, et tout particulièrement celles ayant déjà reçu l'approbation d'autres mainteneurs (et donc proches d'être intégrées). Cet outil s'appelle Gordon (c'est aussi le nom de la tortue qui vit dans nos bureaux à San Francisco !), il est Open Source, et disponible sur https://github.com/dotcloud/gordon. Il utilise l'API GitHub ; autrement dit, il est utilisable pour d'autres projets souhaitant implémenter un processus similaire.
Pourquoi Go ? D'ailleurs, vous seriez pas le projet le plus important écrit dans ce langage ?
Jérôme Petazzoni : il y a des raisons techniques et non techniques. Sur le plan technique, Go gère nativement l'exécution concurrente, grâce aux goroutines (ça ressemble aux greenlets), tout en étant plus facile d'apprentissage que, par exemple, Erlang ou Haskell. De plus, par défaut, un programme Go se compile en un binaire massif embarquant presque toutes les bibliothèques nécessaires à son exécution. Cela veut dire que pour faire tourner un programme Go, il suffit de télécharger le binaire, l'exécuter, et ça marche. Pas besoin de yum/apt/emerge/pacman des bibliothèques supplémentaires, ou même d'exécuter un script d'installation. Cette caractéristique était très importante au début du projet, afin d'encourager les gens à le tester le plus simplement possible.
Sur le plan non technique, Go, c'est un peu la Suisse des langages modernes. Si on avait choisi Python, la communauté Ruby aurait grogné. Si on avait choisi Ruby, la communauté Python aurait grogné (et on serait probablement passés pour des imbéciles, car au début du projet, la majorité de l'équipe était plus à l'aise en Python qu'en Ruby). Si on avait choisi Java, tout le monde aurait râlé ! Plus sérieusement, Go était un moyen de ne pas choisir de camp. Bien sûr, c'était un pari risqué, surtout à l'époque ; mais même si la communauté Go est beaucoup plus restreinte, elle s'est avérée être très pointue dans les domaines qui nous intéressaient. Au final, même si c'est évidemment plus difficile de recruter des développeurs Go (plutôt que Python, Ruby ou Java), ceux qu'on trouve ont plus souvent le profil que l'on recherche.
Sommes-nous le projet le plus important en Go? Euh, c'est quoi, un projet important? Si on en croit les métriques de GitHub (forks, stars, contributeurs, activité…), oui, très probablement ! Mais il y a peut-être des projets encore plus gros dans les labos secrets de Google ou autre. Disons que c'est probablement le plus visible des projets Open Source écrits en Go!
Comment Docker s'articule-t-il avec LXC (Linux Containers) ?
Jérôme Petazzoni : Docker a parfois été décrit comme une surcouche de LXC. D'un point de vue strictement technique, c'était vrai au début, puisque Docker exécutait "lxc-start" pour lancer les conteneurs.
Cependant, depuis la version 0.9, Docker a ajouté un autre moteur d'exécution natif, basé sur libcontainer. Libcontainer est une bibliothèque Go, permettant de faire le travail de LXC, c'est-à-dire la gestion des namespaces et des control groups (les mécanismes du noyau Linux qui composent les conteneurs). Cette bibliothèque est réutilisable en dehors de Docker si nécessaire. Sous le capot, elle fonctionne exactement comme LXC et utilise les mêmes appels système. Mais elle est utilisée par défaut et, par conséquent, il n'est plus nécessaire d'installer les paquetages LXC pour faire tourner Docker. Ça simplifie l'installation.
Ensuite, par rapport à LXC, Docker offre une tonne d'autres fonctionnalités : une API REST, un système permettant de transférer des images depuis et vers une registry, le build avec les Dockerfiles … Aujourd'hui, Docker est une surcouche de LXC tout comme apt et yum sont des surcouches de tar, cpio, et wget !
Comment Docker se compare-t-il par rapport aux BSD Jails, zones de Solaris, OpenVZ Virtuozzo, et Linux-VServer ?
Jérôme Petazzoni : ces projets se comparent à LXC plutôt qu'à Docker. Docker ne va pas les remplacer, mais plutôt s'intégrer avec eux.
Parallels (la société qui développe OpenVZ) a annoncé qu'elle allait contribuer à libcontainer. Il est donc possible que Docker puisse prochainement lancer des VE OpenVZ. VServer, c'est nettement moins certain (et il y a certainement beaucoup moins de gens qui s'en servent encore).
Il est possible de porter Docker sur FreeBSD et Solaris. Beaucoup de fonctionalités doivent être adaptées : non seulement le moteur d'exécution, mais aussi la couche réseau (il faut adapter le système actuel, qui utilise iptables et un pont Ethernet) et le stockage (BTRFS, AUFS et DeviceMapper n'existent pas et seraient vraisemblablement remplacés par ZFS pour le système de copy-on-write).
On voit tous les jours des nouveaux projets démarrer, mais Docker a eu un succès rarement vu dans le monde du logiciel libre. C'est quoi la recette de cette réussite ?
Jérôme Petazzoni : un énorme coup de bol ! Être au bon endroit, au bon moment, avec la bonne techno et la bonne équipe. En 2008, dotCloud (avant d'être un PAAS) ressemblait énormément au Docker actuel. Mais il manquait plein de choses pour réussir : il fallait des noyaux spéciaux (avec, entre autres, OpenVZ et AUFS), la création d'images était beaucoup plus lourde … L'outil était génial, mais seulement pour des sysadmins très pointus et très motivés. Ça a servi de base pour construire le PAAS dotCloud.
Quelques millions de conteneurs plus tard, on avait acquis une solide expérience dans ce domaine ; cette expérience nous a permis d'aller très vite dans le développement de Docker. Le fait d'être à San Francisco a aussi contribué au décollage rapide, car on côtoyait sans cesse des gens construisant des grosses architectures distribuées, qui ont vu immédiatement le potentiel de Docker et nous ont énormément encouragés. Les conteneurs sont très adaptés, par exemple, aux micro-services.
Enfin, si on regarde en détail les fonctionalités bas niveau du noyau sur lesquelles reposent Docker (et les conteneurs en général), elles n'étaient pas aussi stables il y a ne serait-ce que deux ans (et encore aujourd'hui, elles continuent de s'améliorer sans cesse).
Ta fonctionnalité préférée de Docker ?
Jérôme Petazzoni : je vais dire une des rares que j'ai implémentées, le privileged mode ! Techniquement, rien de sorcier : c'est juste une option permettant de lancer un conteneur sans limiter ses droits d'accès. Il peut tout faire, y compris casser complètement la machine sur laquelle il tourne (comme l'utilisateur root). Mais grâce à ça, il y a plein de choses qu'on peut faire tourner dans Docker (et qu'on ne pouvait pas avant) : OpenVPN, Xorg, KVM, et même Docker lui-même (très utile pour l'intégration continue et le développement du projet).
Grâce à ça, on peut piquer le slogan de NetBSD, et dire "of course it runs in a container" :-)
Les nouveautés à venir dans les prochaines versions de docker (identity, authentification…) ?
Jérôme Petazzoni : d'un point de vue "devops", ce qui est le plus prometteur, c'est à mon avis libswarm. Libswarm permet d'interfacer ensemble des clients Docker (CLI ou utilisant directement l'API), des hôtes Docker (faisant tourner des conteneurs), et des ordonnanceurs de ressources (comme Mesos par exemple). Le but est de pouvoir dire "je veux 4 conteneurs basés sur l'image webfront42, chacun sur une machine différente, mais dans le même datacenter que mon conteneur dbfront69", et que le système choisisse tout seul où les placer en fonction des ressources (mémoire, CPU…) disponibles à un instant donné. Il y a ensuite une infinité de variantes sur ce thème : pouvoir relancer les conteneurs lorsqu'une machine est indisponible ; lancer automatiquement de nouvelles machines (si on est sur un IAAS) lorsqu'on manque de capacité ; s'interfacer correctement avec des load balancers ; etc.
Bien sûr, il va aussi y avoir plein d'améliorations pour une clientèle "enterprise" : signature des images pour en assurer la provenance ; analyse des graphes de dépendances entre images pour déterminer celles affectées par une vulnérabilité ; possibilité d'héberger en interne les services du "Docker Hub" …
Le fondateur (le français Solomon Hykes, Epitech 2006) a recruté un PDG, pris la fonction de CTO et reste actif sur https://github.com/shykes. En France, il aurait pris la fonction de PDG. Est-ce typique des US ?
Jérôme Petazzoni : aucune idée !
Tu peux nous expliquer et nous en dire plus sur l'exploit présent dans la version 0.11 ?
Jérôme Petazzoni : cette attaque utilise un appel système particulier, open_by_handle_at(). Cet appel système permet d'ouvrir un fichier en spécifiant non pas son chemin, mais un identifiant opaque. Cet identifiant opaque est normalement obtenu en utilisant un autre appel système, name_to_handle(). Le but est de faciliter l'implémentation de serveurs de fichiers en userspace (par exemple NFS ou 9P). Cette partie est expliquée dans cet article sur LWN.
Il se trouve que l'identifiant opaque en question est, dans la plupart des cas, l'inode du fichier. Il se trouve aussi que dans la plupart des systèmes de fichiers (incluant EXT2/3/4), l'inode de la racine est toujours 2. Il est alors enfantin d'utiliser open_by_handle_at() pour accéder à la racine du système de fichiers sur lequel se trouve un conteneur.
open_by_handle_at() est contrôlé par une capability, CAP_DAC_READ_SEARCH. Le problème, c'est que jusque Docker 0.11, au lieu d'enlever toutes les capabilities pour ne laisser que celles qui sont inoffensives, Docker enlevait celles qui étaient dangereuses pour laisser toutes les autres. Bilan, quand CAP_DAC_READ_SEARCH a été ajouté au noyau, on a oublié de le mettre dans la liste des permissions dangereuses.
« Mais pourquoi vous avez fait un truc pareil ? Tout le monde sait que la sécurité, ça marche pas comme ça ! Faut tout enlever, et donner uniquement les permissions nécessaires ! » Absolument. C'est un héritage des anciennes versions de LXC, dans lesquelles on ne pouvait spécifier que lxc.cap.drop. Les versions plus récentes permettent de spécifier à la place lxc.cap.keep, mais par souci de compatibilité avec les anciennes versions, on utilisait encore lxc.cap.drop. C'est d'ailleurs une des raisons qui nous ont poussé à développer libcontainer : gérer toutes les versions différentes de LXC devenait difficile.
Détail intéressant : l'exploit ne fonctionne a priori pas si vous utilisez BTRFS (car, au moins sur mes machines, le numéro d'inode de la racine n'est pas 2) ou si /var/lib/docker est sur un autre système de fichiers (l'exploit permet alors tout de même de sauter d'un conteneur à l'autre, en étant un peu créatif).
Enfin, nous avons toujours été assez clairs sur le fait qu'il fallait être prudent lorsqu'on fait tourner des processus en "root" dans des conteneurs ; en particulier du code arbitraire. Notre position est simple : les conteneurs seront un jour aussi fiables que les VM, mais ce jour n'est pas encore arrivé ; et en attendant, il faut utiliser des couches de sécurité additionnelles et/ou limiter le champ d'application des conteneurs. La bonne nouvelle, c'est que 99% des applications n'ont pas besoin des droits "root". Les conteneurs sont donc déjà tout à fait utilisables !
Aller plus loin
- Code source de Docker (sur GitHub) (329 clics)
- docker.io (530 clics)
- Petit tutoriel en ligne (970 clics)
- It’s Here: Docker 1.0 (121 clics)
- Présentation de Docker sur LinuxFr.org (1909 clics)
- Tutoriel sur LinuxFr.org pour manipuler les conteneurs Dockers (1582 clics)
- Sur LinuxFr.org, les logiciels pour survivre avec Docker (1020 clics)
- Announcing Docker 1.1.0 (100 clics)
# Fondateur qui recrute un CEO et devient CTO
Posté par Maclag . Évalué à 10.
Ce n'est pas typique des US. C'est juste atypique, mais je connais au moins une autre startup où le fondateur a décidé après quelques années de recruter un CEO pour le remplacer et prendre une autre fonction.
Ça ne l'empêche pas de rester au conseil d'administration, mais la logique c'est que quand une entreprise sort de l'état de startup, le métier de PDG/CEO change significativement également, et soit ce n'est pas un métier qui intéresse le fondateur, soit il pense que quelqu'un de plus expérimenté à ce poste critique sera profitable à la boite (et donc à lui, parce que le fondateur a quand même un gros intérêt personnel à ce que ça marche!!).
[^] # Re: Fondateur qui recrute un CEO et devient CTO
Posté par palm123 (site web personnel) . Évalué à 8.
La première fois que j'ai vu cette approche, c'est en lisant le livre du type qui a développé ce qui s'appelait Vermeer Technologies et l'a revendu à Microsoft, qui l'a rebaptisé FrontPage.
http://www.amazon.fr/High-Stakes-No-Prisoners-Internet/dp/0812931432
Sinon j'aime beaucoup la réponse de Jérôme à la question
Humilité et lucidité.
ウィズコロナ
[^] # Re: Fondateur qui recrute un CEO et devient CTO
Posté par Philippe F (site web personnel) . Évalué à 2.
C'est pas si atypique que ça. Je bosse dans une PME où c'est ce qui vient d'arriver. Après, ne pas être CEO ne veut pas dire qu'il ne dirige pas l'entreprise, il y a des échanges constants. Par contre, il y a un focus plus technique que opérationnel.
Il me semble que c'est aussi ce qu'a fait Steve Jobs chez Apple, faire venir une pointure en CEO. Lequel a fini par dégager Jobs !
[^] # Re: Fondateur qui recrute un CEO et devient CTO
Posté par claudex . Évalué à 4.
C'était la même chose chez Google (avant qu'un des fondateurs revienne au poste).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Fondateur qui recrute un CEO et devient CTO
Posté par cosmocat . Évalué à 2.
Dans ce très bon article sur larry page et Google de Business insider, on y apprend que c'est le conseil d'administration qui a fait venir Schmidt alors que Larry Page était contre. Donc plutôt même effet, mais cause assez différente…
[^] # Re: Fondateur qui recrute un CEO et devient CTO
Posté par Nico C. . Évalué à 4.
+1
Dans la plupart des startups montées par de jeunots, ce sont pas eux qui decident reellement de mettre un "vrai" CEO a leur place, ce sont avant tout les business angels qui vont aligner les millions mais qui ne veulent pas d'un morveux inexperimenté pour gerer la boite.
Et au final, tout le monde est content : le morveux se concentre sur ce qui lui plait et en meme temps il monte en competence sur la gestion si ca l'interesse et les financiers ont un gars experimenté en qui ils ont confiance et qui saura tenir les cordons de la bourse.
Ca n'empeche pas les desastres mais ca les evite serieusement. Dans tous les cas, c'est vraiment un systeme intelligent est pragmatique.
Google n'aurait jamais ete le monstre que c'est aujourd'hui sans ce "chapeautage". Et moult autres startups ont demarré ou sont encore dans ce mode (Apple a aussi connu ca)
[^] # Re: Fondateur qui recrute un CEO et devient CTO
Posté par Misc (site web personnel) . Évalué à 2.
Tu parles de Canonical ?
# Salut cousin :-)
Posté par Thomas Petazzoni (site web personnel) . Évalué à 7.
Tout est dans le titre.
[^] # Re: Salut cousin :-)
Posté par lerouxrv . Évalué à 3.
Salut la famille Petazzoni, tout le monde va bien ?
[^] # Re: Salut cousin :-)
Posté par Romuald Delavergne . Évalué à 0.
Et Maxime du même nom, c'est de la famille ?
[^] # Re: Salut cousin :-)
Posté par Thomas Petazzoni (site web personnel) . Évalué à 1.
Oui, c'est mon frère.
# boot2docker
Posté par palm123 (site web personnel) . Évalué à 3.
On dirait que docker "prend", Solomon Hykes vient d'annoncer (via twitter) plus d'un demi million de téléchargement de boot2docker, lequel site sort sa version 1.1.1
Sven Dowideit @SvenDowideit 7 h
Last night I released #boot2docker 1.1.1 - Lots of small fixes that should make the #windows and #osx more seamless. http://boot2docker.io
J'aime bien la doc pour faire sa propre iso de boot2docker
https://github.com/boot2docker/boot2docker/blob/master/doc/BUILD.md
ウィズコロナ
# Packaging Debian
Posté par Carl Chenet (site web personnel) . Évalué à 6.
Docker 1.0 est non seulement dans Sid (unstable), mais aussi dans Jessie (testing). Yabon.
# Ansible+Vagrant
Posté par SaintGermain . Évalué à 3.
Bonjour,
Dépêche très intéressante, merci !
Je contribue à Apache Bloodhound (j'écrirai une dépêche dessus dès que possible) et je souhaitais faciliter l'installation afin de faciliter les tests et l'utilisation.
J'étais parti sur Ansible+Vagrant (un script Ansible qui provisionne une VM Virtualbox Debian basique) qui permet de tester le logiciel avec juste un "vagrant up".
Les gros avantages de cette approche sont:
Les performances ne sont pas fulgurantes (quelques minutes avec un vieux i5 et un SSD) mais bien suffisantes je pense.
J'ai un peu de mal à voir les avantages (hormis les performances) que peut m'apporter Docker dans ce contexte. Pourtant j'ai l'impression qu'il y a quelque chose à faire. Quelqu'un pourrait-il éclairer ma lanterne ?
Merci par avance !
[^] # Re: Ansible+Vagrant
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 9.
Si j'ai bien compris : Vagrant, qui repose sur virtualbox, va te créer une machine virtuelle, complètement autonome et indépendante de la machine hôte.
Docker repose sur le principe de container : un conteneur n'a pas son propre noyau ou autre. Il réutilise toutes les ressources de la machine hôte, mais avec des privilèges séparés. (c'est une sorte de gros chroot en fait). En définitive, dans un container, il n'y a que les applications que tu lances. Elles sont cloisonnées par rapport à la machine hôte, mais le container repose sur la machine hôte. D'ailleurs, sur un ps sur la machine hôte, tu vois tous les processus lancés dans un docker. Ce n'est pas le cas à priori pour Vagrant/virtualbox.
Et du coup, il y a de belles différences de perf entre un vagrant et docker.
Autre grande différence : dans docker, les étapes de builds sont historisés, un container peut hériter d'un autre container et bien d'autres choses…
[^] # Re: Ansible+Vagrant
Posté par bubar🦥 (Mastodon) . Évalué à 3. Dernière modification le 11 juillet 2014 à 14:50.
Il y aussi une différence de gestion : la "virtualisation" àla vmware est souple, au point que ça devient vite un immonde bordel. Les containers/zones/jails bornent par essence les limites, ce qui a comme avantage essentiel des mises à jour extrèmement simplifiées et un parc parfaitement cohérent.
Pas besoin d'être nostradamus pour voir qu'à terme vmware restera le beau bordel qu'il est actuellement. Pour une "infra virtuelle" (sic) le TCO sera infiniment inférieur en plaçant du full linux : parc de cette "infra virt" totalement uniforme, contrôle facilité, mise à jour globale simplifiée. Mes deux cents, en résumé : on assiste à une rationalisation de la virtualisation. Une dsi avisée mettra le focus sur le service à rendre pour choisir ses infra (ie : exemples : serveurs de sites web et serveurs d'applications métiers sur une infra en full linux + docker), et vmware pour le bordel historique à maintenir.
ps : on peut aussi regarder du côté de SmartOS qui est issu du fork de opensolaris vers illumos, permet à ce dernier de rester indépendant, a maintenant de très gros anciens devs de sun, et sa société ( Joyent également éditrie de Node.JS) ) fait sa plue-value sur une interface centrale de gestion. Les "anciens" Unixiens apprécieront sans nul doute ce SmartOS, où la zone globale est en RO. Bref, à surveiller de prêt désormais.
zai essayé de lier le vendredi à une vraie question
[^] # Re: Ansible+Vagrant
Posté par SaintGermain . Évalué à 1.
Ok merci, cela m'a un peu aidé à comprendre Docker.
Dans mon cas (fournir un moyen de tester/utiliser facilement sur tous les OS), je pense donc que Docker vient en supplément et donc pas en remplacement. Il me faudrait donc dans l'idéal un Ansible + Vagrant + Docker.
Je peux aussi directement diffuser un Docker déjà configuré, mais on perdrait en souplesse.
Le coup de l'historisation des builds est très intéressant, il faut que je me documente dessus.
Merci encore,
[^] # Re: Ansible+Vagrant
Posté par cosmocat . Évalué à 3.
Si effectivement ton objectif est de tester ton application sur tous les OS (dont au moins un n'est pas du linux), effectivement docker n'est pas la solution. Même s'il pourrait t'apporter de la souplesse en pouvant tester plus rapidement sur une plateforme linux donnée.
Par contre, si tous tes OS sont des version différentes de linux, utiliser docker aurait une grande plus value car il apporte plus de souplesse et des meilleurs perfs (et dans le cas de tests, les perfs c'est important pour pouvoir les faire le plus souvent possible).
Je ne sais pas ce que tu fais avec ansible, mais si tu utilises docker, il y aurait surement une grand plus value à créer un conteneur docker avec la majorité de ce que tu fais avec ansible (et donc qui est fait qu'une fois même si c'est long). Et d'ensuite ce baser sur ce conteneur pour en faire un autre qui contient juste l'application que tu veux tester (et donc que tu recrée à chaque fois que tu veux tester une nouvelle version de ton application. Mais ça devrait être beaucoup plus rapide).
[^] # Re: Ansible+Vagrant
Posté par SaintGermain . Évalué à 1.
En gros l'application est un site web (un gestionnaire de ticket + sources + wiki) et le but est de l'installer et l'utiliser (pour le tester ou pour se faire une idée, autrement que via le site de démo).
Je pense qu'il ne sera installé que sur du serveur linux, cependant les contributeurs et utilisateurs ont des machines diverses et variées (Mac et Windows par exemple).
Mon idée est donc d'avoir un Vagrant (basé sur une Debian)+Ansible pour que les contributeurs/utilisateurs puissent facilement tester/utiliser le site.
Par exemple le contributeur peut modifier le code source, faire un "vagrant up" et directement voir le résultat.
En bonus on peut alors utiliser le script Ansible pour installer proprement le site sur un vrai serveur.
J'ai bien compris ce que tu proposes (d'avoir Vagrant+Ansible+Docker) et je vais voir ce qu'il est possible de faire. Mais j'ai un peu peur que cela devienne un peu compliqué.
Je n'ai pas souvent vu de projets open source type "site web" qui proposent ce genre de chose. C'est dommage car je trouve cela fort pratique (en complément d'un site de démo).
[^] # Re: Ansible+Vagrant
Posté par cosmocat . Évalué à 6.
Je ne sais pas si vagrant apporte une plus value et ce qu'il apporte par rapport à du docker pur. Donc peut-être juste Docker+ansible. Tu feras dans le docker file ce que tu fais dans le vagrant file
Pas forcement. Tu auras juste 2 docker files. Un pour monter le conteneur pour qu'il ressemble à l'OS de ta VM. Ce conteneur ne sera à provisionner que quand la config de ton système changera (ce qui devrait être moins souvent que ton appli).
Le second juste avec la logique pour copier les fichiers de ton appli. Ce qui aura pour avantage d'être très rapide à provisionné et basé sur le conteneur précédent.
C'est justement le but de la création de docker! Je pense que justement de plus en plus logiciels vont fournir des docker file basé sur des conteneur "officiel" ou peut-être directement des conteneurs dans l'index officiel https://registry.hub.docker.com/ . Dans l'index il y a dejà des conteneur pour nodejs, nginx, wordpress,…
Le grosse plus value de docker, outre le gain de perf par rapport à une VM car il n'y a pas de temps de demarrage ou d'overhead, c'est que tu garanties que le logiciel s'execute tel que tu l'as testé car tu fournis cela dans un conteneur…
[^] # Re: Ansible+Vagrant
Posté par SaintGermain . Évalué à 1.
Ah ok je crois que je commence à comprendre. Effectivement cela devient plus intéressant si je peux me passer directement de Vagrant.
Alors en théorie je peux me prendre un conteneur officiel, me construire un Docker file aux petits oignons en testant le tout sur ma linux et avoir l'assurance que ce Docker file + conteneur marcheront identiquement sur tous les OS ?
Si oui là je comprend mieux l'intérêt.
C'est dingue comment tout cela évolue vite. J'ai à peine eu le temps de m'intéresser à Vagrant… ;-)
Merci pour les infos !
[^] # Re: Ansible+Vagrant
Posté par cosmocat . Évalué à 3.
Effectivement,
conteneur officiel + docker file perso -> conteneur personnalisé
(et rien n'empeche de faire : conteneur officiel + docker file infra -> conteneur infra + docker file appli -> conteneur pour mon appli. Le conteneur infra pouvant être partagé par toute l'entreprise)
et tu as l'assurance ( il existe des cas limites apparemment où tu peux avoir des différences mais moins que de déployer une appli sur un autre système et la communauté docker essaye de les éradiquer) que ça marchera sur tous les LINUX ayant un noyau assez récent…(bien noter que ça ne marche QUE sous linux. Si un de tes OS n'est pas du linux, soit on ne fait pas du docker, soit on passe par une vm minimale qui permet de lancer docker, genre boot2docker…)
[^] # Re: Ansible+Vagrant
Posté par cosmocat . Évalué à 3.
"ou autre"?
Et toutes leurs dépendances en terme de libraries.
Dans un conteneur docker, il y'a TOUT ce dont à besoin l'application que tu veux lancer dans le conteneur sauf le noyau qui est celui du système d'exploitation qui va lancer le conteneur…
[^] # Re: Ansible+Vagrant
Posté par Renault (site web personnel) . Évalué à 2.
Techniquement si ton application dans le conteneur et une application en dehors de celui-ci utilisent la même bibliothèque comme la libc, au niveau de la RAM la bibliothèque ne sera chargée qu'une fois et le noyau s'occupe de ça.
Du moins, c'est ce qu'il se passe avec les LXC normalement.
[^] # Re: Ansible+Vagrant
Posté par Nico C. . Évalué à 2.
Les 2 differences fondamentales :
- Vagrant s'appuie sur la virtualisation alors que Docker est un conteneur. Y'a pas d'OS hote pour docker.
- Vagrant est avant tout un outil de dev et de test. Docker est un outil pour la mise en prod.
[^] # Re: Ansible+Vagrant
Posté par hermenegilde . Évalué à 1.
Vagrant peut utiliser docker: http://docs.vagrantup.com/v2/docker/index.html
Donc la différence est carrément moins fondamentale, du coup.
# Merci !
Posté par Cascador (site web personnel) . Évalué à 4.
Bravo pour cet article et merci ! Très intéressant !
# Docker vs LXC
Posté par Seb (site web personnel) . Évalué à 5.
J'ai essayé un peu Docker il y a quelques mois pour voir s'il pourrait remplacer mon utilisation de LXC à terme, mais plusieurs points m'ont bloqués.
Comment peut-on mettre à jour simplement un conteneur Docker par exemple (MAJ de sécu etc) ? Si le conteneur doit être reconstruit, il me faut du coup mettre les données des applications dans un autre volume (faut y penser dès le départ donc, /home, /var…).
Dans le cas de PostgreSQL, si je veux profiter de l'authentification par socket UNIX (conf par défaut sous Debian, en ayant un compte utilisateur système nommé de façon identique au compte dans PostgreSQL, pour qu'un autre service s'executant sous cet utilisateur accède à PostgreSQL tranquilou), comment s'y prendre avec Docker ? PostgreSQL + mon application dans le même conteneur (lancer init mais ça semble "non-supporté" et trop aléatoire, bidouiller ça avec supervisord ou similaire) ? Ça ne semble pas la "philosophie" Docker, qui vise à encapsuler une seule application par conteneur, mais ceci apporte une dose de complexité je trouve.
Pour le moment je trouve la solution LXC + Ansible plus simple et confortable pour mes besoins, du fait que LXC lance un système Linux complet accessible par SSH, et dans lequel je peux faire évoluer mon besoin comme réaliser un montage CIFS exploitable par l'application qui y tourne (et la conf. Ansible est applicable sur n'importe quelle machine cible, que ça soit du LXC ou autre, ce qui est cool pour préserver l'historique du parc), mais je ne peux m'empêcher de me dire que je dois mal utiliser Docker, que quelque chose m'échappe.
Des retours sur ce type d'utilisation ?
[^] # Re: Docker vs LXC
Posté par Anonyme . Évalué à 1.
Je n'ai pas encore eu l'occasion de tester, mais j'ai lu un article qui indique que pour le cas des sockets, il faut utiliser un volume. Ton socket sera accessible a la fois sur ton systeme hote et dans le docker.
http://jpetazzo.github.io/2014/06/23/docker-ssh-considered-evil/ (tl;dr chercher socket dans l'article)
[^] # Re: Docker vs LXC
Posté par rahan . Évalué à 2.
C'est rigilo, on a à peu près le même ressenti vis à vis des MAJ de sécurité avec docker. C'est aussi l'une des raisons pour lesquels je reste avec LXC. Un petit coup de Ansible et tout mes conteneurs sont mis à jours via SSH.
L'autre aspect qui m'ennuie, c'est le stockage des images autre part que dans le dépôt officiel. Visiblement on peut créer un dépôt privé mais il faut installer un nouveau logiciel pas super documenté. Cela aurait été plus simple si tout pouvait tenir dans un dépôt git traditionnel.
[^] # Re: Docker vs LXC
Posté par Misc (site web personnel) . Évalué à 2.
Tu peux aussi faire pareil via ansible et docker avec un connecteur spécial:
https://github.com/ansible/ansible/pull/7971
Le registry docker est relativement simple à faire tourner pourtant.
Tu peux aussi regardé du coté de crane et de pulp:
https://github.com/pulp/crane
https://github.com/pulp/pulp_docker
qui permette de gerer ton propre jeu de miroir de rpm, d'imageopenstack ou docker ( et si quelqu'un pouvait coder le support des paquets Debian, ça serait chouette ).
Et je suis pas sur que faire un dépôt basé sur git pour mettre des images de 100 à 200m soit une riche idée :)
[^] # Re: Docker vs LXC
Posté par Kwiknclean . Évalué à 1.
Hello,
Je me pose le même genre de question.
Docker est-il conçu dans le cadre de "dock" qui auraient des nécessités d'inter-connnexion (Socket Unix pour une BDD mutualisée par exemple, ou encore pour un proxy-http style Varnish).
J'ai du mal à vraiment voir ce que m'apporterait Docker par rapport aux Conteneurs "standards".
Docker me semble être avant tout des conteneurs isolés et indépendant les un des autres ?
En fait … j'ai vraiment du mal à saisir la différence de concept entre les Docks et les conteneurs LxC.
[^] # Re: Docker vs LXC
Posté par vieuxshell (site web personnel) . Évalué à 3.
Dans la philosophie Docker, tu considères que l'OS + ton application + la conf sont une image.
Si ton application est un système (genre un serveur web + une DB), tu as 2 images qui communiquent ensemble (docker run --link).
Les données sont supposée être "ailleurs". Le ailleurs recommandé est … un autre container dédié au stockage. Ce container peut partager ses données via un mécanisme built-in à docker (docker run --volumes-from) ou par un mécanisme de partage de fichiers standard (NFS, CIFS).
Quand tu veux mettre à jour (faille de sécurité par exemple), tu rebuild ton (tes) images, tu supprimes le container initial (le web frontal) et tu démarres le nouveau container patché, lié avec le container avec les données et hop c'est reparti.
[^] # Re: Docker vs LXC
Posté par Seb (site web personnel) . Évalué à 5.
Merci pour ces éclaircissements !
Pour donner plus de précision, l'appli en question est Odoo/OpenERP, et on est amené à personnaliser cette application très régulièrement, différemment d'un client à l'autre (besoins qui peuvent évoluer au cours du temps suivant les demandes, rien n'est jamais figé).
Mon ressenti c'est que Docker est très bien adapté pour faire des dizaines voir des milliers de livraisons identiques. En dehors de ce cas, c'est se compliquer la vie que d'adopter un tel outil comparé à une VM standard ou un conteneur OpenVZ/LXC, vu qu'il faut :
Docker encourage le "mono-process", impliquant la mise en place de volumes communs si on veut que 2 conteneurs communiquent, et la livraison de conteneurs identiques à très grandes échelle. De l'autre côté LXC exécute un système complet (comportement par défaut), dans lequel se trouvent plusieurs process fonctionnant de manière cohérente. Si j'ai besoin d'installer un module Python pour générer des fichiers Excel, nul besoin de re-générer une image (un ajout à la conf Ansible et c'est bon, en plus d'être versionné pour garder l'historique).
Idem si je veux connecter un serveur Barman à un serveur PostgreSQL existant : SSH est déjà présent sur les deux pour la communication.
Loin de moi l'idée de critiquer Docker (vu son succès !), j'essaie juste de calquer mes besoins avec l'outil, mais ça renforce un peu mon opinion que Docker n'est peut-être tout simplement pas adapté comparé à d'autres solutions.
[^] # Re: Docker vs LXC
Posté par sheldoncooper . Évalué à 4.
oui docker est complique.
Tous les exemples sur le marche donnent une image simple et simpliste de docker, et lors de la mise en production, on se rend compte, qu'a l'usage, ce n'est pas aussi trivial, car tout n'evolue pas la vitesse. Par exemple, la data doit survivre a une mise a jour. Et la solution la plus intuitive est de mettre a jour le container, plutot que de externaliser la data. Il faut etre conscient de ca, avant de dire que docker est utile ou pas en fonction des besoins.
Pour moi, docker se dote d'une bonne architecture, car elle est flexible et elle contraint a de bonnes pratiques. Malheureusement, je trouve qu'il manque encore des solutions agreable de gestion de configurations : on ne gere pas sa conf dans le container, et on ne devrait pas la gerer comme la data.
Openshift comble cette lacune avec le push de la conf dans le container via des variables d'environement. Ce n'est pas la panacee mais ca a le merite d'exister et d'etre - relativement - agnostique. Un jour peut etre, un wrapper de systemd/supervisord offrira cela, a partir de zookeeper/etcd/autres :)
Mais comme je l'ai dit avant/plus bas, ce n'est qu'un composant et il faut d'autres briques, plus specialisees pour repondre a la problematique de la gestion des configurations, les rollings updates via des proxies - une cas particulier de l'auto enregistrement via serf/zk/eureka, les ACL - qui par defaut sont dynamiques.
[^] # Re: Docker vs LXC
Posté par sheldoncooper . Évalué à 4.
Effectivement.
C'est une erreur commune de penser que docker est une solution de deploiement de container. Docker reste conceptuellement une brique d'un PaaS. Ce n'est pas une solution, c'est un composant. CoreOS ou project atomic/openshift l'ont bien compris.
Si on se projette un peu plus loin, on peut voir docker comme une alternative au packaging classique.
Sachant que la mise a disposition d'un environement est generalement le plus couteux dans une infrastructure, Docker a l'avantage de l'embarquer dans le container final, tout en fluidifiant le process dev -> prod (versionning des images, approche par couche, etc.) Il existe plusieurs strategies pour une utilisation en production, en fonction des superstitions de chacuns.
Pour conclure, il faut rester dans le scope applicatif, avec un couche d'isolation en plus (mapping des ports, volumes, etc.) comme contrainte, mais avec comme avantage (grace a la registry) d'avoir des environements complets versionnes.
[^] # Re: Docker vs LXC
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Attention, NFS en mode noyau ne marche pas dans les containers à l'heure actuelle (sauf s'il y a eu un changement dans le noyau mais j'en doute). Il faut utiliser NFS en mode utilisateur qui n'est plus par exemple dans la Debian par défaut.
[^] # Re: Docker vs LXC
Posté par H4wkmoon . Évalué à 4.
J'ai constaté le même "problème".
Soit je n'ai rien compris à Docker (très possible), soit il y a vraiment un truc qui me gène grandement dans Docker. Un container Docker ne boote pas ! Il est créé et repose sur une seule simple commande. Si la commande s'arrête , le container s'arrête avec. Dans ce contexte, comment démarrer des services automatiques ? Comment administrer tout simplement le docker ? (Mise à jour, supervision, métrologie, sauvegarde, …)
LXC n'a pas ce problème puisqu'un container lxc boote réellement (et en moins de 2s pour un LAMP)
J'ai l'impression que Docker permet aux développeurs, avec des habitudes de développeurs (commit, pull, push, …), d'avoir l'impression de faire du système et de l'infra. C'est une bonne idée, mais devops et sysops, ce n'est pas le même métier.
J'aimerai vraiment qu'on ne me montre que j'ai tort. Tout le monde semble enthousiaste autour de Docker, alors que je le trouve très décevant.
# LXC et sécurité
Posté par GG (site web personnel) . Évalué à 2.
Bonsoir,
il y a déjà quelques temps, il existait une faille de sécurité dans LXC qui permettait à un utilisateur (d'un conteneur) de prendre le contrôle de la machine hôte en écrivant quelque chose dans un fichier quelque part (pardon pour le manque de précision). A l'époque, il y avait des solutions crades pour éviter ça, et les développeurs réfléchissaient à une solution propre.
Est ce que cette faille existe encore sur LXC?
Si oui, qu'en est-il pour Docker?
J'ai fumé à mon insu?
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: LXC et sécurité
Posté par claudex . Évalué à 4.
Je pense que tu veux parler de l'utilisateur root dans un conteneur qui pouvait sortir du conteneur avec les droits. Il est désormais possible de lancer les conteneur sous un compte classique et ce n'est donc plus possible.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Docker pour le bureau, est-ce le futur ?
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 12 juillet 2014 à 17:07.
Docker a l'air de beaucoup intéresser Fedora pour leur prochaine version "Workstation" dédiée au bureau, ainsi qu'Allan Day, qui "pense sincèrement que les applications conteneurisées (sandboxed applications) représentent le futur du projet GNOME". J'avoue être un peu à la masse sur les explications techniques ; vous en pensez quoi, vous autres ?
[^] # Re: Docker pour le bureau, est-ce le futur ?
Posté par Ife . Évalué à 10.
Je pense qu'après « buzzword » il va falloir inventer le mot « buzztechnology ». Des techonologies que les gens utilisent parce que « c'est cool ».
Bref, ce que j'en pense c'est que c'est un gros coup de « buzztechnology », comme le javascript et le CSS pour faire des thèmes gnome-shell. Comprenez ceci, je suis un utilisateur de Gnome Shell, j'adore Gnome Shell, mais il y a des choix techniques avec lesquels je ne suis pas d'accord.
Je ne vais pas partir en vrille sur la javascript/css dans Gnome Shell. Mais sur le fait d'utiliser des application « conteneurisées » sous Gnome. (Encore une fois, je suis un utilisateur fedora, j'adore fedora).
Je vais juste citer Kir Kolyshkin, le project leader d'OpenVZ (l'ancetre de LXC). Quelqu'un au fosdem lui demandais « Quand est-ce qu'il sera possible de faire tourner SELinux dans un “guest” OpenVZ » (désolé pour le franglais, je ne sais pas comment traduire ça.)
Et il répond « Pourquoi voulez vous faire tourner SELinux dans OpenVZ. SELinux fait la meme chose que OpenVZ, ils empêchent les applications de faire des opérations bizarres. (Écrire dans certain fichier, accéder à certain utilisateur, interragir avec certain processeur.) Si vous voulez isoler deux application ou deux systèmes de fichier l'un de l'autre en utilisant SELinux, pourquoi ne créez vous pas un nouveau container ? »
Et c'est là tout le truc. Fedora utilise SELinux, les gens n'aime pas ça, parceque c'est la NSA, si on utilise des paquets non Fedora, c'est la galère parceque les packageurs non-fedoraistes ne les ont pas fait « compatible-selinux », donc tout le monde rale.
Mais des problème comme ça, ou la sécurité va rendre l'utilisation de Fedora difficile, ces problèmes là existerons toujours, et ce sera le même cas avec des applications conteneurisée.
SELinux marchent très bien, les gens râlent, mais il râlerons avec les containeur aussi.
Et je vais avancer un dernier argument. Si on utilise différent containers pour Firefox et Thunderbird. Les deux vont utiliser leur propre NSS (équivalent de OpenSSL) qui est dans leur containers. Donc on revient au problèmes des bibliothèques non partagées..
Ça veux dire qu'il faudra mettre à jour NSS dans le container Thunderbird et dans le container Firefox.
En résumé, SELinux marche très bien.
Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »
[^] # Re: Docker pour le bureau, est-ce le futur ?
Posté par claudex . Évalué à 5.
Pas forcément, tu peux très bien avoir le même NSS (et d'autres libs) avec un
mount --bindà partir de l'hôte.« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Docker pour le bureau, est-ce le futur ?
Posté par reno . Évalué à 2.
Mmm, je t'ai plusser puis j'ai réfléchi: l’intérêt principal des conteneur est d'être 'autonome' ce qui évite les problèmes de compatibilités, mais à chaque fois que tu utilise la solution que tu décris, tu réintroduit le problème de compatibilité, non?
Ne vaudrait-il pas mieux automatiser la création de conteneur pour garder a la fois l'autonomie et une certaine 'facilité de mise à jour'?
Bon, réinstaller N conteneurs c'est moins simple qu'un seul, mais bon si c'est automatisé..
[^] # Re: Docker pour le bureau, est-ce le futur ?
Posté par claudex . Évalué à 3.
Oui, mais si on veut partager une bibliothèque (ce qui était le problème posé), c'est qu'il n'y a pas de problème de compatibilité. Je donnais juste une solution pour contourner ce problème.
Maintenant, on peut bien sûr mixer les deux solution. Le partage pour les bibliothèques qui ne posent pas de problème et avoir une version spécifique dans chaque conteneurs pour celles qui posent problème. Par contre, je pense que si on veut utiliser les conteneurs, on ne veut justement pas se soucier du problème de partage de bibliothèque et bien avoir des conteneurs complètement indépendant comme tu le dis.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Docker pour le bureau, est-ce le futur ?
Posté par jean-michel.bertrou.eu . Évalué à 3. Dernière modification le 12 juillet 2014 à 20:03.
Je dois être également à la masse niveau technique, vu que je n'ai pas compris un mot à la première réponse qu'on t'a écris.
Sur le plan stratégique par contre, je vois tout à fait l'intérêt de creuser pour voir s'il est possible de contenairiser l'environnement graphique.
Si gnome et kde veulent enfin devenir des plateformes de dévelopement digne de ce nom, il faut absolument qu'elles s'abstraient de cette fragmentation débilitante des distributions Linux. Quand je lis ce journal http://linuxfr.org/users/gaetan_63/journaux/sortie-de-guake-0-5-0 je suis effaré de lire qu'il n'y a toujours pas de canal de distribution digne de ce nom pour les développeurs. On est en 2014 merde, on devrait avoir compris que la clé dans le monde du logiciel est la possibilité d'itérer rapidement ! Build - Measure - Learn le plus vite possible comme dirait Eric Ries
Ce qu'on pourrait imaginer, c'est de réduire la myriade de distributions Linux à de bêtes lanceuses de conteneurs tels que docker_kde_4_13 ou docker_gnome_3_12 pour les utilisateurs normaux, ceux qui désirent être à l'avant garde pouvant guère plus difficilement installer docker_kde_4_14_dev ou docker_gnome_3_14_dev
Après côté développeurs d'applis, gnome et kde doivent impérativement s'arranger pour qu'ils puissent distribuer sans intermédiaire son appli en se préoccupant uniquement (à la Android) du niveau d'API qu'il vise (genre docker_gnome >= 3_12)
[^] # Re: Docker pour le bureau, est-ce le futur ?
Posté par Misc (site web personnel) . Évalué à 3.
Perso, c'est pas forcément ce que je voudrais. Moi, j'aime bien avoir un truc intégré avec des gens qui vérifient et qui font pas n'importe quoi et n'importe comment. Je voit bien par exemple comment ça se passe sur les différentes applis android bourré de pub, etc.
Je peux comprendre que des gens veulent ça et je m'oppose pas à la techno ou à laisser le choix pour ceux qui ont moins bons gouts que moi, mais ça me dérange pas que ça ne soit pas déjà le cas, loin de la.
[^] # Re: Docker pour le bureau, est-ce le futur ?
Posté par hermenegilde . Évalué à -5.
T'inquiètes pas, un mec qui dit utiliser Fedora qui tente de faire une réponse technique, ça donne ça.
# Isolation IO
Posté par diorcety . Évalué à 1.
C'est bien beau tout ça, pour des services utilisés de temps en temps, mais pour des services consommateurs en ressources, surtout si c'est pas la même entité qui utilise la même machine physique, ça doit pas être jojo. Je sais on va me sortir qu'il y a le IO scheduler, mais je vous laisse le loisir de tester "l'isolation"…
[^] # Re: Isolation IO
Posté par Julien CARTIGNY (site web personnel) . Évalué à 2.
Sauf erreur de ma part, Docker se base sur LXC qui utilise les cgroup.
Extrait de l'introduction sur les cgroups de wikipedia (en):
En clair, on peut faire de la répartition et de la limitation de l'usage des ressources (réseaux, disques, CPU, mémoire, accès disque, etc…) en cgroup. A part si docker n'expose pas facilement la possibilité de gérer finement les cgroups je vois pas le problème.
A noter que ce paramétrage est dispo sur les autres solutions de container (j'avais beaucoup bidouillé avec vserver à ce propos y'a un paquet d'années).
[^] # Re: Isolation IO
Posté par Misc (site web personnel) . Évalué à 3.
C'est pour ça qu'il aut utiliser systemd et les cgroups :p
( d'ailleurs, c'est ce qui est fait dans atomic : http://www.projectatomic.io/ )
[^] # Re: Isolation IO
Posté par diorcety . Évalué à 10.
C'est exactement le genre de réponse que j'attendais. C'est ce qu'on te "vend" (entre guillemet). Sur le papier ça parait parfait. Sauf que si comme moi (et mon entreprise) tu cherches à l'utiliser tu vas vite tomber sur le poteau rose.
En effet les schedulers ne savent pas prioriser les buffered writes (autant dire pratiquement tout les programmes que l'on peut être amener à utiliser). Alors si tu essayes de rendre prioritaire un service qui fait quelques petites écritures, face à un service qui fait des grosses manipulations de fichiers cela marchera très mal pour les petites écritures. Tu trimeras pour essayer de résoudre le "problème" jusqu'à tomber au fin fond d'un man disant(en cherchant pas mal):
What works
==========
- Currently only sync IO queues are support. All the buffered writes are still system wide and not per group. Hence we will not see service differentiation between buffered writes between groups.
Quelques patchs ont été proposé mais, il me semble pas que c'est d'actualité (et c'est bien dommage)
Je ne cherche pas à critiquer la solution, qui je trouve est une très bonne idée. Mais pour moi ce petit détail n'est pas suffisamment mis en avant; d'où cette perche tendue. Et c'est pour moi une des raisons qui peut empêcher l'industrialisation de celle-ci. Je vois mal expliquer à l'entreprise X que sont service est lent car l'entreprise Y fait des gros dd dans son conteneur(dans le cas de la mutualisation sous forme de conteneur).
[^] # HS
Posté par Zenitram (site web personnel) . Évalué à 6.
J'ai pas compris le raport avec les poteaux ni avec la couleur rose ;-)
Désolé, mais celle-la elle m'a fait rire, je me demandais si c'était fait exprès.
Tu voulais dires ça?
[^] # Re: HS
Posté par diorcety . Évalué à 0. Dernière modification le 15 juillet 2014 à 10:21.
Effectivement, j'avais plus l'image du poteau que tu te prends dans la tronche dans la rue en regardant ton smartphone
# Affectation de ressources physiques à un conteneur
Posté par ThomasJ . Évalué à 0.
Bonjour,
Est ce que quelqu'un sait si on peut affecter à un conteneur un temps CPU max et/ou un nombre de coeurs cpu. Je pose la question sur les coeurs cpu, car un certain nombre d'éditeurs facturent au nombre de coeurs utilisés.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.