Dois-je m'inquiéter des conteneurs Docker excédentaires et non fonctionnels?

142

Chaque docker runcommande, ou chaque RUNcommande à l'intérieur d'un Dockerfile, crée un conteneur. Si le conteneur ne fonctionne plus, il peut toujours être vu avec docker ps -a.

Dois-je m'inquiéter d'avoir une énorme liste de conteneurs non fonctionnels? Dois-je émettre docker rmsur des conteneurs non en cours d'exécution?

Je ne sais pas quelles sont les performances ou les pénalités de mémoire / stockage encourues par ces conteneurs non fonctionnels.

docker

— velo9
source

1

Une docker execcommande a été ajoutée il y a quelque temps, voir docs.docker.com/reference/commandline/cli/#exec - elle exécutera une commande sur un conteneur en cours d'exécution.

— schmunk

Pour info, si vous voulez voir comment supprimer les anciens conteneurs, consultez cette question: stackoverflow.com/questions/17236796/...

— Ryan Walls

1

@schmunk Le lien a été déplacé. docs.docker.com/engine/reference/commandline/exec

— akauppi

72

Les conteneurs qui ne sont pas en cours d'exécution n'utilisent aucune ressource système en dehors de l'espace disque.

Il est généralement bon de nettoyer après vous-même, mais si vous en avez beaucoup assis, cela ne devrait pas ralentir du tout les performances.

Si vous remarquez un ralentissement lors de l'exécution de commandes docker avec beaucoup de conteneurs arrêtés, cela peut être un bogue dans docker, et vous devriez soumettre un bogue.

— Ken Cochrane
source

1

La documentation de la RUNcommande est maintenant déplacée vers: docs.docker.io/en/latest/reference/builder/#run

— aculich

63

La docker rundocumentation décrit comment nettoyer automatiquement le conteneur et supprimer le système de fichiers à la fermeture du conteneur:

  --rm=false: Automatically remove the container when it exits (incompatible with -d)

Ce qui précède montre que par défaut les conteneurs ne sont pas supprimés, mais l'ajout --rm=trueou simplement le raccourci --rmfonctionnera comme ceci:

sudo docker run -i -t --rm ubuntu /bin/bash

Lorsque vous sortez du conteneur, il sera automatiquement supprimé.

Vous pouvez tester cela en répertoriant vos conteneurs Docker dans une fenêtre de terminal:

watch -n1 'sudo ls -c /var/lib/docker/containers'

Et puis, dans une autre fenêtre, exécutez cette commande pour exécuter plusieurs conteneurs docker qui se termineront tous automatiquement après avoir dormi jusqu'à 10 secondes.

for i in {1..10}; do sudo docker run --rm ubuntu /bin/sleep $i & done

— aculich
source

4

Pas une réponse directe à la question , mais une réponse intéressante qui donnera aux utilisateurs un aperçu des mécanismes derrière docker. Merci!

— thaJeztah

3

-rmest obsolète et sera supprimé à un moment donné, utilisez à la --rmplace.

— bain le

5

Si vous exécutez un conteneur avec un volume et n'utilisez pas docker rm -v pour le supprimer, le volume n'est pas supprimé une fois que vous avez supprimé un conteneur. Il y a également un problème avec un pilote de stockage vfs. Si vous oubliez de nettoyer, les volumes consommeront votre espace disque.

— zergood
source

2

Je ne sais pas quelles sont les performances ou les pénalités de mémoire / stockage encourues par ces conteneurs non fonctionnels.

Afin d'évaluer la quantité de stockage utilisée par les conteneurs Docker non exécutés, vous pouvez exécuter:

docker ps --size --filter "status=exited"

--size: affiche la taille totale des fichiers (pour info: expliquez la colonne SIZE dans "docker ps -s" et ce que le mot-clé "virtual" signifie # 1520 ).
--filter "status=exited": liste uniquement les conteneurs arrêtés .

De manière équivalente , vous pouvez exécuter:docker container ls --filter "status=exited"

Vous pouvez également utiliser la commande docker system df(introduite dans Docker 1.13.0, janvier 2017) pour voir l'utilisation du disque docker, par exemple:

username@server:~$ docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              44                  28                  114.7GB             84.84GB (73%)
Containers          86                  7                   62.43GB             41.67GB (66%)
Local Volumes       2                   1                   0B                  0B
Build Cache                                                 0B                  0B

— Franck Dernoncourt
source