Existe-t-il un conteneur utilisant cette image MySQL ? Ou avez-vous docker tagrecréé cette image ? Ou utiliser d'autres versions du miroir MySQL ? Ou utilisez-vous une image basée sur debian:jessie ?
Sachez qu'une image n'est pas un fichier unique, mais un ensemble de couches de stockage. Lorsque vous exécutez docker rmi -f mysql, vous supprimez en fait le mysql:latest ce tag, donc la première ligne est généralement Untagged: mysql:latest.
La logique suivante est que s'il n'y a pas d'autre tag pointant vers la couche de stockage, la couche de stockage sera effectivement supprimée, puis continuera à demander si la couche de stockage suivante est toujours utilisée et ne le sera pas. continuez à le supprimer jusqu'à un certain temps. Si la couche détecte qu'il existe des conteneurs ou des images qui dépendent de la couche de stockage, la suppression s'arrêtera. Ainsi, lorsque vous exécutez docker rmi, vous pouvez observer combien de Deleted: sha256: ... apparaissent. C'est le nombre de calques qui ont été supprimés, et les autres n'ont pas été supprimés.
Donc, si vous docker tag réinstallez cette image mysql, alors lorsque vous exécutez docker rmi, seule l'opération untag sera exécutée et la couche de stockage ne sera pas réellement supprimée.
Ou s'il y a d'autres images dans le système qui sont basées sur la même image de base debian:jessie, alors docker rmi sera uniquement supprimée de ce calque et s'arrêtera à chaque fois dans le futur, pull démarrera également. de cette couche.
De même, ce concept de stockage à plusieurs niveaux aura également un impact sur votre docker pull. Lorsque vous exécuterez docker pull, vous vérifierez la valeur de contrôle de chaque couche du docker:latest officiel, puis la comparerez localement pour voir lesquelles existent déjà. Si elles existent, l'extraction ne sera pas répétée et la couche de stockage actuelle. sera utilisé directement. S'il n'existe pas, tirez-en un nouveau.
Prenons l'exemple de tout à l'heure si vous re-docker tag re-tag l'mysql:latest image avant, alors docker rmi n'a en fait pas supprimé l'image, et lorsque vous docker pull mysql recommencerez, vous le ferez find all La couche de stockage est disponible localement, il n'est donc pas nécessaire de la récupérer à nouveau. Remplacez simplement le niveau supérieur tag par mysql:latest. Il n'y a pas lieu de s'inquiéter de cette situation, et il n'est pas nécessaire de forcer un nouveau téléchargement, car sha256sum peut assurer la cohérence du fichier image et du site officiel.
Votre question doit donc dépendre de la situation spécifique. De manière générale, il n'est pas recommandé d'utiliser la balise latest dans un environnement de production, mais de préciser clairement la version afin que les mises à niveau et la maintenance soient possibles.
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Existe-t-il un conteneur utilisant cette image MySQL ? Ou avez-vous
docker tagrecréé cette image ? Ou utiliser d'autres versions du miroir MySQL ? Ou utilisez-vous une image basée surdebian:jessie?Sachez qu'une image n'est pas un fichier unique, mais un ensemble de couches de stockage. Lorsque vous exécutez
docker rmi -f mysql, vous supprimez en fait lemysql:latestcetag, donc la première ligne est généralementUntagged: mysql:latest.La logique suivante est que s'il n'y a pas d'autre
tagpointant vers la couche de stockage, la couche de stockage sera effectivement supprimée, puis continuera à demander si la couche de stockage suivante est toujours utilisée et ne le sera pas. continuez à le supprimer jusqu'à un certain temps. Si la couche détecte qu'il existe des conteneurs ou des images qui dépendent de la couche de stockage, la suppression s'arrêtera. Ainsi, lorsque vous exécutezdocker rmi, vous pouvez observer combien deDeleted: sha256: ...apparaissent. C'est le nombre de calques qui ont été supprimés, et les autres n'ont pas été supprimés.Donc, si vous
docker tagréinstallez cette image mysql, alors lorsque vous exécutezdocker rmi, seule l'opérationuntagsera exécutée et la couche de stockage ne sera pas réellement supprimée.Ou s'il y a d'autres images dans le système qui sont basées sur la même image de base
debian:jessie, alorsdocker rmisera uniquement supprimée de ce calque et s'arrêtera à chaque fois dans le futur,pulldémarrera également. de cette couche.De même, ce concept de stockage à plusieurs niveaux aura également un impact sur votre
docker pull. Lorsque vous exécuterezdocker pull, vous vérifierez la valeur de contrôle de chaque couche dudocker:latestofficiel, puis la comparerez localement pour voir lesquelles existent déjà. Si elles existent, l'extraction ne sera pas répétée et la couche de stockage actuelle. sera utilisé directement. S'il n'existe pas, tirez-en un nouveau.Prenons l'exemple de tout à l'heure si vous re-
docker tagre-tagl'mysql:latestimage avant, alorsdocker rmin'a en fait pas supprimé l'image, et lorsque vousdocker pull mysqlrecommencerez, vous le ferez find all La couche de stockage est disponible localement, il n'est donc pas nécessaire de la récupérer à nouveau. Remplacez simplement le niveau supérieurtagparmysql:latest. Il n'y a pas lieu de s'inquiéter de cette situation, et il n'est pas nécessaire de forcer un nouveau téléchargement, carsha256sumpeut assurer la cohérence du fichier image et du site officiel.Votre question doit donc dépendre de la situation spécifique. De manière générale, il n'est pas recommandé d'utiliser la balise
latestdans un environnement de production, mais de préciser clairement la version afin que les mises à niveau et la maintenance soient possibles.