Autant je comprends docker dans une démarche industrielle avec des microservices d'entreprises pour la scalabilité d'un service avec une connaissance et la construction de son infra docker ...
La plupart des systèmes de paquet sont assez compliqués, et même Ubuntu par exemple qui s'est donné la peine de réduire énormément la complexité a toujours un système hyper complexe De mon côté, auteur de logiciel, j'ai mon code source, typiquement dans un dépôt Git, une clef PGP pour signer mon paquet et un serveur FTP où télécharger (ici upload) mon paquet source, et pourtant je dois traficoter avec 4-5 outils qui sont souvent des empilements d'autres outils... bref, y'a rien de moins marrant que de construire ses paquets.
En regard, docker est assez simple et se prête bien aux techniques d'intégration continue Un Dockerfile est essentiellement une suite de commandes shell, qui en plus bénéficie d'un système de cache.
Les dépendances utilisées peuvent provenir de bien des sources différentes. Le gestionnaire de paquet d'une distribution n'est qu'un moyen comme un autre d'installer des logiciels – c'est souvent le plus puissant mais aussi le plus coûteux en terme de préparation, dès lors que quelque chose est à préparer. Les autres méthodes sont bien-sûr les tarball, mais aussi les système de paquets spécifiques aux langages ou à une communauté (par exemple npm, yarn, opam, quicklisp, gem, pip, composer pour les langages, Emacs a une fonction spéciale pour installer des packages elisp, et il me semble que certains gros logiciels comme sage ont leur propre système de distribution pour des extensions, mais je peux me tromper). Comme le Dockerfile est essentiellement un shell script, cela permet d'utiliser toutes les dépendances qu'on veut sans s'embêter à préparer des paquets pour les logiciels manquants pour toutes les distributions qu'on souhaite toucher.
Pour des logiciels d'une telle complexité, l'homogénéité des déploiements facilite la maintenance. Pour l'équipe qui développe, le nom de l'image utilisée contient en elle-même toutes les informations de version nécessaires pour essayer de reproduire un bug signalé, par exemple. Il y a régulièrement eu des initiatives pour distribuer les logiciels de cette manière (sur PC-BSD p.ex., il me semble que Ubuntu ou Cent-OS avait aussi introduit une forme de paquet "blob" il y a quelques années, sans que je sache ce qu'ils sont devenus, ou encore les "App bundle" de Mac OS-X, ou les applications Windows pour quitter le monde du libre).
Probablement pour à peu près les mêmes raisons, en 2001, lorsque Open Office est sorti il était distribué soit en source soit en binaires précompilés mais pas de véritables paquets. Lien Wayback Machine
[^] # Re: Docker fourre-tout ?
Posté par Michaël (site web personnel) . En réponse à la dépêche L’application « OnlyOffice pour Nextcloud » est disponible. Évalué à 7. Dernière modification le 08 novembre 2017 à 18:51.
Oui à la base c'est à ça que ça sert... cependant force est de constater que docker a un certain succès comme système de distribution ad-hoc.
J'y vois plusieurs raisons:
La plupart des systèmes de paquet sont assez compliqués, et même Ubuntu par exemple qui s'est donné la peine de réduire énormément la complexité a toujours un système hyper complexe De mon côté, auteur de logiciel, j'ai mon code source, typiquement dans un dépôt Git, une clef PGP pour signer mon paquet et un serveur FTP où télécharger (ici upload) mon paquet source, et pourtant je dois traficoter avec 4-5 outils qui sont souvent des empilements d'autres outils... bref, y'a rien de moins marrant que de construire ses paquets.
En regard, docker est assez simple et se prête bien aux techniques d'intégration continue Un Dockerfile est essentiellement une suite de commandes shell, qui en plus bénéficie d'un système de cache.
Les dépendances utilisées peuvent provenir de bien des sources différentes. Le gestionnaire de paquet d'une distribution n'est qu'un moyen comme un autre d'installer des logiciels – c'est souvent le plus puissant mais aussi le plus coûteux en terme de préparation, dès lors que quelque chose est à préparer. Les autres méthodes sont bien-sûr les tarball, mais aussi les système de paquets spécifiques aux langages ou à une communauté (par exemple npm, yarn, opam, quicklisp, gem, pip, composer pour les langages, Emacs a une fonction spéciale pour installer des packages elisp, et il me semble que certains gros logiciels comme sage ont leur propre système de distribution pour des extensions, mais je peux me tromper). Comme le Dockerfile est essentiellement un shell script, cela permet d'utiliser toutes les dépendances qu'on veut sans s'embêter à préparer des paquets pour les logiciels manquants pour toutes les distributions qu'on souhaite toucher.
Pour des logiciels d'une telle complexité, l'homogénéité des déploiements facilite la maintenance. Pour l'équipe qui développe, le nom de l'image utilisée contient en elle-même toutes les informations de version nécessaires pour essayer de reproduire un bug signalé, par exemple. Il y a régulièrement eu des initiatives pour distribuer les logiciels de cette manière (sur PC-BSD p.ex., il me semble que Ubuntu ou Cent-OS avait aussi introduit une forme de paquet "blob" il y a quelques années, sans que je sache ce qu'ils sont devenus, ou encore les "App bundle" de Mac OS-X, ou les applications Windows pour quitter le monde du libre).
Probablement pour à peu près les mêmes raisons, en 2001, lorsque Open Office est sorti il était distribué soit en source soit en binaires précompilés mais pas de véritables paquets. Lien Wayback Machine