Sommaire
- “Portable application development”, qu’ils disaient (parce que “write once, run everywhere” était déjà pris)
- La portabilité, c’est pas automatique
- Les images multi-arch
’Jour ’Nal,
Aujourd’hui, je vais te parler un peu de Docker, parce que j’ai été amené à l’utiliser récemment dans le cadre professionnel et que ça n’a pas été sans mal, alors ça mérite bien un journal.
Je précise que je n’ai rien de particulier contre Docker lui-même. Je dirais même que je trouve le concept intéressant, mais en revanche je n’aime pas du tout la manière dont elle est utilisée, et notamment la tendance à ne plus fournir certains logiciels que sous la forme d’une image Docker.
Un des outils que j’utilise dans le cadre de mon nouveau travail, l’Ontology Development Kit (ODK), est justement dans ce cas. En théorie, l’utilisation est simple, il suffit d’installer Docker Desktop, de faire un docker pull obolibrary/odkfull, après quoi l’ODK est prêt à servir.
Puisque j’écris ce journal, c’est qu’évidemment en pratique ça s’est révélé plus compliqué que ça.1
“Portable application development”, qu’ils disaient (parce que “write once, run everywhere” était déjà pris)
Dans le cadre professionnel, j’utilise un Mac Mini flambant neuf, fourni par mon employeur2. Flambant neuf, ça veut dire non seulement qu’il vient avec le dernier Mac OS (11.3 « Big Sur »), mais aussi et surtout qu’il est équipé d’une de ces nouvelles puces M13 (parfois appelées « Apple Silicon ») basées sur une architecture arm64, au lieu d’une puce Intel x86_64.
Je suis, semble-t-il, le premier utilisateur d’ODK au monde à essayer de l’utiliser sur un processeur M1. Tous les autres (y compris les développeurs d’ODK) ont encore des ordinateurs à puce Intel.
En théorie, la différence d’architecture n’est pas supposée poser problème. Docker Desktop est disponible pour M1, et même si toutes les images sur Docker Hub ne sont pas nécessairement disponibles pour cette architecture, Docker est normalement capable d’exécuter sur un processeur arm64 une image ciblant l’architecture x86_64.
« Normalement », dans la phrase précédente, signifiant qu’en principe, ça marche, mais que des fois, ça crashe :
However, attempts to run Intel-based containers on Apple Silicon machines can crash as QEMU sometimes fails to run the container.
Puisque j’écris ce journal, vous vous doutez bien de quel côté je suis tombé…
En effet, l’ODK, l’outil dont j’ai besoin, et qui n’est disponible sur Docker Hub que pour x86_64 (puisque tous ses développeurs sont sur cette architecture, et tous ses utilisateurs aussi jusqu’à ce que Bibi arrive), ne fonctionne pas sur une machine arm64. La machine virtuelle chargée de l’émulation plante avec une bonne vieille erreur de segmentation qui ne pardonne pas.
La portabilité, c’est pas automatique
Seule solution, créer une image ODK ciblant l’architecture arm64, supprimant ainsi le besoin de la couche d’émulation.
Docker construit par défaut des images ciblant la même architecture que celle sur laquelle il tourne (ce qui est assez logique, c’est aussi ce que fait typiquement un compilateur par exemple : gcc exécuté sur une machine x86_64 produit un binaire pour x86_64). Du coup, en théorie construire une image ODK pour arm64 est supposé être simple, il suffit de faire docker build . depuis les sources d’ODK sur mon Mac Mini à puce M1.
Puisque j’écris ce journal, vous vous doutez bien que la commande docker build . s’est terminée par une erreur.
Là pour le coup, ce n’est plus réellement Docker qui est en cause, mais ODK lui-même. Je ne vais pas détailler tous les problèmes (il y en avait plusieurs), mais en gros, l’image était impossible à construire sur arm64 parce que les développeurs n’avaient pas imaginé que certains paquets dont l’image a besoin pouvaient ne pas être disponibles sous forme précompilée pour arm64.
Juste un exemple pour illustrer : Une des étapes de la construction de l’image était d’installer, entre autres choses, le paquet Python matplotlib. Lorsque le Dockerfile est exécuté sous x86_64, la commande pip install matplotlib trouve facilement un paquet binaire sur PYPI et l’installe comme si de rien n’était. Sous arm64 en revanche, pip ne trouve aucun paquet binaire de matplotlib pour cette architecture (tout simplement parce qu’un tel paquet n’existe pas, pour l’instant du moins), et tente donc de compiler matplotlib depuis les sources… ce qui échoue car certaines dépendances non-Python (donc non-résolvables par pip) ne sont pas présentes sur l’image en cours de construction.
Une fois le problème compris (ce qui peut prendre un peu de temps si comme moi vous n’avez découvert Docker qu’au cours de l’heure précédente), il se règle facilement : ici, il suffisait d’installer les dépendances non-Python de matplotlib (avec apt-get, l’image ODK est basée sur une image Ubuntu) avant de tenter d’installer matplotlib lui-même, permettant à pip de compiler ce dernier si un paquet binaire n’est pas disponible. Mais il illustre un point qu’il est bon de rappeler : la portabilité, ça se travaille — ce n’est pas parce qu’une technologie permet de faire des trucs portables que tout ce que vous faites avec l’est forcément.4
Après avoir réglé un certain nombres de soucis dans le même genre, l’image peut finalement être construite jusqu’au bout, et fonctionne sur mon Mac à puce M1 comme attendu. C’était juste un poil plus long et un chouia plus compliqué que de faire docker pull obolibrary/odkfull, mais bon, au moins ça marche.
Les images multi-arch
Parce « qu’aucun problème ne devrait avoir à être résolu deux fois » (Eric Raymond), j’ai naturellement soumis aux développeurs d’ODK mon patch permettant de construire l’image sous arm64. Ça permet au moins à quiconque souhaitant utiliser ODK sous cette architecture de construire leur propre image, à défaut de pouvoir utiliser une image pré-compilée pour arm64 disponible sur Docker Hub.
Mais ce n’est évidemment guère satisfaisant et il serait éminemment préférable que les utilisateurs de Mac à puce M1 (ou de tout autre ordinateur avec une architecture arm64) puissent simplement télécharger une image d’ODK toute prête, comme le font les autres utilisateurs d’ODK depuis leurs machines x86_645.
À cette fin, Docker offre le concept d’images multi-architectures. C’est-à-dire que derrière un seul nom d’image et une seule étiquette (tag) peuvent se cacher plusieurs images distinctes pour plusieurs architectures différentes.
À titre d’exemple, regardez l’image ubuntu/nginx : derrière l’étiquette 1.18-20.04_beta se trouvent quatre images différentes, pour les architectures x86_64 (aka amd64), arm64, ppc64, et s390. Quelqu’un faisant un docker pull ubuntu/nginx depuis une machine x86_64 récupérera automatiquement l’image pour x86_64, alors que quelqu’un exécutant la même commande depuis un Mac M1 récupérera l’image pour arm64.
Nous allons donc voir maintenant comment créer des images multi-arch de ce genre.
Installer buildx
La première est d’installer et/ou activer buildx, un greffon de Docker spécialement conçu pour la compilation croisée d’images.
Sous MacOS avec Docker Desktop dans une version récente, il n’y a en fait rien de spécial à faire, buildx est déjà installé et activé — contrairement à ce que dit la documentation, il n’est même pas nécessaire d’activer les « fonctionnalités expérimentales ».
Sous GNU/Linux, buildx n’est pas fourni avec Docker 20.10.2, il faut l’installer soi-même :
$ export DOCKER_BUILDKIT=1
$ git clone git://github.com/docker/buildx
$ cd buildx
$ docker build --platform=local -o .
$ install -D -m 755 buildx ~/.docker/cli-plugins/docker-buildxLe démon Docker doit de plus être démarré avec l’option --experimental.
Permettre l’exécution de programmes ciblant une architecture étrangère
La plupart du temps, pour ne pas dire systématiquement, la construction d’une image Docker implique l’exécution de commandes à l’intérieur du conteneur. Quand on construit une image « native » (ciblant la même architecture que la machine sur laquelle elle est construite), pas de problème. Mais pour construire (par exemple) une image arm64 depuis une machine x86_64, cela nécessite de pouvoir exécuter des binaires arm64 sur un processeur x86_64.
D’après la documentation de Docker, le meilleur moyen de construire une image arm64 depuis une machine x86_64 est en réalité de déporter la construction vers une machine arm64, contournant ainsi complètement la difficulté. Le greffon
buildxpermet de faire ça, mais je n’ai pas exploré cette possibilité qui est de toute façon overkill pour les besoins d’ODK.
Pour ceux qui comme moi n’ont pas envie de monter un cluster de machines de build (ou qui n’ont pas les moyens : il faut quand même prévoir une machine par architecture que l’on veut prendre en charge…), buildx permet d’utiliser une couche d’émulation qui rend possible de construire toutes les images souhaitées sur une seule et même machine.
Une fois encore, sous MacOS, il n’y a rien à faire, Docker Desktop est fourni avec cette couche d’émulation déjà en place et prête à l’emploi.
Sous GNU/Linux, cette couche d’émulation repose sur le mode « User » de QEMU, combiné avec le système binfmt_misc du noyau Linux comme décrit ici. En gros, l’idée est d’indiquer au noyau que les binaires arm64 (par exemple) doivent être interprétés par le programme qemu-user-aarch64, une version de QEMU émulant un processeur arm64.
Vous pouvez mettre en place cette couche d’émulation vous-même si vous le souhaitez : installez les versions de QEMU émulant les architectures qui vous intéressent, puis utilisez le script qemu-binfmt-conf.sh (fourni par QEMU) pour configurer le système binfmt_misc.
Attention : Il est important que les différents émulateurs QEMU pour les différentes architectures soient compilés statiquement !
Si vous êtes fainéant, et puisqu’à ce point on est déjà vendu à Docker de toute façon, vous pouvez aussi procéder de la manière suivante :
$ docker pull multiarch/qemu-user-static
$ docker run --rm privileged multiarch/qemu-user-static --reset -p yesLa deuxième commande installera automatiquement la couche d’émulation pour un certain nombre d’architectures (comme arm64, arm/v6, arm/v7, s390, ppc64, riscv64). Attention, contrairement à une installation « manuelle », cette couche n’est pas permanente : elle ne survit pas à un redémarrage de la machine, pour la rétablir après un redémarrage il faut relancer la deuxième commande une fois le démon Docker disponible.
Créer un builder multi-arch
On y est presque. La dernière étape est de créer un builder dédié aux compilations croisées :
$ docker buildx create --name multiarch --driver docker-container --use
L’option --driver docker-container indique que ce builder tournera lui-même dans un conteneur Docker. C’est nécessaire pour la compilation croisée d’images ; le builder par défaut, qui s’exécute dans l’environnement « normal » de l’hôte, ne peut construire que des images ciblant l’architecture native.
Et voilà, buildx est maintenant prêt à servir. Il fournit une commande build qui s’utilise similairement à la commande build standard de Docker, mais qui accepte une option --platform indiquant les plates-formes pour lesquelles généner une image.
Par exemple, pour créer une image ciblant à la fois x86_64 et arm64 :
$ docker buildx build --platform linux/amd64,linux/arm64 -t example/myimage:v1.0.0 --push .
L’option --push instruit Docker de publier immédiatement les images nouvellement générées sur Docker Hub.
Et donc, comme buildx semble effectivement fonctionner exactement comme ses auteurs disent qu’il est censé fonctionner6, après tout cela j’ai le plaisir d’annoncer que dans le futur, les images d’ODK seront disponibles en version x86_64 et en version arm64 (voire même, pendant qu’on y est pourquoi pas, arm/v6, des fois que quelqu’un veuille l’utiliser sur un Raspberry Pi).
-
C’est déjà arrivé que quelqu’un écrive un journal sur un truc informatique qui fonctionne exactement comme ses promoteurs disent qu’il est censé fonctionner ? ↩
-
J’ai bien tenté de demander un PC sous GNU/Linux, sans succès : le service IT préfère un parc uniforme, donc c’est MacOS pour tout le monde. ↩
-
Alors que tous mes collègues sont au mieux sous MacOS 10.15 avec des processeurs Intel, autant pour l’uniformité du parc… ↩
-
Il est très facile d’écrire du code Java qui ne fonctionnera que sous un seul système par exemple. ↩
-
A priori la plupart des utilisateurs d’ODK sont des scientifiques, pas des développeurs. ↩
-
Comme quoi, ça arrive, en fait. ↩
# Titre
Posté par barmic 🦦 . Évalué à 10.
C'est quoi ODK ?
Il est facile d'écrire un programme qui ne s'exécute que sur la machine de son développeur.
Docker n'y est pas pour grand chose, c'est qemu qui fait le taff. Faut bien voir ici que la "portabilité" consiste à installer qemu sur Mac pour qu'il lance linux qui lancera docker. Perso je trouve que docker hors Linux est un gros hack.
J'avais entendu dire que docker sur M1 c'était balbutiant ça a l'air de pas mal fonctionner.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Titre
Posté par gouttegd . Évalué à 5.
Un ensemble d’outils pour faciliter la création et l’édition d’une ontologie, c’est-à-dire en gros la représentation formelle, informatiquement exploitable, d’un domaine de connaissances.
Farpaitement. Mon point est qu’il est facile de croire que le simple fait d’utiliser un outil conçu pour faire du code portable suffit à rendre le code automagiquement portable, ce qui n’est pas le cas. L’outil peut aider mais ne dispense pas le développeur de devoir faire attention à ce qu’il fait si la portabilité est un objectif.
C’est bien possible, mais ce n’est certainement pas l’opinion de Docker (la société) en tout cas. Au contraire, Docker est avancé comme la solution idéale pour les développeurs sous Windows et MacOS. « Linux » est à peine mentionné.
Pour ce que ça vaut, mon expérience est que tant que l’image dont tu as besoin est disponible pour arm64 (ou si tu développes ta propre image et que tu peux donc la construire toi-même), ça marche bien oui. Par contre faire tourner des images x86_64, dans mon cas rien à faire.
[^] # Re: Titre
Posté par barmic 🦦 . Évalué à 2.
Oui, ce qui est intéressant c'est de savoir quel est l'effort de portabilité. Tu mentionne que docker ne fait pas tout et tu le compare à java, mais python ne fait pas particulièrement mieux d'après ton journal.
Docker n'est pas particulièrement portable c'est une techno linux et tu peux utiliser une VM pour t'en servir ailleurs, mais tout programme est portable si on considère qu'utiliser une VM est une option. Tu ne lancera pas de docker swarm, kubernetes ou autre sur windows ou mac os.
CrEv me corrigera, mais globalement Docker Inc se concentre sur le fait de proposer des outils aux développeurs. Comme un sacrés paquets sont sur mac/win, ils proposent des outils pour, mais en terme de déploiement ça pars sur du linux au final. Il me semble que l'intérêt principal pour eux c'est de pouvoir maintenir le status quo machine de bureau non libre avec un déploiement linux.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Titre
Posté par gouttegd . Évalué à 2. Dernière modification le 15 mai 2021 à 18:29.
Ai-je laissé entendre que « Python fait mieux » ?
Encore une fois, mon point est que la portabilité est l’affaire du développeur, pas de la techno qu’il utilise. J’ai cité Java parce que c’est un exemple classique d’une techno visant la portabilité (c’était quand même le slogan du langage à une époque — write once, run everywhere — slogan qui n’a jamais été vrai), mais j’aurais pu faire référence à Python, à Perl, à Qt, à .NET, à Javascript, whatever.
Faudrait aller dire ça à ceux qui éditent le site docker.com, parce que je te jure ils ont vraiment pas l’air au courant. Tiens, petit exercice : cherche « Linux » sur la page d’accueil…
Non non non, on ne dit pas que ça part sur du linux, on dit que ça part sur du Azure, sur du AWS, sur du Google Cloud Platform, au pire on dit que ça part sur du Kubernetes. Mais en tout cas, on dit que ça part sur une plate-forme sérieuse, pas sur un OS développé par des hippies barbus communistes (sinon ça fait tâche sur le business plan, tu te rends pas compte).
Et au passage, ce n’est pas vrai pour tout le monde de toute façon. Par exemple, quasiment tous les utilisateurs d’ODK l’utilisent sous Mac OS (pas le développent, non : l’utilisent).
[^] # Re: Titre
Posté par barmic 🦦 . Évalué à 2.
Je n'invente rien1. Tout le fonctionnement de docker est basé sur linux (j'ai entendu parler de conteneur windows a une époque - avec donc des dockerfiles spécifiques - mais je ne l'ai jamais vu arriver). Docker sur autre chose que linux c'est une vm (ubuntu je crois) + tout ce qu'il faut pour que ça ne se voit pas trop. CrEv est développeur chez eux, s'il me contredit j'en serait fort aise.
Après personnellement je ne considère pas "utiliser une vm" comme étant de la portabilité, je suis peut être le seul à le penser, mais le fait que docker.com parle ou non de linux ne changera pas mon avis.
Je pense qu'une grande de notre incompréhension est ton irrésistible envie troller du marketing. Je te laisse troller tranquille, je ne marcherais plus dedans.
Get to Know Docker Desktop "Docker Desktop handles the setup and teardown of lightweight VMs on both Windows and macOS, using Hyper-V on Windows desktops and Hyperkit on macOS. " ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Titre
Posté par gouttegd . Évalué à 2.
T’as raison, c’est juste un vilain hack, totalement découragé par Microsoft d’ailleurs.
Bah c’est surtout que je ne comprends pas où tu veux en venir à soutenir mordicus que Docker, c’est fait pour tourner sous Linux et que partout ailleurs, c’est juste un hack, un pis-aller.
Mais soit.
/plonk
[^] # Re: Titre
Posté par barmic 🦦 . Évalué à 7.
C'est une vm ubuntu pour avoir un noyau linux. Je n'appelle pas ça portable et c'est important parce que ça permet de comprendre le genre de problème que tu as eu et de comprendre les mécanismes qui sont en jeux. Les discours qui "vendent" docker n'entrent pas dans ce genre de considérations pourtant ton journal montre que ça n'est pas dans conséquence. Par exemple les binaires que tu build sont des elf pas des macbinary.
Comprendre ça montre permet de faire un choix pour ce qui est de fournir son logiciel en multiplateforme. Par exemple quitte à utiliser une machine virtuelle tu peux fournir une machine virtuelle plus simple et plus légère avec juste ton outil. Ça réduit aussi une partie de la complexité.
J'ai fais la distinction dans mon précédent commentaire de ce qui relève du fait (c'est une vm + une deamon + un conteneur) de qui relève du jugement (appeller ça portable c'est très très très discutable).
Ton journal est l'exemple parfait de ce que cela implique. Je ne dis pas que c'est mal, mais que c'est un gros hack et que si ça paraît fonctionner de soit la plupart du temps (les équipes docker font du bon boulot) ça n'en a pas moins des conséquences.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Titre
Posté par barmic 🦦 . Évalué à 3.
Intéressant, je n'étais pas allé voir. La doc est intéressante : https://docs.microsoft.com/fr-fr/virtualization/windowscontainers/deploy-containers/linux-containers
Ils ont implémenté des conteneurs windows et docker peut être utilisé pour les manipuler. Évidement ce sont des conteneurs les conteneurs windows tournent sous windows et ceux linux qui tournent sous linux.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Titre
Posté par claudex . Évalué à 3.
C'est là dessus que se base kubernetes sur Windows il me semble.
« 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: Titre
Posté par CrEv (site web personnel) . Évalué à 5.
Je t'assure qu'on est tout à fait au courant.
C'est pour le moins assez ridicule de croire qu'on ne sait pas comment fonctionne un conteneur ni à quel point c'est portable ou non…
Lapin compris. C'est sensé démontrer quoi ?
Docker (ou toute autre solution de conteneur) est avant tout fait pour être exécuté sur des serveurs. Anéfé, des serveurs linux. Et aussi surprenant que ça puisse paraitre, mais nombre de conteneurs sont déployés sur des machines fonctionnant dans des clouds 🤷♂️
Quoi qu'il en soit, les conteneurs (Docker en particulier) sont une technologie Linux.
"ceux qui éditent le site docker.com" le savent très bien puisqu'on continue à maintenir l'engine qui permet d'exécuter ses conteneurs sous Linux.
Maintenant, aussi surprenant que cela puisse paraître, beaucoup de développeurs sont sous Windows ou Mac. Docker ne fonctionnant pas sur Windows ou Mac (oui j'omet volontairement les conteneurs windows) nous fournissons aussi un outil, Docker Desktop, permettant d'exécuter, principalement dans le but de les développer, des conteneurs linux sur ces environnements. Et oui, étrangement, la page principale du site cible avant tout ces environnements.
C'est vrai, chez Docker on est tellement contre les hippies barbus communistes que ça fait tâche que docker engine, cli, compose, distribution (et d'autres) sont tous open source.
[^] # Re: Titre
Posté par gouttegd . Évalué à 3. Dernière modification le 16 mai 2021 à 22:22.
Que Docker.com ne met absolument pas en avant le fait que Docker est une « techno Linux ». Quiconque arrive sur Docker.com pour comprendre de quoi il s’agit voit en premier que c’est un truc pour Windows et Mac OS.
Du coup je trouve ça difficilement conciliable avec l’affirmation de barmic selon laquelle Docker pour autre chose que Linux est un « hack ».
Dont acte. Les seuls utilisateurs de Docker que je connaisse ne l’utilisent que sous Mac OS (et non, pas seulement pour développer : les images finales sont utilisées sous Mac OS), donc je n’ai sans doute pas une vision correcte des usages majoritaires de Docker.
Je sais bien, je l’ai installé sur ma machine perso depuis les sources (je ne l’aurais pas installé sur cette machine s’il n’était pas libre, il serait resté confiné à ma machine professionnelle).
Comme l’a très justement noté barmic, c’était un troll dirigé contre le service marketing de Docker. Parce qu’avoir tout son business fondé sur une technologie Linux et tout faire pour que le nom « Linux » apparaisse le moins possible, je trouve ça au minimum cocasse, voire que ça a un côté foutage de gueule.
[^] # Re: Titre
Posté par CrEv (site web personnel) . Évalué à 4.
Probablement oui.
Encore une fois, qu'est ce que ça démontre ? Va sur https://docs.docker.com et tu verra que Linux est présent.
Là tu es juste en train de te rendre compte que la majorité des développeurs sont sous windows / mac et donc forcément la page d'accueil cible ces plateformes puisque ce sont là où les utilisateurs sont (et que en outre Docker Desktop n'est présent que sur windows et mac car sous linux ça juste marche).
Mais tu te trompes. Tout n'est pas fait pour que le nom linux apparaisse le moins possible. Maintenant ça apporterait quel bénéfice d'avoir le mot linux sur la page d'accueil ? La page d'accueil ne rentre pas dans les détails de ce qu'est un conteneur. Ben oué, on ne peut pas tout mettre non plus.
[^] # Re: Titre
Posté par CrEv (site web personnel) . Évalué à 4.
C'est à dire ?
Enfin outre qu'un conteneur docker c'est avant tout des primitives linux donc forcément hors linux cela implique de l'émulation quelque part.
Mais à part ça ?
Docker Desktop sur M1 ça marche. Avec des images arm.
Après oué, forcément, faire tourner des images x86 dessus c'est plus compliqué. Comme à l'époque où les macs ont migrés sous x86, faire tourner les anciens programmes ppc c'était pas toujours évident.
[^] # Re: Titre
Posté par barmic 🦦 . Évalué à 6.
Tout l'intérêt de docker c'est de ne pas utiliser d'émulation avoir de l'émulation rend tout de suite l'outil bien moins pertinent. J'entends qu'il existe des gens qui utilisent d'autres OS, je comprends que ça existe, mais c'est un pis-aller tout de même. D'autant plus quand il s'agit comme ça a l'air d'être le cas ici d'avoir un conteneur. host → VM → docker → conteneur en 1:1 à chaque fois c'est clairement questionnable.
Je dis ça, j'apprécie docker. Je l'utilise au quotidiens et ma prod tourne avec.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Titre
Posté par gouttegd . Évalué à 10.
Et encore tu ne connais pas le pire. Un des principaux outils de l’ODK est un programme écrit en… Java. Qui fonctionne parfaitement bien sur GNU/Linux et sur Mac OS.
Donc sous Mac OS, on utilise Docker pour faire tourner un système GNU/Linux à l’intérieur duquel on lance une JVM pour faire tourner un programme Java… au lieu de simplement installer un JRE et d’utiliser le programme Java directement…
Je ne sais pas à quel moment l’informatique moderne va s’écrouler sous son propre poids à force d’empiler des technos en dépit du bon sens, mais si ça pouvait ne plus trop tarder ce serait pas mal…
[^] # Re: Titre
Posté par groumly . Évalué à 3. Dernière modification le 16 mai 2021 à 22:34.
Quel jre/jvm? Oracle, corretto, Azul, autre?
Et quelle version du jre?
Et le script de lancement, il va ou? (Non, pas la, non)
Et ça tourne sous quel utilisateur, sous quel port?
Et comment tu fais pour sandboxer l’accès au disque?
Le but de docker est pas de faire tourner l’application, c’est de contraindre tout ce qui est généralement hors du contrôle des distributeurs de l’appli pour simplifier les déploiements et réduire à peau de chagrin les problèmes du genre “l’appli plante quand tu lui passes telle requête sur le jre 11.42 sur Debian testing parce que la version qu’ils ont poussé dans testing a un bug”, ou les blagues du genre “on a besoin de jdk 16, Mais il est pas package pour cette distro, donc il faut l’installer à la mano”.
Donc, oui, ca fait prendre des détours, c’est sur, mais le bon sens dit justement que c’est plus simple de faire tourner une jvm dans Linux dans macOS, parce que la virtualization et la containérisation est une technologie bien mieux maîtrisée que d’expliquer à toute la planète qu’il faut utiliser telle version de tel environment.
et je touche même pas aux problématiques de production, à savoir comment recréer un environment a l’identique rapidement, et autres joyeusetés que les devopseurs se coltinent toute la journée.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Titre
Posté par gouttegd . Évalué à 6.
Pour beaucoup d’applications Java, ces questions seraient pertinentes en effet.
Mais ici, le programme Java en question est constitué d’un unique JAR et se lance de la façon la plus bête du monde pour un programme Java :
java -jar robot.jar args....Et ce n’est pas une application serveur, le programme doit tourner sous l’identité de l’utilisateur qui le lance (et qui possède les fichiers que le programme doit traiter), tout simplement.
On n’a quand même pas attendu Docker pour écrire des programmes qui, à partir d’un fichier de données en entrée, sont capables de produire les mêmes données de sortie indépendamment de la plate-forme, de la version du JRE ou de la phase de la Lune.
Je maintiens que l’utilisation de Docker pour l’ODK est overkill.
[^] # Re: Titre
Posté par Psychofox (Mastodon) . Évalué à 6.
Je dirais que c'est déjà bien assez pour en faire un gros hack.
Mais ce hack est devenu un peu la raison d'être de docker vu qu'on n'a plus vraiment besoin de docker sous linux pour faire tourner des containers et qu'il devient déprécié par pas mal de trucs (dont kubernetes qui ne l'utilise plus) et que les entreprises tournent maintenant le dos au swarm mode.
[^] # Re: Titre
Posté par barmic 🦦 . Évalué à 2.
Oui et non. Docker hub est vachement utilisé, compose aussi, buildah est probablement sympa mais encore jeune je ne l'ai pas encore vu beaucoup utilisé (je n'ai pas vu de shift massif de l'un vers l'autre) et j'en oublie probablement.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Titre
Posté par Psychofox (Mastodon) . Évalué à 4.
Tu as raison pour le docker hub quu reste la registry publique principal (mais pas unique).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.