LEARN. PRACTICE. GROW.Concept and mechanism
A Linux container runs isolated processes using the runtime host kernel. An image supplies the base filesystem and configuration; it does not create an independent kernel for every application. Docker Desktop may place that runtime in a virtual machine, so the daemon host is not necessarily the operating system visible in the terminal. Distinguish an image, a created container, and a running process. One image can produce several containers with different configuration and state. The writable layer belongs to the container and does not alter the original image. A container identifier selects an instance for observation; the image reference identifies the origin used to create it.
Guided application
In a fictional reconciliation service, the startup script launches the server in the background and exits. The container stops serving even though the application was launched. Inspect the effective command, main process, and exited state before changing networking or memory. Use foreground execution and signal handling appropriate to the service. Exec-form ENTRYPOINT avoids an unnecessary intermediate shell; a wrapper must forward signals or replace itself with exec when appropriate. docker stop sends the configured signal and may force termination after the grace period. Confirm work completion and persistent state before declaring a clean shutdown.
Script exited at 08:14; service unavailable at 08:14: first inspect the main process.
Common pitfalls
Confusing image with instance; background as persistence; timeout as clean completion.
Related topics: Build and distribution · Networking and access · Data and mounts
The service lifecycle needs to match the supervised process.
Reference: Containers and shared kernel · Docker Engine Linux containers, BuildKit and Compose; official documentation consulted 2026-09-30; version-dependent behavior explicitly scoped