# Day 15 - Introduction to Containers and Docker

## 🎯 **1\. Objective**

Before working on real DevOps projects or advanced Docker concepts, it’s essential to first understand:

* What **containers** are
    
* How they differ from **virtual machines (VMs)**
    
* What **Docker** and **Buildah** do in the container world
    

This session focuses purely on **concepts**, not hands-on commands.

---

## 💡 **2\. Background: From Physical Servers → Virtual Machines → Containers**

### 🖥️ **Physical Servers**

* Earlier, organizations ran one application per physical server.
    
* Hardware resources (CPU, RAM, storage) were often **underutilized**.
    
* Maintaining thousands of physical servers was **expensive** and inefficient.
    

### 🧰 **Virtualization**

To improve resource utilization, the concept of **virtualization** was introduced using a **Hypervisor**.

**Hypervisor:**  
A software layer that lets you create **multiple virtual machines (VMs)** on a single physical server.

Each **VM** has:

* Its own **Operating System (OS)**
    
* Its own **applications and dependencies**
    
* Logical isolation from other VMs
    

**Benefits:**

* Better hardware utilization
    
* Isolation between applications
    
* Easier deployment than physical servers
    

**Drawback:**

* Each VM still requires a **full OS**, consuming large amounts of CPU, RAM, and disk.
    
* Even with virtualization, many VMs remain **underutilized** most of the time.
    

---

## ⚙️ **3\. The Problem with Virtual Machines**

Let’s say:

* Physical server = 100 GB RAM, 100 CPUs
    
* You create 4 VMs (25 GB RAM each)
    

Even if one VM’s application only needs 10 GB RAM, the rest (15 GB RAM) stays **idle**.

At scale — say, 1 million VMs — that wasted capacity means **huge financial loss**.

Hence, a more **lightweight** and **resource-efficient** approach was needed.

---

## 🧩 **4\. Solution: Containers**

Containers were introduced to solve these inefficiencies.

**Definition:**

> A container is a **lightweight, standalone package** that includes everything needed to run a piece of software — code, libraries, dependencies, and minimal OS components.

### 🏗️ **How Containers Run**

Containers can be created:

1. **Directly on a physical server**, or
    
2. **On top of a virtual machine**
    

In both cases, you install a **containerization platform** (like **Docker**, **Podman**, or **Buildah**) over the host OS.

---

## ⚖️ **5\. Containers vs Virtual Machines**

| Feature | Virtual Machine | Container |
| --- | --- | --- |
| **OS** | Full guest OS per VM | Shares host OS kernel |
| **Size** | Heavy (GBs) | Lightweight (MBs) |
| **Startup Time** | Minutes | Seconds |
| **Isolation** | Full hardware-level | Process-level (less secure) |
| **Resource Efficiency** | Moderate | Very high |
| **Use Case** | Legacy apps, full isolation | Microservices, cloud-native apps |

📌 **In short:**

> Virtual machines isolate hardware.  
> Containers isolate processes.

---

## 🧠 **6\. Why Containers Are Lightweight**

* Containers **don’t include a full OS** — only minimal system libraries and dependencies.
    
* They **share** the host system’s kernel.
    
* Only necessary components are bundled → drastically smaller image sizes.
    

Example:

* VM image: ~2–3 GB
    
* Container image: ~100–500 MB
    

This makes containers:

* Faster to build
    
* Easier to transfer (“ship”)
    
* Quicker to deploy
    

---

## 📦 **7\. What’s Inside a Container**

A container image includes:

1. **Application code**
    
2. **Application dependencies** (libraries, frameworks)
    
3. **System dependencies** (minimal OS libraries)
    

If additional libraries are needed (e.g., Python, Node.js, Java), they’re added via **base images** (e.g., `python:3.10`, `node:18`, `openjdk:17`).

---

## ⚙️ **8\. How Docker Works**

**Docker** is a **containerization platform** that simplifies container creation and management.

### 🔄 **Docker Lifecycle**

| Stage | Description | Command |
| --- | --- | --- |
| 1️⃣ Write | Define image in a **Dockerfile** | `Dockerfile` |
| 2️⃣ Build | Convert Dockerfile → Image | `docker build` |
| 3️⃣ Run | Launch container from image | `docker run` |

Behind the scenes, **Docker Engine** executes these commands and handles:

* Layered image building
    
* Container lifecycle management
    
* Resource sharing with host OS
    

---

## ⚠️ **9\. Drawbacks of Docker**

While Docker made containers popular, it has a few limitations:

### 🧱 **Single Point of Failure (SPOF)**

* All containers depend on the **Docker Engine daemon**.
    
* If the Docker daemon stops, **all containers stop**.
    

### 🧩 **Layer Complexity**

* Docker builds images in **layers**.
    
* Too many layers can slow builds and consume disk space.
    

---

## 🔧 **10\. Alternative: Buildah**

To overcome Docker’s limitations, **Buildah** was introduced.

### 🏗️ **What Is Buildah?**

> A container image–building tool that doesn’t depend on a daemon like Docker Engine.

### 🔍 **Benefits of Buildah**

* No **single point of failure**
    
* No background daemon
    
* Works well with **Podman** and **Skopeo**
    
* Compatible with **Docker images** (OCI compliant)
    
* Simpler scripting via **shell commands**
    

Unlike Docker (which uses `Dockerfile`), Buildah can create images directly from **shell scripts**.

---

## 🧭 **11\. Real-World Architecture**

### **Model 1: Containers on Physical Server**

```plaintext
Physical Server
 └── OS
     └── Docker Engine / Container Platform
         ├── Container 1
         ├── Container 2
         └── Container 3
```

### **Model 2: Containers on Virtual Machine (Most Common)**

```plaintext
Physical Server (Cloud / Data Center)
 └── Virtual Machine
     └── OS
         └── Docker Engine / Podman / Buildah
             ├── Container 1
             ├── Container 2
             └── Container 3
```

📌 Most organizations today use **Model 2** because:

* They rely on **cloud providers** (AWS, Azure, GCP)
    
* They avoid maintaining physical data centers
    

---

## 🚀 **12\. Why Docker Became So Popular**

* Simple to learn and use (`docker build`, `docker run`)
    
* Strong community support
    
* Easy image sharing through **Docker Hub**
    
* Integrated with orchestration tools like **Kubernetes**
    
* Lightweight and portable — “Build once, run anywhere”
    

---

## 🧾 **13\. Summary Table**

| Concept | Description |
| --- | --- |
| **Container** | Lightweight, isolated runtime for applications |
| **Docker** | Tool/platform to build and manage containers |
| **Dockerfile** | Script to define how to build an image |
| **Image** | Read-only template containing code + dependencies |
| **Container** | Running instance of an image |
| **Buildah** | Daemonless alternative to build container images |
| **Base Image** | Starting OS or runtime layer (e.g., Ubuntu, Alpine) |

---

## ✅ **14\. Final Summary**

* Containers evolved to improve **resource efficiency** over VMs.
    
* Docker popularized containers through **ease of use** and **portability**.
    
* Containers are **lightweight**, **fast**, and **ideal for microservices**.
    
* Docker’s limitations (single point of failure, layer bloat) led to tools like **Buildah** and **Podman**.
    
* Today, containerization is the **foundation of modern DevOps** and **cloud-native computing**.