Le chiffre ne pouvant pas passer inaperçu, tant il signifie un gain de temps dans pratiquement tous les cas de figure.
D’abord pour Canonical, puisque l’argument --no-install-recommends pour Dockerfiles leur permet un temps de construction des images réduit de 15 %. Il permet de ne pas inclure les paquets recommandés, uniquement les dépendances principales.
Ensuite pour les utilisateurs et administrateurs. Une taille réduite de 60 % signifie des téléchargements nettement plus rapides, moins d’espace consommé et des manipulations plus aisées.
Pour autant, l’éditeur se fait épingler par Phoronix. Le très précis Michael Larabel relève ainsi que l’argument existe depuis longtemps, se demandant ce qui a pu prendre autant de temps chez Canonical pour s’en servir.
Il note que la suppression des paquets recommandés peut poser éventuellement problème dans quelques rares cas de figure. Mais selon Canonical, aucun souci n’a été trouvé pour les paquets Docker visant des projets web.
Commentaires (8)
#1
Avec Busybox on peut faire des images de moins de 1M
" />
#2
on dirait que les gens découvrent l’embarqué et ses contraintes ;)
#3
Quel rapport entre Docker et l’embarqué ?
#4
La choucroute.
" />
#5
Je crois qu’il s’agit d’un quiproquo ici. Le blog de Canonical ne parle pas de leurs images officielles (come je l’ai compris) mais des images qu’ils construisaient en interne (basées sur leurs images officielles).
Bref ils ne partagent finalement qu’une astuce que bon nombre connaisse déjà mais qui a sûrement pu passer inaperçue pour les nouveaux venus.
Donc je ne m’attends pas à voir les images Ubuntu de Docker Hub diminuer drastiquement.
#6
(suite à mon précédent commentaire)
Je crois que ce quiproquo, phoronix l’a fait aussi. Du moins c’était ma conclusion après avoir leur article ce week-end.
#7
docker et l’embarqué même combat ici: chercher la plus petite empreinte, enlever la maximum de bibliothèques et binaires inutiles (pour la taille et pour la sécurité, dans l’embarqué ce serait aussi pour réduire l’empreinte mémoire). Voilà pour l’explication.
#8
Justement, le domaine d’utilisation de docker n’a pas les mêmes contraintes que l’embarqué.
Tu fais juste un rapprochement de 2 activités très différentes.