Dovrei essere preoccupato per i contenitori Docker in eccesso, non funzionanti?

142

Ogni docker runcomando, o ogni RUNcomando all'interno di un file Docker, crea un contenitore. Se il contenitore non è più in esecuzione, è ancora possibile vederlo docker ps -a.

Dovrei preoccuparmi di avere un enorme elenco di container non funzionanti? Devo emettere docker rmsu container non funzionanti?

Non sono sicuro di quali siano le prestazioni o la penalità di memoria / archiviazione che comportano questi contenitori non funzionanti.

docker

— velo9
fonte

1

Un docker execcomando è stato aggiunto qualche tempo fa, consultare docs.docker.com/reference/commandline/cli/#exec - eseguirà un comando da un container in esecuzione.

— schmunk,

Cordiali saluti, se vuoi vedere come rimuovere i vecchi contenitori, vedi questa domanda: stackoverflow.com/questions/17236796/…

— Ryan Walls

1

@schmunk Il link è stato spostato. docs.docker.com/engine/reference/commandline/exec

— akauppi

72

I contenitori che non sono in esecuzione non richiedono risorse di sistema oltre allo spazio su disco.

Di solito è bene ripulire dopo te stesso, ma se ne hai molti in giro non dovrebbe rallentare affatto le prestazioni.

Se noti un rallentamento quando esegui comandi docker con molti contenitori arrestati, potrebbe trattarsi di un bug nella finestra mobile e dovresti inviare un errore.

— Ken Cochrane
fonte

1

I documenti per il RUNcomando ora sono stati spostati in: docs.docker.io/en/latest/reference/builder/#run

— aculich,

63

La docker rundocumentazione descrive come pulire automaticamente il contenitore e rimuovere il file system all'uscita del contenitore:

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

Quanto sopra mostra che per impostazione predefinita i contenitori non vengono rimossi, ma l'aggiunta --rm=trueo solo la scorciatoia --rmfunzionerà in questo modo:

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

Quando esci dal contenitore, questo verrà automaticamente rimosso.

È possibile verificarlo elencando i contenitori della finestra mobile in una finestra del terminale:

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

E poi in un'altra finestra esegui questo comando per eseguire più contenitori docker che usciranno automaticamente dopo aver dormito per un massimo di 10 secondi.

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

— aculich
fonte

4

Non una risposta diretta alla domanda , ma una risposta interessante che fornirà agli utenti alcune informazioni sui meccanismi alla base della finestra mobile. Grazie!

— thaJeztah,

3

-rmè obsoleto e verrà rimosso a un certo momento, utilizzare --rminvece.

— Guadagna il

5

Se si esegue un contenitore con un volume e non si utilizza la finestra mobile rm -v per rimuoverlo, il volume non viene rimosso dopo aver rimosso un contenitore. Inoltre c'è un problema con un driver di archiviazione vfs. Se si dimentica di pulire, i volumi consumeranno spazio sul disco.

— zergood
fonte

2

Non sono sicuro di quali siano le prestazioni o la penalità di memoria / archiviazione che comportano questi contenitori non funzionanti.

Per valutare la quantità di archiviazione utilizzata dai contenitori Docker non in esecuzione, è possibile eseguire:

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

--size: visualizza le dimensioni totali del file (FYI: spiega la colonna SIZE in "docker ps -s" e cosa significa "virtuale" parola chiave # 1520 ).
--filter "status=exited": elenca solo i contenitori arrestati .

Equivalentemente , potresti eseguire:docker container ls --filter "status=exited"

Puoi anche usare il comando docker system df(introdotto in Docker 1.13.0, gennaio 2017) per vedere l'utilizzo del disco docker, ad esempio:

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
fonte