Chapter 6: Why Docker, Images and How a Container Is Created

6.2 One image, and what a container is not

By Ravindra Bagale · Last updated: 25 October 2026

Docker builds an image: a packed filesystem plus the command that starts the app. The developer builds it. Operations — the server-side employee — runs that image, on a laptop or on the EC2. They do not re-install PHP by hand on the server and hope the versions match.

  developer laptop                operations on EC2
  Dockerfile + source             does not reinstall PHP by hand
        |                                  |
        +-------- same image tag ----------+
                         |
                    container process

Suppose we are still on the badge. You build badge-php:1.0 from a Dockerfile and push it (section 6.11). The operations employee pulls badge-php:1.0 and runs it. The client server in the Infosys project pulls the same tag. If 1.0 is wrong, they run badge-php:0.9 again. The argument moves from "which apt command did you skip?" to "which tag is live?"

The EC2 still exists. Docker does not replace the virtual machine from the AWS course. The VM is the host. The container is the app box on that host.

Limits. A container is not a full virtual machine. Containers on one host share that host's kernel. You cannot run a Windows kernel inside a Linux container. A container breakout bug is a host problem, so the host still needs patches. Docker does not automatically give you many machines or a public address — that is Kubernetes, later. Data disappears when the container is deleted unless you put it on a volume. Chapter 7 names the volume types. You still do not open a database port to the world because a container made it easy.

Ravi Sir's Cards for this lesson

Revision cardInterview cardComparison card

मराठी cards