Nous gérons un site Discourse auto-hébergé sur DigitalOcean et disposons d’un disque de 25 Go. Je viens d’essayer de mettre à jour notre image Discourse et j’ai reçu un message indiquant que vous aurez besoin de plus d’espace pour continuer. Après avoir nettoyé l’image et les conteneurs Docker, il nous manque encore 0,4 Go.
Des conseils pour économiser de l’espace ? À la fois pour pouvoir effectuer la mise à jour maintenant et pour économiser de l’espace à l’avenir. Je sais que nous devrons bientôt redimensionner, mais il serait utile de pouvoir effectuer au moins une autre mise à jour de l’image Discourse.
Stockez-vous des sauvegardes localement ?
Si oui, peut-être que supprimer quelques anciennes pourrait aider. 0,4 Go (soit 400 Mo) devrait être gérable.
Vous pourriez également essayer de libérer de l’espace sur le système hôte.
Nous utilisons la fonctionnalité de sauvegarde de DigitalOcean. Je n’ai pas vu d’option pour supprimer manuellement l’une de nos sauvegardes.
Comment puis-je procéder ? Je n’ai pas d’expérience en programmation, mais je suis capable de comprendre quoi faire et pourquoi après avoir reçu des instructions.
Il est important de comprendre pourquoi vous avez des images intermédiaires sans étiquette qui apparaissent comme <none> <none> afin de les éviter, car, comme vous l’avez constaté, vous ne pouvez pas les supprimer si elles sont utilisées.
La raison pour laquelle des images sans étiquette se produisent est que vous avez construit une image, puis vous avez modifié le Dockerfile et reconstruit cette image, et elle a réutilisé certaines des couches de la construction précédente. Vous avez maintenant une image sans étiquette qui ne peut pas être supprimée car certaines de ses couches sont utilisées par une nouvelle version de cette image.
La solution est de :
Supprimer la nouvelle version de l’image
Supprimer l’image sans étiquette et
Reconstruire la nouvelle version de l’image afin qu’elle possède toutes les couches.
Il vous restera une seule image étiquetée qui contient toutes les couches des images précédentes sans étiquette et la nouvelle image.
Je ne m’attendais pas à trouver 2,64 Go dans une image Docker , alors j’essaie de comprendre ce qui se passe. Si je n’ai pas du tout besoin de cette image, alors nous sommes certainement loin d’avoir besoin de redimensionner.
Combien de temps ? Je ne vois aucun indice à ce sujet - je sais que j’utilise avec bonheur un forum sur 20 Go et un autre sur 25 Go.
Sous shared, vous pourriez avoir beaucoup de données de sauvegarde (peut-être dans shared/standalone/backups/default). Vous pourriez également avoir d’anciennes copies de bases de données ou de vieux fichiers journaux. Je vous recommande d’exécuter du -kx / | sort -n | tail -49
ou similaire.
Il est juste de noter que vous pouvez gagner du temps, au détriment de l’argent, en passant à une instance plus grande. Ou vous pouvez faire le compromis inverse.
Cela m’inquiète un peu. DO pourrait bien vous aider avec les sauvegardes de votre système entier, mais si c’était moi, je serais plus heureux de savoir comment faire des sauvegardes de Discourse et comment obtenir une copie locale sécurisée. Et comment élaguer les sauvegardes. (Si par malheur DO supprimait votre instance et votre compte, vous voudriez que vos données survivent à cela.)
Nous utilisons également la fonctionnalité de sauvegarde de Discourse, et j’ai réalisé que nous n’avions pas effacé les anciennes sauvegardes là-bas.
Eh bien, j’ai supprimé toutes les sauvegardes sauf la plus récente en utilisant l’interface Discourse et j’ai également téléchargé la sauvegarde la plus récente sur mon disque local. Cela me ramène à moins de 100 Mo d’espace disponible.
Voici ce que j’obtiens lorsque j’exécute cette commande dans var/discourse
Où {nom_image} est le nom de l’image que vous souhaitez supprimer. Vous pouvez également utiliser l’ID de l’image pour supprimer l’image (par exemple, docker rmi {id_image}). C’est ce que vous devrez utiliser pour supprimer une image nommée <none>.
Par exemple, supposons que vous ayez les images suivantes :
REPOSITORY TAG IMAGE ID CREATED SIZE
my-new-image latest c18f86ab8daa 12 secondes ago 393MB
<none> <none> b1ee72ab84ae Il y a environ une minute 393MB
my-image latest f5a5f24881c3 Il y a 2 minutes 393MB
Il est possible que l’image <none> ne puisse pas être supprimée car my-new-image utilise certaines de ses couches. Ce que vous devez faire est :
Ce qui supprime my-new-image:latest qui réutilise des couches de l’image <none>. Il supprime ensuite l’image <none> en utilisant son ID d’image b1ee72ab84ae. Enfin, il reconstruit my-new-image en créant toutes les couches nécessaires.
Assurez-vous également de ne pas avoir de conteneurs arrêtés qui utilisent toujours l’image « sans étiquette » <none>. Utilisez docker ps -a pour voir toutes les images, y compris celles qui sont sorties. Si c’est le cas, utilisez docker rm {id_conteneur} pour supprimer le conteneur, puis essayez de supprimer à nouveau l’image <none>.
Cela a fonctionné et j’ai également modifié la politique !
Je veux toujours traquer le problème avec l’image <none> (car il est ridicule qu’elle prenne plus de 2 Go d’espace), mais vous avez résolu mon problème le plus immédiat de création de suffisamment d’espace pour la mise à niveau ! Merci !!
Nous utilisons également la fonctionnalité de sauvegarde de Discourse, et j’ai réalisé que nous n’avions pas effacé les anciennes sauvegardes là-bas.