added new docs for devOps

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

@@ -0,0 +1,13 @@
+{
+  "label": "Ansible",
+  "position": 9,
+  "link": {
+    "type": "generated-index",
+    "title": "Ansible Configuration Management",
+    "description": "Learn to manage hundreds of servers simultaneously. Master Agentless automation, Playbooks, and YAML-based configuration for CodeHarborHub infrastructure. Ideal for DevOps beginners eager to streamline server management and deployment processes. Start your journey with Ansible and transform your infrastructure management skills!"
+  },
+  "customProps": {
+    "icon": "🤖",
+    "status": "Beginner-Friendly"
+  }
+}

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

@@ -0,0 +1,107 @@
+---
+title: "Ansible Architecture"
+sidebar_label: "2. How it Works"
+sidebar_position: 2
+description: "Understand the internal components of Ansible, including the Control Node, Managed Nodes, and the Push Model. Learn how Ansible uses SSH to communicate and execute tasks across your infrastructure."
+tags: ["ansible", "architecture", "control node", "managed nodes", "ssh", "push model"]
+keywords: ["ansible architecture", "control node", "managed nodes", "ssh communication", "push model"]
+---
+
+To master automation at **CodeHarborHub**, you must understand how Ansible communicates across a network. Unlike other tools that require a "Resident Agent" on every server, Ansible is **Agentless**. It sits on one machine and "talks" to others using standard protocols.
+
+:::info
+This lesson is crucial for understanding how Ansible operates under the hood. It will help you troubleshoot issues and optimize your automation workflows.
+:::
+
+## The Core Components
+
+Ansible’s architecture consists of four primary building blocks that work together to execute your "Industrial Level" automation.
+
+### 1. The Control Node
+This is the machine where Ansible is installed. It is the "Brain" of your operations.
+* **Requirements:** Any Unix-like machine (Linux, macOS). *Note: Windows cannot be a Control Node, but it can be a Managed Node.*
+* **Action:** This is where you write your Playbooks and run the `ansible-playbook` command.
+
+### 2. Managed Nodes (Hosts)
+These are the remote systems (Servers, Network Devices, or Containers) that you are managing with Ansible.
+* **Requirements:** They only need **Python** installed and an **SSH** connection.
+* **Action:** They receive instructions from the Control Node and execute them locally.
+
+### 3. Inventory
+A list of Managed Nodes. It tells Ansible "Who" to talk to. 
+* It can be a simple static file (`hosts.ini`) or a dynamic script that pulls data from AWS or Azure.
+
+### 4. Modules
+The "Tools" in the toolbox. Modules are small programs that Ansible pushes to the Managed Nodes to perform specific tasks (like installing a package or restarting a service).
+
+## The "Push" Model
+
+Most automation tools use a "Pull" model (where servers ask for updates). Ansible uses a **Push Model**.
+
+```mermaid
+sequenceDiagram
+    participant CN as Control Node (Your Laptop)
+    participant I as Inventory File
+    participant MN as Managed Node (AWS EC2)
+
+    CN->>I: Read list of IPs
+    CN->>MN: Establish SSH Connection
+    CN->>MN: Push "Module" (e.g., install_nginx.py)
+    MN->>MN: Execute Module locally
+    MN->>MN: Remove Module (Cleanup)
+    MN-->>CN: Return Result (Changed / OK / Failed)
+```
+
+## Architecture Features
+
+| Feature | Description | Why it matters? |
+| :--- | :--- | :--- |
+| **Agentless** | No software to update or manage on target servers. | Reduces security vulnerabilities and "resource bloat." |
+| **SSH Transport** | Uses standard OpenSSH for secure communication. | No need to open extra firewall ports. |
+| **Facts Engine** | Automatically discovers system info (OS, IP, CPU). | Allows you to write logic like "If OS is Ubuntu, use `apt`." |
+
+## How Modules Work (The Execution)
+
+When you run a task, Ansible doesn't just send a command string. It follows a professional execution lifecycle:
+
+<Tabs>
+<TabItem value="connect" label="1. Connect" default>
+
+Ansible opens an SSH connection to the Managed Node using your SSH keys.
+
+</TabItem>
+<TabItem value="transfer" label="2. Transfer">
+
+It copies the required **Python Module** to a temporary folder on the remote machine.
+
+</TabItem>
+<TabItem value="execute" label="3. Execute">
+
+It runs the Python script on the remote machine. This script checks the current state and makes changes if necessary.
+
+</TabItem>
+<TabItem value="cleanup" label="4. Cleanup">
+
+Once the task is done, Ansible deletes the temporary Python script, leaving the server clean.
+
+</TabItem>
+</Tabs>
+
+## Visualizing the Workflow
+
+```mermaid
+graph LR
+    subgraph "Control Machine"
+    P[Playbook.yml] --> E[Ansible Engine]
+    E --> Inv[Inventory]
+    E --> API[Modules API]
+    end
+
+    E -->|SSH| Web1[Web Server 1]
+    E -->|SSH| Web2[Web Server 2]
+    E -->|SSH| DB[Database Server]
+```
+
+:::info
+Because Ansible is agentless, you can start managing a server the **second** it finishes booting up. There is no "registration" or "handshake" process required.
+:::

absolute-beginners/devops-beginner/ansible/ansible-variables-vault.mdx

@@ -0,0 +1,131 @@
+---
+title: "Variables and Ansible Vault"
+sidebar_label: "5. Variables & Security"
+sidebar_position: 5
+description: "Learn to make your Ansible playbooks dynamic with variables and secure with encrypted Vaults. Perfect for handling different environments and sensitive data!"
+tags: ["Ansible", "Variables", "Vault", "Secrets Management", "Best Practices"]
+keywords: ["Ansible Variables", "Ansible Vault", "Secrets Management", "Dynamic Playbooks", "Industrial Automation"]
+---
+
+Static playbooks are useful, but "Industrial Level" automation requires flexibility and security. In this guide, we will learn how to use **Variables** to handle different environments (Dev/Prod) and **Ansible Vault** to protect sensitive data.
+
+:::tip Why Variables and Vault?
+* **Variables** allow you to write reusable playbooks that can adapt to different scenarios without changing the code.
+* **Ansible Vault** ensures that sensitive information like passwords and API keys are encrypted and safe from prying eyes, even in version control.
+:::
+
+## 1. Using Variables
+
+Variables in Ansible allow you to write one playbook and use it for multiple purposes. Instead of hardcoding a version number or a username, you use a placeholder.
+
+### Where to Define Variables?
+Ansible has a specific "Precedence" (priority) for variables, but these are the most common places:
+
+1.  **Playbook Level:** Directly inside the `.yml` file.
+2.  **Inventory Level:** Inside your `hosts.ini`.
+3.  **File Level:** In a dedicated `group_vars` or `host_vars` folder.
+
+```yaml title="Example: Playbook with Variables"
+---
+- name: Deploy CodeHarborHub App
+  hosts: webservers
+  vars:
+    app_version: "v2.0.4"
+    node_port: 3000
+
+  tasks:
+    - name: Start the application
+      command: "node app.js --port {{ node_port }}"
+```
+
+:::tip Syntax Note
+Always wrap variables in double curly braces `{{ var_name }}`. If the variable starts the line, you must wrap the entire value in quotes: `"{{ var_name }}"`.
+:::
+
+## 2. Ansible Vault (Securing Secrets)
+
+At **CodeHarborHub**, we **never** push plain-text passwords, SSH keys, or SSL certificates to GitHub. **Ansible Vault** is a built-in feature that encrypts these files so they can be safely stored in version control.
+
+### Common Vault Operations
+
+| Action | Command |
+| :--- | :--- |
+| **Create** | `ansible-vault create secrets.yml` |
+| **Edit** | `ansible-vault edit secrets.yml` |
+| **Encrypt Existing** | `ansible-vault encrypt my_passwords.txt` |
+| **Decrypt** | `ansible-vault decrypt secrets.yml` |
+
+### How to use Vault in a Playbook
+
+1.  Create an encrypted file `vars/secrets.yml`:
+    ```yaml title="Example: Encrypted Vault File"
+    db_password: "SuperSecretPassword123"
+    ```
+2.  Reference it in your playbook:
+    ```yaml title="Example: Using Vault in Playbook"
+    - name: Setup Database
+      hosts: dbservers
+      vars_files:
+        - vars/secrets.yml
+    ```
+3.  Run the playbook by providing the password:
+    ```bash title="Running Playbook with Vault"
+    ansible-playbook site.yml --ask-vault-pass
+    ```
+
+In this example, Ansible will prompt you for the vault password before it can read the encrypted variables. This way, you can safely store sensitive information in your repository without risking exposure.
+
+## 3. Facts: The Special Variables
+
+Ansible automatically discovers information about the Managed Node before running any tasks. These are called **Facts**.
+
+```mermaid
+graph LR
+    A[Control Node] -->|Setup Module| B[Managed Node]
+    B -->|Returns JSON| C[Facts: OS, IP, RAM, CPU]
+    C --> D[Use in Playbook: ansible_os_family]
+```
+
+**Example: Conditional Logic using Facts**
+
+```yaml title="Example: Using Facts in Playbook"
+- name: Install Web Server
+  apt:
+    name: apache2
+    state: present
+  when: ansible_os_family == "Debian"
+```
+
+## Comparison: Variables vs. Vault
+
+| Feature | Variables | Ansible Vault |
+| :--- | :--- | :--- |
+| **Visibility** | Plain text / Human readable. | Encrypted / Block of gibberish. |
+| **Purpose** | Configuration (Ports, Paths, Names). | Secrets (Passwords, Keys, Tokens). |
+| **Storage** | Committed directly to Git. | Committed to Git (but encrypted). |
+
+## Industrial Best Practice: `group_vars`
+
+Instead of cluttering your playbook, create a directory structure like this:
+
+```text title="Best Practice: group_vars Directory Structure"
+.
+├── inventory.ini
+├── playbook.yml
+└── group_vars/
+    ├── all.yml          # Variables for all servers
+    ├── webservers.yml   # Specific for web group
+    └── dbservers.yml    # Specific for DB group
+```
+
+Ansible will **automatically** load these variables based on the group names in your inventory! This keeps your playbooks clean and organized, making it easier to manage large infrastructures.
+
+## Final Graduation Challenge
+
+1.  Create a variable file named `user_config.yml`.
+2.  Add a variable `username: chh_admin`.
+3.  Create a playbook that creates a user on your local machine using `{{ username }}`.
+4.  Now, encrypt `user_config.yml` using `ansible-vault`.
+5.  Run the playbook and see how Ansible asks for the password before it can read the file\!
+
+Congratulations! You've just learned how to make your Ansible playbooks dynamic with variables and secure with Vault. This is a crucial step towards becoming an "Industrial Level" DevOps Engineer at CodeHarborHub!

absolute-beginners/devops-beginner/ansible/intro-to-ansible.mdx

@@ -0,0 +1,84 @@
+---
+title: "Introduction to Ansible"
+sidebar_label: "1. What is Ansible?"
+sidebar_position: 1
+description: "Learn the fundamentals of Ansible, the industry-standard agentless automation tool for configuration management. Understand its role in the DevOps lifecycle, its key features, and how it simplifies managing multiple servers. Perfect for Full-Stack Developers and DevOps Engineers at CodeHarborHub looking to streamline their infrastructure management."
+tags: ["ansible", "configuration management", "devops", "automation", "full-stack development"]
+keywords: ["Ansible", "Configuration Management", "DevOps", "Automation", "Agentless", "Idempotent", "YAML", "Playbooks", "SSH"]
+---
+
+As a **Full-Stack Developer** or **DevOps Engineer** at **CodeHarborHub**, you will eventually manage more than just one server. Imagine having to install Node.js, configure Nginx, and create users on **50 different AWS EC2 instances** manually. 
+
+This is where **Ansible** comes in. Ansible is an open-source IT automation engine that automates provisioning, configuration management, and application deployment.
+
+## The "Furniture" Analogy
+
+To understand where Ansible fits in the DevOps lifecycle, compare it to building a house:
+
+* **Terraform:** Builds the "House" (The VPC, the Subnets, the empty EC2 instances).
+* **Ansible:** Installs the "Furniture" and "Utilities" (Installing Node.js, setting up the Database, adding SSH keys for the team).
+
+## Why Ansible? (The 3 Agentless Pillars)
+
+Ansible stands out from other tools like Chef or Puppet because of its simplicity and "Industrial Level" efficiency.
+
+| Feature | Explanation | Benefit |
+| :--- | :--- | :--- |
+| **Agentless** | No software to install on the target servers. | Less overhead and higher security. |
+| **Idempotent** | Only makes changes if the current state doesn't match the desired state. | Safe to run the same script 100 times. |
+| **YAML Based** | Uses "Playbooks" written in simple, human-readable English. | Easy for the whole team to read and edit. |
+
+## Understanding Idempotency
+
+This is the most critical concept in Ansible. If you tell Ansible to "Ensure Nginx is installed," it first checks the server. 
+
+```mermaid
+graph TD
+    A[Run Playbook] --> B{Check Server State}
+    B -- "Nginx exists" --> C[Result: OK / No Change]
+    B -- "Nginx missing" --> D[Action: Install Nginx]
+    D --> E[Result: Changed]
+    C --> F[Next Task]
+    E --> F
+```
+
+In a manual script, running an "install" command twice might cause an error. In Ansible, it simply says **"OK"** and moves on.
+
+## How it Connects: The SSH Secret
+
+Ansible doesn't use a special "calling" system. It uses **SSH (Secure Shell)**, the same tool you use to log into your servers manually.
+
+<Tabs>
+<TabItem value="traditional" label="Traditional Tools" default>
+
+  * Require a "Client" software installed on every server.
+  * Require specific ports to be opened.
+  * High maintenance as you scale.
+
+</TabItem>
+<TabItem value="ansible" label="The Ansible Way">
+
+  * Uses the existing SSH connection.
+  * Works as soon as the server is launched.
+  * **Push Model:** You push configurations from your laptop to the servers.
+
+</TabItem>
+
+</Tabs>
+
+## Essential Vocabulary
+
+Before we move to the next chapter, familiarize yourself with these terms:
+
+1.  **Control Node:** The machine where Ansible is installed (usually your laptop or a CI/CD runner).
+2.  **Managed Nodes:** The remote servers you are managing.
+3.  **Inventory:** A simple list of IP addresses for your Managed Nodes.
+4.  **Playbook:** The YAML file containing your list of automation tasks.
+
+:::info
+Ansible is perfect for **Full-Stack Developers**. You can write a single "Playbook" that sets up your entire MERN stack environment (Linux + Node.js + MongoDB + Nginx) in under 2 minutes.
+:::
+
+## Learning Challenge
+
+Think about a task you do repeatedly on your local Linux machine (like updating packages or cleaning logs). In the next few lessons, we will learn how to turn that manual process into a reusable **Ansible Task**.