Dans le processus de création de l'image, nous devons prêter attention à quelques points : 1. Le système de fichiers est UnionFs, et chaque RUN dans le Dockerfile générera une couche. Nous devons donc nettoyer les données générées après chaque RUN. Car le résultat généré (taille de 3G) est une superposition linéaire des tailles de chaque couche. 2. Pourquoi les images officielles sont-elles généralement trop petites ? Utilisons mysql:5.6 comme référence pour analyser :
EXÉCUTER apt-get update && apt-get install -y perl --no-install-recommends && rm -rf /var/lib/apt/lists/* Après la mise à jour de la version, supprimez-la les fichiers du package mis en cache d'apt. De manière générale, ce dossier occupera environ 100M selon les situations.
RUN { ...&& apt-get update && apt-get install -y mysql-server="${MYSQL_VERSION}" && rm -rf /var/lib/apt/lists/* && rm -rf /var/lib/mysql && mkdir -p /var/lib/mysql Après avoir installé la base de données, supprimez les fichiers du package mis en cache comme d'habitude. La suppression de /var/lib/mysql peut effacer la base de données exemple.
Jetons un coup d'œil au package vim le plus couramment utilisé sur hub.docker.com. Nous avons constaté que l'image haron/vim fait 300 Mo et utilise scratch comme image de base.
Après une recherche approfondie sur hub.docker.com, je n'ai pas trouvé d'image MySQL basée sur centos. Personnellement, j'estime que le problème est dû au fait que les packages mis en cache ne sont pas supprimés.
En ce qui concerne le problème de taille de l'image de base mentionné par le frère @ShawnTaoo, j'ai également mené l'enquête suivante : centos : dernier 190 + Mo, debian :jessie : 130+Mo, ubuntu : dernier 180+Mo
Vous pouvez vérifier le fichier docker de l'image officielle de mysql. L'image de base doit être différente. En général, de nombreuses images de base officielles sont très petites. Par exemple scratch, mais si vous utilisez un ubuntu ou quelque chose du genre, ce sera environ 180M (merci à @ imdjh de m'avoir corrigé, je n'ai pas remarqué les centos).
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Dans le processus de création de l'image, nous devons prêter attention à quelques points :
1. Le système de fichiers est UnionFs, et chaque RUN dans le Dockerfile générera une couche. Nous devons donc nettoyer les données générées après chaque RUN. Car le résultat généré (taille de 3G) est une superposition linéaire des tailles de chaque couche.
2. Pourquoi les images officielles sont-elles généralement trop petites ? Utilisons mysql:5.6 comme référence pour analyser :
Jetons un coup d'œil au package vim le plus couramment utilisé sur hub.docker.com. Nous avons constaté que l'image haron/vim fait 300 Mo et utilise scratch comme image de base.
Après une recherche approfondie sur hub.docker.com, je n'ai pas trouvé d'image MySQL basée sur centos. Personnellement, j'estime que le problème est dû au fait que les packages mis en cache ne sont pas supprimés.
En ce qui concerne le problème de taille de l'image de base mentionné par le frère @ShawnTaoo, j'ai également mené l'enquête suivante : centos : dernier 190 + Mo, debian :jessie : 130+Mo, ubuntu : dernier 180+Mo
Référence :
analyse miroir mysql
analyse haron/vim
Analyse d'image de base Centos
Analyse d'images de base Ubuntu
Pas étonnant que mon package d'installation n'ait augmenté la 3G qu'après avoir installé une lampe. Il s'avère qu'un mysql a ajouté 1G
Vous n'avez pas encore commencé
Il est recommandé de terminer le tutoriel d'introduction avant de jouer
Commit sans supprimer les fichiers temporaires
Vous pouvez vérifier le fichier docker de l'image officielle de mysql. L'image de base doit être différente. En général, de nombreuses images de base officielles sont très petites. Par exemple
scratch, mais si vous utilisez un ubuntu ou quelque chose du genre, ce sera environ 180M (merci à @imdjh de m'avoir corrigé, je n'ai pas remarqué les centos).
Si vous pouvez rendre votre Dockerfile public, tout le monde peut vous aider à y jeter un œil. Le principal problème est l'écriture du Dockerfile