Your source code is only part of the package.
An application may depend on a runtime, system libraries and built assets. A container image packages the filesystem and metadata used to create a container. The Dockerfile is the build recipe; the image is an output of that build.
Imagine releasing a booking application. Sending only its source folder to a server would leave several questions open. Which runtime is installed? Were assets compiled? Which libraries are present? Packaging a reviewed image makes those choices part of a versioned artifact, while runtime configuration remains a separate concern.
Build, publish, pull, run.
A registry is a distribution point for images. A build process can publish an image to a repository there; an authorized deployment environment can retrieve it. Running the image creates a container. Publishing an image alone does not update an application already running on a server.
Follow the pipeline below. Each stage has a different output, from source to artifact to a running process. A deployment record should connect these stages so that an operator can tell which reviewed build is serving requests and where it came from.
Include what the runtime actually needs.
A build can use compilers and tools that the final application does not need. Multi-stage builds separate those activities, letting the runtime image contain the result without every build dependency. Selecting a suitable base image also shapes the package you maintain.
Keep secrets and unrelated local files out of the build context and final image. Review the inputs, test the resulting application, and schedule rebuilds when dependencies need updates. A successful build tells you that a recipe completed; it does not by itself prove that the application is correct or safe.
Reference: Docker: building best practicesMake the release easy to trace and replace.
For the booking application, record the image identity, configuration version and deployment destination together. If a release behaves differently from the previous one, those details narrow the investigation. They also help another person reproduce the intended setup without relying on memory.
Keep an explicit update process. Pinning an artifact makes selection predictable, but it does not bring in future fixes automatically. When replacing a release, consider application compatibility with stored data and dependent services. Reverting an image cannot necessarily reverse a database migration.
Common questions.
Does latest always mean the newest version?
No. It is a tag name whose meaning depends on the publisher. Inspect the actual release and artifact identity.
Is an image the same as a container?
No. An image is an artifact. A container is an instance created from an image with runtime configuration.
Does a digest prove an image is safe?
No. It identifies content. Trust also depends on provenance, review, configuration and maintenance.
Connect the concept to your work.
DOCKOCK connects application releases to their deployment targets, making it easier to review the image and configuration behind a service.
Explore images & registries in DOCKOCKKeep learning from the source.
Further reading from the teams and documentation behind these technologies.
Docker: image digestsDocker: building best practices