Lu sur le web :
There’s been a welcome focus in the Docker community recently around image size. Smaller image sizes are being championed by Docker and by the community. When many images clock in at multi-100 MB and ship with a large ubuntu base, it’s greatly needed.
J’aime bien l’approche de l’article, qui tient plus à retirer le superflu qu’à partir sur des configurations peu standard. Maintenant, qu’y gagne-t-on ?
L’espace disque est-il vraiment un enjeu majeur aujourd’hui par rapport au temps qu’on y passe et à la perte éventuelle de souplesse ?
Le système de système de fichier par couche devait mutualiser les téléchargements et les espaces de stockage. Ai-je mal compris ?
3 réponses à “[Lecture] Refactoring a Dockerfile for image size”
L’intérêt est je pense sur le temps de 1er téléchargement et 1er lancement. Si on dit que tu provisionnes des environnements à la volée, à chaque nouvelle machine tu dois télécharger tous tes layers. En partant d’une image de 5 Mo pour Alpine plutöt que 150+ Mo environ, tu réduis cette phase d’initialisation. Après, ça suppose que tout le monde se mette à Alpine (qui est plutot pas mal par ailleurs ; je m’y suis mis du coup)
Même dans un cluster docker swarm, le cache n’est malheureusement pas partagé.
Après, il y a un intérêt pour Docker Inc de sauvegarder sa bande passante et réduire son stockage ;-)
Si tu prends l’image python par ex, tu n’as pas envie de prendre image debian + python (~ 180 Mo) alors que tu peux faire la même chose avec Alpine (~ qqs 10aines de Mo au max)
Sur le point sécurité, une image alpine est peut être aussi plus simple à maintenir qu’une image debian & co.
C’est surtout une histoire de salubrité technologique, Faire des images légères qui seront du coup plus rapides à déployer et moins couteuses à stocker. Si on peut le faire, pourquoi faire les porcs.
Parce que ça a d’autres impacts : Entre autres sur ta connaissance de la distribution utilisé, sur la maintenance ou rapidité de maintenance des packages sur cette distribution, sur les tests ou garanties (qui ne sont pas les mêmes sur une Debian utilisée sur des centaines millions de box et sur une distrib qui a 1000 fois moins d’utilisateurs), sur l’extensibilité (les Go en moins, il offrent des lib pour plein de choses), sur la capacité à trouver un package ou une lib native qui fait un peu plus que le minimum de base, etc.
C’est un compromis, mais là où ça m’étonnait c’était que le système en couches devait déjà palier aux problèmes d’espace disque sans avoir à faire ça.