Docker: meaning and definition
Docker in plain language
Packaging everything an app needs reduces differences between machines, but does not guarantee it behaves the same everywhere. The processor type, operating system, settings and outside 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.
Set ports, storage and secrets on purpose. Data that must survive a container being replaced needs proper persistent storage. Keep passwords and keys out of the Dockerfile and the image, and use a trusted base image that is kept up to date and checked for vulnerabilities.
Runtime boundaries and Docker product choices
Linux containers share the host’s operating-system kernel instead of starting a separate operating system for each app. On a Mac or Windows desktop, Linux containers usually run inside a small Linux virtual machine. A container still needs a compatible platform and settings and, for some work, the right drivers or hardware.
Docker Engine, Docker Desktop and Docker Hub do different jobs: running containers, giving developers a desktop setup and sharing images. Check the current licence and subscription terms for what you use; being free for one use does not mean it is free for every company desktop.
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 can contain defaults, but settings for each environment and any secrets should be supplied when the container runs. Use environment variables, configuration files added at run time or a secrets manager. Keeping secrets out of images stops them leaking through image 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.