Skip to content

Commit e4cc125

Browse files
ajay-dhangarajay-dhangar
authored
Merge pull request #232 from codeharborhub/dev-1
added new docs for devOps
2 parents c27dfc8 + 5ad81d9 commit e4cc125

20 files changed

+1855
-1
lines changed

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

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
{
2+
"label": "Ansible",
3+
"position": 9,
4+
"link": {
5+
"type": "generated-index",
6+
"title": "Ansible Configuration Management",
7+
"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!"
8+
},
9+
"customProps": {
10+
"icon": "🤖",
11+
"status": "Beginner-Friendly"
12+
}
13+
}

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

Lines changed: 107 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,107 @@
1+
---
2+
title: "Ansible Architecture"
3+
sidebar_label: "2. How it Works"
4+
sidebar_position: 2
5+
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."
6+
tags: ["ansible", "architecture", "control node", "managed nodes", "ssh", "push model"]
7+
keywords: ["ansible architecture", "control node", "managed nodes", "ssh communication", "push model"]
8+
---
9+
10+
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.
11+
12+
:::info
13+
This lesson is crucial for understanding how Ansible operates under the hood. It will help you troubleshoot issues and optimize your automation workflows.
14+
:::
15+
16+
## The Core Components
17+
18+
Ansible’s architecture consists of four primary building blocks that work together to execute your "Industrial Level" automation.
19+
20+
### 1. The Control Node
21+
This is the machine where Ansible is installed. It is the "Brain" of your operations.
22+
* **Requirements:** Any Unix-like machine (Linux, macOS). *Note: Windows cannot be a Control Node, but it can be a Managed Node.*
23+
* **Action:** This is where you write your Playbooks and run the `ansible-playbook` command.
24+
25+
### 2. Managed Nodes (Hosts)
26+
These are the remote systems (Servers, Network Devices, or Containers) that you are managing with Ansible.
27+
* **Requirements:** They only need **Python** installed and an **SSH** connection.
28+
* **Action:** They receive instructions from the Control Node and execute them locally.
29+
30+
### 3. Inventory
31+
A list of Managed Nodes. It tells Ansible "Who" to talk to.
32+
* It can be a simple static file (`hosts.ini`) or a dynamic script that pulls data from AWS or Azure.
33+
34+
### 4. Modules
35+
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).
36+
37+
## The "Push" Model
38+
39+
Most automation tools use a "Pull" model (where servers ask for updates). Ansible uses a **Push Model**.
40+
41+
```mermaid
42+
sequenceDiagram
43+
participant CN as Control Node (Your Laptop)
44+
participant I as Inventory File
45+
participant MN as Managed Node (AWS EC2)
46+
47+
CN->>I: Read list of IPs
48+
CN->>MN: Establish SSH Connection
49+
CN->>MN: Push "Module" (e.g., install_nginx.py)
50+
MN->>MN: Execute Module locally
51+
MN->>MN: Remove Module (Cleanup)
52+
MN-->>CN: Return Result (Changed / OK / Failed)
53+
```
54+
55+
## Architecture Features
56+
57+
| Feature | Description | Why it matters? |
58+
| :--- | :--- | :--- |
59+
| **Agentless** | No software to update or manage on target servers. | Reduces security vulnerabilities and "resource bloat." |
60+
| **SSH Transport** | Uses standard OpenSSH for secure communication. | No need to open extra firewall ports. |
61+
| **Facts Engine** | Automatically discovers system info (OS, IP, CPU). | Allows you to write logic like "If OS is Ubuntu, use `apt`." |
62+
63+
## How Modules Work (The Execution)
64+
65+
When you run a task, Ansible doesn't just send a command string. It follows a professional execution lifecycle:
66+
67+
<Tabs>
68+
<TabItem value="connect" label="1. Connect" default>
69+
70+
Ansible opens an SSH connection to the Managed Node using your SSH keys.
71+
72+
</TabItem>
73+
<TabItem value="transfer" label="2. Transfer">
74+
75+
It copies the required **Python Module** to a temporary folder on the remote machine.
76+
77+
</TabItem>
78+
<TabItem value="execute" label="3. Execute">
79+
80+
It runs the Python script on the remote machine. This script checks the current state and makes changes if necessary.
81+
82+
</TabItem>
83+
<TabItem value="cleanup" label="4. Cleanup">
84+
85+
Once the task is done, Ansible deletes the temporary Python script, leaving the server clean.
86+
87+
</TabItem>
88+
</Tabs>
89+
90+
## Visualizing the Workflow
91+
92+
```mermaid
93+
graph LR
94+
subgraph "Control Machine"
95+
P[Playbook.yml] --> E[Ansible Engine]
96+
E --> Inv[Inventory]
97+
E --> API[Modules API]
98+
end
99+
100+
E -->|SSH| Web1[Web Server 1]
101+
E -->|SSH| Web2[Web Server 2]
102+
E -->|SSH| DB[Database Server]
103+
```
104+
105+
:::info
106+
Because Ansible is agentless, you can start managing a server the **second** it finishes booting up. There is no "registration" or "handshake" process required.
107+
:::

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

Lines changed: 131 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,131 @@
1+
---
2+
title: "Variables and Ansible Vault"
3+
sidebar_label: "5. Variables & Security"
4+
sidebar_position: 5
5+
description: "Learn to make your Ansible playbooks dynamic with variables and secure with encrypted Vaults. Perfect for handling different environments and sensitive data!"
6+
tags: ["Ansible", "Variables", "Vault", "Secrets Management", "Best Practices"]
7+
keywords: ["Ansible Variables", "Ansible Vault", "Secrets Management", "Dynamic Playbooks", "Industrial Automation"]
8+
---
9+
10+
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.
11+
12+
:::tip Why Variables and Vault?
13+
* **Variables** allow you to write reusable playbooks that can adapt to different scenarios without changing the code.
14+
* **Ansible Vault** ensures that sensitive information like passwords and API keys are encrypted and safe from prying eyes, even in version control.
15+
:::
16+
17+
## 1. Using Variables
18+
19+
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.
20+
21+
### Where to Define Variables?
22+
Ansible has a specific "Precedence" (priority) for variables, but these are the most common places:
23+
24+
1. **Playbook Level:** Directly inside the `.yml` file.
25+
2. **Inventory Level:** Inside your `hosts.ini`.
26+
3. **File Level:** In a dedicated `group_vars` or `host_vars` folder.
27+
28+
```yaml title="Example: Playbook with Variables"
29+
---
30+
- name: Deploy CodeHarborHub App
31+
hosts: webservers
32+
vars:
33+
app_version: "v2.0.4"
34+
node_port: 3000
35+
36+
tasks:
37+
- name: Start the application
38+
command: "node app.js --port {{ node_port }}"
39+
```
40+
41+
:::tip Syntax Note
42+
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 }}"`.
43+
:::
44+
45+
## 2. Ansible Vault (Securing Secrets)
46+
47+
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.
48+
49+
### Common Vault Operations
50+
51+
| Action | Command |
52+
| :--- | :--- |
53+
| **Create** | `ansible-vault create secrets.yml` |
54+
| **Edit** | `ansible-vault edit secrets.yml` |
55+
| **Encrypt Existing** | `ansible-vault encrypt my_passwords.txt` |
56+
| **Decrypt** | `ansible-vault decrypt secrets.yml` |
57+
58+
### How to use Vault in a Playbook
59+
60+
1. Create an encrypted file `vars/secrets.yml`:
61+
```yaml title="Example: Encrypted Vault File"
62+
db_password: "SuperSecretPassword123"
63+
```
64+
2. Reference it in your playbook:
65+
```yaml title="Example: Using Vault in Playbook"
66+
- name: Setup Database
67+
hosts: dbservers
68+
vars_files:
69+
- vars/secrets.yml
70+
```
71+
3. Run the playbook by providing the password:
72+
```bash title="Running Playbook with Vault"
73+
ansible-playbook site.yml --ask-vault-pass
74+
```
75+
76+
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.
77+
78+
## 3. Facts: The Special Variables
79+
80+
Ansible automatically discovers information about the Managed Node before running any tasks. These are called **Facts**.
81+
82+
```mermaid
83+
graph LR
84+
A[Control Node] -->|Setup Module| B[Managed Node]
85+
B -->|Returns JSON| C[Facts: OS, IP, RAM, CPU]
86+
C --> D[Use in Playbook: ansible_os_family]
87+
```
88+
89+
**Example: Conditional Logic using Facts**
90+
91+
```yaml title="Example: Using Facts in Playbook"
92+
- name: Install Web Server
93+
apt:
94+
name: apache2
95+
state: present
96+
when: ansible_os_family == "Debian"
97+
```
98+
99+
## Comparison: Variables vs. Vault
100+
101+
| Feature | Variables | Ansible Vault |
102+
| :--- | :--- | :--- |
103+
| **Visibility** | Plain text / Human readable. | Encrypted / Block of gibberish. |
104+
| **Purpose** | Configuration (Ports, Paths, Names). | Secrets (Passwords, Keys, Tokens). |
105+
| **Storage** | Committed directly to Git. | Committed to Git (but encrypted). |
106+
107+
## Industrial Best Practice: `group_vars`
108+
109+
Instead of cluttering your playbook, create a directory structure like this:
110+
111+
```text title="Best Practice: group_vars Directory Structure"
112+
.
113+
├── inventory.ini
114+
├── playbook.yml
115+
└── group_vars/
116+
├── all.yml # Variables for all servers
117+
├── webservers.yml # Specific for web group
118+
└── dbservers.yml # Specific for DB group
119+
```
120+
121+
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.
122+
123+
## Final Graduation Challenge
124+
125+
1. Create a variable file named `user_config.yml`.
126+
2. Add a variable `username: chh_admin`.
127+
3. Create a playbook that creates a user on your local machine using `{{ username }}`.
128+
4. Now, encrypt `user_config.yml` using `ansible-vault`.
129+
5. Run the playbook and see how Ansible asks for the password before it can read the file\!
130+
131+
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‎

Lines changed: 84 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
1+
---
2+
title: "Introduction to Ansible"
3+
sidebar_label: "1. What is Ansible?"
4+
sidebar_position: 1
5+
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."
6+
tags: ["ansible", "configuration management", "devops", "automation", "full-stack development"]
7+
keywords: ["Ansible", "Configuration Management", "DevOps", "Automation", "Agentless", "Idempotent", "YAML", "Playbooks", "SSH"]
8+
---
9+
10+
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.
11+
12+
This is where **Ansible** comes in. Ansible is an open-source IT automation engine that automates provisioning, configuration management, and application deployment.
13+
14+
## The "Furniture" Analogy
15+
16+
To understand where Ansible fits in the DevOps lifecycle, compare it to building a house:
17+
18+
* **Terraform:** Builds the "House" (The VPC, the Subnets, the empty EC2 instances).
19+
* **Ansible:** Installs the "Furniture" and "Utilities" (Installing Node.js, setting up the Database, adding SSH keys for the team).
20+
21+
## Why Ansible? (The 3 Agentless Pillars)
22+
23+
Ansible stands out from other tools like Chef or Puppet because of its simplicity and "Industrial Level" efficiency.
24+
25+
| Feature | Explanation | Benefit |
26+
| :--- | :--- | :--- |
27+
| **Agentless** | No software to install on the target servers. | Less overhead and higher security. |
28+
| **Idempotent** | Only makes changes if the current state doesn't match the desired state. | Safe to run the same script 100 times. |
29+
| **YAML Based** | Uses "Playbooks" written in simple, human-readable English. | Easy for the whole team to read and edit. |
30+
31+
## Understanding Idempotency
32+
33+
This is the most critical concept in Ansible. If you tell Ansible to "Ensure Nginx is installed," it first checks the server.
34+
35+
```mermaid
36+
graph TD
37+
A[Run Playbook] --> B{Check Server State}
38+
B -- "Nginx exists" --> C[Result: OK / No Change]
39+
B -- "Nginx missing" --> D[Action: Install Nginx]
40+
D --> E[Result: Changed]
41+
C --> F[Next Task]
42+
E --> F
43+
```
44+
45+
In a manual script, running an "install" command twice might cause an error. In Ansible, it simply says **"OK"** and moves on.
46+
47+
## How it Connects: The SSH Secret
48+
49+
Ansible doesn't use a special "calling" system. It uses **SSH (Secure Shell)**, the same tool you use to log into your servers manually.
50+
51+
<Tabs>
52+
<TabItem value="traditional" label="Traditional Tools" default>
53+
54+
* Require a "Client" software installed on every server.
55+
* Require specific ports to be opened.
56+
* High maintenance as you scale.
57+
58+
</TabItem>
59+
<TabItem value="ansible" label="The Ansible Way">
60+
61+
* Uses the existing SSH connection.
62+
* Works as soon as the server is launched.
63+
* **Push Model:** You push configurations from your laptop to the servers.
64+
65+
</TabItem>
66+
67+
</Tabs>
68+
69+
## Essential Vocabulary
70+
71+
Before we move to the next chapter, familiarize yourself with these terms:
72+
73+
1. **Control Node:** The machine where Ansible is installed (usually your laptop or a CI/CD runner).
74+
2. **Managed Nodes:** The remote servers you are managing.
75+
3. **Inventory:** A simple list of IP addresses for your Managed Nodes.
76+
4. **Playbook:** The YAML file containing your list of automation tasks.
77+
78+
:::info
79+
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.
80+
:::
81+
82+
## Learning Challenge
83+
84+
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**.

0 commit comments

Comments
 (0)