je trouve difficile de lire le Dockerfile directement sur Docker Hub
L'une des difficultés (pour expliquer que c'est rarement aussi simple qu'on le croit) est que à la base d'une registry sont les images. Construire une image à partir d'un Dockerfile n'est qu'une des options.
Les deux derniers semblent bizarre pour des images de containers
Non non, c'est pas si bizarre. Il y a pas mal de choses qu'on pourrait présenter. Je n'avais pas tellement pensé en terme de dépendances, mais c'est je vais le proposer. A partir d'une image permettre de connaitres les autres images utilisées lors du build est intéressant.
Une autre information qui m'intéresse d'afficher serait le nombre d'images basées sur celle-ci. Genre combien d'images sont basées sur alpine:3.
Ce sont des choses dont on discute (même si je n'ai aucune information à communiquer sur une potentielle sortie).
Oui c'est pas simple les images "de base". C'est pas simple car les usages sont très variés. Entre autre forcer un utilisateur non root si l'image n'est utilisée que comme base pour construire une autre, ben c'est pas top côté facilité d'usage. Par contre non root serait mieux d'un point de vue sécurité.
Le tout étant affaire de compromis. Mais la première étape serait en effet de présenter ces informations.
Juste pour préciser un peu plus le commentaire précédent, je bosse chez Docker dans l'équipe de dev en charge de ce qu'on regroupe sous le terme de Trusted Content regroupant les images officielles (Docker Official Images, DOI), les éditeurs vérifiés (Docker Verified Publishers) et le programme de sponsor des projets Open Source (Docker Sponsored Open Source).
Et entre autre on travaille sur la qualité des images.
Dans ce sens je suis assez curieux de vues des utilisateurs sur ce qui fait ou non une image de qualité.
Pour prendre un exemple, les images utilisant root ou spécifiant un utilisateur. C'est pas un sujet si simple, car certaines images (par exemples des images de bases) doivent plutôt rester sur root. Par contre un service qui tourne, probablement pas. Mais au final il n'y a pas un consensus absolu sur la question.
Il y a un problème de qualité générale et en effet c'est difficile de trier le bon grain de l'ivraie.
Vu que c'est l'un des sujets sur lesquels je bosse, ca m'intéresse.
Qu'est ce qui ferait qu'une image est de meilleure qualité qu'une autre ? Quels seraient les critères sur lesquels se baser ?
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 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.
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.
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.
Malgré les réponses de CrEV (qui n'est clairement pas neutre, et c'est normal)
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.
On voit clairement que Linux est le parent pauvre / n'est pas la cible des décideurs de chez Docker.
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
j'ai l'impression que Docker n'a pas trop levé le petit doigt pour les développeurs sous Linux
C'est dommage que ce soit l'impression qui en ressorte.
Ç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.
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.
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.
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é.
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…
Je me contrefiche du service en ligne
Genre jamais, jamais tu n'utilises la moindre image en provenance de docker hub?
Idéalement, j'aurais voulu un Docker Desktop open source. Depuis le changement de licence
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
Sans en savoir plus c'est quand même assez compliqué de répondre précisément. Néanmoins, plusieurs choses.
il se trouve que les quotas peuvent être assez vite consommé: 100 téléchargements toutes les 6 heures
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 pull ne 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.
on voit un bundle Docker-desktop avec des quotas, ce qui n'interesse pas nécessairement toutes les entreprises.
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.
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.
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.
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 :
Docker Desktop remains free for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects.
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.
En soit docker desktop ne permet pas de faire un docker run super 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.
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.
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?"
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.
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.
Avec docker-desktop, le message transmis est "Un conteneur, c'est comme une machine virtuelle, mais avec une baleine"
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 ^_-
ça empêche aussi les gens d'en découvrir plus sur l'outil
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.
sous windows c'était obligatoire pour de vraies raisons
C'est toujours pour de vraies raisons sous linux, pas les mêmes certes.
autant sous Linux, c'est dommage de ne pas avoir le choix
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 default et hop tu es sur le système de base.
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.
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é.
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.
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.
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.
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.
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
$ docker run --runtime=sysbox-runc -it any_image
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).
Je n'ai plus la vérification GPG faite par apt, je fais directement confiance à la gestion du service publique Docker Hub
A priori ce n'est pas le cas pour grafana, mais il est tout à fait possible de signer les images et de forcer le client Docker pour ne récupérer que des images signées.
Je n'ai par contre pas vérifié si ca peut fonctionner avec podman par contre. https://docs.docker.com/engine/security/trust/
Maintenant, cela nécessite surtout que l'éditeur de l'image signe, ce n'est pas automatique.
Juste un détail car je pense que je ne l'ai pas vu, mais une bonne pratique reste de sélectionner le tag souhaité et de ne pas dépendre de manière implicite du tag latest.
D'ailleurs, comment tu mets à jour ? Aujourd'hui latest semble être 8.5.1, mais si demain il y a une 8.5.2 comment ca se passe ?
L'avantage si tu force le tag dans ton service c'est que la mise à jour (et donc le pull de la nouvelle image) sera assez transparent puisque tu n'as qu'à changer la version dans le ficher de service et le redémarrer.
[^] # Re: Titre
Posté par CrEv (site web personnel) . En réponse au journal Comment sécurisez-vous les images docker externes ?. Évalué à 5.
L'une des difficultés (pour expliquer que c'est rarement aussi simple qu'on le croit) est que à la base d'une registry sont les images. Construire une image à partir d'un Dockerfile n'est qu'une des options.
Maintenant, les choses évoluent dans le bon sens. Voici par exemple la vue de l'image
python:latest: https://dso.docker.com/images/python/digests/sha256%3Ac43926b6865b221fb6460da1e7e19de3143072fc6be8b64cb1e679f90c7fcaa3Ce n'est pas vraiment le Hub, c'est basé sur atomist qu'on a racheté il y a quelques temps.
Entre autres choses, le Dockerfile est associé.
C'est orienté vulnérabilités mais c'est une base pour beaucoup d'autres choses.
Un truc qui peut aider, c'est le SBOM d'une image : https://docs.docker.com/engine/sbom/
Non non, c'est pas si bizarre. Il y a pas mal de choses qu'on pourrait présenter. Je n'avais pas tellement pensé en terme de dépendances, mais c'est je vais le proposer. A partir d'une image permettre de connaitres les autres images utilisées lors du build est intéressant.
Une autre information qui m'intéresse d'afficher serait le nombre d'images basées sur celle-ci. Genre combien d'images sont basées sur
alpine:3.Ce sont des choses dont on discute (même si je n'ai aucune information à communiquer sur une potentielle sortie).
[^] # Re: Titre
Posté par CrEv (site web personnel) . En réponse au journal Comment sécurisez-vous les images docker externes ?. Évalué à 4.
Oui c'est pas simple les images "de base". C'est pas simple car les usages sont très variés. Entre autre forcer un utilisateur non root si l'image n'est utilisée que comme base pour construire une autre, ben c'est pas top côté facilité d'usage. Par contre non root serait mieux d'un point de vue sécurité.
Le tout étant affaire de compromis. Mais la première étape serait en effet de présenter ces informations.
[^] # Re: Titre
Posté par CrEv (site web personnel) . En réponse au journal Comment sécurisez-vous les images docker externes ?. Évalué à 6.
Juste pour préciser un peu plus le commentaire précédent, je bosse chez Docker dans l'équipe de dev en charge de ce qu'on regroupe sous le terme de Trusted Content regroupant les images officielles (Docker Official Images, DOI), les éditeurs vérifiés (Docker Verified Publishers) et le programme de sponsor des projets Open Source (Docker Sponsored Open Source).
Et entre autre on travaille sur la qualité des images.
Dans ce sens je suis assez curieux de vues des utilisateurs sur ce qui fait ou non une image de qualité.
Pour prendre un exemple, les images utilisant
rootou spécifiant un utilisateur. C'est pas un sujet si simple, car certaines images (par exemples des images de bases) doivent plutôt rester surroot. Par contre un service qui tourne, probablement pas. Mais au final il n'y a pas un consensus absolu sur la question.[^] # Re: Titre
Posté par CrEv (site web personnel) . En réponse au journal Comment sécurisez-vous les images docker externes ?. Évalué à 4.
Vu que c'est l'un des sujets sur lesquels je bosse, ca m'intéresse.
Qu'est ce qui ferait qu'une image est de meilleure qualité qu'une autre ? Quels seraient les critères sur lesquels se baser ?
[^] # Re: Applications that only use SSL/TLS are not impacted by this issue.
Posté par CrEv (site web personnel) . En réponse au lien Correction d'une faille critique dans OpenSSL, publiée le 1er novembre. Évalué à 5.
Hum, si je ne me trompe ce n'est pas celle-ci.
Celle-ci est déclarée corrigée en
3.0.6et est de sévéritélow: https://www.openssl.org/news/vulnerabilities.htmlCelle dont il est question dans le lien est de sévérité
criticalet est corrigée en3.0.7A ma connaissance il n'y a pas encore d'identifiant de CVE publié.
[^] # Re: License?
Posté par CrEv (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. É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: Modèle de conteneurisation
Posté par CrEv (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. É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: Podman-Desktop-Companion
Posté par CrEv (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. É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.
[^] # Re: Podman-Desktop-Companion
Posté par CrEv (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. É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: License?
Posté par CrEv (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. É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: Podman-Desktop-Companion
Posté par CrEv (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. É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 CrEv (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. Évalué à 4.
Aucun problème, la version Linux est dispo maintenant !
[^] # Re: License?
Posté par CrEv (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. Évalué à 4.
L'entreprise étant de droit américain elle respecte les lois américaines, oui.
[^] # Re: License?
Posté par CrEv (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. É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 CrEv (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. É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: Modèle de conteneurisation
Posté par CrEv (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. É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: Merci
Posté par CrEv (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. É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
[^] # Re: Podman-Desktop-Companion
Posté par CrEv (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. É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: Modèle de conteneurisation
Posté par CrEv (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. É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 CrEv (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. É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: Podman-Desktop-Companion
Posté par CrEv (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. É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: Modèle de conteneurisation
Posté par CrEv (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. É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) . En réponse au journal Docker Desktop 4 Linux et rootless containers. É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: Intégration sysbox dans runC
Posté par CrEv (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. É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).
# signature
Posté par CrEv (site web personnel) . En réponse au journal Utiliser Podman en mode rootless pour exécuter en service des containers rootless. Évalué à 7.
A priori ce n'est pas le cas pour grafana, mais il est tout à fait possible de signer les images et de forcer le client Docker pour ne récupérer que des images signées.
Je n'ai par contre pas vérifié si ca peut fonctionner avec podman par contre.
https://docs.docker.com/engine/security/trust/
Maintenant, cela nécessite surtout que l'éditeur de l'image signe, ce n'est pas automatique.
Juste un détail car je pense que je ne l'ai pas vu, mais une bonne pratique reste de sélectionner le tag souhaité et de ne pas dépendre de manière implicite du tag
latest.D'ailleurs, comment tu mets à jour ? Aujourd'hui
latestsemble être8.5.1, mais si demain il y a une8.5.2comment ca se passe ?L'avantage si tu force le tag dans ton service c'est que la mise à jour (et donc le pull de la nouvelle image) sera assez transparent puisque tu n'as qu'à changer la version dans le ficher de service et le redémarrer.