Carnet de notes

[Lecture] Refac­to­ring a Docker­file for image size

Lu sur le web :

There’s been a welcome focus in the Docker commu­nity recently around image size. Smal­ler image sizes are being cham­pio­ned by Docker and by the commu­nity. When many images clock in at multi-100 MB and ship with a large ubuntu base, it’s greatly needed.

— sur Repli­ca­ted

J’aime bien l’ap­proche de l’ar­ticle, qui tient plus à reti­rer le super­flu qu’à partir sur des confi­gu­ra­tions peu stan­dard. Main­te­nant, qu’y gagne-t-on ?

L’es­pace disque est-il vrai­ment un enjeu majeur aujourd’­hui par rapport au temps qu’on y passe et à la perte éven­tuelle de souplesse ?

Le système de système de fichier par couche devait mutua­li­ser les télé­char­ge­ments et les espaces de stockage. Ai-je mal compris ?

Publié

dans

par

Éric

Étiquettes :

Commentaires

3 réponses à “[Lecture] Refac­to­ring a Docker­file for image size”

  1. Avatar de Nicolas Steinmetz
    Nicolas Steinmetz

    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.

    Répondre
  2. Avatar de noname
    noname

    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.

    Répondre
    1. Avatar de Éric
      Éric

      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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *