Docker Basics Explained in Plain Simple Language

Docker — Core Concepts in Plain Words:

Docker:
  A tool that lets you package an app with
  everything it needs so it runs the same way
  everywhere.

Container:
  A live, running version of your app.
  It has its own filesystem, network, and processes,
  but shares the host OS kernel.

Image:
  A read-only template used to create containers.
  Think of it as a snapshot of your app + environment.

Dockerfile:
  A text file with step-by-step instructions
  to build an image.

Registry (e.g., Docker Hub):
  A place to store and share images.

Why Docker matters:
- Ends "works on my machine" problems
- Faster onboarding and deployment
- Lightweight compared to virtual machines
- Easy to ship, scale, and roll back

Docker — Explained Like You're 10:

Imagine you bake a cake.
You want the same cake in every kitchen in the world.

So you write down:
  1. Ingredients
  2. Oven temperature
  3. Baking time

That list is the Dockerfile.
The finished cake is the image.
A slice served on a plate is a container.

Now anyone with the recipe can make the exact
same cake — no matter where they live.

That's Docker in one sentence:
  A recipe that guarantees the same cake
  in every kitchen.

Why it matters:
- Your app runs the same on your laptop
  and in production.
- New team members get set up in minutes.
- Deployment becomes repeatable and safe.

Containers vs Virtual Machines — Plain Simple:

Virtual Machine:
  - Includes a full guest operating system
  - Boots slowly (minutes)
  - Heavier (GBs)
  - Stronger isolation
  - Good for running different OS types

Container:
  - Shares the host OS kernel
  - Boots in seconds
  - Lightweight (MBs)
  - Process-level isolation
  - Great for apps and microservices

One-line summary:
  VMs virtualize hardware.
  Containers virtualize the operating system.

Real-world impact:
  10 containers can easily run on a laptop.
  10 VMs would likely crash it.

When to Use Which:

Use a VM when:
□ You need a different OS than the host
□ You need strong security isolation
□ You are running legacy software
□ You want full system-level control

Use a container when:
□ You are deploying an app or microservice
□ You need fast build/run cycles
□ You want consistent dev and production
□ You are using CI/CD pipelines
□ You want to pack many services on one host

Reality check:
Most modern apps use containers
for deployment and VMs for infrastructure.

Images vs Containers — Plain Simple:

Image:
  - A packaged snapshot of your app
  - Contains code, runtime, libraries, settings
  - Built once, reused many times
  - Does not run by itself

Container:
  - A running instance of an image
  - Has its own process and (optional) writable layer
  - You can start, stop, and delete containers
  - Many containers can run from one image

Analogy:
  Image = recipe card
  Container = cooked dish

Everyday example:
  The official nginx image is downloaded once.
  You can run 3 nginx containers from it,
  each with its own port and config.

Key commands:
  docker build -t myapp:1.0 .   # create image
  docker run -d -p 8080:80 myapp:1.0   # run container

Common Docker Commands:

Images:
  docker images              # list images
  docker build -t myapp .    # build an image
  docker pull nginx          # download an image
  docker rmi          # remove an image

Containers:
  docker ps                  # list running containers
  docker ps -a               # list all containers
  docker run -it ubuntu bash # run a container interactively
  docker run -d -p 8080:80 nginx   # run in background
  docker stop     # stop a container
  docker rm       # remove a container

Logs and shells:
  docker logs     # view logs
  docker exec -it  bash  # open a shell

Rule of thumb:
  Image = "build" and "pull"
  Container = "run" and "stop"

# Dockerfile — a simple Node.js app

# 1. Start from a base image
FROM node:20-alpine

# 2. Set the working directory inside the container
WORKDIR /app

# 3. Copy package files first (better caching)
COPY package*.json ./

# 4. Install dependencies
RUN npm install

# 5. Copy the rest of the source code
COPY . .

# 6. Tell Docker which port the app uses
EXPOSE 3000

# 7. Command to start the app
CMD ["npm", "start"]

# Build the image
docker build -t my-node-app:1.0 .

# Run a container from the image
docker run -d -p 3000:3000 --name my-node my-node-app:1.0

# View logs
docker logs -f my-node

# Stop and remove the container
docker stop my-node
docker rm my-node

# Remove the image (optional)
docker rmi my-node-app:1.0

# What just happened?
# 1. FROM   → started from an official Node.js image
# 2. WORKDIR→ set the folder inside the container
# 3. COPY   → brought our source code in
# 4. RUN    → installed dependencies during build
# 5. EXPOSE → documented the port
# 6. CMD    → told the container how to start

# Volumes — keep data even if the container is deleted

# Named volume
docker volume create mydata
docker run -d -v mydata:/var/lib/mysql mysql:8

# Bind mount (host folder inside the container)
docker run -d -v $(pwd)/site:/usr/share/nginx/html nginx

# Networking — let containers talk to each other

docker network create mynet

docker run -d --name db  --network mynet mysql:8
docker run -d --name app --network mynet -p 3000:3000 my-node-app:1.0

# Inside the "app" container, "db" is reachable
# by hostname: db:3306

Plain simple:
  Volumes keep data safe.
  Networks let containers talk by name.
  Ports let you reach a container from your laptop.

# docker-compose.yml — run multiple containers together

services:
  app:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - db
    environment:
      DB_HOST: db
      DB_USER: user
      DB_PASS: secret

  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: root
    volumes:
      - dbdata:/var/lib/mysql

volumes:
  dbdata:

# Run everything
#   docker compose up -d
#
# See logs
#   docker compose logs -f
#
# Stop everything
#   docker compose down
#
# Rebuild after code changes
#   docker compose up -d --build