Ashok IT Docker & Kubernetes Containerization Method

Last updated: 28 September 2026

Transform any application deployment problem into a portable, environment-agnostic container workflow using Docker and Kubernetes, eliminating version conflicts and manual environment setup forever.

// TL;DR

The Ashok IT Docker & Kubernetes Containerization Method is a 10-step framework for packaging any application—code plus its exact dependencies—into a portable Docker Image that runs identically across every environment. Follow the pipeline: Docker File → Docker Image → Docker Registry → Docker Container. Use it whenever you need to containerize a new app, migrate an existing one, troubleshoot 'works on my machine' environmental issues, or design a Docker/Kubernetes CI/CD pipeline. It eliminates manual software installation and version conflicts by making Docker Engine the only software humans install on any host machine.

Framework

// When should you use the Docker & Kubernetes containerization method?

Use this skill whenever you need to containerize an application, troubleshoot environment-related deployment failures, or design a Docker/Kubernetes-based CI/CD pipeline. Also apply it when onboarding a project to Docker for the first time or when explaining containerization concepts to a team.

// What do you need before containerizing an application?

Application Tech Stackrequired
The specific technologies and their versions used in the project (e.g., Angular 13, Java 17, MySQL 8.5, Tomcat 9.0)
Application Layersrequired
Which layers exist in the application: front end, back end, and/or database
Target Environmentsrequired
The list of environments where the application must run (e.g., Dev, SIT, UAT, Pilot, Prod)
Deployment Goalrequired
What the user is trying to achieve — containerize a new app, migrate an existing one, set up Kubernetes orchestration, etc.
Host Machine Type
Windows or Linux, physical or virtual, cloud provider if applicable (e.g., AWS EC2)

// What core principles make Docker containerization work?

Containerization

Package application code plus required dependencies as a single unit for execution. This single unit is called a Docker Image. Once created, it can run in any computer without bothering about underlying softwares.

Life Without Docker vs. Life With Docker

Without Docker, every environment requires manual software installation, version management, and repeated setup — leading to version conflicts and environmental issues. With Docker, the software installation is taken care of by Docker, not by humans, eliminating inconsistency across environments.

Docker Architecture Pipeline

The four-stage pipeline is: Docker File → Docker Image → Docker Registry → Docker Container. Every containerization effort follows this exact sequence: write instructions, build image, store image, run container.

Every Container Is a Virtual Machine

Docker internally uses virtualization. Every Docker container is one Linux virtual machine created on the host machine, independent from the host OS. When you delete the container, that virtual machine is deleted.

Platform Independence

Docker is platform independent. You can run the Docker image in a Windows machine or a Linux machine. There is no restriction on where containers execute, as long as Docker Engine is installed.

Dependencies, Not Softwares

The required softwares to run an application — Angular, Java, Tomcat, MySQL — are called dependencies of the application. Docker manages these dependencies so the human operator does not have to install them manually on each machine.

One Image, Any Number of Containers

With one Docker image you can create any number of containers. There is no limit. You can run the same image multiple times to create multiple containers, or run different images to create different containers on the same machine.

// How do you containerize an application step by step?

1
Identify the Application Tech Stack and Dependencies
List every layer of the application (front end, back end, database) and its exact version. These are the dependencies of the application. Example: Angular 13, Java 17, Tomcat 9.0, MySQL 8.5. Do not proceed until every dependency version is confirmed — version conflicts are the primary cause of environmental issues.
2
Map the Target Environments
List all environments where the application must run: Dev (developers integration testing), SIT (system integration testing by testers), UAT (user acceptance testing by client), Pilot (pre-production), Prod (live environment). This determines the scale of the deployment problem Docker must solve.
3
Write the Docker File
Create a Docker File containing the set of instructions to build the Docker Image. Specify: base OS (e.g., Linux), all dependencies and their exact versions, the location of the application code (e.g., JAR or WAR file), and runtime configuration. This file is the single source of truth — if a version changes, you change it only here, then rebuild the image. In some projects developers write the Docker File; in others DevOps engineers do. Both should know how.
4
Build the Docker Image
Use the Docker File to build the Docker Image. The Docker Image is a package which contains code plus dependencies. Run: `docker build -t <image-name> .` from the directory containing the Docker File. Verify with `docker images` to confirm the image appears in the local image list.
5
Push the Docker Image to a Docker Registry
Store the Docker Image in a Docker Registry so it can be pulled and run in any environment. Options include: Docker Hub (public/private), Nexus Repository, JFrog Repository, AWS ECR (Elastic Container Registry). Use `docker push <image-name>` after logging in. Public images can be pulled by anyone; private images require authentication.
6
Provision Target Machines with Docker Engine Only
On each target environment machine (Dev, SIT, UAT, Pilot, Prod), install only Docker software — nothing else. Do NOT install Angular, Java, Tomcat, MySQL, or any application dependency manually. Docker Engine is the only prerequisite. On Linux (AWS EC2 Amazon Linux): `sudo yum update`, `sudo yum install docker -y`, `sudo service docker start`, add user to docker group with `sudo usermod -aG docker ec2-user`, then reconnect the session.
7
Pull the Docker Image to Each Environment
On each environment machine, pull (download) the Docker Image from the registry: `docker pull <image-name-or-id>`. Verify with `docker images` to confirm the image is available locally. Pull is equivalent to downloading the image to that machine.
8
Run the Docker Image to Create Docker Containers
Execute `docker run <image-name-or-id>` on the environment machine. When you run the Docker Image, a Docker Container will be created. The Docker Container is a Linux virtual machine where the application executes with all required dependencies. You can run the same image multiple times to create multiple containers. Verify running containers with `docker ps`.
9
Manage and Maintain Containers
Use these commands: `docker ps` — display list of running containers. `docker images` — display list of available images. `docker stop <container-id>` — stop a running container. `docker rm <container-id>` — delete a container. `docker rmi <image-id-or-name>` — delete an image. If code or dependencies change, update the Docker File, rebuild the Docker Image, push to registry, and rerun — do not reinstall softwares manually.
10
Handle Version Upgrades via Docker File Only
If a dependency version must change (e.g., Java 17 to Java 21, Angular 13 to Angular 14), change only the instruction in the Docker File. Then rebuild the Docker Image and rerun in all environments. Do NOT uninstall and reinstall softwares manually across all machines — that is the 'life without Docker' problem this entire methodology is designed to eliminate.

// What does Docker containerization look like in real projects?

A team has a three-layer web application (React frontend, Python backend, PostgreSQL database) that must be deployed across 8 environments. Currently they manually install Node, Python, and PostgreSQL on every machine, causing frequent version conflicts between Dev and SIT.

Identify the tech stack: React 18, Python 3.11, PostgreSQL 15. Write a Docker File specifying all three dependencies and the application code location. Build a Docker Image packaging code plus dependencies as a single unit. Push the image to Docker Hub or AWS ECR. On all 8 environment machines, install only Docker Engine. Pull and run the Docker Image on each machine — Docker takes care of the software installation. When a version conflict is reported, fix it in the Docker File, rebuild the image, rerun. Environmental issues are eliminated because the same image runs identically everywhere.

A DevOps engineer needs to deploy a microservice to 20 cloud machines and is worried about manual setup time and human error.

Instead of installing application dependencies on all 20 machines, write a single Docker File once. Build the Docker Image once. Store it in a registry. On each of the 20 machines, install Docker Engine, then run `docker pull` and `docker run`. Twenty containers are created in the same time it previously took to manually set up one environment. If a mistake is discovered, fix the Docker File, rebuild, redeploy — human error is contained to a single file, not spread across 20 machines.

// What mistakes should you avoid when using Docker?

Installing application dependencies (Java, Angular, MySQL, etc.) manually on machines alongside Docker — this defeats containerization entirely. The only software that should be manually installed on a host machine is Docker Engine.
Using the wrong software version in the Docker File — version conflicts are the primary environmental issue Docker solves, so specify exact versions (not 'latest') for every dependency in the Docker File.
Storing Docker Images only locally and not pushing to a Docker Registry — without pushing to Docker Hub, AWS ECR, Nexus, or JFrog, images cannot be pulled and reused across multiple environments.
Forgetting to add the operating system user to the docker group after installation — on Linux machines, you must run `sudo usermod -aG docker <username>` and reconnect the session, otherwise Docker commands will fail for that user.
Blaming code when the real issue is an environmental issue — the code working in one environment and not another is almost always a dependency version mismatch, not a code bug. Docker eliminates this confusion by standardizing the environment inside the container.
Treating Docker as a DevOps-only tool — both developers and DevOps engineers should know how to write Docker Files and build Docker Images, since in some projects developers are responsible for the Docker File.
Manually uninstalling and reinstalling softwares to handle version upgrades across multiple environments — always handle version changes by editing the Docker File, rebuilding the Docker Image, and rerunning containers.

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

Containerization: Packaging application code plus required dependencies as a single unit for execution. This is the core purpose of Docker.
Docker File: A file containing a set of instructions to build a Docker Image. It specifies where the application code is and what dependencies (softwares) are required to run the application. It is the single source of truth for environment configuration.
Docker Image: A package which contains code plus dependencies. Created from a Docker File, it is the single unit that can be stored in a registry and run in any computer.
Docker Registry: A place where Docker Images are stored for reuse. Examples include Docker Hub, Nexus Repository, JFrog Repository, and AWS ECR (Elastic Container Registry).
Docker Hub: The default public Docker Registry (hub.docker.com) where Docker Images can be stored and pulled. Images can be made public or private.
Docker Container: Created when a Docker Image is run. Every Docker Container is a Linux virtual machine on the host machine inside which the application executes with all required dependencies. When the container is deleted, the virtual machine is deleted.
Docker Engine: The Docker software that must be installed on any host machine in order to pull and run Docker Images. It is the only software that needs to be manually installed — Docker Engine then manages all other dependencies inside containers.
Dependencies: The softwares required to run an application — for example Angular, Java, Tomcat, MySQL. In containerization, dependencies are packaged inside the Docker Image so they do not need to be manually installed on host machines.
Application Tech Stack: The specific technologies and exact versions chosen to build an application's front end, back end, and database layers. For example: Angular 13, Java 17, MySQL 8.5, Tomcat 9.0.
Environmental Issues: The real-time problem where code working in one environment (e.g., Dev) does not work in another (e.g., SIT) due to differences in installed software versions. Docker eliminates environmental issues by standardizing dependencies inside containers.
Application Environments: The multiple deployment stages through which an application passes before going live: Dev (developer integration testing), SIT (system integration testing), UAT (user acceptance testing), Pilot (pre-production), Prod (live environment).
Push Operation: The act of storing a Docker Image into a Docker Registry (e.g., Docker Hub) after building it, so it can be pulled and run in multiple systems in the future.
Pull Operation: The act of downloading a Docker Image from a Docker Registry to a local machine in order to run it. Equivalent to `docker pull <image-name>`.
Virtualization: The concept Docker uses internally to create containers. Running one operating system inside another operating system. Every Docker container is a Linux virtual machine running on the host machine, independent of the host OS.
Docker ps: The Docker command used to display the list of Docker Containers currently running in the system.
Docker images: The Docker command used to display the list of Docker Images currently available in the system.
AWS ECR: Amazon Elastic Container Registry — an AWS cloud service used as an alternative to Docker Hub for storing Docker Images.

// FREQUENTLY ASKED QUESTIONS

What is containerization in Docker?

Containerization is packaging application code plus all its required dependencies as a single unit for execution, called a Docker Image. Once created, that image can run on any computer with Docker Engine installed—without manually installing Angular, Java, MySQL, or any other software. It eliminates version conflicts and inconsistency across Dev, SIT, UAT, and Prod environments.

What is a Docker File versus a Docker Image?

A Docker File is a set of instructions to build a Docker Image—it specifies the base OS, exact dependency versions, and the location of your application code. A Docker Image is the resulting package containing code plus dependencies. You write the Docker File once, then build the image from it with `docker build`. The Docker File is the single source of truth for your environment.

How do I containerize an application with Docker?

Identify your tech stack and exact dependency versions, write a Docker File specifying the base OS, dependencies, and code location, then run `docker build -t <image-name> .` to create the image. Push it to a registry like Docker Hub or AWS ECR with `docker push`. On each target machine, install only Docker Engine, then `docker pull` and `docker run` to create containers.

How do I handle a version upgrade across multiple environments?

Change only the instruction in the Docker File—for example, update Java 17 to Java 21—then rebuild the Docker Image, push it to the registry, and rerun containers on all environments. Never uninstall and reinstall software manually across machines. Editing one Docker File replaces the entire 'life without Docker' problem of repeating setup on every machine.

How does Docker compare to manually installing software on each environment?

Manual installation requires setting up Angular, Java, Tomcat, and MySQL on every machine, causing version conflicts and 'works on my machine' failures. Docker installs only Docker Engine per host and lets one image run identically everywhere. Human error is contained to a single Docker File instead of spread across 20 machines, and environmental issues disappear because dependencies are standardized inside the container.

When should I use Docker containerization?

Use it whenever you need to containerize a new application, migrate an existing one, troubleshoot environment-related deployment failures, or design a Docker/Kubernetes CI/CD pipeline. It's also ideal when onboarding a project to Docker for the first time, deploying across many environments (Dev, SIT, UAT, Pilot, Prod), or explaining containerization concepts to a team.

What results can I expect after adopting Docker containerization?

You'll eliminate version conflicts and 'works in Dev but not SIT' environmental issues, since the same image runs identically everywhere. Deployment time drops dramatically—20 containers can be created in the time it once took to set up one environment manually. Human error is contained to a single Docker File, and version upgrades become a one-file edit instead of a machine-by-machine reinstall.

Is a Docker container the same as a virtual machine?

Docker internally uses virtualization, and every Docker container is essentially one Linux virtual machine created on the host, independent of the host OS. When you delete the container, that virtual machine is deleted. However, containers are lightweight and share the host kernel, so you can run many from one image with no limit on the same machine.

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

A Docker Registry is where Docker Images are stored so they can be pulled and run across multiple environments. Options include Docker Hub, Nexus, JFrog, and AWS ECR. Without pushing to a registry, images stay local and can't be reused elsewhere—defeating the whole point of building once and running everywhere.

Do developers or DevOps engineers write the Docker File?

Both should know how. In some projects developers write the Docker File; in others DevOps engineers do. Treating Docker as a DevOps-only tool is a common mistake—since developers are sometimes responsible for the Docker File, everyone on the team benefits from understanding how to write one and build images.

Why does my code work in Dev but fail in SIT?

This is almost always an environmental issue—a dependency version mismatch between machines—not a code bug. When the same code behaves differently across environments, the installed software versions differ. Docker eliminates this confusion by packaging exact dependency versions inside the container so the environment is identical everywhere.

What software do I need to install on a target machine to run a Docker container?

Only Docker Engine. You should never manually install application dependencies like Java, Angular, Tomcat, or MySQL on host machines—Docker Engine manages all of those inside the container. On Linux (AWS EC2 Amazon Linux) install with `sudo yum install docker -y`, start it, then add your user to the docker group with `sudo usermod -aG docker <username>`.

// GET THIS SKILL — FREE