added new docs for docker...

Author: ajay-dhangar

absolute-beginners/devops-beginner/docker/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Docker & Containers",
+  "position": 5,
+  "link": {
+    "type": "generated-index",
+    "description": "Stop worrying about environment issues. Learn how to package your code, libraries, and dependencies into a single, portable unit that runs anywhere. Docker is a powerful tool that simplifies application deployment and management. Whether you're a developer or a system administrator, mastering Docker will enhance your workflow and enable you to build, ship, and run applications with ease."
+  }
+}

absolute-beginners/devops-beginner/docker/docker-architecture.mdx

@@ -0,0 +1,102 @@
+---
+sidebar_position: 2
+title: "Docker Architecture: Under the Hood"
+sidebar_label: "2. Docker Architecture"
+description: " Learn how Docker's Client-Server architecture works, the role of the Docker Daemon, and how images and containers interact. This foundational knowledge will help you troubleshoot and optimize your Docker workflows."
+---
+
+Docker uses a **Client-Server** architecture. Most beginners think that when they type a command, the terminal "is" Docker. In reality, the terminal is just a remote control talking to a powerful engine running in the background.
+
+## The Three Pillars of Docker
+
+Here is how the components interact when you want to run a container:
+
+```mermaid
+graph LR
+    subgraph "Client (User Interface)"
+    A[docker build]
+    B[docker pull]
+    C[docker run]
+    end
+
+    subgraph "Docker Host (The Engine)"
+    D[Docker Daemon]
+    E[Images]
+    F[Containers]
+    D --> E
+    D --> F
+    end
+
+    subgraph "Registry (Cloud Storage)"
+    G[Docker Hub]
+    H[Private Registry]
+    end
+
+    A --> D
+    B --> G
+    C --> D
+    E --> F
+    D -- Pulls --> G
+```
+
+In this architecture:
+1. **Client:** The command-line tool you use to interact with Docker.
+2. **Docker Host:** The machine where the Docker Daemon runs and manages your containers.
+3. **Registry:** A storage and distribution system for Docker images (like Docker Hub).
+
+## 1. The Docker Client (The Messenger)
+
+The Client is the primary way users interact with Docker. When you type `docker run`, the client sends this command to the **Docker Daemon** using a REST API.
+
+  * **Analogy:** The remote control for your TV.
+
+## 2. The Docker Host (The Engine Room)
+
+This is where the "real" Docker lives. It consists of:
+
+* **Docker Daemon (`dockerd`):** A background service that manages Docker objects like images, containers, networks, and volumes.
+* **Objects:** 
+    * **Images:** Read-only templates used to create containers.
+    * **Containers:** The running instances of images.
+
+## 3. Docker Registry (The Library)
+
+A Registry is a stateless, highly scalable server side application that stores and lets you distribute Docker images.
+
+* **Docker Hub:** The default public registry. It’s the "GitHub of Docker Images."
+* **The Flow:** 
+    1. You **Build** an image on your Host.
+    2. You **Push** it to the Registry.
+    3. Your teammate **Pulls** it from the Registry to their Host.
+
+## The Logic of a Command
+
+When you run `docker run hello-world`, the architecture follows this math:
+
+$$Command \rightarrow Client \rightarrow API \rightarrow Daemon \rightarrow Registry \text{ (if not local)} \rightarrow Container$$
+
+1.  **Client** tells the **Daemon** to run "hello-world".
+2.  **Daemon** checks if the "hello-world" **Image** is in the local **Host** library.
+3.  If **NOT**, the Daemon reaches out to **Docker Hub** (Registry) to download it.
+4.  **Daemon** creates a new **Container** from that image and executes it.
+
+## Why this matters for DevOps
+
+At **CodeHarborHub**, we often separate these parts:
+
+  * Your **Client** might be on your Windows laptop.
+  * Your **Host** might be a powerful Linux server in the cloud (AWS/Azure).
+  * Your **Registry** might be a private storage for your company's secret code.
+
+By separating the "Control" (Client) from the "Execution" (Host), Docker allows us to manage thousands of servers from one single terminal.
+
+## Summary Checklist
+
+  * [x] I understand that the **Client** and **Daemon** can be on different machines.
+  * [x] I know that the **Daemon** is the one that actually manages containers.
+  * [x] I can explain that **Docker Hub** is a type of Registry.
+  * [x] I understand the flow of a `docker run` command.
+
+:::info Note
+On Windows and Mac, "Docker Desktop" runs a tiny, invisible Linux Virtual Machine to act as the **Docker Host**, because the Docker Daemon needs a Linux Kernel to work!
+:::

absolute-beginners/devops-beginner/docker/docker-compose.mdx

@@ -0,0 +1,114 @@
+---
+sidebar_position: 7
+title: "Docker Compose: The Fleet Commander"
+sidebar_label: "7. Docker Compose"
+description: "Learn how to orchestrate multiple containers (Frontend, Backend, DB) using a single YAML file. Understand the key keywords like services, build, ports, and depends_on. Master the essential docker-compose commands to manage your entire stack with ease."
+---
+
+Until now, if you wanted to run a Full-stack app, you had to:
+1. Create a network.
+2. Start the Database container.
+3. Start the Backend container (linking it to the DB).
+4. Start the Frontend container (linking it to the Backend).
+
+That is a lot of typing! **Docker Compose** allows you to write all these instructions in a single `docker-compose.yml` file. When you run `docker-compose up`, Docker reads the file and starts everything in the correct order. It's like being a **Fleet Commander** instead of a solo driver.
+
+## 1. The "Orchestra" Analogy
+
+Think of your containers as **Musicians**:
+* **The Dockerfile:** Is the sheet music for *one* instrument (e.g., just the Violin).
+* **Docker Compose:** Is the **Conductor**. The conductor doesn't play an instrument; they tell every musician when to start, how loud to play, and how to stay in sync.
+
+## 2. The YAML Blueprint
+
+Docker Compose uses **YAML** (Yet Another Markup Language). It is easy to read because it uses indentation instead of curly braces.
+
+Here is a standard `docker-compose.yml` for a **CodeHarborHub** project:
+
+```yaml
+version: '3.8'
+
+services:
+  frontend:
+    build: ./frontend
+    ports:
+      - "3000:3000"
+    depends_on:
+      - backend
+
+  backend:
+    build: ./backend
+    ports:
+      - "5000:5000"
+    environment:
+      - DB_URL=mongodb://database:27017/hub_db
+    depends_on:
+      - database
+
+  database:
+    image: mongo:latest
+    volumes:
+      - hub_data:/data/db
+
+volumes:
+  hub_data:
+```
+
+## 3. The 3 Steps of Compose
+
+To get your entire system running, you only need three steps:
+
+1.  **Define** each service's environment with its own `Dockerfile`.
+2.  **Define** how they connect in the `docker-compose.yml`.
+3.  **Run** `docker-compose up` to start the whole world.
+
+## 4. Key Keywords to Remember
+
+* **services:** These are your containers (e.g., `web`, `api`, `db`).
+* **build:** Tells Docker to look for a `Dockerfile` in a specific folder.
+* **image:** Tells Docker to download a pre-built image instead of building one.
+* **ports:** Maps the Host port to the Container port (just like `-p`).
+* **depends_on:** Tells Docker the order of operations (e.g., "Don't start the Backend until the Database is ready").
+* **environment:** Passes variables (like API keys) into the container.
+
+## The Logic of Orchestration
+
+When you run `docker-compose up`, Docker performs the following "Math":
+
+```mermaid
+graph TD
+    A[Read docker-compose.yml] --> B[Create shared Network]
+    B --> C[Create shared Volumes]
+    C --> D[Pull/Build Images]
+    D --> E[Start Containers in Order]
+    E --> F{Health Check}
+```
+
+$$Total\_Stack = (Net + Vol) + \sum(Service_{1...n})$$
+
+Where:
+
+* **Net:** The shared network for all services.
+* **Vol:** The shared volumes for data persistence.
+* **Service:** Each individual container with its own configuration.
+
+## Essential Compose Commands
+
+| Command | Action |
+| :--- | :--- |
+| `docker-compose up` | Build, create, and start all containers. |
+| `docker-compose up -d` | Run everything in the background (Detached). |
+| `docker-compose ps` | See the status of your entire stack. |
+| `docker-compose logs -f` | Watch the output from all containers at once. |
+| `docker-compose stop` | Stop the services (but keep the containers). |
+| `docker-compose down` | **The Cleanup:** Stop and REMOVE all containers and networks. |
+
+## Summary Checklist
+* [x] I understand that Compose is for **multi-container** apps.
+* [x] I know that `docker-compose.yml` uses YAML indentation.
+* [x] I can explain what `depends_on` does for startup order.
+* [x] I understand that `docker-compose down` wipes the environment clean.
+
+:::success 🎉 Docker Module Complete!
+Congratulations! You have moved from a simple "Hello World" to orchestrating a complex, multi-service architecture. You are now officially a **Container Pro**.
+:::

absolute-beginners/devops-beginner/docker/docker-networking.mdx

@@ -0,0 +1,89 @@
+---
+sidebar_position: 6
+title: "Docker Networking: How Containers Talk to Each Other"
+sidebar_label: "6. Docker Networking"
+description: "Learn about Bridge networks, Host networking, and how to expose your apps to the world. Understand port mapping and service discovery in Docker."
+---
+
+In a modern application, a **React Frontend** needs to talk to a **Node.js API**, which needs to talk to a **MongoDB Database**. If these were three separate physical servers, you would need cables. In Docker, we use **Virtual Networks**.
+
+## 1. The "Gated Community" Analogy
+
+Think of Docker Networking like a **Gated Community**:
+* **The Containers:** These are the houses.
+* **The Bridge Network:** This is the private internal road inside the community. Houses can talk to each other easily using their "Names" (DNS).
+* **Port Mapping:** This is the "Main Gate." If someone from the outside world (the Internet) wants to visit, they must come through a specific gate number.
+
+## 2. The Three Main Network Drivers
+
+Docker provides different "Drivers" depending on how much isolation you need:
+
+### A. Bridge Network (The Default)
+The most common choice for **CodeHarborHub** projects. It creates a private space on your computer.
+* **Key Feature:** Containers can talk to each other using their **Container Name**.
+* **Usage:** `docker run --network my-bridge-net ...`
+
+### B. Host Network
+The container shares the **exact same IP and Ports** as your actual laptop/server. There is no isolation.
+* **Key Feature:** Best for high-performance apps, but dangerous because ports can clash.
+
+### C. None
+The container has no network access at all. Total "Air-gap" security.
+
+## 3. Port Mapping: Opening the Gates
+
+By default, an app running inside a container on port `3000` is invisible to your browser. You must "Map" a port from your **Host** to the **Container**.
+
+**The Formula:** `-p [Host_Port]:[Container_Port]`
+
+```bash
+docker run -p 8080:3000 my-web-app
+```
+
+* **Host Port (8080):** What you type in your browser (`localhost:8080`).
+* **Container Port (3000):** Where the app is actually listening inside the "box."
+
+## 4. Automatic Service Discovery
+
+This is the "Magic" of Docker. If you put two containers on the same user-defined network, you don't need to know their IP addresses\!
+
+```mermaid
+graph LR
+    subgraph "Custom Bridge Network"
+    A[Frontend Container] -- "http://api-server:5000" --> B[Backend Container]
+    B -- "mongodb://db-server:27017" --> C[Database Container]
+    end
+```
+
+Docker acts as a mini **DNS Server**. It knows that `api-server` belongs to the Backend container's IP address. This means you can write your code using friendly names instead of hard-coding IPs, which can change every time you restart the containers.
+
+## Essential Networking Commands
+
+| Command | Action |
+| :--- | :--- |
+| `docker network ls` | See all virtual networks on your machine. |
+| `docker network create hub-net` | Create a new private road for your apps. |
+| `docker network inspect hub-net` | See which containers are currently connected. |
+| `docker network connect hub-net app1` | Add an existing container to a network. |
+
+## The Math of Conflict
+
+If you try to run two containers mapping to the same Host Port, Docker will throw an error:
+
+$$Error = \text{Host\_Port\_8080} \in \text{Already\_In\_Use}$$
+
+**Solution:** Map them to different host ports:
+
+* Container A: `-p 8080:80`
+* Container B: `-p 8081:80`
+
+## Summary Checklist
+
+* [x] I understand that **Bridge** is the default network for isolated apps.
+* [x] I can explain **Port Mapping** (`-p host:container`).
+* [x] I know that containers on the same network can talk using **Names** instead of IPs.
+* [x] I understand that `localhost` inside a container refers to the container itself, not my laptop.
+
+:::info Note
+Never use the default "bridge" network for production. Always create your own named network (`docker network create ...`). Only **named networks** allow containers to look each other up by name!
+:::