Docker Desktop est désormais disponible sous Linux 🎉
note 1: si docker (engine, cli, compose, etc) et certaines parties de Desktop sont libres, Desktop en tant que tel ne l'est pas
note 2: je bosse chez Docker, pas sur Desktop mais sur Hub
Donc oui, Docker Desktop (DD4L) est maintenant disponible sous Linux. Alors j'imagine que la première question qui peut venir est du genre "mais pourquoi se faire chier avec Desktop, Docker ça tourne déjà sous Linux ? -_-" Et de poursuivre lorsqu'on se rend compte qu'en plus Docker Desktop pour Linux utilise un VM et non le docker du système.
Jusqu'à il n'y a pas si longtemps (ok, on va dire grosso modo 2 ans) Docker Desktop n'avait pour unique but que de rendre disponible une techno disponible seulement sous linux (oui on oublie volontairement les conteneurs windows) sous des systèmes qui ne sont pas linux. Ça a commencé avec docker-machine, et maintenant Desktop.
Et si vous vouliez faire un peu plus que juste faire marcher docker, vous pouviez utiliser des outils comme kitematic ou pourquoi pas portainer.
Mais depuis quelques temps on cherche donc à regrouper un certain nombres d'outils dans une unique interface pour le rendre plus facile. Et le truc c'est que cette interface n'était disponible que sous Windows ou Mac, laissant de côté Linux, comme souvent. C'était au final assez triste de voir Linux comme le parent pauvre d'une techno Linux only.
Mais bref, tout ceci a une fin, Desktop est maintenant là sous Linux. Et donc à la question "mais pourquoi ?" la réponse est principalement pour avoir une expérience similaire quelque soit l'environnement choisi pour développer. Windows, Mac ou Linux, les mêmes outils sont disponibles partout maintenant.
Alors bon, partout, presque. C'est dispo sous ubuntu, fedora, arch en x86-64 et bientôt sous raspberry pi.
Si vous voulez en savoir plus, c'est par ici : https://www.docker.com/blog/the-magic-of-docker-desktop-is-now-available-on-linux/
Et si vous voulez savoir pourquoi il y a une VM, la réponse se trouve dans la doc : https://docs.docker.com/desktop/linux/install/#why-docker-desktop-for-linux-runs-a-vm
En gros c'est pour garantir que ça fonctionne partout de la même manière et pour permettre d'utiliser des fonctionnalités noyau qui ne seraient pas disponibles sur la machine hôte.
Dans les autres nouveautés intéressantes (c'était DockerCon hier, les replays sont ici https://docker.events.cube365.net/dockercon/2022 ) il y a entre autre l'acquisition de Nestybox qui développe entre autre sysbox pour faire du rootless. C'est un point qui était un peu mis de côté mais sur lequel on va pouvoir avancer de meilleure manière maintenant.
Il y a d'autres news, mais le but est pas de faire du publi reportage, juste que je trouvais intéressant de partager avec vous cette news linux.
Allez, juste pour partager d'autres trucs sympa, voici par exemple le genre de chose qu'on peut s'amuser à faire avec des Dockerfile (ici visualisé dans Desktop, avec une extension maison)
C'est "juste" un Dockerfile contenant des outils, c'est pas mon image de prod :-) mais la visualisation permet d'un peu mieux voir ce qui se passe.
Pour info c'est basé sur https://github.com/patrickhoefler/dockerfilegraph
# Intégration sysbox dans runC
Posté par Tangi Colin . Évalué à 3.
Merci pour la nouvelle. J'aurai une question mais je sais pas si tu auras la réponse.J'ai découvert sysbox que je ne connaissais pas. Je vois qu'il s'agit d'un fork de runC, le rachat par docker Inc laisse t-il envisager une réintégration du code dans runC ou est ce que le fork dévie trop de la spec OCI pour être envisageable ?
[^] # Re: Intégration sysbox dans runC
Posté par CrEv (site web personnel) . Évalué à 4.
Sur l'éloignement avec la spec OCI, je pense qu'il n'y a pas de problème. C'est déjà utilisable comme un autre runtime
Maintenant pour ce qui est de ce que ça va donner, honnêtement je ne sais pas encore. L'annonce est sortie hier, c'est encore un peu tôt pour savoir exactement, mais le but est bien évidemment de pouvoir profiter de leur connaissance de ce domaine.
Tout ce que je peux en dire c'est qu'il y a déjà du boulot en cours pour moderniser certains aspects de l'engine (qui aujourd'hui est un mix de l'engine docker, containerd, etc).
[^] # Re: Intégration sysbox dans runC
Posté par Wonderfall (site web personnel) . Évalué à 3.
Personnellement je suis un peu sceptique vis-à-vis de sysbox, qui si je ne me trompe pas, repose surtout sur l'utilisation de user namespaces (comme rootless et podman). Le problème des user namespaces c'est que depuis des années on se rend compte que son code (privilégié de surcroît) est problématique et qu'autoriser son accès à des utilisateurs standards est généralement une mauvaise pratique. Et si je ne me trompe pas, avec sysbox, les appels systèmes sont toujours satisfaits par le kernel hôte.
En l'occurrence, Docker Desktop isole l'ensemble des conteneurs dans une VM, mais du coup je doute toujours de l'intérêt de sysbox par rapport à runc + usersn-remap si quelqu'un veut faire la même chose. Je pense que la meilleure approche à terme serait une solution similaire à ce que fait Google avec gVisor (qui fournit un runtime OCI-compliant), qui n'est pas sans défauts mais qui mérite le coup d'oeil.
# Podman-Desktop-Companion
Posté par Gawan . Évalué à 10.
Une solution similaire mais qui peut aussi bien fonctionner avec Podman qu'avec Docker (sans utiliser de VM) et publiée sous licence MIT : Podman-Desktop-Companion
[^] # Re: Podman-Desktop-Companion
Posté par tcit (site web personnel, Mastodon) . Évalué à 1.
Spécifiquement pour Podman, j'ai vu https://github.com/marhkb/pods dernièrement.
[^] # Re: Podman-Desktop-Companion
Posté par CrEv (site web personnel) . Évalué à 4.
Alors oui et non.
C'est de toute façon virtualisé sous Mac et Windows.
Maintenant je suis content que le design de Docker Desktop est tellement bien qu'ils l'aient juste copié - collé :-)
Blague à part, c'est cool qu'il y ait un peu d'activité sur le domaine. Celui-ci, lima, rancher desktop. Tout cela est intéressant et fait bouger un peu les choses, c'est plutôt sain.
[^] # Re: Podman-Desktop-Companion
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 12 mai 2022 à 09:49.
Je suis pas sur de voir l'intérêt de toutes ces gui, mais cockpit intègre déjà podman.
[^] # Re: Podman-Desktop-Companion
Posté par CrEv (site web personnel) . Évalué à 4.
Cockpit ça a un peu rien à voir si je me trompe. Genre c'est pas du tout prévu pour faire tourner docker (ou podman, peut importe) sur mon win/mac.
Alors oui j'entend "on s'en fout on est sous linux" mais ça répond juste pas au même besoin du tout.
[^] # Re: Podman-Desktop-Companion
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 12 mai 2022 à 14:27.
Cockpit c'est une gui (qui inclue entre autre une intégration avec podman). Le message parent parlait de gui pour podman. Je mentionne l'alternative. Voilà c'est tout.
Et au final je ne vois pas en quoi une vm faisant tourner podman et cockpit ne tournerait pas sur un mac ou un windows.
[^] # Re: Podman-Desktop-Companion
Posté par damaki . Évalué à 3.
Merci, depuis le changement de licence et de philosophie de Docker, j'essaie de fuir la version Windows comme la peste.
[^] # Re: Podman-Desktop-Companion
Posté par CrEv (site web personnel) . Évalué à 4.
Aucun problème, la version Linux est dispo maintenant !
[^] # Re: Podman-Desktop-Companion
Posté par CrEv (site web personnel) . Évalué à 5.
Le changement de licence je vois, le changement de philosophie c'est lequel ?
Celui visant à permettre de, entre autre, continuer à pouvoir payer des personnes travaillant sur les produits open source ? docker engine ou compose, docker distribution par exemple ?
Ou celui visant à permettre de, entre autre, continuer de maintenir docker hub et toute la plateforme de la registry, maintenir les images officielles, et continuer à les rendre dispo ?
Juste pour donner un peu une idée de ce que c'est :
https://twitter.com/dotpem/status/1524076555416129536
[^] # Re: Podman-Desktop-Companion
Posté par damaki . Évalué à 0. Dernière modification le 13 mai 2022 à 09:14.
Je parle de la licence de Docker Desktop, c'est amusant que tu me parles du service en ligne que je n'ai même pas mentionné. Je me contrefiche du service en ligne et c'est totalement justifié qu'il soit payant ; la bande passante et les serveurs ne poussent pas sur les arbres. Coupler Docker Desktop et le service en ligne en un abonnement unique, ça me dépasse.
Idéalement, j'aurais voulu un Docker Desktop open source. Depuis le changement de licence, je suis passé à podman et buildah sous WSL, sans regret. Je suis aussi en train d'évaluer Rancher Desktop.
[^] # Re: Podman-Desktop-Companion
Posté par CrEv (site web personnel) . Évalué à 6.
Le fait que tu ne l'ai pas mentionné ne change rien au fait qu'ils sont liés.
Ils sont liés dans les termes, mais ils sont en vrai aussi liés dans les faits.
A moins de ne jamais accéder à la moindre donnée du Hub, ce qui me laisse particulièrement songeur…
Genre jamais, jamais tu n'utilises la moindre image en provenance de docker hub?
Le changement de licence n'a eu aucun impact sur deux points :
- docker desktop n'a jamais été libre, même si certaines parties le sont
- docker desktop ne nécessite toujours pas de compte payant pour tout ce qui est perso, open source, académique, etc
[^] # Re: Podman-Desktop-Companion
Posté par Psychofox (Mastodon) . Évalué à 4.
Soit-dit en passant sur une distro du monde redhat et avec podman, les repos redhat sont proposés en premier et quay est aussi proposé en plus du docker hub si on ne précise pas le préfix docker.io avec l'image.
[^] # Re: Podman-Desktop-Companion
Posté par damaki . Évalué à 1. Dernière modification le 13 mai 2022 à 09:25.
Ah mince, je viens de remarquer que j'avais écrit "Docker" dans mon premier post, je pensais plutôt "Docker Desktop". Je comprends mieux la réponse un peu énervée de CrEv. Désolé pour la méprise.
[^] # Re: Podman-Desktop-Companion
Posté par CrEv (site web personnel) . Évalué à 5.
Aucun problème.
Comme dit, aucun problème pour que les gens aillent voire les alternatives, voir que de nouvelles apparaissent. Pour le moment c'est pas encore ça, entre autre parce que beaucoup d'aspects sont bien moins évidents que ce que pas mal de monde pense.
Mais la concurrence, l'émulation que ça apporte est une bonne chose pour tout le monde, et pour l'ecosystème et les utilisateurs en premier lieu.
Mois je préfère que les gens utilisent Desktop parce que ça leur apporte de la valeur, plutôt que parce que c'est la seule solution.
Et si d'autres solutions conviennent à certain, ben c'est cool.
# Modèle de conteneurisation
Posté par Pierrick Bouvier . Évalué à 4.
À mes yeux, l'outil perd vraiment tout intérêt à forcer l'utilisation d'une VM.
Autant sous windows c'était obligatoire pour de vraies raisons, autant sous Linux, c'est dommage de ne pas avoir le choix. M'enfin, à partir du moment où une GUI est nécessaire pour lancer un conteneur, VM ou pas, l'utilisateur concerné ne doit pas y voir grand chose.
[^] # Re: Modèle de conteneurisation
Posté par David Delassus (site web personnel) . Évalué à 4.
Tout dépend de la techno de virtualisation, kvm est quand même très performant.
De plus, il me semble bien plus simple de limiter la conso CPU et RAM d'une machine virtuelle (fait via la GUI de Docker Desktop).
C'est tout à fait possible de le faire avec les cgroups, mais c'est tout de suite plus complexe pour l'utilisateur lambda.
Et puis, il s'agit d'une première version, un port tel quel du code sous Linux. Peut-être que dans une future version, le "backend" sera suffisamment abstrait pour permettre d'utiliser un Docker hôte (ou tout autre remote Docker ?).
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Modèle de conteneurisation
Posté par CrEv (site web personnel) . Évalué à 4.
Le choix d'avoir une VM est un choix, pas une version par défaut.
Le tout se concentre, entre autre, sur l'idée d'avoir au plus possible le même comportement et la même expérience quelque soit le système. Ce qui typiquement dans un cadre de travail peut être très important.
A partir du moment où on ne se base que sur le système en dessous, ca veut aussi dire que n'importe qui peut faire n'importe quoi dans le système de base et que subitement ca ne va plus fonctionner, ou pas comme prévu.
[^] # Re: Modèle de conteneurisation
Posté par CrEv (site web personnel) . Évalué à 8.
D'ailleurs le vrai utilisateur il fait ses conteneurs lui même en manipulant ses tars.
Et le vrai utilisateur il appelle les primitives du noyau comme un grand.
[^] # Re: Modèle de conteneurisation
Posté par CrEv (site web personnel) . Évalué à 10.
Sinon, moins troll.
C'est toujours pour de vraies raisons sous linux, pas les mêmes certes.
Il y a toujours le choix d'avoir juste docker. La sortie de Docker Desktop ne remplace en rien ce qui existe déjà.
D'autant plus que les deux peuvent cohabiter sans problème. Docker Desktop sous linux défini un nouveau contexte, mais celui du système est toujours là.
docker context use defaultet hop tu es sur le système de base.Je pense que c'est se méprendre sur au moins deux aspects :
1/ la GUI offre bien plus de choses que de lancer un conteneur, et parfois de manière bien plus agréable que la ligne de commande
Un exemple tout bête que j'aime beaucoup, c'est la facilité de pouvoir lire le contenu d'un volume, sans prise de tête :
2/ faut pas mépriser comme ça les utilisateurs ! Parfois, souvent, les utilisateurs de docker ne sont pas forcément ceux qui créent les images, les dockerfiles, etc. Pour beaucoup docker n'est qu'un outil pour simplifier certaines taches. Et donc dans cette idée, pourquoi ne pas juste tenter de leur simplifier la vie ? Il n'est pas besoin d'être bon en docker pour vouloir/devoir/pouvoir l'utiliser. Offrir des possibilités via une interface n'enlève pas les possibilités de l'utiliser hors de l'interface. Chacun choisi alors ce qu'il préfère, et c'est souvent un mix.
C'est exactement comme dire qu'un outil graphique de Git ne sert à rien, que tout le monde doit apprendre les commandes (tellement user friendly) en cli. Ou alors on se met juste à utiliser ce qui est le mieux pour une action donnée dans un contexte donné.
[^] # Re: Modèle de conteneurisation
Posté par Pierrick Bouvier . Évalué à 4.
Allez, j'avoue, j'ai un peu trollé :)
Pour l'avoir déjà utilisé, l'interface de Docker Desktop est plutôt bien faite, et comme tu le soulignes, il y a plusieurs fonctionnalités fort pratique.
Je ne pense pas qu'il soit nécessaire que chacun connaisse parfaitement la cli de docker. Seulement, ton exemple sur Git est juste. Oui, avoir une GUI permet à des profanes de s'en servir. Mais d'un autre côté, ça empêche aussi les gens d'en découvrir plus sur l'outil. C'est un débat qui restera ad vitam dans l'informatique je pense. Avec docker-desktop, le message transmis est "Un conteneur, c'est comme une machine virtuelle, mais avec une baleine". C'est dommage, car ce n'était pas la philosophie première.
Après, pour le choix d'avoir des VM par défaut, je comprends la motivation. Ce n'est pas mon besoin personnel, mais oui, c'est sans doute plus juste pour la majorité des utilisateurs. Il n'empêche que j'y vois toujours un certain retour en arrière, même si avec les Dockerfile, c'est toujours moins pire qu'avant.
[^] # Re: Modèle de conteneurisation
Posté par CrEv (site web personnel) . Évalué à 6.
Je ne m'attendais pas à moins ici :-)
Alors celui-là j'aimerais bien que tu me l'expliques un peu plus, parce que vraiment je vois pas en quoi desktop transmet ce message ^_-
Je pense que c'est justement tout le contraire. Et encore plus depuis la dernière version (4.8).
Juste quelques exemples :
Depuis plusieurs versions, un "getting started" est inclus dans Docker Desktop. C'est juste une série de quelques commandes pour clone un repo, build une image et jouer avec.
Bien que ce soit inclus dans Docker Desktop, c'est tout fait à base de ligne de commandes. Mais tu es guidé.
Voici par exemple le début du tutoriel (utilisant des images Docker évidemment)
(oui c'est sous windows, je suis pas sectaire, et vu que j'ai la même chose quelque soit l'OS :-D )
Ce qui est arrivé avec la 4.8 c'est une nouvelle homepage qui tente de guider dans la découverte de docker. Evidemment si tu connais déjà bien docker, peut-être que ce n'est pas utile. Mais le but ici n'est pas de masquer la CLI, il est d'accompagner.
Et si tu en choisi une, certes on va la lancer avec quelques paramètres par défaut, mais ensuite toute l'interaction est faite à partir de la ligne de commande. Sauf qu'on donne des exemples de choses à réaliser :
Donc au final, oui on simplifie et on aide, non la motivation n'est pas d'empêcher d'en découvrir plus, c'est totalement l'inverse.
[^] # Re: Modèle de conteneurisation
Posté par Pierrick Bouvier . Évalué à 5.
Merci de prendre le temps d'expliquer un peu la vision de l'outil. C'est bien que ce soit une démarche de faire découvrir l'outil plutôt qu'un "simple" clicodrome.
Dans mon expérience personnelle, qui n'est pas représentative de la réalité, 100% des utilisateurs de docker desktop n'avait jamais eu l'idée de lire docker run, se privant de découvrir les possibilités de l'outil. Sans une GUI, cela serait-il différent? Pas sûr, et je reconnais que c'est un coupable facile pour moi.
[^] # Re: Modèle de conteneurisation
Posté par CrEv (site web personnel) . Évalué à 3.
En soit docker desktop ne permet pas de faire un
docker runsuper facilement avec tous ses paramètres, ports, etc.Souvent ça va passer par du compose, voir d'autres solutions (du kubernetes ou autre)
Maintenant il en faut juste pour tout le monde.
Pour un côté perso, j'ai toujours été très CLI. Mais maintenant il m'arrive d'utiliser desktop pour des choses que j'aurais fait en CLI avant.
Et j'ai toujours mon terminal d'ouvert à côté. Mais browser un volume, parcourir les logs d'une stack compose qui est lancée en arrière plan, ben c'est juste plus simple.
Le tout est de ne pas brider l'utilisateur et de juste tenter d'améliorer ce qui parfois est un peu plus galère.
[^] # Re: Modèle de conteneurisation
Posté par Michaël (site web personnel) . Évalué à 6. Dernière modification le 12 mai 2022 à 09:46.
On utilise un outil pour faire quelque chose de précis: pour mon travail de développement je suis plutôt du genre “power-user/scripteur” qui va préférer les interfaces textuelles et les outils CLI pour à peu près tout: git, sql, docker… mais pour des tâches spécifiques comme par exemple faire une validation des critères d'acceptation, discuter un patch, faire une code review, explorer une BDD avec un collègue, et d'autres… les outils graphiques permettent une approche différente de la CLI.
Je trouve que la CLI est assez impitoyable avec la baisse de concentration qui est inéluctable si on n'est pas la personne qui manipule le système, les interfaces graphiques vont au contraire aider à se raccrocher en affichant plus de contexte et en montrant visuellement qu'on change de sujet, pour donner des exemples. Pour la productivité et l'automatisation, c'est bien-sûr la CLI qui garde souvent la main haute, mais ce n'est pas toujours le critère principal!
[^] # Re: Modèle de conteneurisation
Posté par Psychofox (Mastodon) . Évalué à 5.
En même temps sous linux si tu mets un utilisateur régulier dans le groupe docker (ce que beaucoup de gens faisaient par défaut), docker devient une faille de sécurité béante.
Et quand tu vois le bordel de manipulations pour juste faire tourner docker en mode rootless tu comprends vite leur intérêt d'encapsuler le tout dans une boite noire pas libre:
https://docs.docker.com/engine/security/rootless/
Les autres n'ont pas attendu et utilisent déjà podman depuis quelques années.
[^] # Re: Modèle de conteneurisation
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Je viens d'essayer podman. La partie réseau a l'air toute pétée: j'ai des erreurs podman rootless bind: address already in use alors que non c'est bien libre…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Modèle de conteneurisation
Posté par Alex G. . Évalué à 3.
Malgré les réponses de CrEV (qui n'est clairement pas neutre, et c'est normal) je suis complètement de ton avis, et ça m'attriste. On voit clairement que Linux est le parent pauvre / n'est pas la cible des décideurs de chez Docker.
Ce ne sont pas les perfs qui me chagrinent si je mets docker dans une VM, c'est le fait que je dois réserver par avance la mémoire et l'espace disque… et ça vraiment, surtout pour la mémoire, c'est un grosse perte en pratique (docker a fait sa pub comme étant beaucoup plus rapide / flexible que les VM, c'est quand même marrant de le voir se justifier d'être dans une VM, même si c'est pour les développeurs…).
Bref j'ai l'impression que Docker n'a pas trop levé le petit doigt pour les développeurs sous Linux. Ça me chagrine, car je suis sûr qu'ils vont concentrer beaucoup d'effort sur la version desktop, qui en soit aurait été sympa à avoir, mais moi dans ces conditions, ce sera clairement non.
[^] # Re: Modèle de conteneurisation
Posté par CrEv (site web personnel) . Évalué à 7.
Anéfé. J'essaie d'être factuel, mais je suis nécessairement biaisé par ce que j'en sais, mon rôle et l'envers du décors.
J'en ai évidemment une lecture totalement différente :-D
Si Linux ne faisaient pas partie de la cible, desktop pour linux n'existerait toujours pas.
Je pense que personne n'imagine le nombre de discussions qu'il y a eu, et depuis combien d'années, pour avoir un desktop linux. Et on y est enfin !
C'est certainement pas parfait, et on savait à l'avance que cette VM poserait question.
Je pense que si j'étais de l'autre côté, je me dirais la même chose, genre "WTF une VM sous linux pour faire tourner Docker, mais ils se foutent de la gueule du monde !"
Maintenant, pour en voir l'envers du décors, je pense que cette VM est une bonne chose pour permettre de garantir le plus possible un fonctionnement identique partout et être moins embêté par des problèmes noyaux ou de configuration du système hôte.
Quand on voit que certains forkent des distributions juste pour virer systemd, l'étendue des possibilités de problème est quand même important sous Linux :-D
C'est dommage que ce soit l'impression qui en ressorte.
A voir si ce qu'on met et va rajouter dans desktop ne viendra pas tout simplement changer cette vision. En gros, que la valeur du produit soit supérieure aux désagréments que peuvent être les contraintes techniques. En tout cas c'est l'objectif.
[^] # Re: Modèle de conteneurisation
Posté par Psychofox (Mastodon) . Évalué à 4.
Ça peut être vu de deux manières:
- comme une perte (selon toi).
- comme un gain de contrôle.
Ce qui aurait été bien c'est de pouvoir choisir, comme sur le client podman desktop mentionné plus haut (qui supporte aussi docker).
# Docker Destop
Posté par Pol' uX (site web personnel) . Évalué à 10.
Ou simplement « Qu'est-ce que c'est ? Un truc pour déboucher les conteneurs ? » :)
Adhérer à l'April, ça vous tente ?
# Merci
Posté par David Delassus (site web personnel) . Évalué à 4.
J'ai pas grand chose à dire sur le sujet, à part merci de ce journal, merci du travail de Docker sur tout ses produits (Hub, Desktop, etc…), merci de tes réponses à tout ces commentaires.
Pour info, j'ai migré de Linux (après de longues années sous Linux) à Windows pour le travail, et avec le WSL2, Git Bash, Hyper-V, etc… je suis surpris d'en être aussi satisfait. Docker Desktop s'intègre tellement bien avec toutes ces technologies, ce fut un plaisir à utiliser (malgré une perte de performance lors de l'utilisation de volume, mais je pense que c'est du à NTFS).
C'est dire, avant mon setup sous Linux c'était docker + portainer, car oui j'aime bien la GUI et je passe pas toutes mes journées dans la console. Docker Desktop a complètement remplacé portainer, justement parce qu'il me laisse voir les conteneurs qui tournent, ainsi que les stack docker-compose. Je n'utilise pas l'intégration Kubernetes (je préfère KinD), mais je suis ravi de la voir présente.
Pour info, quand Docker a annoncé rendre payant Docker Desktop pour les boites faisant plus de X de CA et ayant plus de Y employés, j'ai vu plein de gens dire "oulala il faut migrer, il faut aller voir ailleurs, comment osent ils vouloir monétiser leur travail propriétaire dont on profite gratuitement?"
Pour ma part, je suis derrière vous, Docker forever <3
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Merci
Posté par CrEv (site web personnel) . Évalué à 4.
Merci pour ce commentaire :-)
C'est justement pour ça qu'on le fait, pour que ça serve.
D'ailleurs, dans les spécificités de l'entreprise, qui est assez récent (on a commencé à aller dans cette direction 1 - 1.5 ans en arrière) on essaie d'avoir des équipes avec un ratio ingénieur - product manager vraiment intéressant. En gros on a des équipes de 5-7 personnes avec 1 engineering manager, 1 product manager, 1 product designer. Le reste sont les devs, front et/ou back et/ou system.
Et le résultat c'est qu'on tente avant tout de résoudre les problèmes des gens, pas de les rendre captif ou autre.
(et si certains veulent voir un peu l'envers du décors, j'ai fait un talk à devoxxfr sur certains aspects de l'orga des équipes, la vidéo est en ligne, Je le refais à AlpesCraft en juin si certains sont dans les coins)
J'ai entendu beaucoup de bien de personnes migrant sous windows du fait de wsl2 et docker.
Depuis quelques temps déjà on a aussi amélioré de manière très importante les perfs du système de fichier sous mac. C'est encore expérimental, ça ne fonctionne pas avec tout, mais c'est dispo.
Il y aurait plein de choses à dire ici…
La première, c'est que beaucoup des personnes que j'ai vu le dire… étaient dans la catégorie qui est exemptée de subscription…
On savait très bien que l'une des conséquences allait être que d'autres outils pouvaient apparaitre. Mais c'était prévu, et voulu. Avant, Docker Desktop était grosso modo tout seul, sans concurrence. Mais ce n'est pas sain. Maintenant on commence lentement à voir des choses arriver. Et cette émulation, cette concurrence est une bonne chose. Docker est et a toujours été dans l'idée d'un ecosystème. A nous d'être suffisamment bon et que les personnes nous choisissent car ce qu'on propose répond à leurs problèmes.
Quand je parle d'ecosystème c'est exactement ce qu'on continue à faire avec les extensions. On pourrait très bien re-développer des fonctionnalités autour des conteneurs. Ou alors on laisse faire ceux qui font déjà, et on leur propose des outils, des partenariats, des intégrations. Et comme ça tout le monde vit.
Et pour finir sur la partie financière, on a tellement entendu de critiques à propos de Docker qui n'avait pas de business model, qui ne gagnait pas d'argent… et ce sont les même qui critiquent aujourd'hui. Ben 🤷♂️
Il faut aussi voir que cet argent sert à financier l'open source.
Pour exemple, docker compose a été totalement réécrit en Go, des développeurs continuent à rajouter des fonctionnalités, à l'améliorer. Mais en soit compose ne rapporte rien, mais il faut bien payer ces gens. Ou maintenir les images officielles que tout le monde utilise. Cet argent a donc servit à racheter infosiftr et à les payer, sachant que ce sont eux qui maintiennent les images officielles (open source) depuis des années.
Ou encore avec sysbox.
Et si certains veulent aller plus loin, Kelsey Hightower s'est entretenu avec le CEO de Docker lors de la dockercon, ça parle aussi de financement et il dit les choses probablement avec plus de clarté que moi : https://docker.events.cube365.net/dockercon/2022/content/Videos/084b1a56-982a-48b2-87ab-09c37ed7ab48
# License?
Posté par Benjamin Henrion (site web personnel) . Évalué à 0.
"Docker Desktop (DD4L) est maintenant disponible sous Linux"
C'est quelle license?
[^] # Re: License?
Posté par claudex . Évalué à 5.
C'est littéralement expliqué sur la deuxième ligne du journal.
« 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: License?
Posté par Benjamin Henrion (site web personnel) . Évalué à 0.
Et quels en sont les termes?
[^] # Re: License?
Posté par CrEv (site web personnel) . Évalué à 3.
Je pense que c'est la page que tu cherches : https://www.docker.com/legal/docker-subscription-service-agreement/
Ce n'est pas que pour Desktop, ce sont les termes des subscriptions dans leurs globalités.
[^] # Re: License?
Posté par Benjamin Henrion (site web personnel) . Évalué à 1.
Cela implique de prendre un abonnement?
Et d'avoir une connection internet?
[^] # Re: License?
Posté par CrEv (site web personnel) . Évalué à 2. Dernière modification le 12 mai 2022 à 13:41.
Pour faire quoi ?
Donc oui, si tu n'es pas dans un des cas présents (l'ensemble de ces cas représente un peu plus de 50% des utilisateurs), ça demande d'avoir un plan pro/team/business.
Pour de l'open source, pour du personnel, académique, etc c'est toujours gratuit.
edit: https://www.docker.com/blog/updating-product-subscriptions/
[^] # Re: License?
Posté par Benjamin Henrion (site web personnel) . Évalué à 2.
"You understand that the Service is subject to United States export controls administered by the United States Department of Commerce and the United States Department of Treasury Office of Foreign Assets Control."
Cela veut dire que les développeurs russes et iraniens ne peuvent pas l'utiliser.
[^] # Re: License?
Posté par Misc (site web personnel) . Évalué à 2.
Un peu plus, la liste de l'OFAC est quand même large: https://www.treasury.gov/ofac/downloads/sdnlist.txt
[^] # Re: License?
Posté par CrEv (site web personnel) . Évalué à 4.
L'entreprise étant de droit américain elle respecte les lois américaines, oui.
[^] # Re: License?
Posté par Marc Quinton . Évalué à 3.
bonjour,
qu'en est-il de la licence pro permettant d'augmenter les quotas de téléchargement vers le Docker-hub. Dans une entreprise qui fait un peu de Devops avec des containers Docker sur une forge Gitlab avec des runners, il se trouve que les quotas peuvent être assez vite consommé: 100 téléchargements toutes les 6 heures.
Sur la fiche de tarification, on voit un bundle Docker-desktop avec des quotas, ce qui n'interesse pas nécessairement toutes les entreprises.
Combien de licences acheter quand l'adresse IP source vers le Docker-hub est unique et partagée par tout un réseau interne d'entreprise. Et pourquoi ne pas mettre a disposition une formule spécifique pour ce besoin.
Nous avps mis en place un cache ce qui permet de diminuer la charge coté Docker-hub et aussi la charge de notre accès Internet. Mais j'aimerai bien avoir une solution plus solide si le besoin s'en faisait sentir.
[^] # Re: License?
Posté par CrEv (site web personnel) . Évalué à 6. Dernière modification le 13 mai 2022 à 00:10.
Sans en savoir plus c'est quand même assez compliqué de répondre précisément. Néanmoins, plusieurs choses.
Ils le sont ou ils le peuvent ? A noter qu'un build ou pull ne compte pas nécessairement dans les quotas. Entre autre si l'image est déjà en cache, un
docker pullne va rien faire à part vérifier le digest de l'image et ne comptera pas.A noter aussi que les images des Verified Publishers et les images fournies par les membres du programme de sponsoring des projets open source ne sont pas soumises au rate limiting.
C'est à prendre dans l'autre sens. Cette page présente les différentes subscriptions. Docker Desktop (dans la limite des cas évoqués ici même) à besoin d'une subscription non personnelle. Mais il s'agit avant tout d'une subscription Hub. Ce n'est pas un bundle.
Maintenant, concernant le problème en lui-même. Déjà, 100/6h (400/jour) ca veut dire qu'il n'y a même pas d'authentification. Juste un compte gratuit permet de doubler les quotas, passer à 200/6h (800/jour).
Ensuite, ben c'est ce qui est sur la page. Un compte pro et on passe à 5000 pulls/jour, soit un peu plus de 12 fois plus. Pour $5 par mois…
Je sais pas bien ce qu'il faut dire de plus.
En gros, si ton business dépend de ca, j'imagine que $5 par mois ca semble faisable. Sinon, je vois pas.
D'ailleurs, à moins que je ne me trompe, mais j'imagine que le coût de mise en place et de la maintenance du cache… dépasse $60 par ans, non ?
Le quota de pulls a un objectif majeur, qui a été atteint, qui était de limiter les très, très gros abuseurs. Pour faire simple, l'impact a été négligeable voir invisible sur la très grande majorité des utilisateurs et des entreprises.
[^] # Re: License?
Posté par Marc Quinton . Évalué à 3.
hello,
je n'ai aucun problème a payer 50, 100, 500€ par an, si on m'explique en Francais dans le texte pourquoi je paie, pour combien d'utilisateurs par rapport à l'usage que j'en fait dans mon entreprise.
Je souhaitais juste avoir une précision et faisait part de mon étonnement du bundle de la licence pour un produit dont je n'ai pas besoin (Docker Desktop) et le besoin de dowload avec des limites que je peux gérer plus finement, moyennant finance.
Si un compte pro suffit a couvrir mon besoin (téléchargement assez massif sur le docker-hub) alors, oui, moi ca me convient. Massif, c'est plusieurs centaines voir milliers de téléchargements par jour ou semaine. Et puis, avec le cache, je n'ai en général que très peu de requetes qui passent à travers le cache et se retrouvent sur le docker-hub.
Mais j'ai aussi des postes utilisateurs sur 2 réseaux Internet différents. Par ailleurs, étant dans un service public, avec le grand réseau RIE, je me demande ce que ca donne, si tous les .gouv.fr se retrouvent avec la même IP sur le docker-hub.
A aucun moment je ne me suis permis de critiquer la démarche de la société en charge du service. Tout service, a des limites dans le gratuit.
[^] # Re: License?
Posté par CrEv (site web personnel) . Évalué à 3.
Je crains que les pages n'existent qu'en Francais pour le moment.
le truc c'est que pour pouvoir répondre plus précisément il faut des données plus précises. Genre "des centaines voir milliers de téléchargements par jour ou semaine" c'est pas assez précis, on va de centaines par semaine à milliers par jours :-)
Maintenant, la vraie solution pour ne pas être embêté par les limites de pull, c'est d'être authentifié. Que les outils (genre les CI) soient authentifiées, comme les utilisateurs.
Le type de compte dépend de plusieurs facteurs (genre desktop et + 250 personnes / $10 millions de revenu annuel alors c'est forcément payant). Mais ca dépend aussi de ce qui est recherché. Typiquement si l'entreprise est assez grosse, l'offre business contient entre autre le SSO, ce qui simplifie grandement les choses.
Mais encore une fois, tout ceci dépend avant tout de ce qui est souhaité, de la taille, des usages.
Dans des cas spécifiques avec une seule IP, il y a aussi des possibilités de le prendre en compte de notre côté (j'entend par là non soumis au pull rate limiting). Par contre les conditions exactes je ne les connais pas, il faut voir avec les équipes sales ou support.
[^] # Re: License?
Posté par Psychofox (Mastodon) . Évalué à 5. Dernière modification le 13 mai 2022 à 13:46.
Si tu utilises gitlab, tu peux utiliser la registry de gitlab. Ça limite largement les pulls à faire sur le docker hub.
On peut critiquer le fait que docker propose des applis proprios mais je trouve normal qu'il monétisent un accès au repo après une certaine limite étant donné les coûts d'infrastructure que cela apporte. Ça ne bloque pas les usages léger / hobby et les business peuvent choisir de payer, financer toute autre alternative et/ou maintenir leurs images de base. On peut déjà faire plein de truc avec une dockerfile FROM scratch.
[^] # Re: License?
Posté par Marc Quinton . Évalué à 2.
c'est exactement ce qu'on fait, mais dans une certaine mesure. Et puis, je suis dans une entreprise assez importante et on ne peut pas forcer les users a faire systématiquement une copie de tous les containers qu'ils utilisent dans notre registry, ou alors pour avoir le meilleur controle possible. Pour le reste, autant utiliser Docker et son serveur applicatif tel qu'il est et c'est fort confortable. Mais se pose la limite des quotas, d'ou ma question. Et je n'ai rien contre un financement participatif sous forme de licence pro sur ce service, dans la mesure ou ca rentre en terme de budget.
[^] # Re: License?
Posté par greenjava . Évalué à 2.
Juste petite remarque en passant, comme ça parle aussi de Gitlab, il existe une manière de mettre en cache les images de manière (presque) transparente dans Gitlab en passant par Dependency Proxy.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.