Separate build tools from a container runtime

Build and runtime have different jobs

Docker supports builds with several stages, allowing selected artifacts to be copied from one stage to another. The final image can therefore be separated from tools needed only to create the application. The official guide describes how stages are defined and how artifacts move between them. This is useful for keeping the runtime purpose clear. [1]

Describe the runtime contract

List the executable, data, configuration, and dependencies required when the container starts. Keep that list separate from compilers, source transformation tools, and other build inputs. Define where outputs are written and how a failure is reported. A scientific worker and a web API may have very different runtime contracts even if both are distributed as images.

Build a small representative workload and inspect the produced artifact before adding more stages. Check startup, input paths, expected outputs, and permissions in the final image. Retain version information so the result can be matched to its build. Avoid relying on a file that happens to exist in a development environment but is never copied into the runtime stage.

Test the image as a delivery artifact

Run the final image using the configuration expected in deployment. Inspect behavior with a missing input, an invalid setting, and a completed job. Record the build and execution commands with the release. A smaller image can be useful, but size alone does not prove that the runtime is correct. The practical objective is an understandable, repeatable application environment that contains what the workload needs and can be checked independently.