Docker Containers vs VMs — ต่างกันยังไง ใช้ตัวไหนดี?Docker Containers vs VMs — What's the Difference, and Which Should You Use?

# เริ่มจาก base image
FROM node:20-alpine

# ตั้ง working directory
WORKDIR /app

# copy package.json แล้วติดตั้ง dependencies
COPY package*.json ./
RUN npm ci --production

# copy source code
COPY . .

# บอกว่า app ใช้ port อะไร
EXPOSE 3000

# คำสั่งรัน app
CMD ["node", "server.js"]

# สร้าง image จาก Dockerfile
docker build -t my-app:v1 .

# ดู images ทั้งหมด
docker images

# รัน container จาก image
docker run -d -p 3000:3000 --name my-app my-app:v1

# ดู container ที่กำลังรัน
docker ps

# หยุด / ลบ container
docker stop my-app
docker rm my-app

# 1. สร้าง VM ใหม่
# 2. ติดตั้ง Ubuntu
# 3. ติดตั้ง Node.js
sudo apt update
sudo apt install nodejs npm

# 4. copy code ไปที่ VM
scp -r ./my-app user@vm-ip:/home/user/

# 5. ติดตั้ง dependencies
cd /home/user/my-app && npm install

# 6. รัน app
node server.js

# ใช้เวลา: 15-30 นาที 😩
# ถ้ามี 3 servers = ทำ 3 รอบ 😩😩😩

# 1. สร้าง image (ครั้งเดียว)
docker build -t my-app:v1 .

# 2. รัน (ที่ไหนก็ได้)
docker run -d -p 3000:3000 my-app:v1

# ใช้เวลา: 1-2 นาที 🎉
# ถ้ามี 3 servers = docker run 3 ที 🎉🎉🎉

# docker-compose.yml
version: '3.8'

services:
  web:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://db:5432/myapp
    depends_on:
      - db
      - redis

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: myapp
      POSTGRES_PASSWORD: secret
    volumes:
      - pgdata:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine

volumes:
  pgdata:

# เปิดทุก service พร้อมกัน
docker compose up -d

# ปิดทุก service
docker compose down

# === Images ===
docker build -t app:v1 .           # สร้าง image
docker images                       # ดู images ทั้งหมด
docker pull nginx:latest            # ดึง image จาก Docker Hub
docker rmi app:v1                   # ลบ image

# === Containers ===
docker run -d -p 8080:80 nginx     # รัน container
docker ps                           # ดู container ที่รันอยู่
docker ps -a                        # ดูทั้งหมด (รวมที่หยุดแล้ว)
docker stop <container_id>          # หยุด
docker rm <container_id>            # ลบ
docker logs <container_id>          # ดู logs
docker exec -it <id> /bin/sh        # เข้าไปใน container

# === Docker Compose ===
docker compose up -d                # เปิดทุก service
docker compose down                 # ปิดทุก service
docker compose logs -f              # ดู logs แบบ realtime

In the previous post we talked about the CI/CD pipeline and how it lets us build, test and deploy automatically.

But have you ever hit this? "It works on my machine, but it breaks on the server." 🤦

The cause is a difference in environment — different OS versions, different libraries, different config — so code that runs happily on your machine falls over on someone else's.

The fix is to make every environment the same, and there are two main ways to do it:

1. Virtual Machines (VMs) — simulate an entire computer
2. Docker Containers — simulate only what the app needs

Let's look at what each one is, how they differ, and when to reach for which.

---

What Is a Virtual Machine (VM)?

A VM (Virtual Machine) is an entire computer simulated in software — it has a virtual CPU, RAM, disk and network, and it runs on a real machine (the Host) through a Hypervisor that allocates resources to each VM. Think of dividing an apartment building into rooms: every VM is independent, each can run a different OS, and if one VM crashes it does not touch the others.

Notice that each VM carries its own Guest OS, which means:

• ✅ Complete separation (isolation is very strong)
• ✅ Different operating systems can run side by side (Windows on a Linux host)
• ❌ But it eats a lot of RAM, CPU and disk
• ❌ Slow to start (a whole OS has to boot)

Popular hypervisors:

• Type 1 (Bare-metal): VMware ESXi, Hyper-V, Proxmox — run directly on the hardware
• Type 2 (Hosted): VirtualBox, VMware Workstation — run on top of an existing OS

---

What Is a Docker Container?

A container simulates only the environment the app needs — no whole OS required! A container shares the kernel with the Host OS and then uses Linux features (namespaces, cgroups) to separate each container's processes, filesystem and network. The result: very light (MB instead of GB), very fast (starts in seconds instead of minutes), and portable (it runs anywhere Docker runs).

Notice that there is no Guest OS — containers share the Host OS kernel, which means:

• ✅ Very light (MB vs GB)
• ✅ Very fast to start (seconds vs minutes)
• ✅ Many containers can run at the same time
• ❌ They must share the same Linux kernel (on Mac/Windows a small VM is hidden underneath)
• ❌ Weaker isolation than a VM

---

VM vs Container, Side by Side

The table below compares VMs and containers across every dimension — notice that containers are faster, lighter and easier to scale on almost every count, but VMs still hold two advantages: stronger isolation (separate kernels) and support for a different OS (running Windows on a Linux host, for instance):

	Virtual Machine	Docker Container
Size	Several GB (a full OS)	A few MB — a few hundred MB
Start-up time	Minutes (an OS boot)	Seconds
Performance	Hypervisor overhead	Close to native
Isolation	Very high (separate OS)	Moderate (shared kernel)
How many you can run	5-20 per machine	100+ per machine
Different OS possible	Yes (Windows on Linux)	No (needs the Linux kernel)
RAM usage	Reserves the whole block	Uses only what it needs
Portability	Hard to move (huge files)	Easy to move (small images)

---

How Does Docker Work?

Docker runs on a client-server architecture — the Docker CLI (the client) sends commands to the Docker Engine (the daemon), which manages images and containers. There are three core concepts to understand, and the OOP analogy is a good one: Dockerfile = source code, Image = class, Container = object:

1. Dockerfile — the Recipe for an Image

A Dockerfile is a text file that says, step by step, how to prepare the environment — start from a base image (Node.js 20, say), copy the source code in, install the dependencies, declare the port, and define the command to run at start-up. It is like a cooking recipe: follow the steps and you get the same result every time:

# start from a base image
FROM node:20-alpine

# set the working directory
WORKDIR /app

# copy package.json, then install dependencies
COPY package*.json ./
RUN npm ci --production

# copy the source code
COPY . .

# declare which port the app uses
EXPOSE 3000

# the command that runs the app
CMD ["node", "server.js"]

2. Image — What the Dockerfile Produces

An image is a snapshot of an environment that is ready to run — the result of a docker build on a Dockerfile. The image holds everything the app needs (OS libs, runtime, code, configs) and can be shared through Docker Hub or a private registry. It is like a burned CD — copy it and run it anywhere:

# build an image from the Dockerfile
docker build -t my-app:v1 .

# list all images
docker images

An image is read-only — just like a class in OOP.

3. Container — the Instance Running From an Image

A container is an image that is actually running — created with docker run. One image can produce many containers, each with its own filesystem, network and process space. It is the object you new from a class in OOP:

# run a container from an image
docker run -d -p 3000:3000 --name my-app my-app:v1

# list the running containers
docker ps

# stop / remove a container
docker stop my-app
docker rm my-app

The relationship:

---

A Real Example: Deploying a Web App

Let's compare the real steps for deploying a web app the VM way (the old way) and the Docker way (the new way) — you will see how much Docker cuts out, and, more importantly, that everyone gets the same environment. No more "but it runs on my machine":

The VM Way (the Old Way)

SSH into the server, install the OS, install the dependencies one by one, configure everything by hand — and if you have 10 servers you repeat it 10 times. Forget a step and it breaks:

# 1. create a new VM
# 2. install Ubuntu
# 3. install Node.js
sudo apt update
sudo apt install nodejs npm

# 4. copy the code to the VM
scp -r ./my-app user@vm-ip:/home/user/

# 5. install dependencies
cd /home/user/my-app && npm install

# 6. run the app
node server.js

# time taken: 15-30 minutes 😩
# with 3 servers = do it 3 times 😩😩😩

The Docker Way

Write the Dockerfile once, then docker build + docker run and you are done — dev, staging and production all get exactly the same environment. Deploying to 10 servers is just docker run ten times (or let K8s handle it for you):

# 1. build the image (once)
docker build -t my-app:v1 .

# 2. run it (anywhere)
docker run -d -p 3000:3000 my-app:v1

# time taken: 1-2 minutes 🎉
# with 3 servers = docker run 3 times 🎉🎉🎉

---

Docker Compose — Running Several Containers at Once

A real app is never a single container — there is a web server + database + cache + message queue + ... Running docker run one at a time, wiring up the network yourself, setting up the volumes yourself, gets messy fast! Docker Compose solves this by declaring every service in one YAML file and starting them all with a single docker compose up:

# docker-compose.yml
version: '3.8'

services:
  web:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://db:5432/myapp
    depends_on:
      - db
      - redis

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: myapp
      POSTGRES_PASSWORD: secret
    volumes:
      - pgdata:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine

volumes:
  pgdata:

# bring every service up together
docker compose up -d

# take every service down
docker compose down

One command, and web + database + cache are all running ✅

---

So When Should You Use Which?

Most of the time the answer is Docker — but there are use cases where a VM is still necessary:

Use a Docker container when:

• 🐳 You want to deploy an app quickly
• 🐳 You want the same environment everywhere (dev = staging = production)
• 🐳 You need to run several microservices
• 🐳 You are working with a CI/CD pipeline
• 🐳 You need to scale up and down fast (Kubernetes)

Use a VM when:

• 🖥️ You need to run a different OS (a Windows app on a Linux host)
• 🖥️ You need very strong security isolation (multi-tenant, compliance)
• 🖥️ You are running a legacy app that requires a specific OS
• 🖥️ You need full control of the OS (kernel tuning, custom drivers)

Use both:

Large organizations usually run both: VMs as the infrastructure layer + containers running on top of the VMs

Cloud providers (AWS, GCP, Azure) use VMs as the backend and then let us run containers on those VMs.

---

The Docker Commands You'll Actually Use — A Summary

These are the Docker commands DevOps engineers use every day — you don't have to memorise them all, just know they exist and reach for docker --help when you need it. The ones you will use most are docker build, docker run, docker ps and docker logs:

# === Images ===
docker build -t app:v1 .           # build an image
docker images                       # list all images
docker pull nginx:latest            # pull an image from Docker Hub
docker rmi app:v1                   # remove an image

# === Containers ===
docker run -d -p 8080:80 nginx     # run a container
docker ps                           # list running containers
docker ps -a                        # list all of them (including stopped)
docker stop <container_id>          # stop
docker rm <container_id>            # remove
docker logs <container_id>          # view the logs
docker exec -it <id> /bin/sh        # get a shell inside the container

# === Docker Compose ===
docker compose up -d                # bring every service up
docker compose down                 # take every service down
docker compose logs -f              # follow the logs in real time

---

Summary

Docker changed how software is deployed for good — from "install it machine by machine and hope it runs" to "build once, run anywhere". Every cloud provider, every CI/CD pipeline, every microservice architecture rests on containers. Learning Docker is one of the first skills a DevOps engineer needs:

• VM = a whole simulated machine (with a Guest OS) → heavy, but high isolation
• Container = only the environment is simulated (kernel shared) → light, fast, portable
• Dockerfile → Image → Container (recipe → CD → player)
• Docker Compose = several containers running together from a single file
• In the real world you use both — VMs as infrastructure, containers running the app
• Docker really does solve "It works on my machine" 🐳

In the next post we will talk about the API Request Lifecycle — when you hit send on a request to a server, what actually happens? 🌐🐕