跪拜 Guibai
← All articles
Frontend

Docker's Mental Model: Images Are Templates, Containers Are the Running App

By lcy453 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

The "it works on my machine" problem costs teams hours of debugging environment drift. Docker eliminates that by making the runtime environment itself a versioned artifact, so onboarding a new developer or deploying to production starts from an identical snapshot.

Summary

The core Docker workflow turns a Dockerfile into a static image, then runs that image as a container. An image bundles the OS layer, language runtime, dependencies, code, and startup command into a single distributable artifact. Containers are the live instances — you can spin up multiple independent containers from one image, each with its own port mappings and state.

Docker Hub acts as the default public registry, analogous to npm for JavaScript packages, but private registries from Alibaba Cloud, Harbor, or on-premise servers are common inside companies. When a corporate network blocks direct access to Docker Hub, teams work around it with proxies, internal mirrors, or offline image transfers using `docker save` and `docker load`.

The relationship is linear: Dockerfile → build → image → run → container → push → registry → pull → run elsewhere. Understanding this chain before memorizing CLI flags prevents the common confusion between images and containers.

Takeaways
An image is a static template containing the OS, runtime, code, dependencies, and default startup command.
A container is a running instance created from an image; multiple containers can run from the same image independently.
Docker Hub is the default public image registry, but private registries like Harbor, Alibaba Cloud, or on-premise servers are standard inside companies.
Corporate networks that block Docker Hub cause pull failures; workarounds include proxy configuration, internal mirrors, or offline `docker save`/`docker load` transfers.
The core loop is: write a Dockerfile, build an image, run a container, push to a registry, and pull it elsewhere.
Conclusions

Newcomers often conflate images with containers because both appear in the same CLI workflow, but treating an image as a class and a container as an object clears up most operational mistakes.

Offline image transfer via `docker save` and `docker load` is an underappreciated pattern that sidesteps entire categories of network and registry authentication problems in air-gapped environments.

Docker's analogy to package managers like npm is precise enough to be useful but hides a key difference: images carry an entire OS userspace, not just library code, which is why they solve environment drift so thoroughly.

The jump from "Docker installs things" to "Docker snapshots environments" is the difference between using it as a convenience tool and using it as a deployment primitive.

Concepts & terms
Image
A static, read-only template that packages an application's runtime environment — OS base layer, language runtime, dependencies, code, and default command — into a single distributable artifact.
Container
A running instance created from an image. Multiple isolated containers can be launched from the same image, each with its own filesystem, network, and process space.
Docker Hub
Docker's default public registry for storing and distributing images, analogous to npm for JavaScript packages.
Image Registry
A service that stores and distributes Docker images. Docker Hub is the most common public implementation, but private registries like Harbor or cloud-provider registries are widely used in enterprises.
Dockerfile
A text file containing instructions for building a Docker image, specifying the base OS, dependencies to install, files to copy, and the command to run on container startup.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗