Devo me preocupar com excesso de contêineres do Docker sem execução?

142

Todo docker runcomando, ou todo RUNcomando dentro de um Dockerfile, cria um contêiner. Se o contêiner não estiver mais em execução, ele ainda poderá ser visto comdocker ps -a .

Devo me preocupar em ter uma lista enorme de contêineres que não estão em execução? Eu deveria estar emitindodocker rm em contêineres que não estão em execução?

Não tenho certeza de quais penalidades de desempenho ou memória / armazenamento são afetadas por esses contêineres que não estão em execução.

docker

— velo9
fonte

1

Um docker execcomando foi adicionado há um tempo atrás, consulte docs.docker.com/reference/commandline/cli/#exec - ele executará um comando em um contêiner em execução.

— schmunk

FYI, se você quiser ver como remover os recipientes velhos, consulte esta pergunta: stackoverflow.com/questions/17236796/...

— Ryan Paredes

1

@schmunk O link foi movido. docs.docker.com/engine/reference/commandline/exec

— akauppi 20/01/17

72

Os contêineres que não estão em execução não ocupam nenhum recurso do sistema além do espaço em disco.

Geralmente é bom se limpar depois de si mesmo, mas se houver muitos deles por perto, não deve diminuir o desempenho.

Se você notar uma lentidão ao executar comandos do docker com muitos contêineres parados, pode haver um erro no docker e você deve enviá-lo.

— Ken Cochrane
fonte

1

Os documentos para o RUNcomando agora foram movidos para: docs.docker.io/en/latest/reference/builder/#run

— aculich

63

A docker rundocumentação descreve como limpar automaticamente o contêiner e remover o sistema de arquivos quando o contêiner sai:

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

O exemplo acima mostra que, por padrão, os contêineres não são removidos, mas a adição --rm=trueou apenas a mão curta --rmfuncionará da seguinte forma:

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

Quando você sair do contêiner, ele será removido automaticamente.

Você pode testar isso listando seus contêineres em uma janela do terminal:

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

E, em outra janela, execute este comando para executar vários contêineres de janela de encaixe que sairão automaticamente após dormir por até 10 segundos.

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

— aculich
fonte

4

Não é uma resposta direta à pergunta , mas uma resposta interessante que dará aos usuários algumas dicas sobre os mecanismos por trás do docker. Obrigado!

— precisa saber é o seguinte

3

-rmfoi descontinuado e será removido em algum momento, use-o --rm.

— banho

5

Se você executar um contêiner com um volume e não usar janela de encaixe rm -v para removê-lo, o volume não será removido após a remoção de um contêiner. Também há um problema com um driver de armazenamento vfs. Se você esquecer de limpar, os volumes consumirão seu espaço em disco.

— zergood
fonte

2

Não tenho certeza de quais penalidades de desempenho ou memória / armazenamento são afetadas por esses contêineres que não estão em execução.

Para avaliar a quantidade de armazenamento que os contêineres do Docker não em execução estão usando, você pode executar:

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

--size: exibe o tamanho total do arquivo (FYI: explique a coluna SIZE em "docker ps -s" e o que significa a palavra-chave "virtual" # 1520 ).
--filter "status=exited": lista apenas contêineres parados .

Equivalentemente , você pode executar:docker container ls --filter "status=exited"

Você também pode usar o comando docker system df(introduzido no Docker 1.13.0, janeiro de 2017) para ver o uso do disco do docker, por exemplo:

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