APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Um contentor Linux executa processos isolados que usam o kernel do anfitrião do runtime. Uma imagem fornece o sistema de ficheiros e configuração de base; não cria um kernel independente por aplicação. Docker Desktop pode colocar esse runtime numa máquina virtual, pelo que o anfitrião do daemon não é necessariamente o sistema visível no terminal. Distingue imagem, contentor criado e processo em execução. A mesma imagem pode originar vários contentores com configuração e estado diferentes. A camada gravável pertence ao contentor e não transforma a imagem original. O identificador do contentor serve para observar a instância; a referência da imagem identifica a origem usada para a criar.
Aplicação guiada
Num serviço fictício de reconciliação, o script de arranque lança o servidor em background e termina. O contentor deixa de servir apesar de a aplicação ter sido lançada. Verifica o comando efetivo, o processo principal e o estado terminado antes de alterar rede ou memória. Usa execução em foreground e tratamento de sinais adequado ao serviço. A forma exec do ENTRYPOINT evita uma shell intermediária desnecessária; um wrapper tem de encaminhar sinais ou substituir-se com exec quando apropriado. docker stop envia o sinal configurado e, depois do período de espera, pode forçar a paragem. Confirma conclusão de trabalho e estado persistente antes de declarar uma interrupção limpa.
Script terminado às 08:14; serviço indisponível às 08:14: o primeiro passo é observar o processo principal.
Armadilhas comuns
Confundir imagem com instância; background como permanência; timeout como conclusão limpa.
Tópicos relacionados: Build e distribuição · Rede e acesso · Dados e mounts
O ciclo de vida do serviço precisa de corresponder ao processo supervisionado.
Referência: Containers and shared kernel · Docker Engine Linux containers, BuildKit and Compose; official documentation consulted 2026-09-30; version-dependent behavior explicitly scoped