Qual é a diferença entre imagens e contêineres Docker?

Question

Accepted Answer

Uma **imagem** Docker é um **modelo** somente leitura (uma aplicação empacotada com suas dependências); um **contêiner** é uma **instância em execução** de uma imagem. A relação é como uma classe e um objeto: uma imagem pode gerar muitos contêineres. ## Imagem versus contêiner ```text IMAGE → a read-only TEMPLATE: the app + dependencies + config, built in layers (like a blueprint/class; stored, shared, versioned) CONTAINER → a RUNNING INSTANCE of an image (with a writable layer on top) (like an object created from a class; has runtime state) One IMAGE → many CONTAINERS (run the same image multiple times) ``` ## Trabalhando com imagens ```bash docker build -t myapp:1.0 . # BUILD an image from a Dockerfile docker images # list local images docker pull nginx # download an image from a registry docker push myapp:1.0 # upload an image to a registry docker rmi myapp:1.0 # remove an image ``` As imagens são construídas (a partir de um Dockerfile), armazenadas localmente ou em registros, versionadas com tags (`myapp:1.0`), e compartilhadas. ## Trabalhando com contêineres ```bash docker run -d -p 80:80 nginx # RUN a container from an image (-d = background) docker ps # list RUNNING containers docker ps -a # list all (including stopped) docker stop # stop a container docker start # start a stopped container docker rm # remove a container docker logs # view a container's logs docker exec -it bash # run a command inside a running container ``` Os contêineres são criados a partir de imagens, têm um ciclo de vida (executar, parar, iniciar, remover), e você pode inspecionar logs ou executar comandos dentro deles. ## A relação em camadas ```text → Images are built in LAYERS (each Dockerfile instruction adds a layer, cached/shared) → A container = the image's read-only layers + a thin WRITABLE layer on top → Changes in a running container go to its writable layer (lost when removed, unless persisted via volumes) — the underlying image is unchanged ``` ## Por que isso importa Entender a distinção entre imagens e contêineres é fundamental para trabalhar com Docker, portanto é um conhecimento essencial e indispensável. A relação — uma **imagem** é um **modelo** somente leitura (a aplicação empacotada com dependências, como um blueprint ou classe) enquanto um **contêiner** é uma **instância em execução** dessa imagem (como um objeto criado a partir de uma classe, com estado em tempo de execução) — é o modelo conceitual central do Docker, e confundir os dois leva a confusão sobre como o Docker funciona. Entender que **uma imagem pode gerar muitos contêineres** (executando a mesma imagem várias vezes) é fundamental para entender como o Docker permite escalabilidade e consistência. Conhecer as operações práticas — construir, listar, fazer pull, fazer push e versionar **imagens** (com tags como `myapp:1.0`), e executar, parar, inspecionar (logs) e executar comandos em **contêineres** (gerenciar seu ciclo de vida) — é um conhecimento prático cotidiano para usar o Docker. Entender a **relação em camadas** (imagens construídas em camadas em cache compartilháveis; um contêiner sendo as camadas somente leitura da imagem mais uma camada gravável fina onde as mudanças em tempo de execução ficam, perdidas na remoção, a menos que persistidas via volumes) explica tanto a eficiência do Docker (compartilhamento/cache de camadas) quanto um detalhe importante (as mudanças do contêiner são efêmeras sem volumes). Como a distinção imagem/contêiner é o modelo mental fundamental para Docker, e como entendê-lo (e as operações associadas e a estrutura em camadas) é necessário para construir, executar e gerenciar workloads Docker corretamente, entender a diferença entre imagens e contêineres é um conhecimento Docker essencial e fundamental — o conceito central sobre o qual todo o resto do Docker se baseia, e uma distinção que todo usuário Docker deve compreender claramente.