Start here
Docker in plain language
Packaging dependencies reduces differences between environments, but does not guarantee identical behaviour on every machine. CPU architecture, operating-system compatibility, configuration and external services still matter.
Containers normally share the kernel of their container host rather than carrying a complete guest kernel like a VM. Desktop environments may use a supporting VM to provide the required container environment.
How it works
Build once, configure when you run
Image and runtime are different things
- Build definition
Source and declared dependencies define the build.
- Image
A versioned package distributed through a registry or other transfer.
- Container
Run the image with ports, configuration and storage attached.
Several containers can use the same image while having different runtime configuration.
Create a repeatable image
Declare the application and dependencies. Review the base image and avoid embedding credentials.
Configure the runtime
Provide required environment values, network access and storage. Use the tested image version.
Test replacement
Recreate the container and confirm that required data persists and the application starts correctly.
Illustrative example · Fictional data
Replacing a fictional document API
- Input
- An API container writes uploaded test documents. Its image contains the application, not those uploads.
- Process
- Attach persistent storage for uploads. Start the container, save a synthetic file, then replace the container using the same storage.
- Expected output
- The new instance can still serve the saved document.
- How to check it
- If the file exists only in the old container’s writable layer, replacement can lose it. A volume also needs its own backup plan.
Where it helps
- Keeping application dependencies consistent across testing and deployment.
- Running separate services with isolated runtime environments.
- Distributing a versioned application package.
Image, container and volume
- Image
- The packaged application and filesystem layers used to create containers.
- Container
- An instance running from an image, with its own runtime settings.
- Volume
- Storage managed separately from a container’s disposable writable layer.
From Dockerfile to image, registry and running container
A Dockerfile describes build steps and the application’s default startup command. In a directory containing a suitable Dockerfile, docker build -t demo-app:local . creates a tagged image; docker run --rm demo-app:local starts a container from it. These are illustrative commands, not instructions to run an unknown image on a production machine.
An image is a read-only template; a container adds runtime state. A registry stores images for distribution. Testing one image and then promoting that same image digest helps keep the deployed artefact consistent; a mutable tag by itself is not proof that two environments received the same image.
Configure ports, storage and secrets deliberately. Data that must survive container replacement needs an appropriate persistent store. Keep credentials out of the Dockerfile and image, and use a trusted base image with a maintenance and vulnerability-review process.
Runtime boundaries and Docker product choices
Linux containers use kernel isolation mechanisms rather than booting a separate guest operating system for each application. Linux containers on a non-Linux desktop generally run through a Linux virtual-machine environment. The container still depends on a compatible platform, configuration and, for some workloads, drivers or hardware.
Docker Engine, Docker Desktop and Docker Hub serve different purposes: running containers, providing a desktop development environment and distributing images. Check the current licence and subscription terms for the product you deploy; a free option for one use case does not establish entitlement for every enterprise Desktop deployment.
An orchestration platform can manage multiple containers, but is not required to learn the build-and-run workflow. Start with an application you understand, inspect its logs and stop/restart behaviour, then decide whether its deployment needs a managed container service or a cluster.
Related reading and learning pathways
Common pitfalls
- Secrets copied into an image can remain in its layers.
- Container isolation is not a guarantee that unsafe code cannot affect its host.
- A mutable image tag can point to a different build later.
Put the idea to work
Try it yourself
Draw an application image and two containers using it. Mark which settings differ and where shared data should live. Explain what should happen when one container is replaced.
Common questions
Is a container a virtual machine?
No. Containers normally share their host kernel, whereas a VM runs a guest operating system with its own kernel. That makes containers lighter and faster to start than VMs, but the isolation boundary is different. Workloads with strict isolation needs sometimes run containers inside VMs.
Does Docker require Kubernetes?
No. Docker tools can build and run containers without Kubernetes. Docker Engine and Docker Compose can run one or several containers on a single machine. Kubernetes becomes relevant when you need to schedule and manage containers across many machines.
Does an image include production configuration?
It may contain defaults, but environment-specific settings and secrets should be supplied through appropriate runtime mechanisms. Use environment variables, configuration files mounted at runtime or a secrets manager. Keeping secrets out of images prevents them leaking through registries or image layers.
Your next step
Continue learning
Connected concepts
Sources and further reading
Examples on this page are teaching exercises using fictional information. They are not client case studies or measured outcomes.