Frequently Asked Questions About Piyush Docker-to-Kubernetes Container Fundamentals Framework
21 answers covering everything from basics to advanced usage.
// Basics
What does 'Build-Ship-Run' actually mean in Docker?
Build-Ship-Run is Docker's three-stage core workflow. BUILD creates a Docker image from a Dockerfile using 'docker build'. SHIP moves that image into a registry using 'docker push'. RUN pulls the image onto a target environment with 'docker pull' and instantiates it as a container with 'docker run'. Every container workflow has exactly these three stages, and none should ever be skipped or collapsed.
What is a 'lightweight sandbox environment' in Docker?
It is Piyush's term for a container. A container is 'lightweight' because it holds only a bare-minimum OS image plus the exact libraries the application needs — not a full OS installation. This keeps image sizes small and resource usage optimised. The 'sandbox' aspect means it runs isolated from other containers while still carrying everything the app needs to run anywhere.
Why don't containers include a full operating system?
Containers share the host OS kernel, so they don't need a complete OS installation. They carry only a bare-minimum OS image and the specific libraries the application requires. Bundling a full vanilla OS would bloat image sizes and waste resources. This lightweight design is precisely what lets many containers run densely on one physical server without the overhead virtual machines carry.
What is the difference between Docker and a container?
Docker is a platform that enables the build-ship-run workflow; a container is the concept of a lightweight, isolated runtime unit. Docker is one implementation of a container engine — alternatives like Podman also exist. Confusing the two is a common beginner mistake. You can containerise applications without Docker, but Docker is the most common tooling that makes the workflow accessible.
// How To
How do I write my first Dockerfile?
Create a file named exactly 'Dockerfile' with a capital D and no extension. Add ordered instructions: select a base OS image (e.g. ubuntu or a language-specific base), install required dependencies, copy your application source files into the image, then define the command that runs the app. Keep it minimal — include only the libraries your application actually needs to keep the image small.
How do I push a Docker image to Docker Hub?
After building your image locally with 'docker build', use 'docker push' to send it from local storage to Docker Hub, the default registry bundled with Docker. The Docker Client sends the command to the Docker Daemon, which uploads the image. Choose your registry the way you'd choose a version control system — it must support versioning and controlled access for safe promotion.
How do I run the same image across Dev, Test, and Prod?
On each environment, the Docker Client issues 'docker pull' to retrieve the identical image from the registry, then 'docker run' to spin up a container. Because every environment pulls the exact same versioned image, behaviour stays consistent. This uniformity is what eliminates environment-specific failures — there is no rebuild or per-environment variation to introduce misconfiguration.
How do I diagnose whether containerisation will solve my deployment problem?
Check whether failures when promoting builds across Dev → Test → Prod stem from missing dependencies, environment misconfiguration, or library misalignment. Document exactly what was present in lower environments but missing in Prod. If the failure class is dependency or configuration drift, containerisation solves it directly by packaging everything into one shippable image. If the problem is elsewhere, containers alone won't fix it.
// Troubleshooting
My container built fine but 'docker run' fails — where do I look?
Trace the failure through the Docker component model: Client → Daemon → local image storage → registry → Daemon on target → Container Runtime → running container. A run-time failure usually sits with the Container Runtime or a bad run command in the Dockerfile. Confirm the image pulled correctly and that the CMD or entrypoint actually launches your app with the right dependencies packaged inside.
Why does my app still crash in Prod even after containerising it?
Likely you're rebuilding the image per environment or pushing different images, breaking the guarantee that all environments run identically. Ensure you build once, push that image to a registry, and pull the exact same image everywhere. Also confirm your Dockerfile installs the precise dependency versions — a floating version tag can pull a different library at build time and reintroduce misconfiguration.
I named my file 'dockerfile' or 'Dockerfile.txt' — does it matter?
Yes. The default and best-practice name is 'Dockerfile' with a capital D and no extension. A lowercase 'd' or an added extension means Docker won't detect it by default, and 'docker build' may fail to find your instructions. Rename it to exactly 'Dockerfile' unless you have a specific reason to use a custom filename with the -f flag.
Can I skip the registry and copy images directly between servers?
You shouldn't. Skipping the registry removes versioning, auditability, and controlled promotion — the registry is version control for binaries, just as GitHub is for source code. Pushing directly to Prod also breaks the safe promotion path. Always push to a registry, then pull on each target. This keeps promotion trackable and prevents untracked, unrepeatable deployments.
// Comparisons
How do containers compare to virtual machines for resource usage?
Containers share the host OS kernel like flats in one building sharing land, while VMs each run a full isolated OS like separate houses on separate plots. VMs waste CPU and memory per instance; containers consume only what the app needs. For running 20 microservices on one server, 20 containers are far more efficient than 20 VMs, which would each carry redundant OS overhead.
How does a Docker registry compare to GitHub?
A Docker registry does for binary images what GitHub does for source code: it provides versioned, trackable, intermediate storage. GitHub tracks and stores code commits; a registry like Docker Hub, Nexus, or JFrog Artifactory tracks and stores built image versions. Both enable safe, auditable promotion. The parallel makes clear why you never bypass the registry — you'd be skipping version control for your binaries.
How does Docker compare to Podman or other container engines?
Docker is one implementation of a container engine that enables the build-ship-run workflow; Podman is an alternative that runs the same containerisation concept. The core methodology — build an image, ship via a registry, run as a container — is engine-agnostic. Docker is the most common and beginner-friendly starting point, especially bundled with Docker Hub, but the framework principles transfer to any compliant engine.
How does the Build-Ship-Run framework compare to just using shell scripts to deploy?
Shell scripts reconfigure each environment separately, which reintroduces drift and the missing-dependency failures containers eliminate. Build-Ship-Run packages everything once into an immutable image and runs that identical artifact everywhere. Scripts are imperative and environment-dependent; the container workflow is declarative via the Dockerfile and produces a single shippable unit. The container approach is auditable through the registry and repeatable across any host.
// Advanced
What is the role of the Docker Daemon (dockerd) in the workflow?
The Docker Daemon is the background service on the host that receives commands from the Docker Client and executes them. It builds images from Dockerfiles into local storage, pushes and pulls images to and from registries, and instructs the Container Runtime to spin up running containers. Every 'docker build', 'push', 'pull', and 'run' command you issue is actually carried out by the Daemon.
What is the difference between the container engine and the container runtime?
The container engine (Docker) is the higher-level platform equivalent to a hypervisor for VMs, allowing multiple containers to run on one OS kernel. The container runtime is the lower-level component the Docker Daemon instructs to actually spin up and manage running container instances from a pulled image. The engine orchestrates the workflow; the runtime does the concrete work of launching containers.
How does this framework set me up for learning Kubernetes?
Kubernetes orchestrates containers at scale, so it assumes you already understand how a single container is built, shipped, and run. Mastering Build-Ship-Run gives you the mental model of images, registries, and runtimes that Kubernetes depends on. When you later define Kubernetes pods that reference images pulled from a registry, the flow is exactly the pull-and-run stage you already know, extended across a cluster.
Why should each application have exactly one Dockerfile?
One Dockerfile per application keeps a single source of truth for how that app's image is built. Multiple Dockerfiles for one app create ambiguity about which produces the canonical image, undermining the guarantee that all environments run identically. The Dockerfile's ordered instructions — base OS, dependencies, file copies, run command — fully define the image, so one file per app makes builds repeatable and auditable.
How do I keep my Docker images small and efficient?
Include only the bare-minimum OS image and the exact libraries your application needs — never a full vanilla OS installation. Choose a lean base image, install only required dependencies, and avoid bundling unused packages. This follows the Lightweight Sandbox principle: smaller images pull faster across environments, consume less storage in the registry, and let more containers run densely on a single host.