Tech Tutorials with Piyush Watch original video

Piyush Docker-to-Kubernetes Container Fundamentals Framework

Last updated: 27 July 2026

Map any application deployment scenario onto the Docker build-ship-run methodology so you can containerise, store, and run it correctly across multiple environments.

// TL;DR

The Piyush Docker-to-Kubernetes Container Fundamentals Framework maps any application deployment onto Docker's three-stage Build-Ship-Run methodology: BUILD an image from a Dockerfile, SHIP it via a registry, and RUN it as a container on each target environment. Use it whenever you need to containerise an application from scratch, explain Docker fundamentals, or move from traditional environment-based deployments to a container-based workflow — especially when starting a Kubernetes (CKA) learning path. It eliminates 'it works on my machine' failures by packaging code, libraries, dependencies, and a minimal OS into one shippable unit that runs identically across Dev, Test, and Prod.

Framework

// When should you use the Docker Build-Ship-Run framework?

Use this skill whenever you need to understand, explain, or implement Docker containerisation from scratch — especially when moving from traditional environment-based deployments to a container-based workflow, or when beginning a Kubernetes learning path.

// What do you need before containerising an application?

Application descriptionrequired
What the application does, its language/runtime, and its key dependencies
Target environmentsrequired
The environments the application must run in (e.g. Dev, Test, Prod)
Current deployment pain points
Specific failures or misalignments experienced across environments (optional but sharpens diagnosis)
Registry preference
Which image registry will be used: Docker Hub, Artifact Registry, JFrog Artifactory, Nexus, etc.

// What are the core principles behind Docker's container model?

Build-Ship-Run

Every container workflow has exactly three stages: BUILD the Docker image from a Dockerfile, SHIP it via a registry, and RUN it as a container on each target environment. Never skip or collapse stages.

Package Everything

A container must carry the application code, all libraries, dependencies, and the bare-minimum OS image together as one shippable unit. This is what eliminates 'it works on my machine' failures caused by environment misconfiguration or missing dependencies.

Lightweight Sandbox

Containers are not full operating systems. They include only the packages and libraries the application actually needs — not the full vanilla OS installation — which keeps image sizes small and resource usage optimised.

Shared Infrastructure, Isolated Tenants

Containers share the host OS kernel (like flats sharing a building and land) whereas virtual machines each consume a full isolated OS (like independent houses on separate plots). This shared model minimises resource wastage and allows many applications to run on the same physical server.

Registry as Version Control for Binaries

You must never push a Docker image directly to an environment. A Docker registry (e.g. Docker Hub) plays the same role for binary images that GitHub plays for source code — it provides versioned, trackable, intermediate storage that makes promotion across environments safe and auditable.

One Dockerfile Per Application

Each application has exactly one Dockerfile. The Dockerfile is a set of ordered instructions: specify a base OS image, install dependencies, copy application files, and define the run command. It is the single source of truth for how an image is built.

// How do you apply the Build-Ship-Run framework step by step?

1
Diagnose the environment-promotion problem
Identify whether failures when promoting builds across Dev → Test → Prod are caused by missing dependencies, environment misconfiguration, or library misalignment. If yes, containerisation directly solves this class of problem. Document what was missing in Prod that existed in lower environments.
2
Author the Dockerfile
Create a file named exactly 'Dockerfile' (capital D, no extension — this is the default and best practice). Write ordered instructions: (1) select a base OS image, e.g. ubuntu, (2) install required dependencies/packages, (3) copy application source files from local system into the image, (4) specify the command to run the application. Keep the image minimal — only bare-minimum libraries the application needs.
3
Build the Docker image using 'docker build'
Run 'docker build' on the Docker client. This command is sent to the Docker Daemon (dockerd), which reads the Dockerfile and produces a Docker image stored locally on the Docker host. The image is the shippable, versioned package containing code + dependencies + OS layer.
4
Push the image to a Docker registry using 'docker push'
Never deploy directly from the build host. Use 'docker push' to send the image from local storage to a registry (Docker Hub, Artifact Registry, JFrog Artifactory, Nexus, etc.). Choose the registry the way you choose a Version Control System — it must support versioning and controlled access. This step completes the SHIP phase.
5
Pull the image to each target environment using 'docker pull'
On each target environment (Dev, Test, Prod), the Docker client issues 'docker pull' to the local Docker Daemon, which retrieves the image from the registry. All environments pull the same image — this is what guarantees consistency and eliminates environment-specific failures.
6
Run the container using 'docker run'
Issue 'docker run' on the target environment. The Docker Daemon instructs the container runtime to spin up a running container instance from the pulled image. The application is now live. The container will only consume the CPU, memory, and storage it actually needs — not a fixed allocation like a VM.
7
Validate the architecture against the Docker component model
Confirm the full flow maps correctly: Docker Client → Docker Daemon (dockerd) → local image storage → registry → Docker Daemon on target → Container Runtime → running container. Identify which component handles each of build, push, pull, and run. Any breakage in the pipeline will be traceable to one of these components.

// What do real containerisation scenarios look like?

A Node.js web API works on a developer's laptop and on the test server but crashes on the production server with a missing library error.

This is the classic environment misconfiguration failure that containers solve. Author a Dockerfile that uses a Node base image, installs the exact npm dependencies, copies the application code, and defines the start command. Build the image, push it to Docker Hub, then pull and run the same image on Prod. Because the library is packaged inside the image, the missing-library failure cannot recur.

A team is evaluating whether to use containers or virtual machines for running 20 microservices on a single physical server.

Apply the building-vs-house analogy: 20 VMs would be like 20 independent houses each on their own plot — massive resource wastage with unused CPU and memory per VM. 20 containers are like 20 flats in one building sharing the host OS kernel and infrastructure, each isolated, each using only the resources it needs. Containers are the correct choice for density and resource efficiency.

// What mistakes should you avoid when using Docker?

Pushing a Docker image directly to a production environment without going through a registry — always use a registry as the intermediate, versioned store.
Naming the Dockerfile with a lowercase 'd' or adding an extension — the default name 'Dockerfile' (capital D) is best practice and must be followed unless there is a specific reason to deviate.
Confusing a Docker image with a running container — the image is the shippable package; only 'docker run' converts it into a live running container instance.
Confusing Docker (the platform) with containers (the concept) — Docker is one platform that enables the build-ship-run workflow; alternatives like Podman also exist.
Assuming containers carry a full OS installation — they carry only a bare-minimum OS image with the libraries the application needs, not the full vanilla OS binary set.
Skipping the registry step and trying to move containers directly between environments — you cannot ship containers directly; you ship images via a registry.

// What are the key Docker terms you need to know?

Build-Ship-Run: The three-stage core workflow of Docker: BUILD a Docker image from a Dockerfile, SHIP it through a registry, and RUN it as a container on any target environment.
Dockerfile: A text file containing an ordered set of instructions that tells the Docker Daemon how to construct a Docker image: base OS, dependencies, file copies, and run command. Default name is 'Dockerfile' with a capital D.
Docker Image: The shippable, versioned binary package produced by 'docker build'. Contains the application code, all libraries, dependencies, and a bare-minimum OS image. Images are stored in a registry and converted into containers at runtime.
Docker Container: A running instance of a Docker image. An isolated, lightweight sandbox environment that carries everything an application needs to run, irrespective of the host operating system.
Lightweight Sandbox Environment: Piyush's term for a container — 'lightweight' because it holds only the bare-minimum OS image and required libraries, not a full OS installation, making image sizes small.
Docker Daemon (dockerd): The background service on the Docker host that receives commands from the Docker client and executes them — building images, pushing/pulling to/from registries, and instructing the container runtime to spin up containers.
Docker Registry: An intermediate binary storage system for Docker images, analogous to a Version Control System for source code. Examples: Docker Hub, Artifact Registry, JFrog Artifactory, Nexus. Required for safely promoting images across environments.
Docker Hub: The default Docker image registry bundled with Docker. The first and most common place to push and pull Docker images.
Container Engine: The software layer (equivalent to a hypervisor for VMs) that allows multiple container instances to run on a single OS kernel. Docker is one implementation of a container engine.
Container Runtime: The lower-level component instructed by the Docker Daemon to actually spin up and manage running container instances from a pulled image.
Environment Misconfiguration: Piyush's term for the most frequent cause of build-promotion failures in pre-container workflows: missing libraries, dependencies, or configuration differences between Dev/Test and Prod environments.
Build Promotion: The process of moving a build artifact from one environment to the next (Dev → Test → Prod). Containers solve the misconfiguration failures that traditionally plagued this process.

// FREQUENTLY ASKED QUESTIONS

What is the Docker Build-Ship-Run framework?

The Build-Ship-Run framework is Docker's three-stage container workflow: BUILD a Docker image from a Dockerfile, SHIP it to a registry like Docker Hub, and RUN it as a container on each target environment. Each stage is mandatory and must never be skipped or collapsed. This structure guarantees the same image runs identically across Dev, Test, and Prod, eliminating environment-specific failures.

What is a Docker container versus a Docker image?

A Docker image is the shippable, versioned binary package produced by 'docker build' — it contains your code, libraries, dependencies, and a minimal OS layer. A container is a running instance of that image, created by 'docker run'. The image is the blueprint stored in a registry; the container is the live, isolated sandbox actually executing your application on a host.

How do I containerise an application from scratch?

Write a single Dockerfile with ordered instructions: select a base OS image, install dependencies, copy your application files, and define the run command. Then run 'docker build' to create the image, 'docker push' to send it to a registry, and on each environment run 'docker pull' followed by 'docker run'. All environments pull the same image, so behaviour stays consistent.

How do I fix an app that works on my laptop but crashes in production?

Containerise it. Missing-library and configuration failures in Prod are caused by environment misconfiguration — the exact problem containers solve. Author a Dockerfile that installs the precise dependencies and copies your code, build the image, push it to a registry, then pull and run that same image in Prod. Because dependencies are packaged inside the image, the missing-library failure cannot recur.

How does Docker compare to virtual machines?

Containers share the host OS kernel — like flats sharing one building and land — while VMs each run a full isolated OS, like separate houses on separate plots. This shared model means containers use only the CPU, memory, and storage they need, letting many applications run densely on one server. VMs waste resources per instance, so containers win for density and efficiency.

When should I use containers instead of traditional deployment?

Use containers whenever builds fail on promotion across Dev → Test → Prod due to missing dependencies, library mismatches, or environment misconfiguration. They're also the right choice when running many microservices densely on one server, or when beginning a Kubernetes learning path. If you keep hitting 'it works on my machine' failures, containerisation directly solves that class of problem.

What is a Docker registry and why do I need one?

A Docker registry is intermediate binary storage for images — Docker Hub, Artifact Registry, JFrog Artifactory, or Nexus — that plays the same role for images that GitHub plays for source code. It provides versioned, trackable, auditable storage so you can safely promote images across environments. You must never push an image directly to Prod; always ship through a registry.

What is a Dockerfile and how many do I need?

A Dockerfile is a text file of ordered instructions telling the Docker Daemon how to build an image: base OS, dependency installs, file copies, and the run command. You need exactly one Dockerfile per application — it is the single source of truth. Name it exactly 'Dockerfile' with a capital D and no extension, which is the default and best practice.

What results can I expect after adopting the Build-Ship-Run workflow?

You get identical application behaviour across every environment because all environments pull the same versioned image, eliminating 'it works on my machine' and missing-dependency failures. You also get higher server density since containers use only the resources they need, and an auditable promotion path through the registry. This is the foundation for scaling into Kubernetes orchestration.

What are the Docker components that handle build, push, pull, and run?

The Docker Client issues commands to the Docker Daemon (dockerd), the background service that executes them. The Daemon builds images to local storage, pushes and pulls to and from a registry, and instructs the Container Runtime to spin up running containers. The full flow is: Client → Daemon → local image storage → registry → Daemon on target → Container Runtime → running container.

Can I move a container directly between environments?

No — you cannot ship containers directly. You ship images through a registry. Push the image with 'docker push', then on each target environment pull it with 'docker pull' and instantiate it with 'docker run'. Containers are runtime instances local to a host; only the image is portable, and the registry is the mandatory intermediate store.

// GET THIS SKILL — FREE